Offline apps: when it's worth working without internet

An app needs to work without internet when people use it in exactly the places where the signal drops: basements, warehouses, construction sites, crowded events, on the road. If it's only used at the office on WiFi, it isn't worth the effort. Between those two extremes there are three levels, and most of the time the first or second is enough.

The starting question: where is the person using it

Don't start with technology. Start with a day in the life of whoever holds the phone:

• a technician servicing a boiler in a basement;
• a sales rep taking orders at clients in areas with poor coverage;
• a server on a big terrace where the WiFi doesn't reach the back tables;
• an organizer scanning tickets at the gate while a thousand phones around them load the network.

If losing signal stops them from working, or makes them write on paper and type it in later, the app needs an offline mode. If the signal drops rarely and the person can wait a minute, a clear message ("You're offline, try again") is enough.

Android's guide to offline-first apps starts from the same situations: slow connections, short interruptions (an elevator, a tunnel) and devices that only have internet some of the time.

The three levels of "offline"

1. Reading without internet

The app keeps the last data it saw on the phone: the client list, today's schedule, the product catalog. With no signal, the person can see it but can't change anything. It's the simplest level and covers a lot of cases. Android's guide calls it the minimum for an offline-first app: being able to read without a network.

2. Queued writes

The person fills in a report or an order, the app saves it locally and sends it on its own when the signal comes back. This works well when what they write doesn't clash with what others write, such as a service report that belongs only to them.

3. Fully offline, with sync

Several people change the same data without internet, and everything has to be reconciled when they're back online. This is where conflicts come in: if two reps change the same order, which version wins? A common rule in mobile apps is "last write wins," but it doesn't fit everywhere. With stock levels, for instance, two deductions have to be added up, not overwrite each other.

Each level takes more work than the one before, especially in testing.

What to decide up front, not later

1. What data lives on the phone. The whole catalog, or only what's assigned to that person? More data means more storage and longer syncs.
2. Which actions truly need internet. A payment, a booking for a slot that someone else might take, a real-time stock check. These stay online-only, and the app says clearly why the button doesn't work right now.
3. How the status looks. People need to see that they're offline and what hasn't gone out yet: "3 reports waiting to be sent." Without that, they close the app thinking they're done.
4. What happens on a conflict. The rule is written at the start, for each type of data.
5. How long data can stay unsynced. An hour, a day, a week-long trip? The answer changes how sync is built.

App store app or web app

Both a native app (from the App Store or Google Play) and a web app can work offline. On the web, the core piece is the service worker: a script that sits between the app and the network, can keep files in a cache and answer requests when there's no connection. It only works over HTTPS. Larger data goes into IndexedDB, the browser's database.

There's a catch on iPhones, though. Safari deletes the data a site has stored (including the service worker cache and IndexedDB) if the person hasn't used the site for seven days in Safari. Web apps added to the home screen keep their own counter and, in practice, aren't affected. For a team that uses the app every day, that's not a problem; for one used once a month, it is. We covered the web-or-store choice in our article on web apps versus store apps.

What drives the effort

We can't quote a cost without seeing the workflows, but we know what pushes it up: the level you choose (the third is by far the hardest), how many types of data sync, how many people edit the same things, and how many platforms the app runs on. Testing matters too: every flow has to be tried with signal, without it, and with signal that comes and goes.

If you'd like to work out which level you need, see our App Dev services.