Offline-first apps, in short
An offline-first app saves each action on the phone first and sends it to the server when the signal returns. Field staff can finish a job in a basement, and the office gets the record later. Storing the data is the easy part. The build stands or falls on three rules: which actions work offline, who wins when two changes meet, and whose name goes on a late change.
If you run operations at a UK or EU firm of 10 to 200 people, and your staff work away from a desk, this is for you. They might be maintenance engineers, surveyors, inspectors, installers or drivers. You may be commissioning a web application for them, or living with one that loses work when the signal drops.
Offline features look finished in a demo, because demos run on office wifi. The failures arrive weeks later, and quietly: a job note overwrites the office's change, or a safety record names the wrong engineer. Below are the rules that prevent those failures, and how to test them before you accept the software.
What offline-first means, and where the signal runs out
Android's developer guidance defines an offline-first app as one that can perform "all, or a critical subset of its core functionality without access to the internet". The phone holds a working copy of the data. Every action saves there first, and a sync step sends it to the server later.
That differs from an app that merely caches pages. A cached app can show the last screen it loaded, but it can't save anything new. The difference matters the moment someone has to record a reading, a photo or a signature.
Signal runs out more often than office staff assume. Ofcom's Connected Nations report for 2025 found 4G from all four mobile networks across 90% of England's landmass, and 76% of Wales. Those are outdoor figures. Much field work happens indoors, often in the worst places for a signal: basements, plant rooms, lift shafts, steel-framed warehouses and farm buildings.
Decide what must work offline, action by action
Not every action needs to work offline, and making everything work offline is the most expensive way to build. Walk through a normal day and give each action one of three answers: works offline, works offline with a visible warning, or needs a signal.
Say you run a 60-person property maintenance firm in Leeds. Your engineers service boilers, carry out landlord gas safety checks and fix leaks. The list for them might look like this:
| Action | Offline? | Why |
|---|---|---|
| Open today's and tomorrow's jobs, with addresses and access notes | Yes, downloaded before they leave | Nobody can start work without them |
| Record readings, photos, parts used and the customer's signature | Yes, saved on the phone and sent later | This is the work itself; losing it means a return visit |
| Mark a job complete | Yes | The office sees it when the phone reconnects |
| Check whether a part is in stock at the depot | With a warning: the last known count and when it was checked | Stock changes by the hour |
| Book a follow-up visit | Saved as a request, confirmed when the office calendar accepts it | Two engineers could pick the same slot |
| Search every customer's full history | Needs a signal | Too much data to keep on every phone |
Every screen that shows downloaded data should say how old it is. "Stock: 4, checked 07:12" is useful. "Stock: 4" is a guess dressed as a fact, and an engineer will drive to the depot on the strength of it.
Our web applications page promises every state designed, "including empty, loading, error, and permission denied". Offline adds two more. One says there is no signal. The other says a change is saved on this phone but not yet sent, with a count of how many are waiting.
When two people change the same record
Sooner or later the office and the field will change the same job while one of them is offline. When the two changes meet, the app has to pick what survives. Most apps pick by default rather than by design.
Microsoft's Dynamics 365 Field Service shows how blunt a default can be. Its documentation on offline sync judges conflicts per record, not per field. So a technician changing a work order's start time clashes with a dispatcher changing its end time. By default the technician's offline changes win and overwrite the dispatcher's; turn on conflict detection and the dispatcher wins instead.
ODK, open-source software for surveys and follow-up visits in the field, is more careful. Its server labels every late update that was based on an older version. Changes to different properties count as a "parallel update"; changes to the same ones count as a "conflict", which is flagged for someone to review.
Real conflicts are rarer than people fear. Researchers at Ink & Switch, who built prototypes of what they call local-first software, found that users "surprisingly rarely encounter conflicts". Their merging method resolves most changes on its own. It leaves one case to the app or the person: two people changing the same property of the same thing.
So design the data so that most changes can't collide, and write a rule for the rest:
| Kind of data | Example | Rule when two changes meet |
|---|---|---|
| Things that happened | Readings, photos, notes, parts used, time on site | Keep every entry; each one is new, so nothing is overwritten |
| Counts and balances | Parts in the van, visits left on a contract | Record each movement and add them up; never overwrite the number |
| Plans the office owns | Appointment time, assigned engineer | The office's version wins, and the engineer sees what changed |
| Job status | Scheduled, on site, complete, cancelled | Agree an order in writing; if the office cancels a job the engineer has completed, both see it and a person decides |
| Shared details | A customer's phone number, access notes | Merge field by field; if both changed the same field, keep both and ask someone |
The first two rows do most of the work. They record events instead of editing values, the design our guide to audit trails recommends. When two phones add parts at once, the app keeps two entries and the count stays right.
Be wary of "last write wins" as the rule for everything. In Android's description, each device stamps its changes with a time and the server keeps the newest. That trusts every phone's clock, and whichever device syncs last can erase work nobody meant to replace.
Whose name goes on a change sent late
Back in Leeds, two engineers share a tablet in the van. Priya carries out a gas safety check in a basement flat with no signal, saves the record and hands the tablet to Tom. Tom signs in at the next job, where the signal returns, and the app sends everything waiting in its queue.
With the simplest queue, the server credits Priya's check to whoever is signed in when it arrives. That is Tom. The Gas Safety (Installation and Use) Regulations require the landlord's record to include "the name and signature of the individual carrying out the check". Your record now names an engineer who wasn't there.
A queue built for shared devices follows five rules:
- Stamp each change with the person who made it, not the person signed in when it sends.
- Send each person's changes under their own sign-in. Priya's check waits on the tablet until she signs in again, and the tablet shows whose changes are still waiting.
- Keep two times: when the action happened on the device, and when the server received it. Phone clocks drift, and the gap is useful evidence.
- Give each change its own ID. If the signal drops halfway through sending and the app tries again, the server recognises the ID and records the check once, not twice.
- Treat a refusal differently from a failed connection. No signal means keep the change and retry. A refusal from the server, such as a job the office has cancelled, means stop retrying and show it to the engineer and the office.
The last rule matters most, because a refusal that hides in a retry loop looks exactly like a slow connection. Every refused change should end up in front of a person: fixed, re-sent, or cancelled with a reason.
Shared devices need the same care for what people see. When Tom signs in, the app should clear anything it stored for Priya, or her permissions leak into his session. Our guide to role-based access control explains why "may change" and "may see" are separate questions. Both apply on a shared tablet.
Web app or native app for offline work
A web app can work offline. Browsers can store data on the device and run a service worker, a small script that keeps the app working without a connection. On iPhones, three limits decide how far that goes.
First, stored data can disappear. In 2020 WebKit, the engine behind Safari, began deleting a website's stored data after seven days of Safari use without the person interacting with the site. Web apps added to the Home Screen keep their own count of days in use, and WebKit says it doesn't expect their data to be deleted. So install the app to the Home Screen on every iPhone, and check that it's been done.
Second, a web app on an iPhone can't send its queue in the background. The Background Synchronization API, which defers sending until a connection returns, works in Chrome and Edge but not in Safari or Firefox. Queued changes leave the phone when someone opens the app with a signal, so the app should try to send as soon as it opens.
Third, Apple sets the rules. In February 2024, a test version of iOS 17.4 removed Home Screen web apps in the EU, reducing them to shortcuts. Apple reversed the decision on 1 March 2024 after requests to keep them. Native apps depend on Apple too, through the App Store, so neither route is free of platform risk.
| Web app installed to the Home Screen | Native app | |
|---|---|---|
| Installing and updating | From a link; updates when it next opens | Through an app store or your device management |
| Sending queued changes on an iPhone | Only while the app is open | Can carry on in the background, within the phone's limits |
| Stored data on an iPhone | Kept when installed; a Safari tab's data can be deleted | Kept until the app is removed |
| Bluetooth instruments, such as meters and analysers | Not supported in Safari | Supported |
| One app for the office and the field | Yes | Usually a second codebase |
Our view: start with an installed web app when the field work is job lists, forms, photos and signatures. Go native when changes must send in the background, when the app reads Bluetooth instruments, or when staff upload long videos.
What a lost phone gives away
Offline working means customer data lives on the phone: names, addresses, access notes, key safe codes and photos of people's homes. The UK's Information Commissioner's Office says you "should enable storage encryption" on smartphones and tablets that store personal information. It protects the data if a device is lost or stolen.
Encryption is the floor. Keep the next day or two of jobs on the phone, and remove completed jobs once the server confirms it has them. Microsoft's field service app works the same way: records leave the device when they no longer match its offline filter.
Then add a screen lock through your device management and a way for the office to sign out a lost phone. Show key safe codes only on the day of the visit.
When you don't need an offline-first app
Offline-first adds a sync engine, conflict rules and a harder test plan. Plenty of firms don't need any of it.
- If your staff work where the signal is reliable, such as an office or a shop, keep unsent forms as drafts. Show a clear message when a save fails. That covers the odd dropout for a fraction of the work.
- If people only need to read offline, such as job sheets, manuals and drawings, a read-only copy on the phone is far simpler. With no offline changes, there are no conflicts and no queue.
- If your field process works like everyone else's, configure a product first. Both Dynamics 365 Field Service and Salesforce Field Service have mobile apps that work offline, and ODK covers offline forms and surveys. Our guide to custom software vs off-the-shelf sets out when building your own pays.
- If your field team runs on a shared spreadsheet and WhatsApp today, the first job is moving the process out of the spreadsheet. Offline working is one line in that brief, not the whole project.
Seven offline tests to run before you accept the app
A demo on office wifi proves nothing about offline working. Run these tests on the staging copy with real phones before you sign off.
- Put a phone in aeroplane mode and complete a whole job, from opening it to marking it done. Reconnect. Everything should arrive once, stamped with the time it happened.
- Take two phones offline and change the same job on both, plus the same job from the office. Reconnect them one at a time and compare the result with your written rules.
- On a shared tablet, save a change offline as one person, sign out, and sign in as another. Reconnect. The record should name the first person, and the second shouldn't see the first person's data.
- Cancel a job in the office while an engineer completes it offline. Both of them should see the refusal, and it should never vanish.
- Reconnect a phone and switch the signal off again mid-send, or force the app closed. Check the server for duplicates.
- On an iPhone, install the app to the Home Screen the way your staff will, leave it for a week, then open it offline. Today's jobs should still be there.
- Sign a test phone out remotely and check its stored data has gone.
Ask for the sync rules in writing too: which actions work offline, the rule for each kind of record, and how refused changes reach a person. They belong in your documentation, in your own accounts, next to the code.
Spend a day where the signal drops
This week, spend a day with one of your field teams, or ask them to note every place the signal drops. Beside each place, write what they do there and what they need to record. Then list the records that both the office and the field change on the same day.
Those three lists are the offline part of your brief. They tell a builder which actions must work offline, which records need a conflict rule, and whether shared devices change the design. Hand them over before anyone quotes, and judge the answer by how many of your rules it writes down.
Questions
Can we add offline working to an app we already have?
Often, in stages. Read-only offline, such as today's jobs and the documents that go with them, can usually be added without large changes to the server. Saving changes offline is a bigger job. The server has to accept changes that arrive late, recognise a change it has already received, and record who made each one and when. Have someone check the data model for those three things before anyone commits to a plan.
How long can staff work offline before it becomes a problem?
As long as the phone holds the jobs they need and has room for the photos. The risk grows with time, though. The longer a phone stays offline, the further its copy drifts from the office's, and the more conflicts it brings back. Pick a limit that suits the work, such as a warning after a day without sending, and show the office which devices have gone quiet.
Who owns the app and the data on the phones?
You should. The data on each phone is a copy of your company's records, and the master copy sits on a server in your own accounts. When we build, the code, the repository, the hosting and the documentation sit in your accounts and move to you at handover. Ask anyone who builds for you to put the same in writing.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.