Native App or PWA? The Decision in Practice

"We need an app" is one of the most common requests I get, and roughly half the time the honest answer is that a fast mobile web experience would serve the business better for a fraction of the cost. The other half genuinely need to be in the store, and it is usually obvious why within about ten minutes of asking.

What makes this decision hard is that it gets framed technically — capabilities, performance, offline support — when the deciding factors are almost always distribution, business model and who maintains it. The technical gap between a good progressive web app and a native app has narrowed considerably. The distribution gap has not.

So this is the practical framing: what each one genuinely gives you, what the real costs are on both sides, and the specific questions that resolve it.

What is the actual difference now?#

Distribution, a handful of platform capabilities, and who owns the relationship with the user.

A progressive web app is a website that can be installed to the home screen, works offline, and receives push notifications on most platforms. A native app — or React Native, which is native from the user's point of view — is distributed through app stores, has full access to device capabilities, and runs as a first-class application.

The rows that decide most projects are the first and the second-to-last. Being in a store is a distribution channel and a payment constraint at the same time, and both of those are business decisions rather than engineering ones.

The capability gap is smaller than the reputation#

Camera, geolocation, offline storage, push notifications, background sync to a degree — a modern PWA does all of this. The genuine remaining gaps are sustained background execution, deep hardware integration such as Bluetooth peripherals and health data, widgets, and anything requiring tight system integration.

The install gap is larger than the reputation#

Installing a PWA on iOS still means finding a share menu and choosing an option most people have never used. That friction is real and it is the single biggest practical disadvantage — not because installation is technically hard, but because nobody knows how.

Which questions actually resolve it?#

Six, and none of them are about features.

1. How do users find you? If it is search and links, the web wins. If it is a store, or word of mouth naming an app, that matters.
2. How often will they use it? Daily-use tools benefit from a home screen presence people trust. Occasional-use services do not.
3. Do you charge for digital goods? Store billing takes a substantial share and it is mandatory for in-app digital purchases.
4. Do you need background work or deep hardware access? Real-time location tracking, Bluetooth devices, health data — that is native.
5. Who maintains it in two years? Store builds need signing certificates, SDK updates and periodic re-submission forever.
6. Does the audience expect an app? For some categories it is a credibility signal, whatever the technical merits.

Answer those honestly and the decision usually makes itself. In my experience the fifth is the one most often skipped and most often decisive, because a store presence is a permanent maintenance commitment that a website is not.

Answer them about the users you have#

These questions are easy to answer aspirationally — about the audience you intend to reach rather than the one currently using the product. Analytics already knows how people arrive, how often they return and what device they are on, and reading that before the discussion keeps the decision anchored to evidence rather than to ambition.

The credibility answer is legitimate#

For some audiences, not being in the store reads as not being a real product. That is not a technical argument and it is a real market fact, and treating it as irrational is a good way to lose an argument you were right about on the merits.

When is the web genuinely better?#

More often than the request implies, and for reasons that compound.

When discovery happens through search#

A store listing is not indexed the way a page is. If people find you by searching for the problem you solve rather than for your brand, the web is where they find you, and an app is a second destination you have to drive traffic to.

When the interaction is occasional#

Nobody installs an app to do something twice a year. Booking, one-off purchases, occasional lookups — these are web interactions, and putting them behind an install requirement loses most of the audience at the first step.

When you want to ship on your own schedule#

A web deploy is live in minutes. A store update is a review, then a gradual adoption curve, and for weeks afterwards you are supporting two versions. For anything iterating quickly that difference is substantial.

When you charge for digital goods#

Store commission on in-app digital purchases is significant and largely unavoidable. For a subscription business, moving that transaction to the web changes the unit economics materially, and it is worth modelling before committing.

When the content needs to be findable#

Anything you want indexed, linked to, quoted or shared has to be a page. Content locked inside an app is invisible to search, to anyone who has not installed it, and increasingly to the AI systems people now ask instead of searching. For a product whose value is partly its content, that is a decisive constraint rather than a minor one.

When the budget is finite#

One responsive web application serves every device. Two native platforms plus a web presence is three surfaces, and even React Native — which meaningfully reduces that — is still a store build plus a website.

When do you genuinely need an app?#

When one of a fairly short list of things is true.

Background execution#

Location tracking while the app is closed, continuous sensor recording, geofencing, activity recognition. The web cannot do these and the workarounds are not workarounds. This is the clearest technical case.

Deep hardware or platform integration#

Bluetooth peripherals, health and fitness data, HomeKit, widgets, watch apps, secure biometric flows tied to platform keychains. If the product is defined by one of these, the decision is made.

Reliable push as a core mechanic#

Web push exists on iOS and it comes with more caveats and lower reliability than the native equivalent. If notifications are how the product works rather than a nice addition, that difference matters — and it is a fraught area even natively.

Store distribution is the channel#

For consumer products in categories where people browse the store, being absent from it is being absent from the market. That is a marketing fact rather than a technical one and it is decisive when it applies.

Daily-use tools with real retention#

An app people open every day earns its home screen icon, and the presence itself drives usage. Pulse is this shape — a habit tracker opened daily, offline, gesture-driven — and it would not work as well behind a browser tab.

What about React Native?#

It is the answer to "we need an app but not two of them", and it is what I build.

React Native produces genuinely native apps for both platforms from one codebase, using the same language and much of the same reasoning as the web work around it. It is not a compromise in the way a wrapped website is — the interface is native components, the performance is native, and the store treats it as a normal app.

It does not remove the store overhead#

One codebase, still two store listings, two review processes, two sets of signing credentials and two platforms to test on. The saving is in development, not in distribution or maintenance, and people consistently underestimate the second.

Expo makes the operational part manageable#

Managed builds, over-the-air updates for JavaScript changes, and a build service that removes most of the native toolchain pain. For a small team it is the difference between shipping and fighting Xcode — worth a post of its own.

You still need native knowledge occasionally#

Some integrations require touching native modules, and when that happens you need someone who can. It is a smaller share of the work than it used to be and it is not zero, which is worth knowing before committing to a stack on the basis that it avoids native code entirely.

The web is still the acquisition layer either way#

Even for products that clearly need an app, almost nobody discovers it inside the store. They arrive from a search, a link, an advertisement or a recommendation, and that journey passes through a web page. A store-first product with a weak site is losing people before the install is ever offered, which is why the two decisions are less independent than they look.

Can you do both?#

Yes, and the sensible version is a shared backend with two front ends rather than one codebase rendering everywhere.

A web application and a mobile app talking to the same API is a normal architecture and usually the right one. The temptation to share the interface layer as well — running React Native for Web, or wrapping the site in a shell — produces something that is slightly wrong on every platform.

Share the API, the types and the validation#

This is where the genuine reuse is. One schema, one set of validation rules, one authorisation model, consumed by both clients. That removes the class of bug where web and mobile disagree about what a valid input is — which is what a shared contract is for.

Do not share the interface#

Mobile navigation patterns, gesture expectations and layout conventions differ from web ones for good reasons. A shared component layer tends to converge on the lowest common denominator and satisfies neither audience.

Start with the web unless you know otherwise#

If you are unsure, building the web version first gives you an audience, real usage data and a working backend. Adding an app afterwards to a validated product is a straightforward project; building both simultaneously for an unvalidated one is how budgets disappear.

What does a wrapped website cost you?#

The store overhead of an app and the experience of a website, which is the worst arrangement available.

Putting a web view in a native shell is superficially attractive — one codebase, store presence, quick to build. What you ship is an app that feels like a website: browser scroll physics, no native transitions, a visible loading state on launch, and gestures that behave slightly wrong.

Reviewers are unsympathetic#

App stores have explicit guidance about apps that are simply a website in a container, and rejections on those grounds are common. If the app offers nothing beyond what the site does, it is at genuine risk — one of the more predictable rejection reasons.

Users notice, even if they cannot name it#

The feedback is rarely "this is a web view". It is that the app feels slow or cheap, which is harder to act on and just as damaging to retention.

The exception is a genuinely hybrid product#

Native shell, native navigation, and specific screens rendered as web content that changes frequently — a help centre, a terms page, a rapidly iterating catalogue. That is a deliberate architecture rather than a shortcut, and it works.

What does each cost to build and run?#

The build difference is real and the running difference is larger.

The bottom three rows are the ongoing tax people forget. An app that is finished still needs attention every year, because the platforms move and a build that stops meeting their requirements gets removed.

Version fragmentation is a real support cost#

A meaningful share of users will be on a build several months old, so the API has to keep working for them and bugs have to be diagnosed against versions you no longer run. The web simply does not have this problem.

Budget for the store presence itself#

Screenshots for several device sizes, a description, keywords, a privacy policy, data-handling disclosures and a support URL are all required before the first submission, and they need revisiting whenever the app changes materially. It is not development work and it is several days of somebody's time that never appears in an estimate.

What do I usually recommend?#

A fast, installable mobile web experience for most projects, and React Native when the answers point clearly at the store.

The default recommendation is an excellent mobile web build — properly fast, installable, working offline where that helps. It reaches everyone, ships continuously, costs less, and for a large share of the businesses that ask me for an app it is what they actually needed.

When background work, hardware access, store distribution or daily-use retention genuinely apply, React Native is the efficient way to get there, and Expo makes the operational side manageable for a small team.

The honest counterweight: I build both, and recommending the web version means a smaller project. But an app nobody installs is worth less than a site people use, and the failure mode of this decision is not a slightly suboptimal technology — it is a six-figure build sitting at two hundred downloads while the mobile site it replaced was serving thousands. That outcome is common enough that the question deserves ten honest minutes before anybody writes a line of code.

Roughly half the people asking for an app need a fast mobile site. The question that separates them is about distribution and maintenance, not capabilities.

Conclusion#

The capability gap between a good PWA and a native app has narrowed to background execution, deep hardware access, widgets and reliable push. The distribution gap has not narrowed at all, and that — plus store billing on digital goods and the permanent maintenance commitment — is what actually decides the project.

Resolve it with six questions: how users find you, how often they use it, whether you sell digital goods, whether you need background or hardware access, who maintains the store builds in two years, and whether your audience treats an app as a credibility signal. That last one is a legitimate market fact rather than an irrational preference.

Choose the web when discovery happens through search, when the interaction is occasional, when you want to deploy on your own schedule, when store commission would change your unit economics, or when the budget only stretches to one surface done well.

Choose an app when you need background execution, deep platform integration, notifications as a core mechanic, store distribution as your channel, or when it is a daily-use tool that earns its home screen icon. React Native is the efficient route there — but it saves development time, not distribution or maintenance overhead, and people underestimate the second consistently.

Avoid the wrapped website: it carries the full store overhead and delivers a web experience, reviewers are explicitly unsympathetic to it, and users notice without being able to name why. If both make sense eventually, share the API, types and validation and keep the interfaces separate — and build the web version first unless you already know otherwise. If you want a straight answer for your particular case, that is a ten-minute conversation.