Does your product actually need a mobile app

Probably not. A short list of device capabilities forces a native or cross-platform build, and if your product needs none of them, a responsive web app is the right answer. The list: reliable background location, Bluetooth Low Energy, NFC, durable offline writes that sync without the user reopening anything, real push on iOS, biometric-gated local secrets, health and wearable data, and camera pipelines beyond what getUserMedia hands you. Selling digital goods is on it too, but as a platform-fee question rather than a technical one.

Every other reason offered for building an app is either already possible on the web or a wish dressed as a requirement. Engagement. An icon on the home screen. A competitor who has one. We quote mobile work from $20,000 and marketing sites from $7,500, so the cheaper answer is the one that costs us money. It’s still usually the correct one.

The gates, in one table

A checklist, not a comparison. If your product requires a row marked gate, you need an app. If it requires none of them, you don’t.

Background location, BLE, and NFC: the radio gates

These three fail for the same reason: a browser will not keep a process alive holding a radio open while the user is somewhere else.

Reliable background location

The Geolocation API works while your page is in the foreground and stops mattering the moment it isn’t. iOS suspends background tabs aggressively, and there is no web equivalent of region monitoring or significant-change updates.

Native gives you both, with real limits. iOS monitors at most 20 geofence regions per app, which is why fleet products swap regions in and out as the device moves. Android has required a separate background-location grant since Android 10, and Google reviews a declaration form before publishing an app that asks for one. Budget for the review, not just the code.

The gate is arriving, departing, and dwelling while the screen is off. Showing a map when someone opens the page is the foreground case, and the web handles that fine.

Bluetooth Low Energy

Web Bluetooth exists in Chrome and Edge on desktop and Android. It is absent from Safari and Firefox, so shipping a BLE feature on the web means excluding every iPhone. That alone usually ends the discussion.

Even where it exists it’s a foreground, user-gesture API. Every connection goes through a chooser the user taps, and there is no background scanning or silent reconnect. If your product pairs with a sensor, a lock, a scale, or a label printer and expects it to reconnect on its own, that’s a gate.

NFC

Web NFC reads and writes NDEF tags in Chrome for Android and nowhere else. Native iOS has read NDEF since iOS 11.

Card emulation, which is what people mean by NFC payments or access badges, is a different animal. Apple has been opening secure-element and host card emulation to third parties through an entitlement, region by region, on application. Treat it as a commercial process with a lead time rather than an API you call, and check your markets before it goes on a roadmap.

Offline writing is the gate people misjudge in both directions

Offline reading is not a gate. A service worker plus IndexedDB has served cached shells and cached data on a plane for a decade.

Offline writing splits in two, and only one half is a platform limit. Conflict resolution is your problem anywhere: last write wins, per-field merge, or a CRDT, chosen by how bad a silent overwrite is for your users. That work is identical in Swift, Kotlin, and TypeScript.

Durability and flush is where the web genuinely loses. Background Sync and Periodic Background Sync are Chromium-only, so on iOS a queued write sits until the user reopens your tab. Worse, Safari deletes all script-writable storage for a site untouched for seven days. A home-screen install exempts it, so your durability rests on a manual step most users never take.

So the honest rule. Occasional offline use where the person returns to the tab within a day is a web case, and you should still call navigator.storage.persist(). Field staff filling in forms across a week of poor coverage is a gate, and the most common legitimate one we see.

Push notifications on iOS, precisely

Web push has worked on iOS since 16.4, in March 2023, and most articles stop there. The deciding detail: it only works for a web app added to the Home Screen through the share sheet. iOS has no browser-initiated install prompt, so you’re asking people to follow a three-tap instruction before you may contact them, and deleting the icon revokes it.

The capability is thinner too. No time-sensitive or critical interruption levels, so nothing you send breaks through a Focus mode. No Live Activities. No provisional authorisation, the native trick of delivering quietly first and asking permission after you’ve proved useful.

Push therefore isn’t a binary gate, it’s a conversion question. If notifications are a retention channel, the web is adequate for whoever installs. If a notification is the product, as with an on-call alert or a driver dispatch, build the app.

Biometrics, local secrets, and health data

Biometric authenticationis solved on the web. WebAuthn with a platform authenticator, which is what a passkey is, gives you Face ID or a fingerprint gating a sign-in on both platforms. Anyone telling you an app is required for “Face ID login” is years out of date.

Biometric-gated local secrets are a different capability, and the web has no answer. Native keychains hold a key that only becomes usable after a fresh biometric check, and invalidate it if the enrolled biometrics change. That is what an offline vault, a downloaded medical record, or a local message archive with device-only keys needs. Encrypted messaging trips several gates at once, which is part of why Hush, our own anonymous encrypted chat product, is a Flutter app rather than a website.

Health and wearable data is the least arguable gate here. There is no web API for HealthKit or Health Connect, and no route to an Apple Watch or Wear OS surface that starts with a URL. If your product reads steps, heart rate, sleep, or glucose, the medium is decided and only the stack is open.

Camera pipelines, and the scanning myth

getUserMedia gives you a live video track and frames you can process. Paired with a WebAssembly decoder, that reads QR codes and retail barcodes fine in a browser. Occasional scanning is not a reason to build an app, whatever the agency post says.

What it won’t give you consistently across browsers is sensor control: locked exposure and focus, torch on every device, RAW capture, multi-camera fusion, depth or LiDAR, and the world-tracking layers in ARKit and ARCore. Nor a native decode pipeline, since BarcodeDetector is Chromium-only.

The threshold is duty cycle. Someone scanning a parcel twice a day is a web case. Someone scanning eight hundred labels a shift needs focus lock, torch, and a decode loop tuned to the hardware, and the battery arithmetic stops working inside a browser tab. That’s a gate.

Selling digital goods is a fee question, not an engineering one

The stable part: purely digital content consumed inside an app generally goes through the platform’s in-app purchase, at 15 to 30 percent depending on your revenue tier and how long a subscriber has been paying. Physical goods and real-world services do not, which is why every delivery app takes a card directly.

The unstable part is external linking. Litigation and regulation through 2024 and 2025 forced both stores to permit out-of-app purchase links in some jurisdictions, on terms that differ by region and keep being revised. We won’t print a percentage that will be stale by the time you read it. Model your margin twice, at the store rate and at your processor’s. If that gap is the whole business, sell on the web and treat the app as a client.

If none of the gates apply, build the responsive web app

Say it plainly, because this SERP won’t. One codebase, one release train, one URL you can paste into an email. Add a manifest and a service worker and you get a home-screen icon, a splash screen, a standalone window with no browser chrome, and an offline shell. On Android you also get an install prompt and full web push.

That covers most business software. Dashboards, admin consoles, booking flows, quoting tools, CRMs, marketplaces with no driver app attached. Our own Clora AI multi-company HR and payroll portal is a web product for exactly this reason. Nothing in payroll needs a radio.

Two caveats, so this doesn’t read as web triumphalism. An installed web app on iOS is a second-class citizen, and Apple has shipped regressions that broke home-screen installs. And a responsive site is not automatically a good phone experience: hit targets, thumb reach, and input types are design work you still have to do.

The costs the app-versus-website posts leave out

The standard comparison stops at build price. These are the costs that surprise people in year two.

Review latency on every release

Web deploy to fix a typo: minutes. App deploy to fix a typo: build, upload, review, rollout. Apple publishes that the large majority of submissions are reviewed inside 24 hours, but the tail is real and lands on the day you need it least. Play adds staged rollouts, and personal developer accounts opened since late 2023 must run a closed test with roughly a dozen testers over a fortnight before applying for production access. That rule has been revised at least once, so check it rather than trusting this sentence.

Forced updates and the version floor

Shipping is not adopting. A meaningful share of users sit on an old build for weeks, so you either support old clients or build a version gate: an endpoint returning a minimum supported version, and a blocking screen below it. Ordinary work, but your API now tolerates two or three client generations at once, and every breaking schema change acquires a client-side half.

Two release trains, permanently

Apple charges $99 a year for the developer programme and Google $25 once, which is the trivial part. The overhead is two store listings, two sets of screenshots at current device sizes, certificates and profiles that expire on their own schedule, a privacy nutrition label and a data safety form to update whenever your SDKs change, and an annual deadline after which Apple rejects builds made with an older SDK. Then two OS releases a year that can break you in beta.

Our own estimate: for a modest app, that maintenance floor runs a few days of engineering per quarter before anybody writes a feature. Price it in, because the website side of the ledger doesn’t carry it. The MVP cost estimator takes platform count as an input.

What we would not build

We would not build a native shell wrapping your website. It clears no gate, doubles your release process, and risks rejection under Apple’s minimum-functionality rule. If the wrapper would be enough, your product was a web app and you just proved it.

We would not build an app to raise engagement. Nobody opens an icon they didn’t want, and the fix is a better product on the surface people already use.

We would not build both mediums for a first release. Ship the one the gates decide and let usage say whether the second is a business or a hunch. Splitting a first-release budget across two mediums reliably ships two half-finished things.

Where this framework costs us, and where it fails

First, the part that costs us. Our mobile band starts at $20,000 and our marketing site band at $7,500. Both figures are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff. A framework whose answer is usually “build the cheaper thing” is a poor sales instrument. We publish it anyway, because the alternative is arguing in month four about why the app isn’t working.

Now the failure mode, which is real. This framework scores capability and ignores distribution. For some categories the store isthe acquisition channel: games, consumer subscription apps, anything with a paid-install motion, anything whose buyers search the store rather than the web. If that is genuinely how customers find you, it’s a business reason to build an app and the gate list has nothing useful to say about it. What we’d push back on is that claim asserted rather than evidenced: show us the channel data.

And the case where you should hire nobody. For offline forms for a field team of twenty, or a checklist for one warehouse, buy an off-the-shelf mobile forms product. Those handle offline capture, sync, and the store listing for a few hundred a year, and no custom build above our $7,500 minimum beats them at that scope. Spend a fortnight trying. If it fails, you have a specification instead of an idea.

The compressed decision

Walk the gate list. Background location, BLE, NFC, durable offline writes, push as a core mechanic on iOS, biometric-gated local secrets, health or wearable data, or a camera pipeline needing sensor control. One hit and you’re building an app, and the next question is cross-platform versus native, which we take apart in React Native versus native iOS and Android. Zero hits and you’re building a responsive web app, and the money you saved on a second release train buys features instead.

If you’re unsure which side of that line you sit on, it’s a thirty-minute conversation, not a discovery phase. Send us the requirementand we’ll say which gates it trips, including when our mobile app development work is not what you need.