Building Offline-First Mobile Apps That Actually Work

The problem with "offline support"

Most apps treat offline as an error state — show a snackbar saying "No internet" and block the user. That’s not offline-first. Offline-first means the app works fully without a network connection, and syncs when connectivity returns. For field agents in rural India, this isn’t a nice-to-have — it’s the primary use case.

Our three-tier storage architecture

We use three storage layers on-device: 1) Drift (SQLite) for structured business data, 2) Flutter Secure Storage for credentials, 3) SharedPreferences for settings. The SQLite layer is the source of truth during offline periods — orders, visits, and task data are written locally first, always.

Sync strategy: queue, batch, retry

Every write operation goes into a local queue. When the device has connectivity, a background WorkManager job batches pending operations and syncs them to the server. If a sync fails, exponential backoff kicks in (5s, 10s, 30s, 60s). The queue persists across app kills and device restarts.

Conflict resolution

The hardest part of offline-first is conflicts. Two agents modify the same retailer record offline — who wins? Our approach: last-write-wins with server timestamps for non-critical data (profiles, settings), and manual resolution for business-critical data (orders, payments). The server always has the final say on state.

Delta sync over full sync

We never download the entire product catalog on every sync. Instead, we use FCM silent push to notify devices of changes, then sync only the delta (modified records since last sync timestamp). This keeps sync fast even on 2G connections and reduces server load.

Testing offline scenarios

We test with airplane mode enabled for entire user flows. If an agent can start their day, visit 10 retailers, place orders, and punch out — all without internet — then reconnect and have everything sync cleanly, the architecture works. That’s our acceptance criteria.