"And it should work without internet too" is a sentence that shows up often in mobile app briefs and sounds harmless. In practice it's one of the biggest architectural decisions in the whole project — not because it's extremely difficult technically, but because it changes how data is handled everywhere in the app, not just on one screen.
Why it can't be added afterwards
An app designed around the assumption of a constant connection handles data simply: a request goes to the server, the server responds, the screen renders. If offline mode gets bolted onto that setup later, a question appears on every single screen — what should happen when there's no connection right now. "Show an error" isn't offline mode; it's just another way of saying the app doesn't work offline.
Genuine offline mode requires the app to work with a local copy of the data from the start, one that syncs continuously with the server, rather than treating the server as the sole truth that's always waited for. This decision runs into the data layer, into how new records created offline are identified, and into how the app behaves visually.
What the user needs to know at every moment
An app that doesn't distinguish between verified data and a local copy lies to the user in a subtle but dangerous way. It shows a number that looks like a fact, when it's actually the last known value from an hour ago.
Three things a user should always know, without having to ask:
- Whether the connection is active, simply and visibly, not buried in settings.
- Which changes are waiting to be sent. The queue of writes made offline that haven't reached the server yet needs to be visible — otherwise the user assumes their work is done, while it's actually sitting on the phone.
- That something failed to send. A silent sync failure is worse than a visible error, because it only surfaces once somebody notices elsewhere — a colleague not seeing an entry that was supposed to have been sent long ago, for instance.
How synchronisation works
Once the connection is restored, the app has to send the accumulated changes in the right order and resolve any conflicts. The basic principle:
- Changes are stored locally with a timestamp and an unambiguous identifier, so they can later be matched to the server record.
- The queue is sent incrementally, not all at once — with a large number of changes or an unstable connection, a bulk send would fail entirely instead of partially.
- The server acknowledges each write individually, so the app knows exactly what has synced and what's still waiting.
- Failed items stay in the queue and are retried, with a visible status for the user.
Conflicts: when two people change the same thing
This is a scenario that almost never comes up in a brief and almost certainly happens in production. Two technicians in the field, two salespeople, two warehouse staff — each working offline, each changing the same record in a different way, and when both come back online the system has to decide what wins.
| Strategy | How it works | When it fits |
|---|---|---|
| Last write wins | the newer timestamp overwrites the older one | simple fields, low risk of data loss |
| Field-level merge | only the fields that genuinely differ get changed | records with several independent fields |
| Escalate to a human | the system shows both versions and lets someone choose | important or sensitive data |
| First write wins, second is rejected | the second user is warned and must redo the change | when it matters to know about the loss |
Which strategy to pick isn't a technical question — it's a decision about what the company prioritises in a conflict: simplicity, or certainty that nothing gets silently lost. For critical data, like a report that invoicing depends on, it pays to escalate to a human rather than automatically picking a winner. We discussed the same "escalate rather than silently decide" principle in our article on field service automation, where offline technician reports face exactly this problem.
What's worth settling before development
- Which data has to work offline and which can require a connection — not everything in the app needs the same level of offline support.
- How long the app can stay offline before that becomes a problem — hours, days, weeks — and what happens to a queue that's grown very long in the meantime.
- Which conflicts are acceptable to resolve automatically and which have to go to a person.
- How offline behaviour gets tested — not just "turn off wifi", but an unstable, intermittent connection too, which is more common in real operation than a total outage.
Summary
Offline mode is an architectural decision to make at the start of a project, not an add-on tacked on at the end. The app always has to make clear whether it's working with verified or local data, the queue of unsent changes has to be visible, and the conflict resolution strategy has to be chosen based on what the company genuinely risks by losing data — not on what's simplest to code.
The scope of a solution like this depends on how data-heavy the app is and how many users might work on the same records offline at once. If you're planning a mobile app with offline support, we'll go through your specific requirements in a no-obligation consultation, or take a look at our development solutions.