Offline field app: how do you design one?

The real cost of offline

An app that reads and writes live to a server is simple: a single source of truth, no ambiguity. Offline breaks that model. You need a local database, a queue, a conflict-resolution strategy and an interface that tells the user what has been sent and what is waiting. That is a real extra cost. It is worth it when the alternative is a technician writing on paper and re-entering it in the evening, which costs time, produces errors and loses photos.

Decision 1 — what should the app carry?

Carrying everything is not viable: a fleet of several hundred machines with its full history will not reasonably fit on a phone, and the initial sync becomes endless. The right granularity is almost always the technician's day: their assigned jobs, the records of the equipment involved, the applicable checklists, and only the recent history of that equipment.

Decision 2 — who wins in a conflict?

Two technicians edit the same record offline. When the network returns, something has to give. Three strategies are possible: last sync wins, first wins, or both versions are kept with an office arbitration. The choice depends on the data. For an hour meter, the higher value is probably the right one. For a work report, you should never silently overwrite: keep both and ask. The only unacceptable answer is losing an entry without saying so.

Decision 3 — what happens to the photos?

Photos account for most of the data volume. A job typically has three to seven, and a photo from a recent phone weighs several megabytes. Sent as-is over a weak network, they block synchronisation. So you need to resize and compress on the device before sending, send photos separately from the data so the report arrives even if a photo fails, and allow an interrupted upload to resume.

Decision 4 — how do you know it has been sent?

A technician who doesn't know whether their report has been sent will take a screenshot “just in case.” That is the sign of an interface that doesn't own its own state. The app must always show how many items are pending, attempt sync as soon as the network returns, and never delete local data before the server confirms it.

This guide describes a practice, not legal advice. The obligations that apply depend on your equipment, its use and your sector: check them with your inspection body or your legal adviser.