Offline-First Architecture for Mobile: Local Storage and Sync Protocols

The local store is the application

In an offline-first design every screen reads from and writes to the local database. Network synchronisation happens in the background and updates the local store, which the interface observes. This inverts the usual model where the interface waits on a request.

The benefit is latency and resilience: interactions are immediate and work identically whether connectivity exists or not. The cost is that the application must now handle data that is local but not yet synchronised, and must be honest with the user about that state.

Users need to see sync status, because a field technician needs to know whether a completed inspection has actually reached the server before leaving a site.

• Read and write locally, never block the interface on the network.
• Surface pending, synced and failed states clearly to the user.
• Let unsynchronised work continue across application restarts.
• Treat the network as an enhancement, not a dependency.

Choosing local storage

SQLite remains the default choice for structured local data because it supports queries, transactions and migrations, and it is available on every platform. WatermelonDB and similar libraries add reactive queries and sync primitives on top, which reduces the amount of bespoke code needed.

For simple key-value preferences, platform storage is sufficient. For larger binary assets such as images or documents, store files on the filesystem and keep only references in the database, so the database stays small and fast.

Migrations matter more than they appear. An application that has been on a device for two years must upgrade its local schema in place, with tests covering every historical version that could still be installed in the field.

Designing the sync protocol

The simplest workable protocol is change-based: the client tracks local changes with a monotonically increasing local sequence, sends them in batches, and pulls changes since the last server cursor. The server assigns a global ordering and returns accepted changes plus any rejected ones with reasons.

Batching, compression and delta payloads keep sync efficient on poor connections. Sync should be resumable: an interrupted batch must not corrupt state, which means the server must be idempotent per change identifier and the client must record what has been acknowledged.

Pull should be paginated with a durable cursor. Asking the server for everything changed since a timestamp is fragile, because clocks differ; a server-assigned cursor is stable and comparable.

• Track local changes with a monotonic local sequence.
• Make the server idempotent per change identifier.
• Use a server-assigned cursor rather than client timestamps.
• Support resumable batches and compression.

Conflict resolution in the field

Conflicts are inevitable when the same record is edited offline on two devices. The resolution strategy must be chosen per entity rather than globally: last-writer-wins per field is adequate for most operational data, while anything involving money, stock or approvals needs a stricter rule such as server-authoritative validation.

Prefer field-level rather than record-level last-writer-wins, because record-level resolution discards unrelated edits made on another device. Preserve the losing value in an audit record so a disputed change can be reviewed.

Finally, design for the constraints of field use: background sync is restricted on both major mobile platforms, storage may be reclaimed by the operating system, and devices may be shared between shifts. Requiring the application to be open, and providing an explicit sync action, is often more reliable than relying on background execution.

• Choose a resolution strategy per entity, not globally.
• Prefer field-level over record-level last-writer-wins.
• Retain overwritten values for audit and dispute review.
• Provide an explicit manual sync and tolerate restricted background execution.