"Will it work offline" sounds like a yes-or-no feature on a spec sheet. It is actually an architecture, and the price difference between "yes, reads" and "yes, everything" is the single largest line item most app quotes quietly gloss over. Here is what you are actually buying, in Google's own documented terms.
What offline-first means in engineering terms
Android's architecture docs define it plainly: an offline-first app "is able to perform all, or a critical subset of its core functionality without access to the internet." The mechanism behind that sentence is specific: "the local data source is the canonical source of truth for the app," everything the UI reads comes from a database on the device, and "the network data source is the actual state of the application," meaning the phone's copy can lag and must be reconciled on reconnect. That reconciliation "is called synchronization," and it is where the money goes.
Where the cost actually sits
Google's own doc is unusually honest about the price: "writing data in offline-first apps often requires more consideration than reading data because of potential conflicts," and under the lazy-write strategy it calls the queue-and-reconcile design "nontrivial because there can be conflicts between the network and local data sources when the app comes back online." Conflict resolution "often requires versioning," bookkeeping about when and in what order things changed. We have a whole engineering post on what that machinery looks like in practice, offline sync conflicts; the short version is that two people editing the same record on two airplanes is a solvable but genuinely hard problem, and it is the part of the quote that costs.
Apple's parallel guidance is a warning against faking it: "always attempt to make a connection. Do not attempt to guess whether network service is available," and Apple deprecated the SCNetworkReachability preflight check in iOS 17.4 precisely because it guesses wrong.
When owners actually need it
The honest triggers are concrete, not vibes: field teams where connectivity is the exception (warehouses, ships, construction, rural routes), revenue flows that must not stop (the September 2023 Square outage put point-of-sale systems down for fourteen hours and cost businesses thousands each, while Square's own offline mode kept some stores running), and users in markets where connectivity is structurally sparse. The ITU counts roughly 2 billion people still offline, about a quarter of the world's population; if your users are among them or serving them, offline is not a feature, it is the product.
The honest triggers for skipping it: Google's docs themselves endorse online-only writes for transactions "that must happen online in near real time, for example, a bank transfer," and they set the minimum bar at reads: "at a minimum, an offline-first app must be able to perform reads without network access." If your app is a dashboard, a catalog, or a reader, cache aggressively and you have bought most of the benefit at a fraction of the sync-engine price.
The Square outage is worth one more beat, because it shows the two-layer failure owners actually face. It was not a connectivity problem on the customer's side; the vendor's cloud went down for fourteen hours, and businesses reported losing thousands of dollars in a day while customers walked out or paid cash. The stores that kept trading were running Square's own offline mode, which is exactly the architecture in miniature: the terminal held a local copy and kept taking payments while the network was gone. Offline-first thinking protects you from both failure shapes, the bad signal in the field and the bad day in someone else's datacenter.
Our position
We quote offline as two separate lines, reads and writes, because they are two different products. Offline reads are a caching problem and belong in almost every app by default. Offline writes are a distributed-systems project and belong only where the business case is a concrete revenue or safety flow, not a hypothetical. In practice a caching layer ships in days, while a conflict-resolving sync engine is weeks of work plus a maintenance surface that stays on the books for as long as the app does. If a studio quotes you "offline support" as one line, ask which one they meant, because the invoice difference between them is the largest undiscussed number in mobile quotes.
The takeaway
internet; the device database is the source of truth
writes are a separate, harder product
versioning, not in the connectivity check
low-connectivity markets; revenue that must not stop
by design even in offline-first apps
apple deprecated preflight checks in ios 17.4
estimate, not one
If your users work where the signal does not, that is a custom software scoping question we price honestly, and one we shipped in the field with CashTaq. Send us the use case.
// sources
// next step
We work this way on client projects too.
Tell us what you are making. We reply with a plan, a timeline, and a price.
