Offline-first mobile apps: why they matter and how to build one
Why some apps must work without a connection, and the architecture behind offline-first mobile apps: local storage, sync queues, and conflict handling.
Microverge Engineering2 min read
Most apps treat the network as always available and handle "offline" as an error. That's fine for a news feed. It isn't fine for a medicine reminder, a field inspection form, or a delivery driver's checklist. For those apps, the moment the network disappears is exactly when the app needs to work.
Offline-first flips the usual design: the app reads and writes to a database on the device, and syncs with the server in the background whenever it can.
When offline-first is worth it
- The app does something time-critical, like reminders or alarms.
- Users work in places with poor signal: basements, warehouses, rural areas, underground transit.
- Users enter data that must never be lost, like inspection results or medical information.
- Speed matters. Reading from the device is nearly instant, so offline-first apps also feel faster online.
The building blocks
- 1A local database. SQLite is the usual choice on iOS and Android, and works well in React Native and Flutter. The screens read from it directly.
- 2An outbox. Every change the user makes is saved locally and added to a queue of pending changes.
- 3A sync engine. When the device is online, it sends queued changes to the server, pulls down new data, and retries anything that failed.
- 4Local scheduling. Anything time-based, like notifications, is scheduled on the device, so it fires with or without a connection.
The hard part: conflicts
If the same record changes on two devices while one is offline, which version wins? There's no universal answer; it depends on the data. Common strategies include last-write-wins with timestamps, merging changes field by field, or keeping both versions and asking the user. Decide this per data type early, because it's painful to retrofit.
Testing it properly
- Test with airplane mode on, then off, mid-action.
- Kill the app while changes are still queued, and confirm nothing is lost on restart.
- Simulate the server being down, slow, or returning errors.
- Make two devices edit the same record and check the result is what you designed.
We used this approach to build Presora, a medicine reminder app whose reminders fire even with no signal.