Mobile apps · Mixed

Working offline: an app that doesn't break in an elevator

In one line: Design the app around the assumption that there's no network, and you get for free an app that also feels fast when there is.

The base assumption

A cellular network isn't an on-off switch but a spectrum: slow, intermittent, connected but with no throughput. An app that assumes a good connection shows an endless loading spinner exactly when the user needs it.

The right approach: the device holds a local source of truth, and the network is a background sync process.

Three mechanisms

Read cache. What loaded once shows again immediately, with a subtle “updating” mark.

Write queue. Actions the user took are saved locally and sent when there's a connection. The interface shows the result immediately.

Conflict resolution. What happens when two devices changed the same item. Decide in advance: last wins, field-level merge, or ask the user.

What the user needs to see

Sync status quietly but clearly, and what hasn't been sent yet. Hiding the state entirely breeds distrust the moment something disappears.

Going deeper

Keep a version or update timestamp from the server on every record, and send it back on write to detect a conflict. Without it, two updates in parallel overwrite each other silently — the worst kind of data loss, because nobody gets an error.