Field technicians work in basements, plant rooms, rural sites, lift shafts and factories with thick concrete walls. Inspectors visit remote installations. Sales reps travel through areas with patchy coverage. If their mobile app needs a signal to load a job or save a checklist, work stops — or, worse, people go back to paper and type it in later. For field and factory teams, an app that works offline isn't a luxury. It's the difference between an app that's used and one that's abandoned.
Online-only vs offline-capable vs offline-first
- Online-only apps load and save everything from the server. No signal, no app.
- Offline-capable apps cache some data and may let you view jobs offline, but saving often fails or is unreliable.
- Offline-first apps are designed around local data. Everything the user needs is on the device; every change is saved locally first; sync happens in the background whenever possible.
Offline-first takes more design effort, but it gives the most reliable experience — the app behaves the same whether the network is good, bad or absent.
What data goes on the device
Storing everything on every device isn't practical or secure. Decide what each user needs:
- Their assigned jobs for today and the coming days.
- Customer, site and equipment details for those jobs, with relevant history.
- Checklists, forms and procedures.
- Reference data: products, parts, reason codes, price lists if needed.
- Documents and manuals they're likely to need, downloaded in advance.
Data is refreshed whenever the device is connected, and old data is cleared to save space.
Sync: the heart of offline-first
Every change made offline is recorded in a local queue. When connectivity returns, the app sends the queued changes to the server in order and pulls down any updates. Good sync is:
- Automatic — users don't need to press a sync button, though a manual option helps.
- Resilient — interrupted syncs resume without duplicating data.
- Visible — the user can see whether everything is synced and what's pending.
- Efficient — only changes are sent, and large files are uploaded separately.
Handling conflicts
When two people change the same record while offline — or the office changes a job while the technician has it offline — the system must decide what to do. Options include:
- Field-level merge — if the office changed the appointment time and the technician added notes, keep both.
- Rules by field — for example, the technician's completion data always wins; the office's scheduling data always wins.
- Append-only records — notes, photos and readings are added rather than overwritten, so conflicts can't occur.
- Flag for review — genuine conflicts are shown to a supervisor to resolve.
Designing data so most changes are additions rather than overwrites removes most conflicts at the source.
Photos, signatures and files
Field apps capture a lot of media: before-and-after photos, signatures, voice notes, documents. These are stored locally, compressed sensibly and uploaded in the background, with progress visible and automatic retry. Large uploads should prefer Wi-Fi where the user or company prefers, and the job should sync its data even while photos are still uploading.
Reassigned and cancelled jobs
If a job is reassigned or cancelled while a technician is offline, the technician may still work on it. When the device reconnects, the app should tell the technician clearly and the office should see what happened. Clear rules and messages prevent confusion.
Security on devices
- Require app login, with biometric unlock for convenience where appropriate.
- Rely on device encryption and keep stored data to what the user needs.
- Expire sessions after a period and require re-authentication.
- Allow administrators to revoke a user's access so data is cleared on the next connection if a device is lost.
- Avoid storing sensitive data like full payment details on the device.
Native, cross-platform or PWA?
All three can work offline to some degree:
- Native apps (iOS and Android separately) offer the most control over storage, background sync and device features.
- Cross-platform apps (one codebase for both) offer most of the same capabilities with less duplicated effort, and suit most field apps.
- Progressive web apps run in the browser, install from a link and can work offline using caching and local storage. They're excellent for lighter use cases; for heavy offline data, large media and background sync, a native or cross-platform app is usually more reliable, especially on iOS.
Testing in real conditions
Offline apps must be tested where they'll be used: in basements, on flaky mobile networks, with airplane mode toggled mid-save, with low battery and full storage, on older phones. Lab testing on office Wi-Fi misses most real problems. Pilot with a small group of field users before full rollout.
An example
A lift maintenance company's first technician app required connectivity to save each checklist step. In machine rooms and shafts, saves failed and technicians gave up, completing paper sheets instead. The rebuilt offline-first app downloaded each technician's jobs every morning, saved every step locally and synced automatically when they returned to the street. App usage rose to nearly all jobs within weeks, and paper sheets disappeared.
Common mistakes
- Testing only on office Wi-Fi.
- Treating offline as an add-on late in the project.
- No visible sync status.
- No conflict rules.
- Storing more data on devices than users need.
How we build
Corposol builds mobile apps for technicians, inspectors, sales teams and shop floors that work reliably offline. Talk to us about your field app.
Frequently asked questions
What does offline-first mean?
The app is designed to work fully from data stored on the device, treating the network as something that comes and goes. Changes are saved locally first and synced in the background when connectivity is available.
What happens if two people edit the same record offline?
The app needs a conflict rule — for example, field-level merging, the latest change wins for some fields, or flagging the conflict for a person to resolve. The right rule depends on the data.
Can photos and signatures be captured offline?
Yes. They're stored on the device and uploaded when connected, often in the background and resumable if the connection drops.
Are offline apps less secure?
Data on the device needs protection: device-level encryption, app login, limiting what's stored to what the user needs, and the ability to revoke access if a device is lost.
Can a progressive web app work offline?
Yes, to a good extent. PWAs can cache the app and store data locally. For heavy offline use, large media or deep device integration, native or cross-platform apps are often more robust.
