If you already run a website and are wondering whether you need "an app", this is the comparison you want — not one between PWAs and websites (a PWA is your website), but between making your site installable and commissioning a separate native app. We build PWA tooling, so read with that in mind; we have tried to make the native column as strong as it deserves to be.
Cost and time
PWA. If you control your hosting, the marginal cost is close to zero: generated files, an hour of setup, no ongoing fees. On hosted platforms it ranges from "an hour" (Webflow with a proxy) to "not possible without moving" (Shopify theme, Wix). No store fees on iOS because there is no store; a US$25 one-time Google Play fee if you want a TWA listing.
Native. A competent agency build of a straightforward app — the kind that shows your content, lets people log in and buy — is measured in weeks to months and in the tens of thousands of dollars for both platforms; a cross-platform framework (Flutter, React Native) reduces but does not remove the duplication. Then annual costs: Apple's US$99 developer fee, store maintenance, OS updates every autumn that occasionally break something, and a codebase that drifts from the website unless someone keeps them aligned. The cost is not the build; it is the second product you now own.
Capabilities
This is where native wins, and it is worth being specific about how much.
| Capability | PWA on Android | PWA on iOS | Native |
|---|---|---|---|
| Camera, photo picker, geolocation (foreground) | Yes | Yes | Yes |
| Push notifications | Yes | Yes (16.4+, installed) | Yes |
| Offline | Yes | Yes | Yes |
| Payments (Payment Request / Apple Pay / Google Pay on the web) | Yes | Yes | Yes |
| Bluetooth, NFC, USB | Yes (Chrome) | No | Yes |
| Background location, background audio | Limited | No | Yes |
| Widgets, Siri/Assistant, lock-screen controls | No | No | Yes |
| Biometric sign-in | Yes (WebAuthn/passkeys) | Yes (passkeys) | Yes |
| Heavy graphics / games | WebGL/WebGPU — good | WebGL — good, memory-limited | Best |
If your product is a content site, a shop, a booking system, a dashboard, a community, a publication or most games, everything you need is in the "Yes" rows. If it is a fitness tracker that runs in the background, a hardware companion, or something that lives on the lock screen, native is the correct choice and no PWA tooling changes that.
Discovery
Native apps are found in stores — which matters if people search "parking app" and expect results. PWAs are found the way websites are: search engines, links, QR codes, your existing traffic. Web search reaches far more people than store search for most businesses, but a store listing carries a legitimacy signal some audiences want. The middle path is real: a Trusted Web Activity lists your PWA on Google Play with no second codebase. There is no equivalent for the App Store.
Updates and control
PWA: deploy to your website, everyone has it. No review, no version fragmentation, no "please update your app" screens. Native: every change to the app itself goes through store review (hours to days) and reaches users as they update, which some never do. Content pulled from your server updates instantly in both models — the difference is in the app shell and features.
Monetisation
Selling through a native app means platform billing for digital goods: 15–30% to Apple or Google. A PWA sells through your existing web checkout at your normal card-processing rate; Apple has no say over a website. On Google Play, a TWA selling digital goods must use Play Billing, so the same rule applies to that listing — physical goods and off-app services are exempt in both cases. Advertising works equivalently: web ad networks in a PWA, mobile ad networks in native.
Performance and feel
A well-built PWA on a modern phone is indistinguishable from native for content-driven apps: instant open from cache, smooth scrolling, system-integrated notifications. Where native still feels better is in complex gesture-driven UI, very large lists, and anything that needs 60 fps animation on older devices. If your website already feels fast on a phone, the PWA will too; if it doesn't, neither will the app until the site is fixed.
The decision rule
- List the capabilities your product truly needs. If any is in the "No" rows above for the platforms your users are on, go native (or cross-platform).
- Otherwise, make the website installable first. It costs almost nothing and you learn what users actually do with an icon on their phone.
- If Play Store presence turns out to matter, add a TWA. Same files.
- Revisit native only when you have evidence — from the PWA — that a native-only capability would change outcomes.
Most website owners who follow this never reach step 4. Some do, and for them the PWA phase was still the cheapest possible market research.