Designing Offline-First Applications
Key takeaway
Offline support is a data architecture decision, not a feature toggle. Write to a local store first, sync in the background with a queue, and decide a conflict resolution rule per entity before writing any code — retrofitting offline onto a request-response app is close to a rewrite.
Field technicians, warehouse staff, delivery crews, and anyone on a construction site or a train all share a condition your office network never reproduces: connectivity that comes and goes mid-task. Applications that assume a connection fail them in the most frustrating way possible — by losing work.
The core pattern
- The local store is the source of truth for the user interface. Every action writes locally and returns immediately.
- Changes go into an outbound queue with a client-generated id, so retries are safe and ordering is preserved.
- A background process drains the queue when connectivity returns, with backoff.
- Inbound sync pulls changes since a cursor, not the whole dataset.
Conflicts are a business decision
Two people edit the same record while offline; someone has to lose, and only the business can say who. Decide per entity: last write wins is acceptable for a status field, unacceptable for a stock count. Field-level merging avoids most conflicts. For genuinely contested data, queue it for human resolution rather than silently discarding someone's work — silent loss is what destroys trust in an offline application.
Be honest in the interface
- Show connection state and, more importantly, sync state: this record is saved locally, syncing, or confirmed.
- Never show a success message that implies the server accepted something it hasn't seen.
- Surface sync failures where the user will act on them, with a retry.
- Show how stale the displayed data is when it matters — prices, availability, assignments.
Practical constraints
- Scope the local dataset: sync this user's assignments, not the whole database.
- Plan for schema migration of the local store — devices will run old versions for months.
- Encrypt local data; an offline app means business data sitting on a device that gets lost.
- Set a retention rule, or the local store grows until the app is slow and the device is full.
- Test on a real bad connection, not by toggling airplane mode. Intermittent and slow is far harder than off.