Most mobile tutorials assume a stable connection. African users don't have that luxury. Here's how to build apps that work offline first — with real sync strategies, WatermelonDB, and conflict resolut

Designing Offline-First Mobile Apps for Unreliable Networks

Your app crashes the moment a user steps into a dead zone. For users in cities like Accra, Nairobi, or Lagos — switching between 4G, 2G, and nothing, sometimes within a single bus ride — that is not an edge case. It is the default experience. If your mobile app treats the network as a given, you have already failed a significant portion of your users before they even open it.

Offline-first is not a feature. It is an architectural decision made early, and it shapes everything from your data layer to your sync logic.

What "Offline-First" Actually Means

Offline-first does not mean your app works without the internet eventually. It means the internet is treated as an optional enhancement, not a hard dependency. The app reads and writes to a local store first, and synchronizes with the server whenever connectivity is available.

This flips the traditional model:

Traditional: UI → API → Database → Response → Render
Offline-first: UI → Local DB → Render (sync happens asynchronously in the background)

Users never wait on a spinner because of the network. They interact with locally committed data, and the server catches up.

Choosing Your Local Storage Layer

For React Native applications, two options stand out depending on complexity:

SQLite is the battle-tested choice. It is relational, fast, and supported on both iOS and Android. Libraries like react-native-quick-sqlite give you near-native performance. If your data model is straightforward — users, orders, records — SQLite is predictable and easy to reason about.

WatermelonDB sits on top of SQLite and adds a reactive, observable data layer designed specifically for offline-first apps. Its killer feature is lazy loading: it never fetches more data than the UI needs at a given moment, which keeps performance smooth even with thousands of local records. WatermelonDB also has a built-in sync protocol that gives you a clean contract between your client and server.

Here is what a basic WatermelonDB sync call looks like:

import { synchronize } from '@nozbe/watermelondb/sync';

async function syncWithServer(database) {
  await synchronize({
    database,
    pullChanges: async ({ lastPulledAt }) => {
      const response = await fetch(`/api/sync/pull?lastPulledAt=${lastPulledAt}`);
      const { changes, timestamp } = await response.json();
      return { changes, timestamp };
    },
    pushChanges: async ({ changes }) => {
      await fetch('/api/sync/push', {
        method: 'POST',
        body: JSON.stringify(changes),
      });
    },
  });
}

The lastPulledAt timestamp is the backbone of delta sync — you only pull records that changed since the last successful sync, keeping payloads lean and bandwidth costs low. That matters enormously for users on limited data plans.

Handling Conflict Resolution

Conflicts happen when the same record is modified on two different devices, or locally and on the server, before a sync completes. There is no silver bullet, but there are clear strategies:

Last-Write-Wins (LWW)

The simplest approach. Every record carries a updated_at timestamp. Whichever version is newer wins. LWW is appropriate for user profile data or settings where simultaneous edits are rare and the stakes are low.

Server-Wins

The server is the source of truth. Local changes are suggestions. If the server has a newer version, it overwrites the local one. Good for shared catalogues, product listings, or any data owned by an admin.

Client-Wins

The local change always takes precedence. Useful for personal data — a user's own journal entries or drafted forms — where the server copy should never overwrite something the user intentionally typed.

Operational Transformation / Merge

For collaborative or complex data (think shared documents or multi-field records), you merge changes field by field rather than record by record. This is complex to implement but eliminates data loss. Libraries like Automerge bring CRDT-based merging to JavaScript, though the learning curve is steep.

For most business apps — field data collection, logistics, healthcare forms — a combination of LWW with a manual conflict flag works well in practice. Flag the conflict, surface it to the user, let them choose.

Building a Reliable Background Sync Queue

Sync should never block the user and should survive app restarts, crashes, and long offline stretches. The pattern is a persistent queue:

Every write operation is appended to a local queue (stored in SQLite).
A background worker processes the queue whenever connectivity is detected.
Successfully synced items are removed from the queue.
Failed items are retried with exponential backoff.

In React Native, use NetInfo from @react-native-community/netinfo to listen for connectivity changes and trigger your sync worker. For long-running background tasks, react-native-background-fetch can wake the app periodically even when it is not in the foreground — critical for logistics or health apps where data freshness matters.

Key practices for a robust queue:

Idempotent API endpoints: Retried pushes should not create duplicate records. Use client-generated UUIDs, not server-auto-incremented IDs.
Ordered operations: Some writes depend on others (create a parent before a child). Use a sequence number in the queue.
Partial sync support: Allow a sync to succeed partially. Do not roll back everything if one record fails.

Optimistic UI: Keeping the Experience Snappy

Write to local storage and update the UI immediately. Do not wait for server confirmation. If the sync later fails permanently, surface a non-intrusive error and offer a retry. Users in low-connectivity environments are accustomed to latency — what they cannot tolerate is an app that freezes or shows a blank screen.

Mark pending records visually (a subtle grey indicator, a "syncing" badge) so users know which data is still local. Transparency builds trust.

Testing for the Real World

Simulate the conditions your users actually face:

Use Android's network throttling tools in the emulator to test at 2G speeds.
Toggle airplane mode mid-operation and verify the queue handles it gracefully.
Test with a large local dataset to catch performance regressions in your query layer.
Simulate a server returning errors on push and verify retry logic kicks in.

Why This Matters for Your Project

If you are building a mobile product for African markets — or any emerging market with variable connectivity — offline-first architecture is not optional, it is competitive. Apps that keep working when the signal drops retain users. Apps that stall, lose them. The sync strategies and storage patterns covered here are production-proven and achievable with the React Native ecosystem today. Baking them in from the start costs far less than retrofitting them onto an app that was designed to assume the internet is always there.