Offline Mode: When Your App Needs It
By CodexierPublished 6 min read
Offline support appears on almost every app requirements list and is almost never defined. It can mean the app does not crash without signal, or it can mean a technician edits a work order in a basement, a colleague edits the same order in the office, and both changes survive. The first is a day of work; the second is a project of its own. This guide sets out the levels, what each costs, and how to decide from where your users actually are when the signal drops.
Who actually works offline
Sweden has good mobile coverage in towns and patchy coverage in exactly the places where work happens: basements, plant rooms, forests, ferries, the northern inland, warehouses with steel shelving. Ask the people who will use the app to describe the last time they had no signal at work and what they needed to do at that moment. If the answer is read a checklist, that is one level. If the answer is record a delivery with a signature and a photo, that is another. If nobody can remember, you probably need the first level only.
Levels of offline support
Each level adds a capability and a class of problems. Naming the level in the requirements is what turns a vague wish into something a developer can estimate.
| Level | What the user can do without signal | What the app must handle | Typical need |
|---|---|---|---|
| 1. Graceful degradation | See the last loaded screens; clear messages when actions need a connection | Cache responses, detect connectivity, retry | Almost every app |
| 2. Cached reading | Browse a chosen data set fully: schedule, customer list, manuals | Local database, background refresh, stale indicators | Sales, service, care staff |
| 3. Queued actions | Create and submit records that upload later: reports, signatures, photos | Outbox, ordering, retries, duplicate protection | Field service, transport, inspections |
| 4. Full offline editing with sync | Edit shared records offline and merge with others' changes | Conflict detection and resolution, versioning, user-facing merge decisions | Rare: shared documents, multi-user field editing |
Sync conflicts explained
A conflict happens when two people change the same record while at least one of them is offline. The app cannot know which change is right, and every strategy for deciding has a failure case. This is the mechanism that makes level four expensive: the code is not hard to write, but every rule has to be explained to users and tested for each record type.
Last write wins
The most recent change overwrites the earlier one. Simple, and silently loses work. Acceptable for low-value fields such as a note, not for a status or a quantity.
Field-level merge
Changes to different fields on the same record both survive; changes to the same field conflict. Handles most real cases but needs per-field tracking and a rule for the rest.
Ask the user
Show both versions and let a person choose. Correct, but only workable when conflicts are rare and the user understands the record. Never make a driver resolve a merge at a loading dock.
Avoid by design
Give each record one owner while it is in the field, so nobody else can edit it. This is the cheapest strategy and works for most field workflows.
Cost of each level
The cost is not only build time; it is the ongoing weight every future feature carries. At level one, a new screen is a new screen. At level three, a new screen that creates records needs an outbox entry, a retry rule and a test for what happens if the device dies mid-upload. At level four, it also needs a merge rule. Be honest about whether the workflow justifies that on every feature forever.
- Level one: a small fraction of the app budget, mostly error handling and caching. Do it always.
- Level two: a local database and a sync schedule; moderate, and it also makes the app faster online, which users notice more than offline.
- Level three: an outbox with ordering, retries and idempotent uploads so a report is never created twice. The photos and signatures are where storage and upload edge cases live.
- Level four: conflict handling per record type, plus the user interface to explain it. Often several times the cost of level three, and it grows with every new record type.
- All levels: testing time rises steeply, because every flow must be tested online, offline and in the transition between the two.
Testing offline behaviour
Offline bugs hide in transitions: the signal that drops during an upload, the connection that returns for three seconds, the phone that restarts with an outbox half sent. A test plan for offline is a list of those transitions, run on real devices, not only in the simulator's airplane mode.
- Start an action online, cut the connection mid-request, and confirm the app neither loses nor duplicates the record.
- Work offline for an hour, restart the phone, reconnect, and check everything uploads in order.
- Use a poor connection, not no connection; slow and flaky is more common than absent and breaks different code.
- Have two users edit the same record with one offline, and check the outcome matches the rule you chose.
- Fill the device storage with photos and confirm the outbox handles it and the user is told.
When you do not need this: an app used in offices, shops and homes with normal coverage needs level one and perhaps level two for speed, and any supplier proposing more is selling complexity. Where levels three and four earn their cost is a documented workflow in places without signal, with actions that must not be lost. That analysis is part of scoping a cross-platform MVP app with us: we name the level in the plan, so the estimate on the pricing page means the same thing to both sides. If you are unsure which level your users need, book a call and describe where they work.
Frequently asked questions
Is a web app or PWA enough for offline use?
For level one and light level two, a well-built PWA with a service worker can cache screens and data. Reliable queued uploads with photos, background sync and large local data sets are where native or cross-platform apps are more dependable, especially on iOS, which limits what a PWA may do in the background.
How much data can we store on the phone?
Structured data for a schedule or customer list is small; photos and documents are what fill devices. Set a rule for how many days of records to keep locally and compress photos before storing, and tell the user when storage is running low rather than failing silently.
Does offline support affect GDPR?
Yes. Personal data cached on a device is personal data you are responsible for, on a device that can be lost. Encrypt local storage, keep the cached set minimal, expire it, and make remote wipe or logout on lost devices part of the plan.
Can we add offline support later?
Level one and two can be added to an existing app with moderate effort. Level three and four are much easier to design in from the start, because they shape how records are identified and how the backend accepts uploads. If field use is plausible, decide the level before the data model is built.
Not sure which offline level your app needs?
Fifteen minutes: describe where and how your users work, and we will tell you which level fits, what it changes in the build and what it costs.
Book a free 15-minute call