Contents7
A cellar to inspect, an underground car park, a rural building site, a warehouse with thick walls: the field is often where the network does not reach. An app that shows an error message at that moment has lost. The technician writes in a notebook, takes photos with the phone camera, and everything goes back to the journey the app was meant to remove: re-entry in the evening, lost photos, information that arrives a day late.
Offline is not a box you tick in a quote. It is a series of decisions, from the simplest to the most expensive, which are better made with eyes open.
In short
Offline has three levels: the app opens, data already viewed stays readable, entries wait for the network to return.
The third level is the most useful in the field, and the most expensive, because everything happens at sync time.
Two people editing the same record offline raise a business question, not just a technical one: who is right?
An app installed from the browser covers the first two levels; the third is sturdier in a native app.
The decision rests on evidence: where do your teams lose the network, and for how long?
The three levels of offline
Saying an app “works offline” can mean three very different things.
- It opens.
The screens are kept on the phone: the app launches without a network instead of showing a blank page. Its data still needs a connection to update.
- It can be read.
Records already opened (the client’s file, the plan, today’s job list) stay readable, with the date of their last update.
- It records.
Entries, ticked boxes and photos are kept on the phone, then sent to the server when the network returns, with nothing lost and nothing sent twice.
Each level builds on the previous one, and each adds work. The first is almost a setting. The second means choosing what the phone keeps, and for how long. The third changes the app’s architecture.
From the field
Challenge Us opens without a network
Challenge Us, a group-challenge app we developed, keeps its interface in cache and opens even offline. Its data comes from the server and needs a connection to update: that is the first level, enough for a use where people enter their day once they are back online. The details are in the Challenge Us case study.
What offline changes for the team
The benefit is not measured in features but in steps the team no longer has to take.
- Enter it on the spot, once. The report is made in front of the equipment, not from memory on the way back to the van. Details forgotten within twenty minutes stay in the record.
- No more double track. Without offline, the team keeps the notebook “just in case”, and re-entry comes back. With it, the notebook really goes.
- Time-stamped evidence. The photo and the time of the job are attached to the record when they are taken, not when the network comes back.
- Less waiting. Nobody hunts for a signal bar, phone held in the air, before moving to the next task.
These gains assume the app is already adopted: the conditions for adoption, short screens and frictionless sign-in, are covered in what a field app changes for your teams.
The real issue: synchronisation
Saving on the phone is the easy part. The work lies in the network’s return.
An offline entry, from phone to server
- The entry
Saved on the phone, with a unique identifier created on the spot.
- The wait
The entry joins a queue the user can see (“3 uploads pending”).
- The network returns
The queue goes to the server, in order.
- The check
The server verifies rights, discards an upload it already has and settles conflicts.
Three questions decide the quality of that journey.
Never send anything twice. An interrupted upload will be retried. If each entry carries a unique identifier created on the phone, the server recognises an upload it already received and creates no duplicate.
Do not trust the phone’s clock. It can be set by hand. The phone can record the time of entry for information, but what matters (the day of a job, a deadline) is validated on the server, as we explain in app security.
Know who is right. Two technicians edit the same record, each in a basement. The first to get the network back sends their version; does the second overwrite it? Firestore, Google’s database for apps, says it plainly in its offline documentation: for multiple changes to the same document, the last write wins.
Key takeaway
A conflict is settled by a business rule
“Last write wins” suits many fields. For others (a stock level, a signature, a status approved by a manager), the rule must be written before development: add up, reject, or flag the conflict to a person. It is a business decision, which the developer turns into code.
Installable web app or store app
The choice between an installable web app and a native app, compared in PWA or native app, takes on a particular colour when the network drops.
Installable web app
It opens offline and keeps data in the browser
The browser may delete that data if the phone runs short of space
Background upload when the network returns is not available everywhere
Native app
It keeps its data in a real database on the phone
Sync can be finely controlled, including when the app is closed
It goes through the stores or a private distribution channel
The web’s limits are documented. WebKit, Safari’s engine, describes in its 2023 storage policy automatic eviction of a site’s data when the quota is exceeded, when the device is short of space or when the site has not been used for some time. The interface that lets a web app defer an upload until the network returns does not work in some of the most widely used browsers, according to MDN’s documentation. And on the web, Firestore’s offline persistence is disabled by default, with a piece of advice: ask users whether they are on a trusted device before keeping sensitive data.
On the native side, an app built with Expo has a SQLite database on the phone, which persists across app restarts. The choice of back end matters too: Firestore provides offline out of the box on Android and iPhone, whereas a Postgres database such as Supabase’s requires organising sync yourself, as Supabase, Firebase or your own server explains.
For an internal tool that mostly needs to open and be read without a network, the installable app is often enough. When important entries must survive a day without a network, the native app is safer.
What it costs, and when to skip it
Full offline is one of the decisions that move the price of an app the most: it touches every entry screen, adds tests (cutting the network mid-upload, two phones on the same record) and has to be maintained with every release, like the rest of the maintenance budget.
You can skip it when outages are short and rare, when an entry can wait a few minutes, or when the app is mostly for reading. You cannot skip it when the team spends hours without a network, or when a lost entry has a real cost: a disputable report, an unproven delivery, a job billed twice.
Where to start
- Map the dead zones.
For two weeks, the team notes where the network drops, and for how long.
- Sort the actions.
Which must work without a network (recording a report, taking a photo), which can wait (browsing the full history).
- Write the conflict rules.
For each piece of data several people can edit, who wins.
- Test without a network.
On a first version, in airplane mode, with the people who will use it.
These choices go into the app’s requirements document and are tested early on a clickable prototype. The other decisions in a project each have their article: custom or off-the-shelf, publishing under your own developer account, notifications, subscriptions, the client portal, AI in an app, taking over an abandoned app, low-code and vibe coding.
Frequently asked questions
Can a web app work offline?
Yes, to open and to read data already loaded: a service worker keeps the interface in cache, and the browser can store data. For entries that must wait a long time for the network to return, the browser offers fewer guarantees than a native app, which keeps its data in a database on the phone.
What happens if two people edit the same record offline?
It depends on the rule in place. By default, many systems keep the last version the server receives. For sensitive data (a stock level, an approved status), you need a business rule written before development: add up, reject, or flag the conflict to a person.
Does offline mode add a lot to the price?
The first level (the app opens without a network) costs little. Offline entry with sync costs significantly more, because it touches every entry screen, needs specific tests and has to be maintained with every release. That is why it should be decided from field evidence, not as a precaution.
Is the data kept on the phone safe?
It is exposed if the phone is lost or shared. Keep only what is necessary on the phone, delete it on sign-out, and never store a secret there. On the web, Firebase recommends asking users whether they are on a trusted device before keeping sensitive data.
Sources
- Firebase documentation, access data offline (new tab)firebase.google.com
- WebKit, updates to storage policy, August 2023 (new tab)webkit.org
- MDN, Background Synchronization API (new tab)developer.mozilla.org
- Expo documentation, SQLite (new tab)docs.expo.dev
Jim · founder of Brain Plus AI
Also in web and mobile apps
Understand6 min
Field team app: what it changes for your staff
Technicians, drivers, travelling sales staff, site crews: an internal app spares them paper, photos lost in a messaging app and evening re-keying. Here is what it changes, and what it takes for it to be used.
Choose and price6 min
App back end: Supabase, Firebase or your own server
Behind an app’s screens you need accounts, a database, files and rules. Supabase, Firebase and your own server answer this in three ways, and each commits you to different things.
Choose and price6 min
PWA or native app: which to choose for your business?
An installable web app (PWA) goes onto the home screen without going through the App Store or Google Play, and is enough in many cases, not all. Here is how to decide, and why we start with it.