Offline-first gets requested frequently and implemented poorly. The usual pattern: an app ships, users in areas with patchy connectivity complain, and someone adds try/catch around API calls with a toast that says “You’re offline.” That’s not offline-first — it’s offline-aware. There’s a big difference.
The core principle
Offline-first means the app reads from and writes to a local store first, then syncs to the server in the background. The user never waits for a network response to see or interact with their data. Connectivity is treated as a nice-to-have optimisation, not a requirement.
Choosing a local store
For React Native, WatermelonDB is our default for relational data. It’s SQLite-backed, fast on large datasets, and designed specifically for offline-first sync patterns. For simpler apps (mostly read, occasional write), MMKV with a manual sync queue works with less setup.
The sync queue pattern
- Write to local DB, assign a client-generated UUID
- Enqueue a sync operation
- When connectivity is available, flush the queue against the API
- On conflict, apply your resolution strategy (last-write-wins, merge, or user prompt)
The conflict resolution strategy is where most implementations get lazy. Define it explicitly before you write a line of sync code — it’s almost impossible to retrofit.
What to test
Test the offline paths as first-class scenarios: airplane mode on device, background sync after reconnect, sync failure and retry. Most teams test happy path in CI and assume offline works. It rarely does until you test it deliberately.