Offline mode in a mobile app: how to work without internet

Offline mode is needed by apps used where connectivity is poor or absent: couriers, field staff, warehouse workers, travellers. For most apps it is enough to cache data for viewing and handle missing connectivity gracefully. A full offline-first approach — where users create and change data without internet and the app syncs later — is considerably harder and needs well-designed synchronisation and conflict resolution.

Here are the levels of offline support, on-device storage, synchronisation and conflicts.

When does an app need offline mode?

Offline mode is needed when the user's work must not stop because of connectivity. If people cannot do their job without a network and they regularly lose it, offline mode becomes a core feature rather than a nice extra.

• field staff — installers, inspectors, sales reps;
• logistics — couriers, drivers, warehouse pickers in poor coverage;
• healthcare and field research — filling in forms where there is no signal;
• travel — tickets, maps, bookings;
• content — books, courses and podcasts for the road.

On choosing between an app and a website, see mobile app or website and PWA instead of a mobile app.

What levels of offline support are there?

Offline support comes in different depths. The more users can do without a network, the harder development and testing become.

Level	What users can do offline	Complexity
Error message	See a clear message and a retry button	Minimal
Read cache	View previously loaded data	Low
Deferred actions	Create records that are sent later	Medium
Offline-first	Work fully, with background sync	High

Start with an honest question: which flows do users actually perform without a network — and build offline support only for those.

Photo: Unsplash

How do you store data on the device?

For offline mode, data lives in a local database on the device, and the interface reads from it rather than straight from the network. The network becomes a means of synchronisation, not the data source for every screen.

1. Local database — SQLite or a layer on top of it, available for native and cross-platform apps.
2. Only what is needed — the device gets the user's own data and tasks, not the whole company database.
3. Timestamps and versions — every record has a version or modification time for sync.
4. Encryption — the local database is encrypted and tokens are kept in the system's secure storage.
5. Cleanup — data is wiped on sign-out.

How do you synchronise changes?

Changes made offline are written to a local operation queue. When connectivity returns, the app sends operations to the server in order and receives changes made by others. Resending the same operation must never create duplicates.

type PendingOperation = {
  id: string            // unique key — the server will not create a duplicate on retry
  entity: 'delivery'
  entityId: string
  action: 'update_status'
  payload: { status: 'delivered'; signedAt: string; photoId?: string }
  createdAt: string
  attempts: number
}

Sync rules:

• every operation has a unique idempotency key — see idempotent payments and webhooks;
• sync starts when the network returns and runs in the background with retries;
• only changes since the last sync are downloaded from the server;
• large files — photos, signatures — upload separately and resume after interruptions;
• users see the status: what has been sent and what is waiting for a network.

How do you resolve conflicts?

A conflict arises when the same record was changed on an offline device and on the server. Choose a resolution strategy for each data type in advance — there is no universal rule.

• last write wins — simple, fine for non-critical fields;
• field-level merge — different fields from different sources are combined;
• source priority — for example, a dispatcher's status overrides the app's;
• manual resolution — the user sees both versions and chooses;
• append-only — logs and comments have no conflicts at all.

How do you test offline mode?

Offline mode breaks in situations that never occur in an office with good Wi-Fi: slow networks, a drop in the middle of a send, the app closed before syncing. So these scenarios are tested deliberately.

• emulating slow and unstable networks;
• dropping the connection during sends and file uploads;
• closing the app with unsent changes;
• editing the same record on two devices at once;
• long offline use followed by syncing a large volume.

On testing mobile and web products, see manual testing in a small team and Flutter vs React Native vs native.

In short

• Offline mode is needed when users' work must not depend on connectivity.
• Levels: error message, read cache, deferred actions, offline-first.
• The interface reads from a local database; the network is for sync.
• Changes accumulate in an operation queue with idempotency keys.
• Choose a conflict resolution strategy for each data type in advance.