Offline support: when your app must work without a connection
Field teams, warehouses and basements lose connectivity. What offline support really involves, and when it is worth the cost.
The short answer
Field teams, warehouses, basements, rural sites and aircraft all have one thing in common: the connection drops exactly when someone needs to record something. Offline support means the application keeps working without a connection and reconciles with the server when it returns. It sounds like a feature and is a design decision that touches how data is stored on the device, how changes are queued and synced, what happens when two people changed the same thing, and how the user knows what state they are in. There are three levels, each more expensive than the last, and most field needs are met by the middle one.
The three levels
| Level | What works offline | What it needs | Fits |
|---|---|---|---|
| 1. Read-only | Viewing data downloaded while online | Local cache, clear staleness indicator | Reference material, schedules, manuals |
| 2. Capture and sync | Viewing, plus recording new items and edits that queue and sync later | Local queue, sync engine, status per item, conflict rules for edits | Inspections, deliveries, visit notes, photos, forms |
| 3. Full offline operation | Everything, including complex workflows and multi-user edits | Local database, bidirectional sync, conflict resolution, background sync | Warehouses, remote operations, long disconnections |
Designing for capture and sync
- Decide what must be available offline and download it while online, with a visible “last updated” time.
- Store new records and edits locally first, always, so the app feels the same online and offline.
- Queue changes with timestamps and identifiers generated on the device.
- Sync automatically when a connection appears, in the background where the platform allows, resumable after interruption.
- Show status per item: saved locally, syncing, synced, failed with reason.
- Handle conflicts by rule, decided per data type with the business: append, last wins, or a person reconciles.
- Test with the connection cut mid-action, repeatedly, on real devices.
Deciding whether it is worth it
Ask what the field team does away from the desk and how often the connection is absent at that moment. If the answer is “records inspections in basements weekly”, capture and sync pays for itself in the first month of not re-entering paper notes. If the answer is “occasionally checks a schedule”, a read-only cache is enough. Full offline operation is for businesses whose work genuinely happens disconnected for hours, and it is a substantial engineering commitment that should be chosen with eyes open.
What this means for you
Offline support is a design decision with three levels. Choose from what the field team actually does without a connection, build capture and sync properly if that is the need, decide conflict rules with the business before building, and never let a captured record disappear. Done that way, the app is trusted in the basement, which is where its value was always going to be proven.
Frequently asked questions
Do we need offline support if coverage is usually fine?
Usually is the problem. The moments without coverage, a basement, a rural site, a warehouse with metal shelving, a plane, are exactly when a field worker needs to record something. If the app's main use is capturing information away from the desk, some level of offline capture is worth it. If it is mostly consulted at a desk, probably not.
What happens when two people edit the same record offline?
A conflict, and the application must have a rule: last write wins, first write wins, field-level merge, or a person decides. The right rule depends on the data. For inspection notes, appending both is fine; for a stock count, a person must reconcile. Deciding this before building is what separates offline support that works from one that silently loses data.
Is a progressive web app enough for offline?
For reading downloaded content and capturing forms to sync later, yes, on most modern devices, and it avoids the app stores. For heavy local data, background sync under all conditions or deep device integration, a native or hybrid app is more reliable. Start from what the field team actually does offline and choose from there.
Sources
- MDN: Offline and background operation (accessed 2026-09-12)