One codebase that installs from the browser, or a real App Store presence. The right answer depends on which capabilities your product actually needs.
A progressive web app is a website that behaves like an app: it installs to the home screen, works offline, and sends push notifications. A native app is built for the platform and distributed through its store. The pitch for PWAs — one codebase, no store review, instant updates — is real. So are the gaps, and on iOS they are bigger than most comparison articles admit. The honest answer starts with which platform your users are on and which device capabilities your product needs.
On Android, a well-built PWA is close to a first-class citizen: install prompts, push notifications, background sync, and a place in the app drawer. Distribution is a URL — no store review, no 15–30% platform fee on payments, and every user is on the latest version the moment you deploy. For content products, portals, booking flows, and internal tools, that is often everything required.
iOS is the asterisk. Push notifications only work after the user manually adds the site to their home screen via the Share menu (supported since iOS 16.4, and iOS 26 now opens home-screen sites as web apps by default), and the reachable notification audience ends up roughly an order of magnitude smaller than a native app’s. There is no background sync, no Bluetooth or NFC access, and Safari can evict stored data under storage pressure. Regulators have pushed Apple on this — the EU fined Apple €500M over browser-engine restrictions — but as of 2026 the capability gap on iOS remains.
Native apps get the full platform: reliable push with Time Sensitive notifications and Live Activities, background processing, Bluetooth/NFC, geofencing, widgets, biometrics, and deep OS integration. They also get App Store distribution — which is both a cost (review cycles, platform fees) and an asset: store presence is still where many users expect to find and trust an app, and install friction is one tap.
The price is two codebases or a cross-platform framework, store review on every release, and slower iteration. For teams that need native reach without two teams, React Native and Flutter remain the middle path — one codebase compiled to real native apps. That is usually the right comparison to make: not PWA vs pure native, but PWA vs cross-platform native.
Your product is content, commerce, booking, or an internal tool — and Android or desktop is a big share of your audience.
You need to ship and iterate fast, without store review or platform fees.
Push on iOS is nice-to-have, not core to the product.
Reliable push notifications on iOS are core to engagement.
You need hardware access — Bluetooth, NFC, sensors — or heavy background work.
App Store presence matters for trust, discovery, or your business model.
Yes, since iOS 16.4 — but only after the user manually adds the site to their home screen from the Share menu and grants permission. That multi-step flow means the reachable audience is far smaller than a native app's, so if iOS push is core to your product, build native.
Yes. Service workers cache the app shell and data so it loads and functions without a connection — one of the defining PWA capabilities, and it works on both Android and iOS.
That's often the right sequence: validate the product as a PWA, then invest in native (or React Native/Flutter) once you've proven demand and hit a real capability wall. The backend and most business logic carry over.
Google Play, yes, via Trusted Web Activity. Apple's App Store is stricter and generally expects a more native-feeling wrapper, which narrows the practical PWA-to-store path on iOS.
Push notifications and background sync support arrived late and remain more limited than Android's — if those are core to your product, that gap usually decides the question.
A practical comparison of React Native and Flutter for cross-platform mobile development — performance, team fit, ecosystem, and when native beats both.
Read the guideThe security work that actually protects a mobile app — storage, network, auth, and API hardening — organized around OWASP's mobile standard.
Read the guide