Offline-first
Also: local-first, offline-capable
What is Offline-first?
Offline-first is a mobile app design where the app reads and writes to a local database as the primary store and synchronises with the server when connectivity allows, so work continues without a network.
What Offline-first means
In an offline-first app, every screen works from local data. Actions (mark delivered, record a reading, capture a signature) are written locally and queued, then pushed to the server in the background. Incoming changes are pulled and merged. The user is never blocked by a spinner waiting for a network that may not come back for an hour. Connectivity becomes an optimisation rather than a requirement.
The hard parts are synchronisation and conflict resolution. Each record needs a version or timestamp, the sync protocol needs to handle partial failures and retries without duplicating writes, and the design has to decide what happens when two devices change the same record. Common strategies are last-write-wins for low-stakes fields, server-authoritative rules for money and status, and explicit merge for anything else. Large attachments such as photos need their own upload queue with resumable transfers.
Offline-first is not simply caching for reads, and it is not the same as a progressive web app. It is a data architecture decision that touches the backend API, which must accept batched, out-of-order and duplicate writes gracefully.
Who it really matters to
- Operations head: field staff in warehouses, basements, rural routes and hospital wards lose connectivity daily; an app that stops working stops the operation.
- CTO / Head of Engineering: sync and conflict handling are the core design problem and cannot be added after the app is built around network calls.
- Product manager: offline capability decides whether a field app is trusted or worked around with paper and WhatsApp.
- Data lead: sync metadata (device, timestamp, version) is what makes field data auditable and reconcilable.
Why it exists
Offline-first exists because the people who most need mobile software often work where the network is worst, and because even good networks drop for seconds at a time. Designing around a local store makes the app fast and dependable and turns connectivity loss into a background concern. The trade-off is significant: local storage, sync queues, conflict rules and backend idempotency all have to be designed and tested. For a desk-bound app it is unnecessary; for a field app it is the difference between adoption and abandonment.
Where it is applied
- A delivery driver app that records pickups, proof of delivery and cash collection with no signal and syncs later.
- A field service technician app capturing job notes, parts used and customer signatures inside buildings.
- A rural healthcare worker app recording patient visits and vitals that upload when back in coverage.
- A retail store audit app photographing shelves in basements and syncing at the end of the visit.
- A school attendance and assessment app used in classrooms with unreliable connectivity.
Is Offline-first a skill?
Technique / practiceAn architectural pattern implemented with local databases and sync frameworks such as WatermelonDB, SQLite or PowerSync, plus backend support. Eazyware builds offline-first field apps under the React Native mobile service, including sync design and conflict rules.
Eazyware service that covers it: React Native Mobile Application Development. Starting prices are on the pricing page.
Frequently asked questions
How do you handle conflicts when two devices edit the same record?
Decide per field. Low-stakes fields can use last-write-wins; money, status and anything regulated should be server-authoritative with explicit rules; genuinely ambiguous cases should surface to a person. Version every record so the server can detect the conflict at all.
Can we make an existing app offline-first?
Partially, and with effort. Reads can be cached fairly easily, but write queues, idempotent APIs and conflict handling usually require reworking the data layer. It is much cheaper to decide offline-first at the start of a field app.