Offline-First Mobile Apps: Sync, Conflicts and Patchy Networks

Why offline-first is a product decision, not a feature

Connectivity is not a binary state. A field sales rep in a tier-2 town may have 4G at the bus stand and nothing inside the distributor's godown. A commuter loses signal for ninety seconds between metro stations, several times a trip. A nurse charting at the bedside works in a building whose thick walls and shielded rooms were never designed for mobile coverage. In each case the network is technically available most of the time, and that is exactly what makes naive apps fail: they assume the request will succeed, and they have no plan for the moment it does not.

The cost of getting this wrong is rarely a crash. It is quieter: duplicate orders because the user tapped submit three times, a site inspection that vanished because the app was killed while a request hung, a support team that cannot reproduce anything because it only happens in a basement. Retrofitting offline support into an app designed around request and response usually means rewriting the data layer, which is why we ask the connectivity question in the first discovery workshop, not after the first field complaint.

Not every screen needs to work offline. A payment confirmation or a live chat genuinely needs the server. The useful exercise is to list every user action and mark it as must work offline, can queue, or online only, and then design the data model around the first two columns. That single table, agreed with the product owner, prevents months of arguments later about what the app was supposed to do in a tunnel.

Make the local database the source of truth

The core architectural move is simple to state: the user interface reads from and writes to a local database, never directly to the network. When a user saves a form, the write lands in SQLite on the device, the screen updates immediately from that write, and a separate sync process is responsible for getting it to the server later. The server remains the shared system of record, but from the app's point of view the local store is what is true right now.

This changes how you design screens. There are no loading spinners on save, because saving is a local transaction measured in milliseconds. Instead, each record carries a sync state, typically pending, synced or failed, and the interface shows it honestly: a small clock icon for queued changes, a clear message for a change the server rejected. Users cope well with an app that says it will send this when you are back online. They do not cope with an app that silently loses their work.

On the storage side, SQLite is the dependable default on both platforms. In React Native, WatermelonDB adds lazy loading and a pull and push sync protocol on top of it, and our Mobile App Development practice lists offline-first SQLite and WatermelonDB sync among its standard deliverables. Flutter teams typically reach for Drift, and native teams use Room on Android and Core Data, SwiftData or GRDB on iOS. Pick the store for its migration story as much as its speed, because the schema on a phone that has been offline for a month still has to upgrade cleanly.

Sync queues and idempotency keys

Every local change should also write an entry to an outbox table, in the same database transaction as the change itself. That one rule guarantees that a record is never saved without a matching instruction to send it, even if the app is killed a millisecond later. A sync worker drains the outbox in order whenever connectivity and the operating system allow, and marks entries done only when the server has acknowledged them.

Because mobile networks drop responses as often as requests, the client will regularly resend something the server already processed. The defence is an idempotency key: a unique identifier generated on the device for each mutation and sent with it. The server stores keys it has seen for a sensible window and returns the original result for a repeat instead of applying it twice. Generating record identifiers on the client, ideally time-ordered UUIDs, removes another class of bugs, because a child record can reference its parent before the server has ever seen either.

The pull direction needs the same care. Rather than asking the server for everything changed since the device's clock said it last synced, ask for changes after a server-issued cursor or change token, and include deletions as tombstones so the device can remove records it would otherwise keep forever. Page large pulls, and make each page commit atomically, so an interrupted first sync resumes rather than restarting from zero.

• Write the record and its outbox entry in one local transaction so neither can exist without the other.
• Send a client-generated idempotency key with every mutation and have the server deduplicate on it.
• Retry with exponential backoff and jitter, so a thousand phones regaining signal at once do not stampede the API.
• Move entries that fail repeatedly with validation errors to a dead-letter state the user can see and fix, instead of retrying them forever.
• Pull changes with a server-issued cursor and explicit tombstones, never with timestamps taken from the device clock.

Choosing a conflict strategy: last-write-wins, field-level merge or CRDTs

Conflicts happen when two devices change the same record while at least one of them is offline. There is no universally correct answer, only a choice per type of data, and the worst outcome is not choosing and letting whichever request arrives last silently overwrite the other. Write the conflict rules down in the data model document alongside each entity, because product owners need to agree with them.

Last-write-wins is the simplest strategy and is fine for data with a single natural owner, such as a user's own profile or settings. Use a server-assigned version or a hybrid logical clock to decide what last means, because phone clocks drift and some users set them wrong on purpose. Field-level merge is the sensible default for shared business records: track which fields each device changed relative to the version it started from, apply non-overlapping changes from both sides, and only raise a genuine conflict when the same field was edited twice.

Conflict-free replicated data types, through libraries such as Automerge or Yjs, are the right tool for collaborative text, checklists and ordered lists where several people edit at once. They carry real costs: metadata that grows with history, harder server-side validation and more complex querying. Some data should not merge at all. Stock counts and balances are better modelled as operations, such as reserve two units, that the server validates and can reject, than as states two devices fight over. Append-only data such as sensor readings sidesteps conflicts entirely, because nobody edits a reading after it is taken.

• Use last-write-wins, decided by server versions rather than device clocks, for data with one clear owner.
• Use field-level merge with a base version for shared records like customer details, visits and inspections.
• Use CRDTs only for genuinely collaborative documents and lists, and budget for their storage overhead.
• Model quantities and money as server-validated operations, and design append-only records wherever the domain allows.

Background sync on iOS and Android, and the battery bill

Teams often design as if the app can sync whenever it likes. Neither platform allows that. On iOS, BGTaskScheduler lets you request short app refresh tasks and longer processing tasks, but the system decides when they run based on usage patterns, battery and network, and a user who force-quits the app stops most background work until they open it again. Silent push notifications can nudge a sync, but they are throttled and not guaranteed. Background URLSession transfers are the reliable exception: uploads and downloads handed to the system continue even when the app is suspended.

On Android, WorkManager is the right abstraction for deferrable sync. It respects Doze and App Standby Buckets, survives reboots and lets you declare constraints such as unmetered network or battery not low. Periodic work cannot run more often than every fifteen minutes, and some manufacturers add aggressive battery optimisation on top of stock Android, so field-team deployments often need a short onboarding step asking users to exempt the app. Long user-initiated uploads belong in a foreground service with a visible notification and the correct declared service type.

The practical design is to sync opportunistically: immediately after a local write when online, when the app comes to the foreground, and in whatever background windows the platform grants. Batch outbox entries into fewer, larger requests, compress payloads, and avoid waking the radio for one small change, because radio wake-ups are where battery quietly disappears. Measure it: a sync design that costs a few percent of battery a day will be uninstalled by the field team that depends on it.

React Native, Flutter or native for offline-first

For most offline-first business apps the framework choice matters less than the data layer. React Native and Flutter both have mature SQLite bindings, both can share sync logic across platforms, and both let you drop into Swift and Kotlin for the parts that need it. Those parts are predictable: background task registration, background transfers, secure key storage and hardware integrations such as Bluetooth wearables. Budget for native modules from the start rather than discovering them in week eight.

React Native suits teams with strong TypeScript skills and a web product to share types and validation with, and WatermelonDB gives it a well-trodden sync path. Flutter suits teams that want tight control of rendering and a single language across the app, with Drift for typed SQL. Fully native is worth the cost when background behaviour, sensors or battery are the product itself, or when the app must squeeze into older, low-memory devices common in field deployments. Managed sync layers such as PowerSync can save months on the plumbing, at the price of adopting their data model.

Our portfolio project NeuroPulse is a useful reference point. It is an offline-first health telemetry app that syncs ECG and blood-oxygen data from wearables into an encrypted on-device store, online or not, built with React Native alongside Swift and Kotlin modules, WatermelonDB and Firebase. That mix, a cross-platform core with native edges, is the shape we would expect most serious offline-first apps to take.

Test on bad networks, and treat device data as exposed

Offline bugs do not appear on office Wi-Fi, so testing has to recreate the field. Apple's Network Link Conditioner, available in the developer settings on a test iPhone and as a macOS tool, simulates high latency, packet loss and very slow links. The Android emulator lets you set network speed and latency, and a fault-injecting proxy such as Toxiproxy in front of a staging API can add timeouts and dropped connections on demand. Most importantly, test the transitions, not just the states: losing signal halfway through an upload is a different bug from being offline throughout.

Security deserves the same rigour, because offline-first deliberately puts business data on devices that get lost, shared and stolen. Encrypt the local database, for example with SQLCipher, and keep the key in the iOS Keychain or the Android Keystore, hardware-backed where available. Mind the iOS Data Protection class: the strictest class makes files unreadable while the phone is locked, which also blocks background sync, so the choice is a real trade-off to make consciously. Cache only what the user's role needs, wipe local data on logout and when the server revokes a session, and consider how health or financial data on devices fits your obligations under India's DPDP Act, HIPAA or GDPR.

• Toggle airplane mode in the middle of a large upload and confirm nothing is lost or duplicated.
• Kill the app during sync, reopen it offline and check that the outbox resumes in the right order.
• Edit the same record on two offline devices, reconnect both and verify the agreed conflict rule.
• Set the device clock wrong by a day and confirm ordering and pulls still behave.
• Join a captive-portal Wi-Fi network where the phone reports connectivity but every request fails.
• Log out with unsynced changes and confirm the user is warned before local data is wiped.

How we would approach an offline-first build

We start with the action inventory from the first section and a data model that names an owner and a conflict rule for every entity, before any screens are designed. A thin vertical slice follows: one entity, end to end, through the local store, outbox, idempotent API and pull cursor, tested on a conditioned network on real low-end devices. Only when that slice survives the failure checklist do we scale it to the rest of the app.

If you are planning a field, healthcare or commuter-facing app, our Mobile App Development team covers the client side, and API Integration & Development covers the idempotent, queue-backed endpoints the sync layer depends on. A short scoping call is usually enough to map your actions into offline, queued and online-only, which is the single most useful input to any estimate.