Why field apps should work with no signal

Ask a field technician where their app lets them down and they will name the exact places. The plant room under the hospital. The back of the frozen-goods warehouse. The second basement of the car park. Buildings that block signal are part of the job, and the job does not wait for a connection.

Most field apps are designed in an office with good Wi-Fi, so they quietly assume the network is always there. When it is not, the technician sees a spinner, writes the readings on the back of a work order, and types them in later from the van. Some of it never makes it in. Invoices go out days late. The office calls the technician to ask what happened on site, and the technician, by now at the next job, tries to remember.

What offline-first means

Android's architecture guide describes an offline-first app as one that can perform all, or a critical subset, of its core functionality without the internet. The design choice that follows is simple to say and takes discipline to build: the copy of the data on the phone is the one the app reads and writes. The server is where that data syncs to. It is never something the app waits on before letting the technician carry on.

For a field-service app, that means a technician with no signal can still:

open today's jobs and the history of the site they are standing in,
work through the checklist, take photos and log readings,
build the invoice from the parts and hours on the job,
and get the customer to sign on the phone.

When the phone reconnects, all of it syncs in the background, and the office sees the job complete a few seconds later.

Make the hard decisions before writing code

Offline-first is mostly a list of decisions, and they are cheaper to make on a whiteboard than in a bug report.

First, what travels with the phone. Today's jobs, certainly. Every past job for every customer, probably not. A sensible window might be the next two days of work plus the last few visits to each site on the route.

Second, what happens when two people change the same thing. A dispatcher reassigns a job at the same moment a technician, offline, marks it complete. Something has to win. "Last write wins" is the simple rule, and it is sometimes wrong. For field work we prefer ownership by field: the technician owns the checklist, readings and photos, and the office owns the schedule and the assignment.

Third, what must never happen offline. Taking a card payment is the usual example. The app should say plainly that it needs a connection for that step, rather than failing without a word.

Fourth, how the technician knows where things stand. A small, honest status line does the job: "Saved on this phone", "Syncing", "Synced 10:02". People trust an app that tells them the truth about their data.

Plan for it in the first release

You do not need every offline feature in version 1.0. You do need the local data store from the start. If the first release reads straight from the server, every screen gets built around that assumption, and adding offline later means rebuilding most of them.

So the first release keeps a local copy of the day's jobs, even if offline photo upload or offline invoicing comes a release or two later. On our mobile apps page, the illustrative field-service app ships offline mode as version 1.1, rolled out to half the technicians first. That only works because version 1.0 already kept its data on the phone.

Test it where it actually fails

Switching off Wi-Fi in a simulator catches the obvious bugs. The real ones only show up on site. A sync that half-finishes when the signal flickers in the car park. Photos that fill the phone's storage by Thursday. A job that shows complete on the phone and open in the office because the app was closed mid-sync.

Give the beta to the two or three technicians who work the worst sites, and ride along for a day. You will come back with a better bug list than any test plan would give you.

A good place to start

List the five places your technicians most often lose signal, and what they are trying to do in each one. That list is most of your specification. If you would like a second pair of eyes on it, here is how we build field apps.