The apps that matter most to a business are often used where the network is worst: a delivery van in a basement car park, a technician inside a plant, a sales agent in a district town, a surveyor on a site. An app that assumes a connection fails exactly when the work is happening. Offline first means designing so that the app works without a network and treats the connection as a bonus, not a precondition.
This article sets out how we design such an app, from data storage to the words on the screen, and how we test it before anyone in the field finds out the hard way.
Decide what the app must do offline
Not everything needs to work without a connection, and the list decides the architecture. Write down the tasks the user must complete offline, the tasks that can wait, and the tasks that genuinely need the server, such as a payment authorisation. A delivery app must capture a signature and a photo offline; it can defer route optimisation; it cannot verify a card without a network.
The list also decides how much data to keep on the device. A technician needs today's jobs and the parts catalogue; not the company's full order history. Downloading less makes the app faster, the sync simpler and the device safer if it is lost.
Store locally, sync in the background
The app writes every change to a local database first and shows it immediately. A sync process then pushes changes to the server when a connection exists and pulls what has changed on the server. The user never waits for the network to see their own work.
Three design rules keep this sane. Give every record an identifier generated on the device, so a job created offline has a stable id before the server has seen it. Record changes as a queue of operations, not as a snapshot, so the server can apply them in order. And keep the sync process independent of the screens, so it runs whether or not the user is looking.
Decide the conflict rules before the code
Two people will edit the same record while one of them is offline. It will happen in the first week. The question is what the system does, and the answer is a business rule, not a technical one.
The common options: the last write wins, which is simple and sometimes wrong; field-level merging, where non-overlapping changes both survive; a rule that one role's changes take precedence; or a review queue where a person resolves the clash. Choose per record type during discovery, write the rule into the scope, and show the user what happened when a conflict was resolved rather than resolving it silently.
Tell the user the truth
The interface has to show three things at all times: whether the device is connected, whether the user's changes have reached the server, and whether the data on screen is current. A small, persistent indicator does this; a modal that blocks the screen every time the signal drops does not.
Pending changes should be visible per item, so a driver knows which deliveries are still queued. When a sync fails for a reason the user can fix, such as a photo that is too large, say so and let them retry. When it fails for a reason they cannot fix, keep the queue and try again without asking. Never lose a change and never make the user re-enter one.
Handle the hard parts explicitly
Photos and files. They are large, and a queue of forty photos on a weak signal takes a long time. Compress on the device, upload in the background with resumable transfers, and show progress per file. Let the record sync before its attachments do, so the office sees the job even if the photos arrive later.
Time. Device clocks are wrong more often than expected. Record the device time and the server receipt time separately, and decide which one the business reports use.
Authentication. A token that expires while the user is offline must not lock them out of their own queued work. Keep the local data accessible, refresh the session when the connection returns, and only then push the queue.
Data on lost devices. Encrypt the local database, tie it to the device's own secure storage, and provide a remote wipe through the device management your organisation uses. The less the app stores, the less this matters.
Battery and data allowance. A sync engine that retries every few seconds on a weak signal drains the battery and the data plan by lunchtime. Back off between attempts, sync in batches, prefer Wi-Fi for large uploads when the user allows it, and let the user see what a sync will cost before it starts. Field staff notice battery life before they notice features, and an app that empties a phone by midday is uninstalled by the end of the week.
Test it the way the field will use it
Offline behaviour is not tested by turning airplane mode on and off at a desk. The test plan includes: a network that drops mid-sync, a network that is present but too slow to be useful, a device that restarts with a full queue, two devices editing the same record, a session that expires while offline, and a day's worth of realistic work with no connection at all.
What it means for the estimate
Offline first adds real work: the local data layer, the sync engine, the conflict handling and the extra testing. In our experience it adds weeks, not days, to a field app, and it is cheaper to include from the start than to retrofit after a launch that failed in a basement. The mobile app development page lists what a build includes; tell us where the app will be used, and we will tell you which parts of this article apply to it.
