Offline support is usually requested as a technical feature and delivered as one, which is why it so often behaves strangely. The hard part is not storage. It is deciding what should happen when two versions of the truth disagree.
Three patterns, in increasing difficulty
Read-only cache: the app shows the last-known data and blocks writes while offline. Cheap, honest, and enough for most content apps.
Queued writes: actions taken offline are stored and replayed in order when connectivity returns. Suits apps with a single author per record — field inspection tools, delivery apps, personal trackers.
True bidirectional sync: multiple writers, conflict resolution, per-field merge rules. Expensive, and only justified when collaboration is the product.
The questions that pick the pattern
- Can two people edit the same record?
- Is a stale read dangerous, or merely annoying?
- If a queued write fails on replay, who needs to know and how?
- How long can a device realistically stay offline?
Make conflicts visible
Silent last-write-wins is the default in most sync libraries and the source of most trust problems. When a conflict happens, showing the user that it happened — even in a small way — costs one screen and saves a great deal of support work.
Want this applied to your product?
We do this work for clients every week. Bring us the specifics and we will tell you what we would change first.
Book a Call