PWA vs. Native App vs. Web App: How to Choose

Short answer. Build a native or cross-platform mobile app when people open the product most days, when push notifications are part of how it works, when it has to run with no network, or when it needs deep hardware access. Build a progressive web app when use is occasional, when discovery happens through search or a shared link, and when you would rather ship one codebase than three. Build a plain web app when nobody needs it offline, on their home screen, or in a notification. Most products that think they need all three actually need a PWA plus a mobile app, and never a separate plain web app.

What the three things actually are

A plain web app runs in a browser tab. It is HTML, CSS and JavaScript served over the network, and if the network is gone, so is the app.

A progressive web app is the same web app with two additions: a service worker, which lets it cache assets and data and keep working offline, and a web app manifest, which lets a user install it to the home screen so it launches without browser chrome. It is not a different technology stack. It is a web app that has done two specific pieces of work.

A native app is compiled and installed from the App Store or Google Play. In practice most teams do not hand-write two of them. They write one React Native or similar cross-platform codebase, ship it to both stores, and drop to Swift or Kotlin only for the parts that need it.

Side-by-side comparison

	Plain web app	Progressive web app	Native (or cross-platform) app
How users get it	URL	URL, optional install to home screen	App Store or Google Play
Works offline	No	Yes, via service worker cache you design	Yes, and with fewer storage caveats
Push notifications	No	Yes on Android; on iOS only after the user adds it to the Home Screen, iOS 16.4+	Yes on both platforms
Home screen icon	No	Yes, a real launcher entry on Android Chrome and Samsung Internet, a share-menu install on iOS	Yes
Hardware access	Camera, location, limited sensors	Same as web app; Bluetooth and some sensors are not available in every browser	Full platform access
Discoverable in search	Yes	Yes	No, only the store listing is
Shipping an update	Deploy, live immediately	Deploy, live on next load	App review, then user updates; JavaScript-only changes can go over the air on some stacks
Store review and fees	None	None	Yes, per store
Codebases to maintain	One	One	One cross-platform, plus native modules where needed
Typical fit	Internal tools, dashboards, anything always online	Occasional-use customer portals, content, commerce, link-shared tools	Daily-use products, field work, notification-driven products

What PWAs can and cannot do on iOS and Android right now

This is the part of any PWA comparison most likely to be out of date, so each claim below carries its source and the date we read it.

Installing to the home screen. On iOS 16.3 and earlier, a PWA could only be installed from Safari. On iOS 16.4 and later it can be installed from the Share menu in Safari, Chrome, Edge, Firefox and Orion. On Android, only Chrome on devices with Google Mobile Services and Samsung Internet on Samsung devices install a PWA as a real app package with an entry in the app launcher, the app switcher and system settings. Other Android browsers add a browser-badged home screen shortcut that just opens the site. (MDN, "Making PWAs installable", https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable, last modified 7 September 2026, read 24 September 2026.)

That difference matters commercially. On Android a PWA can look and behave like an installed app. On iOS and on non-Chrome Android browsers, "install" means something weaker, and your onboarding has to account for it.

Push notifications. Web Push arrived for iOS and iPadOS web apps in 16.4, and only for web apps that have been added to the Home Screen. The permission prompt must come from a direct user action such as tapping a subscribe button. (WebKit, "Web Push for Web Apps on iOS and iPadOS", https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/, published 16 February 2023, read 24 September 2026.) Apple's current developer documentation still states the same restriction: "Add web push to Home Screen web apps in iOS 16.4 or later and Webpages in Safari 16 for macOS 13 or later." (Apple, "Sending web push notifications in web apps and browsers", https://developer.apple.com/documentation/usernotifications/sending-web-push-notifications-in-web-apps-and-browsers, read 24 September 2026.)

So push on a PWA is real on iOS, but it is gated behind a step most users never take. If notifications are how your product works, you are asking every iOS user to add the app to their Home Screen first. A native app asks for permission on first launch. That gap is a common reason a PWA plan gets abandoned halfway.

Hardware access. Camera and location work well from the web. Web Bluetooth does not: MDN classes it as limited availability and experimental, meaning it does not work in some of the most widely used browsers. (MDN, "Web Bluetooth API", https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API, read 24 September 2026.) If your product talks to a peripheral, check each specific API against current browser support before you commit to the web.

Offline storage durability. Safari's Intelligent Tracking Prevention deletes a site's script-writable storage, including IndexedDB, LocalStorage, and service worker registrations and caches, after seven days of Safari use without user interaction on that site. Web apps added to the Home Screen are not part of Safari and run their own counter, and Apple does not expect deletion for first-party data inside them. (WebKit, "Full Third-Party Cookie Blocking and More", https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/, published 24 March 2020, read 24 September 2026.) The practical rule: never treat browser-tab storage as durable, and treat offline data as safe only in an installed app.

App store distribution. A PWA is not in the App Store by default, and repackaging one to get there runs into Apple's minimum functionality rule, which says an app "should include features, content, and UI that elevate it beyond a repackaged website". (Apple, App Review Guidelines, guideline 4.2, https://developer.apple.com/app-store/review/guidelines/, read 24 September 2026.) On Android there is a supported path: a Trusted Web Activity wraps web content in an Android app so a PWA can ship through Play. (Chrome for Developers, "Trusted Web Activity", https://developer.chrome.com/docs/android/trusted-web-activity/, read 24 September 2026.) If store presence is a requirement on both platforms, plan for native on iOS.

The decision framework: six questions

Answer these in order. The first one that gives a hard answer usually decides it.

1. Does it have to work with no network? Not "should be fast on a bad connection", but genuinely offline: a warehouse, a basement, a job site, a plane. If yes, you need an installed app, and on iOS specifically you need to understand the storage rules above before choosing a PWA. If offline is a nice-to-have, a PWA's service worker cache covers it well.

2. Are push notifications load-bearing? If the product does not work unless a notification reliably arrives, go native. If notifications are a re-engagement bonus, a PWA is fine and you accept lower opt-in on iOS.

3. Do you need to be in an app store? Sometimes the answer is about procurement or credibility rather than technology: an enterprise buyer or a consumer audience expects a store listing. That is a legitimate reason to go native, and it is worth separating from the engineering requirements so it gets argued honestly.

4. What hardware does it touch? Camera and location: the web is fine. Bluetooth peripherals, background location, deep OS integration: native. Check the specific API rather than reasoning from the general category.

5. How often do you need to ship? A PWA deploys like a website, so a fix is live in minutes. A native release goes through review. If you are iterating weekly on a product still finding its shape, that difference compounds, and it is a real argument for starting as a PWA and adding native later.

6. What does a second codebase actually cost you? Not just to build. To keep. Every feature gets specified once and implemented twice, every OS upgrade needs regression testing, and every hire needs two skill sets. If the answers to questions 1 through 4 did not force native, this question usually settles it in favor of the web.

Where each one wins

A PWA wins when use is occasional and discovery happens through search or a shared link: a customer portal someone opens once a quarter, a booking flow, a content or commerce experience, an internal tool used from whatever device is nearest. You get one codebase, instant updates, search visibility, and a link you can paste into an email.

A native or cross-platform app wins when the product is opened most days, when notifications drive the behavior you care about, when it runs where there is no signal, or when it needs hardware the browser does not reach. Field work, inspection, delivery and service apps land here almost every time.

A plain web app wins when the app is always online anyway and nobody wants an icon: internal dashboards, admin consoles, reporting tools. Adding a service worker to a product like this is work nobody asked for.

And the most common real answer: a PWA for the public, search-visible surface, and a mobile app for the daily-use core. They can share one backend API.

Mistakes we see most often

Choosing a PWA to save money, then needing iOS push. The saving is real until the notification requirement shows up, at which point you have built the thing twice. Answer question 2 before the estimate, not after.

Choosing native for credibility with no other reason. If that is genuinely the reason, say so and decide it as a marketing question. It is a defensible answer; it is just not an engineering one.

Treating "PWA" as a decision instead of two pieces of work. A service worker and a manifest are tasks with owners and test cases. A web app does not become a PWA because someone wrote PWA in the brief.

Assuming iOS behaves like Android. Most of the surprises in this comparison are iOS-specific, and most of them relate to installation being a user action rather than a default.

Where to read next

If you are weighing a cross-platform build against fully native, our mobile application development page covers where React Native fits and where native modules are worth the extra work.

Still not sure which of the three your product is? Send us the answers to the six questions above and we will tell you what we would build and why, including when the answer is that you do not need an app at all. Start the conversation.