Think of a gym chain's membership app. A member opens the app at the entrance on the gym's basement floor; they need to show a QR code to get through the turnstile. There is no signal in the basement. The app waits with a spinning icon, then says "Something went wrong." A queue builds up behind them, and the staff member searches for the member's name by hand. The next day there is a one-star review in the store: "The app never works."
The app does work. The problem is that the QR code is requested from the server again every time it opens. The code could have been stored on the phone; nobody had asked "should this screen open without internet?"
Offline mode is usually associated with apps built for field teams. Yet in consumer apps, too, people open the app on the subway, on a plane, in a lift, in a car park, abroad with mobile data switched off, or simply on a weak café network. The questions below are for deciding in advance how an app behaves in those moments.
1. Which screens should open without internet?
Making every screen work offline is expensive and often unnecessary. Sorting screens into three groups makes the work clear:
- Must open. Things the user shows at a door, a till or a staff member: a ticket, a boarding pass, a membership code, a booking confirmation, an order number. If these do not open without internet, the app has lost its most important moment.
- The last version is enough. Past orders, saved recipes, downloaded lessons, account details. Users would rather see data that is a few hours old than see nothing.
- Internet required. Payment, live stock, current prices, the sending side of messaging. These do not work offline; but the screen should say so clearly (see point 5).
Drawing up this list in the first design meeting is much cheaper than fixing "why won't this screen open" later.
2. What is stored on the phone, and for how long?
For each screen in the "last version is enough" group, make two decisions: whether the data is stored on the phone, and when it counts as out of date. A list of offers can be misleading a day later; past orders stay correct for months.
Stored data should be shown with its time on screen: "Last updated: today 08:40." If users know what they are looking at, old data is not a problem but a convenience. The data kept on the phone also needs a limit. An app that keeps every product image forever climbs to the top of the phone's storage list after a few months, and gets deleted.
If personal data is stored, it belongs on the same list that it is kept encrypted on the device and removed when the user signs out.
3. What happens if the user does something while offline?
Reading is the easy part. The real decision is about actions the user takes while offline: adding a product to favourites, saving a note, marking a workout as done, filling in a form.
There are two options. Either the action is refused and the user is told "try again when you are connected", or the action is written to a waiting list on the phone and sent in order when the connection returns. The second is far better for the user, but it does not suit every action. A note or a favourite can be queued; a payment or confirming an appointment slot cannot, because by the time the connection returns, that slot may be taken.
Every queued action should appear as waiting on screen, and the mark should disappear once it is sent. Users should not have to wonder whether what they did has been lost.
4. What happens if two devices change the same data?
A user adds milk to a shopping list on their tablet while deleting bread from the same list on their phone; the phone is offline at the time. When the connection returns, which one wins?
This looks rare, but it happens regularly with shared lists, family accounts and people who use more than one device. Write the rule for each type of data in advance. In most cases a simple rule is enough: additions to a list are merged, and if the same field was changed twice, the last change wins. Where a change could cause loss, such as overwriting a whole piece of text, it is safer to show the user both versions and let them choose.
5. How does the app communicate the connection state?
The worst offline experience is one where the user does not know what is going on: a loading icon that spins forever, a general "an error occurred" message, or a button that does nothing.
Instead:
- A calm, small strip at the top of the screen: "You're offline. What you save will be sent when you're connected."
- A clear explanation on buttons that need internet: "Payment needs an internet connection."
- An upper time limit for loading. If no answer arrives within a few seconds, show stored data if there is any; if not, say what is happening.
When the connection returns, handling it quietly is usually enough. Do not bother the user with a notice every time the connection changes.
6. Is a weak connection tested too?
Most teams test offline mode by switching flight mode on and off. In real life, the more common case is not no connection at all but a slow, patchy one. The phone thinks it is connected, the request goes out, and no answer comes for thirty seconds.
Add weak connections to the test plan. Both iOS and Android development tools can slow the network down and make it drop in and out. See what the screens do under these conditions: are waiting actions sent twice, does a half-finished upload lock the screen, can the user press the same button three times?
The double-sending problem matters most. The server should receive each action with a single identifier; if the same action arrives a second time, it should not save it again.
7. Is offline use measured?
How much to invest in offline mode depends on how often users actually lose their connection. That should come from measurement, not guesswork.
The app can record the number of offline launches, the number of queued actions and how long they waited before being sent (uploading the figures in bulk when the connection returns). A few weeks of data show which screens are really used without internet. Sometimes the result is unexpected: most users open the app in the same place, for example a gym's basement floor.
In short
Offline mode is not a single feature but a set of decisions. Decide which screens must open, what is stored on the phone and for how long, either refuse offline actions clearly or put them in a visible queue, write down conflict rules, describe the connection state in calm language, test weak connections too, and measure offline use.
In mobile app projects we sort screens into these three groups at the first design stage, and we write offline behaviour into the acceptance tests like any other feature.
Planning a project like this?
Plan it in 10 steps