~12 min read · "The app should work offline." It's one of the most casually-asked-for features in mobile development and one of the most translated-incorrectly. Here are the five tiers of offline — what each one actually means, what each one costs, and which one your specific feature really needs.
The request usually arrives near the end of a scoping conversation, as a kind of self-evident addition.
"Oh, and it should work offline."
"We need offline mode."
"What happens when the user doesn't have internet?"
The buyer says it the way you'd add salt to a recipe — a minor finishing touch, not a structural choice. The developer hears something different. They hear a request that, depending on what the buyer actually meant, could be ten lines of code, or could be a six-week project that affects every other feature in the app.
The gap between those two outcomes is the largest in mobile development. "Should work offline" is the most under-translated phrase a buyer can say. It maps onto five very different technical realities, each costing roughly twice the previous one. Almost every buyer asks for the highest tier and would be entirely satisfied with the second or third.
This article is about pulling that phrase apart. Naming the five tiers. Showing what each one actually requires. And — most usefully — giving you the framework to figure out which one your specific app needs, so the conversation with your developer is about what to build, not about what you might have meant.
The Five Tiers of Offline
Let's name them, in increasing order of complexity and cost.
Tier 1 — Opens. The app launches when the user has no internet. They can see the splash screen. They might see a "no connection" message. Nothing actually works, but the app doesn't crash and isn't blank. Cost: basically free; it should be standard behavior in any modern app.
Tier 2 — Reads. The app shows the user content they've previously seen, cached on the device. They can browse what's already there. They can re-read articles, look at previously-loaded products, see their order history. They can't make any changes — anything that would require talking to the server is disabled or queued. Cost: small but real.
Tier 3 — Writes. The user can do things offline — create a post, make a note, add an item to a list, fill out a form. These actions get saved locally and synced to the server when the connection returns. The user doesn't have to wait; they don't have to re-do their work. Cost: significant. This is where offline becomes real engineering.
Tier 4 — Syncs. The app handles round-trip synchronization cleanly when the user reconnects. Changes the user made offline are pushed to the server; changes the server has that the user hasn't seen yet are pulled down. The sync happens automatically, in the background, with the user barely noticing. Conflicts (when both sides changed something) are detected and resolved according to clear rules. Cost: substantial. This is offline-first architecture.
Tier 5 — Merges. Multiple users, multiple devices, all editing simultaneously, sometimes offline, with intelligent conflict resolution. When two people edit the same document on two different devices, the changes merge cleanly rather than one overwriting the other. Cost: extreme. This is the engineering Dropbox, Notion, and Google Docs have spent years and many millions of dollars on.
These five tiers are not the same thing. A buyer who says "the app should work offline" is, depending on what they actually meant, asking for anywhere from a few lines of code to a multi-month engineering project. The cost ratio across the tiers is roughly 1x : 5x : 15x : 30x : 60x — and the difference between tier 3 and tier 5 is often the difference between "we can ship this in a quarter" and "we cannot ship this at all on this budget."
The translation work — which tier do you actually need? — is therefore the most consequential conversation that follows the casual offline request.
Tier 1: Opens
This shouldn't really need its own tier. Every app should at least open without internet. The user shouldn't be staring at a blank screen if their plane lost its Wi-Fi.
But it's worth naming, because some apps genuinely fail this bar. They show a blank screen, or an infinite spinner, or crash entirely. If your app does any of these things on a connection drop, you're below tier 1, and the fix is almost free.
A tier 1 app shows a clean state when there's no connection. Maybe it tells the user "you're offline." Maybe it shows them the last screen they were on, dimmed. Maybe it shows a friendly empty state. The point is that the app doesn't break.
This is the floor. If your developer can't deliver tier 1, you have a problem that's bigger than offline mode.
Tier 2: Reads
Tier 2 is what most buyers actually mean when they say "offline mode" — even if they think they're asking for more.
The idea: the user has already loaded some content (a list of articles, a product catalog, their conversation history, their saved items). Even when they lose connection, they can still see that content. They can scroll through it. They can read it. They can navigate around within what they've already loaded.
What they can't do is change anything that talks to the server. The "post a comment" button is disabled, or it's enabled and shows a friendly "we'll send this when you're back online" message. The "favorite this item" tap might work locally but isn't synced. The user is in read mode until they reconnect.
Tier 2 is achievable for most apps with a moderate engineering investment. The work involves caching responses to disk, knowing when to use the cache versus the network, and handling the transition gracefully when the connection returns. For a typical app, this is maybe $4,000–$8,000 of additional work, and the result is dramatically better user experience for anyone who uses the app on the subway, on flights, in rural areas, or in buildings with bad reception.
For many apps — particularly content-consumption apps, news, podcasts, articles, catalogs — tier 2 is exactly what they need. The user wants to keep reading; they don't actually need to keep posting. Tier 2 satisfies the request. Going further would be over-engineering.
Tier 3: Writes
Tier 3 is where offline becomes real engineering — and where the cost step up is largest.
The idea: the user can do things offline. They can create new posts, edit existing items, fill out forms, complete workflows. When they reconnect, the things they did get sent to the server, applied properly, and they appear normally in their account from that point forward.
The reason this is so much more expensive than tier 2 is that the app now needs to store its own truth, separately from the server. It can't just "show what the server says." It has to track:
What the user did, locally. What's been sent to the server. What hasn't been sent yet. What got an error response. What needs to be retried. Whether a previous attempt succeeded silently. Whether the local data is fresher than the server's data, or vice versa.
This is fundamentally different from a normal request-response app. The mental model of the data has to shift from "the server is the truth, the app is just a view" to "the app and the server each have a version of the truth, and we have to reconcile them."
That shift affects every part of the app that touches data. It's not a feature you bolt on. It's an architectural decision that ripples through the codebase. We touch on why this kind of decision is so consequential in your developer is stuck in technical debt — choices about how the app stores and reconciles data are exactly the kind of "joints" that have to be designed deliberately or they create years of pain later.
For a typical app, going from tier 2 to tier 3 is $15,000–$30,000 of additional work, and it has to be planned from the start. Retrofitting tier 3 onto an app that wasn't built for it is significantly more expensive — sometimes a substantial rewrite of the data layer.
Tier 3 is the right choice for apps where the user does work — not just consumes content. Note-taking apps. Task managers. Field-worker apps for plumbers, electricians, inspectors. Anywhere the user produces value while disconnected.
Tier 4: Syncs
Tier 4 is tier 3 plus automatic, intelligent synchronization.
In tier 3, the app stores what the user did and sends it up when reconnected. The sync is one-way, mostly. The user does things, those things eventually make it to the server.
In tier 4, the sync goes both ways, automatically. The user has the app open on their phone. They're offline. The server has new things (a colleague made changes, a new notification came in, an order status updated). The moment the phone reconnects, both sides reconcile — the user's changes go up, the server's changes come down, the app's display updates, all without the user manually refreshing.
This requires the app to keep track of what version of each piece of data it last saw, what's changed since, and how to merge the two without losing anything. It requires the server to support this kind of conversation — keeping track of changes since each client's last sync. It requires error handling for partial failures, network drops mid-sync, conflicting changes.
For a typical app, going from tier 3 to tier 4 is another $15,000–$25,000 of additional work, and it requires deliberate decisions about the data model. Some data models support sync naturally. Others don't, and have to be redesigned.
Tier 4 is the right choice when the user expects the app to be live. Email apps. Chat apps. Collaborative task managers. The user shouldn't have to think about syncing; the app should just be current whenever they look at it. We expand on the related conversation in what real-time actually costs — tier 4 offline often pairs with tier 2 or tier 3 real-time, because what feels like "real-time" to the user is often "we synced 2 seconds ago".
Tier 5: Merges
Tier 5 is the hardest engineering in consumer software.
The setup: a single piece of data — a document, a list, a board, a project — can be edited by multiple users on multiple devices, sometimes simultaneously, sometimes offline. When everyone reconnects, the changes need to merge in a way that preserves everyone's intent, doesn't lose work, and doesn't silently corrupt the data.
This is what Google Docs does. What Notion does. What Figma does. What modern collaborative apps that "just work" across devices do. It looks effortless from the outside. Underneath, it's some of the most sophisticated engineering in the field — CRDTs (conflict-free replicated data types), operational transforms, vector clocks, careful versioning, custom merge algorithms.
The reason Google Docs is one of the most engineered consumer products in history is not the editor or the rendering. It's the merge.
For a typical app, tier 5 is category-defining engineering. It's not a feature; it's the entire product. Apps that need true tier 5 are either built around it from day one (Notion, Figma) or they accept significant constraints (last-write-wins, single-active-editor locks, "you've been edited by someone else, please reload").
For the vast majority of apps, tier 5 is the wrong target. The buyer who asks for "offline mode" almost never needs tier 5. They've conflated "the app should work without internet" with "the app should magically merge changes from arbitrary users and devices" — and the second is a fundamentally different product.
A Diagnostic for Your Feature
Six questions usually resolve which tier your specific feature needs.
Does the user need to *read* content while offline, or also *create* content? Reading is tier 2. Creating is tier 3+.
If the user creates something offline, do they need to see it merged with other people's changes when they reconnect? No: tier 3. Yes: tier 4 or 5.
Could multiple users edit the same thing at the same time? No: tier 4 is enough. Yes: tier 5.
Is offline use a primary scenario, or an edge case? Primary (a field-worker app, a flight-mode reading app): tier 3 or higher, designed from the start. Edge case (a typical consumer app that should be polite when the user's signal drops): tier 2 is usually enough.
Would a single-device, last-write-wins simplification be acceptable? If yes, you can target tier 4 with a much simpler implementation than tier 5.
What would the user actually do when they're offline? This is the question to ask honestly. For most consumer apps, the answer is "look at things they already loaded" — which is tier 2. The tier-3-and-up scenarios are real but specific.
If the answers point to tier 2, you're looking at a small additive engineering investment. If they point to tier 4 or 5, you're looking at an architectural decision that needs to be made early and that will affect the whole project.
The cheapest mistake is asking for tier 5 when tier 2 was enough. The most expensive mistake is building tier 2 when the product actually needs tier 4.
Why "Offline" Usually Shouldn't Be a Scope Checkbox
Most buyers think of offline as one feature that the app either has or doesn't. The truth is messier and more useful.
A well-built app makes per-feature decisions about offline. This screen should work offline (tier 2). This action should be queueable (tier 3). This other feature is online-only because the cost of supporting it offline doesn't justify the benefit.
This per-feature approach is almost always cheaper and more useful than a blanket "the app should work offline." It produces an app where the right things work offline and the things that don't work offline degrade gracefully. The user understands intuitively which features are which, the way they understand that Google Maps shows them cached map data offline but can't search for a new destination.
The conversation to have with your developer isn't should the app work offline. It's for each feature, what should happen when there's no connection. That conversation is longer, more specific, and produces a much better app.
Where Offline Sits in Your Backend Choice
There's one more layer to flag, because it's almost always missed.
Your backend choice — covered in your app's backend might not actually be a backend — affects what tiers of offline are possible.
Custom server code can support any tier. The team builds the sync protocol that the app needs.
BaaS platforms (Firebase, Supabase) have built-in support for some kinds of offline-first sync, which is actually one of their main selling points. Firebase's Firestore in particular handles tier 3 and most of tier 4 out of the box. This is a real strength.
No-code stitches generally don't support offline beyond tier 2. The automation platforms aren't designed for it.
Thin glue layers over third-party services inherit whatever the underlying service supports. Stripe's API isn't offline-friendly. Shopify's is, to a degree.
This means that the choice of backend, made early in the project, constrains what offline tiers are achievable later. A buyer who chose Firebase early because it was cheap and easy can usually retrofit tier 4 cheaply, because Firestore was designed for it. A buyer who chose a custom REST backend without thinking about sync can't retrofit tier 4 cheaply — the entire data layer often has to be redesigned.
This is the kind of decision that, made deliberately, saves substantial cost later. Made carelessly, it locks in years of friction.
The Honest Close
"Offline mode" is one of the most translated-incorrectly requests in mobile development. The buyer asks for it casually. The developer either over-builds it (tier 4 when tier 2 was enough) or under-builds it (tier 2 when the product actually needed tier 4).
Both mistakes are expensive. The first costs money. The second costs the product.
The translation — which tier do you actually need? — is the most valuable scoping conversation you can have on this topic. The five tiers are real. The cost differences between them are real. The architectural commitments are real. Picking the right tier for your specific app, and building it deliberately, is what separates the apps that "just work everywhere" from the ones that crash when the train enters a tunnel.
You don't need to understand the engineering of offline sync. You don't need to know what a CRDT is. You just need to know that "offline" is five different products, costing five different amounts, and that the right answer for your app is almost certainly one of the middle three — not the casual tier 5 your reference apps spend tens of millions of dollars maintaining.
Asking which tier, before signing, is the cheapest possible way to save yourself a significant misalignment. The conversation takes thirty minutes. The savings can be measured in months.