What breaks when an app depends on the network
Many apps are thin clients. Each tap sends a request to a server, and the screen waits for the answer. When the connection drops, the app shows a spinner, then an error, and anything typed into a form may be lost. The app has not failed; it never had the data it needed in the first place.
An app that works offline is built the other way round. It assumes the network may be absent and treats a working connection as something to use when it is there.
Keep the data on the device
The first step is a local copy of the data the person needs. Phone apps usually store it in an embedded database such as SQLite, which runs inside the app with no server. Web apps can use IndexedDB in the browser. The app reads from this local copy, so screens load at once whether or not there is a connection.
Deciding what to keep is a design question. A field technician’s app might hold today’s jobs, the manuals for the equipment on them, and the forms to fill in, but not the company’s entire history. The local copy has to fit on the device and be refreshed when a connection allows.
Write locally, then send
When the person makes a change, the app writes it to the local database straight away and shows it as done. This is sometimes called an optimistic update. The change also goes into a queue, often called an outbox, of things that must reach the server.
When a connection returns, the app works through the outbox. Each change carries a stable identifier, so if the app sends it, loses the connection before hearing back, and sends it again, the server can recognise the repeat and apply it once. This property is called idempotency, and offline apps depend on it, because retries are normal rather than exceptional.
Bring copies back together
While a device is offline, other people may change the same data. When it reconnects, the app has to merge what it did with what happened elsewhere. Sometimes the changes touch different things and combine cleanly. Sometimes they collide, and the app needs a rule for which change wins, or a way to merge both.
How does offline sync work? and How are sync conflicts resolved? cover this in detail.
Talk to nearby devices directly
Syncing with a server only helps once the server is reachable. If two people are side by side in a basement, on a ship, or at a site with no coverage, neither can reach the server, but both may need the same information now.
For that, apps can exchange data directly between devices, over Bluetooth Low Energy or a local network, and sometimes relay through other devices in a mesh. The server still becomes the system of record when it is reachable again; the direct link covers the time in between.
Design for it from the start
Offline support is hard to add to an app built around constant requests, because the assumption that the server answers is spread through every screen. It is easier when it is part of the design:
- Show sync state honestly. Let people see what is saved on the device, what is waiting to send, and what has been confirmed by the server.
- Separate local success from final success. Saving a record on the device is not the same as the backend accepting it. The app should know the difference and handle a later rejection.
- Decide what needs a live answer. Payments, unique bookings, and permission changes may need to wait for a connection. Most other work does not.
- Test without the network. Use airplane mode, slow and flaky connections, and reconnection after long gaps, not just a working connection that happens to drop.