Offline mode app: when you need it and how it works

The short answer

Offline mode means an app keeps working without an internet connection, usually by storing data on the phone and sending changes to the server when the connection returns. Apps used underground, in rural areas, on journeys or in the field need it most. Syncing saves each change locally, queues it, uploads it later and settles any clash with someone else's edit.

What an offline mode app is

An offline mode app is one that does something useful when the phone has no connection, instead of showing a blank screen and an error. The something can be small or large. Some apps only remember the last screen the user looked at. Others let a person work for a whole shift with no signal and send everything afterwards.

The phrase offline first app describes the far end of that range. Android's developer guidance describes an offline-first app as one that can run all of its core functions, or a vital part of them, without internet access. In that design the phone keeps its own copy of the data, the screens read from that copy, and the network is used to keep the copy in step with the server. An online-only app works the other way round: every screen asks the server first.

Neither approach is right for every app. Offline support is a feature with its own design and testing work, so the useful question is how much of it your users need. The rest of this guide helps you answer that.

Five levels of offline support

Offline is not a switch. Apps sit at different points on a scale, and each step up asks more of the build. Agreeing which level you want is the first useful decision.

Most business apps sit at the second or third level. The fourth and fifth make sense when people create data in places where the signal cannot be trusted.

Which apps need offline mode

An app needs offline mode when losing signal costs the user something real: a missed job, lost work, a ticket they cannot show. Four questions find out whether that applies to yours.

• Where is the app used, and how often is the signal poor or missing there?
• What happens to the user if a screen will not load at that moment?
• Does the user create or change data, or only read it?
• Would the user be able to wait until the signal returns?

The apps that tend to answer yes are inspection and survey tools, delivery and field service apps, warehouse and storeroom counts, travel guides, event apps for crowded venues, and learning apps with downloaded lessons. Note-taking and task apps are in the same group, because people expect their work to be safe wherever they are.

Apps that exist to show something live gain less. A video call, a live order tracker or a chat window is only useful with a connection. They still need to fail politely, with a clear message and no lost input, but a full offline mode would add cost without adding value.

How syncing works when the connection returns

Sync means keeping the copy on the phone and the copy on the server the same. For an app that records changes while offline, it usually runs in this order.

1. The user acts, for example by saving a form. The app writes the change to a database on the phone at once and shows it as saved or pending.
2. The change joins a queue of things waiting to be sent, each with the time it was made and the record it touches.
3. The app watches for a usable connection. When one appears, it sends the queue in order.
4. The server checks each change against its rules, accepts or rejects it, and replies.
5. The app marks accepted changes as saved, shows any rejected ones to the user, and fetches changes made elsewhere since the last sync.
6. The screens refresh from the phone's copy.

Android's guide names two broad ways to fetch those outside changes, pull-based and push-based. In the first, the app asks the server for updates, for example when it opens. In the second, the server tells the app that something has changed. Many apps use both. The operating systems also limit what an app may do in the background, and the limits differ by platform and version, so ask your developer to check the current documentation for iPhone and Android before promising users automatic updates.

What happens when two edits collide

A conflict occurs when the same record is changed in two places before they sync. It might be two staff members, or one person with a phone and a tablet. The app and the server need a rule for which change wins. Android's guide mentions last write wins as one strategy: the most recent change replaces the earlier one.

The right rule depends on the data, as the table shows.

Whatever rule you choose, write it down in plain words before the build starts. It is a business decision as much as a technical one, and a developer should not have to guess it.

Design details that are easy to miss

• Show the state. A small banner when the phone is offline, and a marker on items waiting to send, tell users whether their work is safe.
• Say what will not work. Searching the whole catalogue, taking payments and creating new accounts usually need the server. Disable or explain them instead of letting them fail.
• Decide how sign-in behaves. A person offline for days may hold an expired session. Define whether they can still open their saved work.
• Think about storage. Downloaded content takes space on the phone, so give users a way to see it and clear it.
• Protect the data on the phone. A lost phone with a full offline copy is a risk. Ask your developer how the stored data is protected and which records should never be kept on the device.
• Plan for updates. When a new version of the app changes how data is stored, the data already on phones must be converted without loss.

Offline rules also touch income. Paid features, subscriptions and adverts often need a connection to check status, so settle what happens offline early. The guide to app monetisation models explains the main ways apps earn, which helps you see where a connection is required.

What offline support does to scope

Offline support changes the size of the whole project. It reaches past any single screen. The work grows with the number of data types that must work offline, whether users create data or only read it, how many people can edit the same record, and how bad the signal is where the app is used. Ask each builder to describe the online-only version and the offline version separately, so you can see what the difference involves. A single line reading offline mode hides too much.

Draw the offline states before building starts. Every screen needs a version for no connection, and many need a waiting-to-send version. The guide to app wireframes and prototypes shows how to sketch those screens cheaply, while changing them is still easy.

Ask any candidate builder which offline apps they have shipped and how they dealt with conflicts. The comparison of in-house, agency and freelancer routes lists questions worth putting to every team you consider.

How to test offline behaviour

Test on real phones, in the places where the app will be used. A test room with strong wifi hides most of these problems.

• Turn on aeroplane mode at each step of the main task and check what the user sees.
• Cut the connection halfway through saving, then restore it.
• Try a weak signal as well as no signal. A weak connection is often worse, because requests hang instead of failing.
• Close the app while changes are still waiting, then reopen it.
• Edit the same record on two devices and sync both.
• Return to the app after a long gap and check that sign-in and old data behave as designed.
• Fill the phone's storage and see how the app copes.

Telling users, and handing the rules over

If the app works offline, say so in the store listing and in the first screens, and describe it honestly: what works, and what needs a connection. The guide to app store optimisation basics covers the listing fields where that information goes.

Write the sync rules, the offline screens and the known limits into the documents you receive at the end of the project. They are exactly what a new developer will need later, and preparing for a website or app handover explains what to ask for. If you want a team to build the app, the mobile app development page describes what Liftup Technologies builds.

Related guides

• Mobile app development
• App store optimisation basics
• How to prepare your business for a website or app handover
• In house vs agency vs freelancer for app development
• App Monetisation Models: How Apps Make Money Explained
• What to build in the first version of your app

Questions and answers

What is offline mode in an app?

Offline mode lets an app keep doing useful work when the phone has no internet connection. It usually works by storing data on the phone, so screens can read it without the network, and sending any changes to the server later. How much works offline is a design choice.

Which apps need offline mode?

Apps used where the signal is poor or disappears benefit most, such as inspections, deliveries, warehouse work, travel and events. Apps whose purpose is live information, like video calls or live tracking, gain little, though they should still fail politely with a clear message.

How does syncing work when the phone reconnects?

The app saves each change on the phone, adds it to a queue and sends the queue to the server once a connection returns. The server accepts or rejects each change, and the app then fetches changes made elsewhere. A written rule decides what happens when two edits clash.

Is an offline first app the same as caching?

No. A cache keeps recent data so screens load quickly and may show the last view offline. An offline first app treats the phone's own database as the main source for its screens and lets people create and change records with no signal.

Can I add offline mode after launch?

Often yes, but it is easier when planned from the start. Adding it later means changing how the app stores and reads data, which touches many screens. Tell your builder early which actions must work with no signal.

Do payments and sign-in work offline?

Usually not fully. Payments, creating accounts and checking subscription status normally need the server. An app can record an order and complete the payment later, but that needs careful design and must follow the payment provider's rules, so check the current documentation.