What is offline-first?
Offline-first design treats the network as optional rather than assumed. The app reads and writes to local storage first and shows data instantly, then syncs with the server in the background when a connection is available. The UI never blocks waiting for the network.
Why it matters
Phones lose connectivity constantly — subways, elevators, dead zones, planes. An app that freezes or errors the moment the network drops feels fragile. Offline- first apps stay usable and fast everywhere, which is a major quality differentiator and, for some products, a hard requirement.
What to learn
- Local-first reads and writes
- Detecting connectivity with NetInfo
- Queuing writes made while offline
- Optimistic UI updates
- Background sync when connectivity returns
- Showing sync and offline status to the user
- The complexity cost of offline-first
Common pitfall
Showing a spinner and blocking the UI whenever a request is in flight, so the app is unusable offline. Offline-first flips this: render from local data immediately, apply the change optimistically, and sync in the background. Blocking on the network is exactly the experience offline-first exists to avoid.
Resources
Primary (free):
- NetInfo — Docs · docs
- TanStack Query — Offline · docs
- Offline first — Community resources · docs
Practice
Make one feature work offline: read from local storage so it renders instantly, let the user make a change while offline that is queued, and sync it when NetInfo reports the connection is back. Show an offline indicator. Done when the feature is usable in airplane mode and syncs on reconnect.
Outcomes
- Read and write local-first so the UI never blocks.
- Detect connectivity and queue offline writes.
- Apply optimistic updates and sync in the background.
- Communicate offline and sync status to the user.