Web app vs mobile app in 2026: what actually forces you native

You need a native mobile app only when a device capability forces it. Background execution, Bluetooth and NFC, sustained on-device inference, and deep OS integration are the four things a web app still cannot do on an iPhone. That is the only technical input to this decision. Distribution can also justify a native build, but that is a business decision, and it is worth naming as one rather than dressing it up as engineering.

Sitting between the two is the Progressive Web App, or PWA: a web deployment model with app-like behavior, installed from the browser rather than a store. It inherits the browser's capability ceiling, and on iOS that ceiling is set by WebKit, not by your code.

This is an unfashionable position to hold in the same year we shipped three mobile products. We hold it anyway, because most of the reasons people give for building an app have quietly stopped being true, and nobody updated the comparison tables.

Device capability is the only input that forces the decision

Start from the capability requirement and the decision usually makes itself. If your product needs to do work while the user is not looking at it, talk to hardware over a short-range radio, run a model against a live camera feed, or live inside the operating system's own surfaces, you need a native app. If it does not, you are choosing a distribution and engagement strategy, not satisfying a technical constraint.

The four capability gates, as they apply to iOS:

1. Background execution. Background Sync is unsupported. If a form submitted offline has to reach your server before the user reopens the app, that is a native requirement, not a service worker pattern.
2. Short-range radio and peripherals. Web Bluetooth, Web NFC, and WebUSB are not available in Safari. For direct access to a reader, beacon, wearable, or payment terminal from iOS, you need a native integration rather than a standard web API.
3. Sustained on-device inference and camera pipelines. A single photo upload is a web problem. Running a model against a live camera stream at frame rate, with hardware acceleration, is not.
4. Deep OS integration. Widgets, Live Activities, CarPlay, HealthKit, Siri intents, and share sheet targets have no web equivalent.

If none of those apply, write down why you want an app anyway. That sentence is usually about retention or credibility, and both have cheaper answers.

These are platform limits, not web limits

The list above is a WebKit list, not a web list, and conflating the two is the most common error in this category.

Chrome on Android ships Web Bluetooth, Web NFC, and WebUSB. It supports Background Sync. It can prompt for installation automatically and request notification permission from an ordinary browser tab, with no install step in between. The same code, deployed once, has materially different capabilities depending on which phone is running it.

So the honest framing is not web versus native. It is that a web app is close to capability parity with native on Android and meaningfully short of it on iOS, and iOS is where the constraint that decides your architecture almost always lives. If your users are predominantly on Android, the case for building anything native is weaker than most comparisons suggest.

The iOS gap narrowed, but not in the places that matter most

Progressive web apps on iOS are better than the 2021 consensus admits and worse than the 2026 marketing claims. Both halves are true, and most posts pick one and stop.

What works now. Push notifications have worked for home screen web apps since iOS 16.4 in March 2023, which invalidates the single most repeated claim in this entire category. Safari 18.4 added Declarative Web Push, dropping the service worker requirement for the simple case, and Screen Wake Lock. The Badge API works. As of iOS 26, any site added to the home screen opens in standalone mode by default, with or without a manifest.

What still does not. Push only works after the user installs to the home screen, and there is no automatic install prompt, so the entire notification funnel depends on a manual Safari gesture you have to design for and earn. Background Sync is absent. Cached storage can be evicted after a period of disuse. Apple briefly removed home screen web apps in the EU during the iOS 17.4 beta, then reversed within two weeks. The capability shipped intact, though articles claiming otherwise are still ranking today. We went through the rest of these claims against WebKit's own documentation in what is true and what is folklore about PWAs on iPhone.

The practical read: a web app can now handle notifications and offline caching well enough for a portal, a booking tool, an internal field application, or a first version of almost anything. It cannot do reliable background work, and its install path on iOS is a conversion problem you own.

The store commission argument stopped being a constant

The thirty percent cut is no longer a fixed number you can build an architecture around, and anyone still using it as the reason to go web is quoting a rate that does not exist.

On iOS, the sequence matters. In May 2025, Apple updated US App Store Review Guidelines 3.1.1 and 3.1.3 to permit external payment links, buttons, and calls to action with no entitlement, no approval, and no commission, following the contempt finding in the Epic dispute. The Ninth Circuit upheld that finding in December 2025 but rejected a total ban on link-out commissions and sent the question back for a cost-based rate. The Supreme Court agreed to hear Apple's appeal on June 30, 2026, limited to the contempt question. Then in August 2026, with the district court proceeding on remand, Apple filed its proposed rate: up to fifteen percent on US external link purchases, tiered down to five percent for small business program developers and ten percent for subscription renewals and certain partner programs.

On Android, the same pressure produced a different outcome. Google settled with Epic rather than litigating to the end and dropped Play Store commissions to twenty percent, a standing rate rather than a contested one. Android also permits distribution outside the store entirely, which removes the commission question rather than repricing it.

So the US external link rate on iOS is zero today, a number is being set in court, and a merits ruling is still ahead. Android sits at twenty percent with a sideloading escape hatch. The EU, Japan, and Brazil run separate regimes with their own fee stacks.

The engineering consequence is the part worth acting on. Treat the commission rate as a configuration value, not an architectural assumption. If your unit economics only work at zero percent, and moving to fifteen means re-architecting checkout, you have encoded a court schedule into your data model. Route purchases through a layer that can switch between in-app purchase and external link per storefront, and keep the rate in config where you can change it without a release.

Cost tracks surface count, not platform choice

A web app is the cheapest thing to run because it is one deployable surface with no store review between a fix and a user. That is the whole cost story in one sentence, and it holds up better than any per-hour estimate.

Cross-platform reduces the cost of covering both mobile platforms to roughly one codebase plus the native modules you cannot avoid. Two native codebases is the most expensive option available, and the expense that matters is not the initial build. It is everything that recurs: two dependency graphs, two build pipelines, two secret stores, two sets of platform permissions, two release cycles, and two configuration surfaces that can drift apart while both look correct.

Which is why the useful question is not which platform is cheapest to build. It is what capability or distribution requirement justifies the additional surface, because the surface is what you pay for every week after launch.

Cross platform stopped being the performance compromise

The performance objection to React Native is over, and the argument moved to library ecosystem and migration debt instead.

React Native 0.76 made the New Architecture the default in October 2024. Version 0.82 removed the opt-out in October 2025. Version 0.85 deleted the legacy bridge from the codebase in April 2026, and 0.86 in June 2026 starts every new project fully bridgeless. JSI replaced JSON serialization across the boundary, Fabric replaced the old renderer, and TurboModules replaced the old native module contract with a Codegen-generated, type-checked interface.

That last detail is the one we care about most, and it is not a performance point. Under the old bridge, a mismatch between what JavaScript sent and what native expected surfaced at runtime, in production, on someone's phone. Codegen moves that class of failure to compile time. That is a review-surface improvement, and review surface is where the real cost lives.

The remaining cross-platform question is no longer whether it will be fast enough. It is whether every third-party dependency you rely on has been rewritten for the New Architecture, because the interop layer is gone and anything not updated will not run at all.

AI assistance moved production cost, not review cost

There is a live argument in 2026 that agentic coding assistants have made a second codebase cheap enough that you should stop compromising on cross platform and build both natively. That argument is half right, and dangerous in the half that is wrong.

Production cost genuinely collapsed. Generating a second platform implementation from a specification is faster than it has ever been. But shipping is not generating. The failure mode we keep finding in AI-assisted work is not bad code, it is plausible configuration that works in the sense that it runs without error and produces no complaint, while being wrong. That is a review problem, and review did not get cheaper.

The asymmetry is the whole point. If AI assistance halves your production cost and doubles your review surface, building both natively is a worse trade in 2026 than it was in 2022, not a better one. The correct conclusion from cheaper code generation is not to build more surfaces. It is to spend the savings on verification. This is the same thing we have argued about where failures actually originate and about what it means to build AI-native rather than AI-enabled.

Three builds, three different answers

The framework above is not theoretical for us, and it did not produce the same answer twice.

An iOS product that identifies objects from a live camera feed was never a web candidate. The capability gate closed the question before the first line of code: a model running against a camera stream with hardware acceleration has no web equivalent that holds up in the field. That is what a genuine native requirement looks like, and it is rarer than the request for one.

A clinician-facing portal on Android went the other way on the same logic. The work was records, forms, scheduling, and notifications, all of which the web handles, and on Android specifically the capability gap was close to nothing. What pushed it to a mobile build was deployment context: managed devices, controlled distribution, and workflow expectations from clinicians who were not going to accept a browser tab. That was a distribution decision, and we were honest with ourselves that it was.

A two-sided iOS marketplace with identity verification and payments sits in the hardest category. Identity verification wants the camera and a native document capture flow. Payments now want a routing layer that survives a commission rate being decided in a courtroom. That build has the most exposure to the policy changes above, and it is the one we would design most defensively today.

For our own web properties the answer is boring in the right way. A Next.js App Router stack on TypeScript and Postgres, running in Docker behind Cloudflare and Caddy, ships changes in minutes with no store review between us and our users. That is a real capability, and it is the one people undervalue most when they are excited about an app.

The decision sequence we run

Answer these in order and stop at the first yes.

1. Does the product require background execution, short-range radio, sustained on-device inference, or OS-level surfaces? If yes, build native. Skip the rest.
2. Is distribution controlled or managed, such as clinician devices, field hardware, or an enterprise fleet? If yes, a mobile build is probably right for distribution reasons. Write that down honestly rather than inventing a technical justification.
3. Does the retention model depend on notifications reaching users who will not install anything? If yes, weigh the iOS install funnel carefully, because home screen push requires a manual gesture. On Android this question mostly answers itself.
4. Does the revenue model break if the external link commission moves from zero to fifteen percent? If yes, fix the payment routing layer before choosing a platform.
5. Otherwise, build the web app first. Ship it, learn what users actually do, and build the native app when a capability gate closes, not when a comparison table suggests it.

The failure mode in this decision is not picking wrong. It is picking early, on a set of facts that expired in 2023, and then discovering the constraint that actually mattered after the second platform is already in production.

What we would tell you not to do

Do not build both to hedge. A hedge in software is two surfaces to review, and review is the resource that did not get cheaper.

Do not treat a store commission as a fixed input. It is a moving legal outcome with a different value on every platform and in every major jurisdiction, and it belongs in configuration.

Do not trust a capability claim about iOS that does not carry a date. This category is full of confident statements that were true in 2021, false since 2023, and still ranking.

Corrected August 31, 2026: an earlier version described Apple's DMA response as degrading home screen web apps in the EU. That removal happened in the iOS 17.4 beta and was reversed before release.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.