What working offline really involves
Most apps are windows onto a server. Every screen asks the server for data, and every action is sent straight back. Take the connection away and the window goes blank. An offline-capable app is built the other way round. It keeps its own copy of the data on the phone, works against that copy, and treats the server as something to synchronize with when it can.
That change touches nearly every part of the app, which is why it must be decided at the start. Adding offline support to a finished online app usually means rebuilding its data layer. It also raises questions that are about the business as much as the technology, and those are the subject of this guide.
Decide which tasks must work offline
Supporting everything offline is rarely necessary and always expensive. Walk through a working day with the people who will use the app, and sort each task.
| Kind of task | Example | Offline difficulty |
|---|---|---|
| Looking things up | Job details, manuals, price lists, a customer's history | Low. Download in advance and refresh when online |
| Capturing new records | Inspection forms, readings, photos, signatures | Moderate. Queue and send later |
| Changing shared records | Updating a job status that others also edit | High. Conflicts must be settled |
| Acting on live quantities | Reserving stock, booking a slot, taking a card payment | Very high, or not sensibly possible offline |
The first two rows cover what most field teams need. Tasks in the last row depend on a shared truth held by the server, and the usual answer is to let the user record a request that is confirmed once the phone is online again.
Decide what data lives on the phone
- 01
What does each person need for their day?
Why it mattersDownload a person's own jobs, customers and reference data, not the whole database. Less data means faster sync and less exposure if a phone is lost.
- 02
How fresh must it be?
Why it mattersReference data may be fine if refreshed each morning. A job list may need refreshing whenever a connection appears.
- 03
How large are the files?
Why it mattersPhotos, drawings and manuals fill storage and use mobile data. Decide what is downloaded in advance and what on request, and whether large uploads wait for Wi-Fi.
- 04
How long can someone stay offline?
Why it mattersA few hours in a basement and several days at a remote site are different designs. The longer the gap, the more conflicts and the larger the queue.
- 05
What must never be stored on the device?
Why it mattersSome data is too sensitive to keep on a phone. That may rule a task out of offline use.
Plan synchronization and conflicts
When the connection returns, the app sends its queued changes and collects what changed on the server. Most of the time nothing clashes. The design work is in the cases where something does.
| Conflict rule | How it works | Suits |
|---|---|---|
| Last change wins | The most recent save replaces the earlier one | Low-value fields where an overwrite does no harm |
| Field by field | Changes to different fields of one record are combined | Records edited by several roles, each owning different fields |
| Server decides | The server applies business rules, for example a status can only move forward | Workflows with a fixed sequence |
| Ask a person | Both versions are kept and someone chooses | Important records where silent loss is unacceptable |
| Append only | Nothing is overwritten: each entry is added to a list | Notes, readings, photos, logs |
Choose a rule for each kind of record, and write it down in plain language so that the business can approve it. Two further details prevent most trouble. Each record created offline needs an identifier made on the phone, so that sending it twice cannot create a duplicate. And every queued change should be retried safely until the server confirms it.
A worked example
An elevator maintenance app
This example is invented to show the decisions in order. Technicians service elevators in shafts and basements where phones have no signal.
- TasksOffline: viewing the day's jobs and each unit's service history, completing the service checklist, taking photos and capturing the customer's signature. Online only: ordering parts, because stock must be checked.
- DataEach technician's phone holds their jobs for two days and the history of those units. Manuals are downloaded per unit model the first time they are opened.
- ConflictsChecklists and photos are append only. Job status is decided by the server, which accepts a move from assigned to done but refuses to reopen a job closed by the office.
- PartsA technician offline can add a parts request to the job. It is sent and confirmed against stock when the phone reconnects, and the technician is notified of the result.
- FeedbackEach job shows one of three marks: saved on this phone, sending, or saved to the office. A technician can see at the van whether anything is still waiting.
Technicians stop keeping paper notes to retype later. The office sees completed jobs within minutes of a technician leaving the building, and the one task that cannot work offline is handled as a request.
Security, sign-in and what the user sees
- Protect data on the device. Stored data should be encrypted, and the app should be able to clear it when a user signs out or a phone is reported lost.
- Decide how sign-in works offline. A user who was signed in can usually continue. Decide how long that lasts without contact with the server, and whether a local code or biometric check is required.
- Show sync status honestly. People need to know what is saved only on the phone. A small, consistent mark on each record does more than a spinner.
- Never lose work silently. If the server rejects a queued change, tell the user what happened and keep their version so that it can be corrected and sent again.
- Warn before risky actions. Signing out, uninstalling or clearing storage with unsent work should produce a clear warning.
Test in the conditions people really work in
- 01
Test with no connection at all
Switch to flight mode, complete a full day of tasks, then reconnect and check that everything arrives once.
- 02
Test with a poor connection
A weak signal that drops mid-upload causes more faults than no signal. Use network throttling and real locations.
- 03
Test conflicts on purpose
Change the same record on two phones and in the office system, then reconnect in different orders.
- 04
Test long gaps and large queues
Leave a device offline with many photos queued and confirm that sync completes and can resume after interruption.
- 05
Test updates
Install a new version of the app over one with unsent data and confirm that nothing is lost.
Offline planning checklist
Offline workflow planning checklist
0 of 11 checkedWhat to do next
Spend a day with the people who will use the app and note where their phones lose signal and what they do then. That record decides the first table in this guide. Then use our mobile app scope planner to set the offline tasks beside the rest of the scope.
Offline capture is central to several of the products we describe, including a field service mobile app and a construction field reporting app. Tell us where your teams work and we will suggest what to support offline first.
Common questions
Can offline support be added to an existing app later?
It can, though it is closer to rebuilding the data layer than to adding a feature. An online app asks the server for everything, while an offline app works from local storage and synchronizes. If there is any chance your users will need to work without a signal, say so before development starts, even if offline features are scheduled for a later phase.
Does offline mode make an app more expensive?
Yes. Local storage, a sync engine, conflict handling, extra interface states and much more testing all add effort. The cost rises steeply with the number of record types that can be edited offline by several people. Limiting offline support to viewing and capturing new records keeps most of the benefit at a fraction of the complexity.
What happens if two people edit the same record offline?
Whatever your conflict rule says, which is why the rule must be chosen deliberately. For some fields the latest change can simply win. For others, changes are merged, decided by server rules or shown to a person. The outcome to avoid is an overwrite that nobody notices, particularly on records with financial or safety consequences.
Is data stored on the phone safe?
It can be made reasonably safe with encryption, limits on how much is stored, automatic clearing on sign-out and the ability to revoke access for a lost device. It is never as controlled as data kept only on a server. Decide which data may be held on devices, and keep the most sensitive items online only.
Would a web app work offline too?
A progressive web app can store data and work offline to a degree, and suits lighter cases such as reference content or simple forms. For heavy capture, large files, background sync and long periods offline, a native or cross-platform app is generally the more dependable choice. Our comparison of a PWA and a mobile app explores the differences.
