Offline-first is an architecture
Field apps do not need better error handling for lost connections. They need a data model where the network was never assumed in the first place.
There is a version of offline support where the app detects a lost connection, shows a message and retries. It works in a demo and fails in a basement, because the failure is not the request — it is that the user kept working for forty minutes while the request was impossible.
Offline-first inverts the relationship. The local database is the source of truth. The user interface reads and writes locally and never waits on a network call. Synchronisation is a background process that reconciles with the server whenever it can, and the user is never blocked by it.
That makes the outbound queue the most important component in the app. Every mutation is appended to a durable journal before it executes, so an app killed mid-upload resumes from the last known good entry rather than losing the work. This is the difference between an engineer re-keying a day's jobs in the evening and not.
Conflicts then become a product decision rather than a technical accident, and they should be agreed before any code is written. On field service work we settled on server-wins for pricing and scheduling, device-wins for observations the engineer made on site, and an exception queue for anything else.
Payload size matters more than teams expect. Delta sync rather than full refresh, compressed and chunked photo uploads that can resume, and a hard budget on what a sync costs in data and battery. A correct app that flattens the phone by lunchtime is not a working app.
On a deployment of nine hundred installation engineers this took job completion time down by forty-two percent, and the number of lost jobs from around forty a month to zero. None of that came from the interface.