Making an App Work Offline

What "works offline" means

Android's guide to building an offline-first app defines it as an app that can perform "all, or a critical subset of its core functionality without access to the internet". It lists what such an app must do:

• "remain usable without a reliable network connection";
• "present users with local data immediately instead of waiting for the first network call to complete or fail";
• fetch data in a way that respects battery and data, "such as when charging or on Wi-Fi".

The minimum is that the app "must be able to perform reads without network access". Writing offline is optional.

Decide what must work offline

Every screen that works offline needs its data stored, kept fresh and sent back, so sort each action into one of three groups:

• Must work offline: reading the jobs, orders or notes someone needs today; filling in a form or checklist on site.
• Can wait: things that can be saved now and sent later, such as a comment, a photo or a completed inspection.
• Needs a connection: payments, live stock or prices, anything another person must see at once.

Android's guide gives a bank transfer as the example of a write that "must happen online in near real time". Deciding this early also shapes the backend. Our guide to choosing a mobile app or a web app covers how offline needs affect that choice.

Keeping data on the device

Android's guide calls the copy on the device "the canonical source of truth for the app": screens read from it, and server updates are written into it first. Common tools:

• Android: the Room library, a layer over the SQLite database. Android says the most common use is to "cache relevant pieces of data so that when the device can't access the network, your users can still browse that content while they're offline".
• Web apps and PWAs: MDN describes IndexedDB as a browser database for "significant amounts of structured data, including files/blobs". For the app's pages, scripts and images, a service worker stores responses with the Cache API.

Two warnings from MDN apply to web apps. Cached items "don't expire unless deleted", so the app must clear out what it no longer needs. And the browser "may delete the Cache storage for an origin" when space runs low, so treat it as a copy, not the only one. Our guide to progressive web apps explains how to ask for persistent storage.

web.dev's offline cookbook gives a strategy per request: "cache then network" for content that changes often, "network only" for analytics pings, and a fallback such as an "Unavailable while offline" page.

Changes made offline

Android's guide describes three ways to handle writes:

• Online-only writes: try the server and, if it fails, tell the person.
• Queued writes: put the change in a queue and send it when the app is back online, for things like "analytics events and logging".
• Lazy writes: save the change on the device first, then send it "at the earliest opportunity". Android calls this "the correct choice when the data is critical to the app", with the example of a to-do list where tasks added offline must not be lost.

Lazy writes are where conflicts come from.

Syncing when the connection returns

Android's guide calls bringing the device and server back in line "synchronization", and describes two approaches:

• Pull-based: the app fetches fresh data just before it shows a screen. It is "relatively easy to implement" and suits short gaps in connection, but long gaps leave screens stale or empty.
• Push-based: the app downloads a baseline at first start, then the server tells it when data has changed. "The app can remain offline indefinitely", but the server "needs to support synchronization".

When retrying, Android recommends exponential backoff, waiting longer after each failure, and not retrying requests that failed because the person is not signed in "until proper credentials are available". The server should also handle receiving the same change twice.

When two changes collide

If someone edits a record offline while a colleague edits the same record online, the app has two versions. Android's guide says conflict resolution "often requires versioning": the app records when each change was made, and the server "has the responsibility of providing the absolute source of truth".

The common approach for mobile apps, according to the guide, is "last write wins": each change carries a timestamp and the server keeps the newest. Simple, but the earlier edit is lost. Alternatives:

• Last write wins is fine for settings, bookmarks and status flags.
• Field by field suits forms where two people change different fields of the same record.
• Keep both and ask suits notes, quotes and anything where a lost edit costs real work.

Background work on Android and iPhone

Waiting changes should go out even if the app is closed.

• Android: the WorkManager library lets tasks "persist across app restarts and device reboots". Work can wait for conditions such as "an unmetered network" or enough battery, and retries can use exponential backoff. Android lists "periodically syncing application data with a server" as a typical use.
• iPhone: Apple's guide to choosing background strategies explains that the system may move an app to the background "at any time". The app can ask for extra time to "finish sending a message or complete saving a file". For regular refreshes, an app refresh task gets "up to 30 seconds of background runtime", and "the system decides the best time" to run it. For large transfers, Apple's guide to background transfers describes tasks that "continue to run even when your app is suspended".
• Web apps: MDN's Background Synchronization API lets a service worker send deferred requests "once the user has a stable network connection", but MDN marks it as not working "in some of the most widely-used browsers", so a web app also needs to retry when it is next opened.

On every platform the system decides when background work runs, so do not promise instant sending.

Telling people what is happening

People need to know that they are offline, what still works and whether their changes are saved:

• a small, calm banner such as "You're offline. Changes will be sent when you reconnect", not a blocking error;
• a mark on each item that has not been sent yet, and "Saved on this phone" rather than "Saved" until it reaches the server;
• online-only actions disabled with a short reason, as Android's guide suggests;
• a clear message if a change could not be sent, with a way to retry.

Do not lean on the browser's online flag alone. MDN's page on navigator.onLine says a connection to a local network "is considered online, even though the LAN may not have Internet access", so the property "is inherently unreliable": use it for hints, and treat a failed request as the real signal. Our guide to app onboarding covers first-run screens, which should also cope with no signal.

A checklist

• Each screen and action is marked: works offline, saved for later, or needs a connection.
• The app reads from the device first and shows data without waiting for the network.
• Changes that matter are saved on the device before they are sent.
• Queued changes are retried with backoff and survive the app closing.
• The server accepts repeated requests safely and has a rule for conflicts.
• Stored data is cleaned up, and nothing important lives only on the device.
• People can see when they are offline and which changes are not sent yet.
• It is tested in airplane mode, on a weak signal and with the app closed mid-sync.

Frequently asked questions

What does it mean for an app to work offline?

At a minimum, the app shows the data a person needs from a copy stored on the device, without waiting for the network. Many apps also let people make changes offline, save them on the device and send them to the server when the connection returns.

Can a web app work offline, or only a native app?

Both can. A web app or PWA uses a service worker and the Cache API for its files and IndexedDB for data. A native app has fuller control over storage and background syncing, which matters for heavy offline use.

What happens if two people change the same record offline?

The app records when each change was made and the server decides which version to keep. A common rule is last write wins, where the newest change is kept. For notes or forms where a lost edit costs real work, merge field by field or keep both and ask.

Will offline changes be sent as soon as the signal returns?

Not always instantly. Android's WorkManager and Apple's background tasks let the system choose when background work runs, to save battery. The app should show which changes are still waiting and send them when it can.

Does offline support make an app more expensive to build?

It adds work: storing data on the device, a sync process, conflict rules, a backend that supports syncing and more testing. Deciding early which screens must work offline keeps that work limited to what users need.

Planning an app that has to keep working where the signal is poor? We build iPhone and Android apps together with the backend, API and admin dashboard behind them. See our mobile app development service and all our services, or email [email protected].