A mobile app lives on trains, elevators, weak Wi-Fi, low batteries and phones that suspend it whenever the operating system feels like it. “Assume the network works” is a web-shaped assumption wearing a mobile costume.
Offline design starts with deciding what must remain true when the network disappears.
Offline is a spectrum
Some products need to create records offline and sync them later. Others only need cached reading, a form that survives a failed submit, or a graceful 'try again' state. Decide what your app actually promises offline instead of declaring the whole thing 'offline-first'.
The right design depends on what users are doing when connectivity disappears.
Cache data with meaning
Caching is a decision about freshness, taken one screen at a time. Can yesterday's catalogue be shown? Can an old medical instruction be shown? Can pricing be stale?
Where old data could mislead, show its age or refuse to show it at all. The app should not quietly present old information as current simply because it happened to be on the device.
Queue writes that can safely wait
Forms, messages, field observations and uploads can be saved on the device and synchronised later. Give each queued action a stable identifier — an ID that survives an app restart — and an explicit state: pending, syncing, failed, completed.
Do not make users submit the same form three times because the spinner was emotionally ambiguous.
Conflict is a product decision
If two devices edit the same record offline, which version wins? Last-write-wins — the later save quietly overwrites the earlier one — may be acceptable for a note and dangerous for inventory or clinical data.
Conflict rules belong to product and domain design, not only the sync library.
Assume the app will be killed
Mobile operating systems suspend and shut down apps in the background. Save important work to the device before assuming a background task will finish. Design uploads and long operations so they can resume where they stopped, or check afterwards what actually went through.
The operating system is not being rude. It simply has other priorities.
Test ugly networks on purpose
Testing on perfect office Wi-Fi misses the behaviour that matters. Test slow responses, dropped packets, the moment a device comes back online, app restarts mid-sync, duplicate retries and old cached data.
The worst network is not 'no network.' It is a network that works just enough to be confusing.
Design trust, not just resilience
Users need to know whether an action is saved, pending or failed. Good offline UX makes uncertainty visible and gives recovery paths.
The technical goal is consistency. The product goal is confidence.