In this article
The most expensive assumption in mobile development is that the user has an internet connection.
Office apps get away with it. Field apps do not. Inspectors work in basements, drivers pass through dead zones, and rural sites can offer one bar of signal on a good day. We have shipped several React Native field applications, including inspection tools, compliance platforms and dispatch apps, and each one taught the same lesson from a different angle. Offline is not an edge case. For these users it is the normal condition.
This is the architecture that survived contact with real field workers, and the mistakes that shaped it.
Local is the source of truth
Most apps treat the server as the truth and the phone as a window onto it. Offline-first reverses that. The phone's local database is where work happens, and the server is where work eventually arrives.
This sounds like a technical detail, but it is a product decision. When an inspector completes a checklist in a basement, that inspection is finished. The app says so and the inspector moves on. Sync is bookkeeping that happens later. The moment the interface makes a field worker wait on a spinner because the server is unreachable, you have built an office app that happens to run on a phone.
Every record in the local database carries a sync status: pending, syncing, synced or failed. The interface reads and writes locally, always. A background process works through the pending queue whenever a connection allows.
The sync queue: ordered and persistent
Our sync queues follow three rules that took real projects to learn.
Order by dependency, not by time. If a worker creates a site visit and then attaches photos to it, the visit must sync before the photos, or the server rejects orphaned attachments. We queue operations with explicit parent references and never send a child before its parent has a server ID.
Persist across restarts. Phones die in the field. The queue lives in the same local database as the data, so a phone that dies at 2% battery picks up exactly where it left off. An in-memory queue is a data-loss machine.
Chunk for hostile networks. A rural connection that can move 50 KB will time out on a 5 MB photo batch. We upload evidence photos individually with per-item retry, so one bad photo never blocks a hundred good records. In one compliance app, photos and signatures upload separately from the inspection data itself. The record arrives first and the evidence follows as bandwidth permits.
Decide the conflict policy before writing code
Two people edit the same record offline, and one version has to win. There is no universal answer, only a policy the client has to choose consciously. In field service work we usually land on last-write-wins with an audit trail, because field data rarely collides (each worker owns their own jobs), and when it does, the audit log lets a supervisor sort it out. Collaborative data is different, and merging strategies get expensive quickly.
The mistake to avoid is discovering you need a conflict policy in week fourteen, in production, from a support ticket. It is a one-hour conversation in discovery. Have it early.
Test more than airplane mode
Everyone tests airplane mode. The field is harsher than airplane mode. The conditions that break sync are the in-between states: one bar of signal that connects and stalls, a network that accepts the request and never responds, Wi-Fi that is connected but has no internet. We simulate all three with throttling proxies before any field app ships, and we log every sync failure with enough context to debug it from an office a continent away.
The payoff
Done well, offline-first is invisible. Workers stop thinking about connectivity, back offices see data flow in as the day progresses, and nobody loses an hour of work to a dead zone. Three of the field platforms we built this way are documented in our case studies: a field service compliance platform with geofenced checks and photo evidence, a multi-role dispatch platform with GPS proof of completion, and an offline-first inspection app with AI assistance that still works without a connection.
If you are planning an app for people who work where the signal is poor, that is the kind of project we like. Our React Native practice and mobile development pages cover how we work, or tell us about your project and we will scope it for free.