We spent a month treating offline support as a caching problem, and it did not work.
The pattern we had: fetch from the API, write to a local cache, fall back to the cache when the network fails. It broke in every way you'd expect. Edits made offline disappeared. Two devices disagreed. A failed sync left the database half-written.
The fix was to stop thinking about cache and start thinking about the model. There is one local database, and it is the source of truth for the UI. The network is a sync mechanism that moves changes between that database and the server, with a queue of pending mutations.
Once that was the model:
Offline edits live in the same table as everything else, marked pending, so the UI never shows stale or vanished data.
Sync is idempotent per mutation, so retrying after a crash is safe.
Conflicts are decided in one function instead of three screens.
The caching version was a week of work that failed for a month. The data model version was three weeks that then worked. Offline is not a feature you add at the end; it is a decision about where the truth lives.
Top comments (0)