When you build a remote patient monitoring app, "the network is down" isn't an edge case. It's Tuesday. A patient takes a blood-pressure reading in a basement flat with no signal, and that reading still has to reach their care team. So the app has to assume the network is unreliable and treat the local device as the source of truth until the server confirms otherwise. Here's how I approach offline-first in React Native.

Persist the cache, not just hold it in memory

A normal data-fetching setup keeps server state in memory and refetches on mount. That's useless offline. The fix is to persist the query cache to disk so it survives app restarts. I use TanStack Query with a persister backed by a fast key-value store (MMKV), so the last known data is on screen instantly, even with the radio off.

Treat writes as a queue, not a request

The important inversion is this. A new reading isn't "a POST that might fail." It's an entry appended to a local queue that is eventually flushed to the server. The UI reflects the local state immediately, and sync happens in the background when connectivity returns. The user never waits on the network to see their own data.

• Capture, then write locally and optimistically update the UI.
• Detect reconnect (for example with NetInfo), then flush the queue.
• On success, reconcile with server state. On conflict, resolve deterministically.

Make sync observable

Silent sync is scary in a medical context. People need to trust that their data landed. A small, honest status ("saved on device", "syncing", "synced") does a lot of work, and it's cheap once writes already flow through a queue you control.

The mindset

Offline-first isn't a library you bolt on. It's a default you design around: local-first reads, queued writes, explicit reconnection, and a UI that tells the truth about where the data currently lives. Get those four right and the network becomes an optimization rather than a dependency.