Progressive Web App or Native App: Which Do You Need?

"Do we need an app?" is usually a progressive web app vs native app question in disguise. The answer depends less on technology than on three facts about your product: which phone features it needs, how people will find it, and how often they will come back.

A progressive web app (PWA) costs less to build and reaches anyone with a link. A native app can do more on the device and lives in the app stores. The differences are specific and checkable, especially on iPhone, so this guide lists them one by one.

The short version

A PWA is usually the right first build when:

• the product already works as a responsive website and you want it to feel like an app;
• people arrive from search, an email or a shared link, and use it now and then;
• what you need from the phone is the camera, location while the app is open, offline reading or form entry, and notifications;
• one team and one codebase have to serve phones and desktops.

A native app is the better choice when:

• the product has to work in the background: tracking location, talking to Bluetooth devices, reading health sensors;
• being in the App Store and Google Play is part of how customers find and trust you;
• people use it daily and expect deep integration, such as widgets, the share sheet or the wallet;
• you sell digital content or subscriptions inside the app and want the stores' billing.

What a PWA is once the label is removed

A PWA is a website with three additions. It is served over HTTPS. It has a web app manifest, a small JSON file that gives the name, icons, start address and display mode. And it registers a service worker, a script the browser runs in the background for your site to cache files and data, answer requests when the network is gone and receive push messages.

Installing it puts an icon on the home screen and opens the site in its own window without the browser's address bar. It is still made of pages with addresses, and it still updates the moment you deploy, with no store review. Google's Learn PWA course walks through each part.

Progressive web app vs native app, capability by capability

"PWA" does not mean one fixed set of features. What a web app can do depends on the browser, so the comparison needs separate columns for Android and iPhone.

Capability	PWA on Android (Chrome)	PWA on iPhone (Safari)	Native app
Installing	The browser offers an install prompt	Manual: Share, then Add to Home Screen	From the store
Push notifications	Yes	Yes, once the app is on the Home Screen (iOS 16.4 or later)	Yes
Offline use	Yes, through the service worker and local storage	Yes, by the same mechanism	Yes
Camera, microphone, location while open	Yes	Yes	Yes
Background location and geofencing	No	No	Yes, with the user's permission
Bluetooth, NFC and USB devices	In Chromium-based browsers	No	Yes
Sending queued data in the background	Limited, through Background Sync	No	Yes, within the system's limits
Store listing	Google Play, packaged as a Trusted Web Activity	The App Store expects more than a wrapped website	Yes

Browser support moves, in both directions. Before you commit to a feature, check its current compatibility table on MDN and try it on real devices.

Where iPhone changes the plan

Most of the surprises in PWA projects come from iOS, and four of them affect planning.

Installing is manual. A page cannot trigger an install prompt in Safari. The user has to open the Share menu and choose Add to Home Screen, so you need an on-screen hint that shows them how, and you should expect many iPhone visitors to keep using the site in a browser tab.

Push depends on installing. Web push on iPhone works for web apps that have been added to the Home Screen, and the permission request must come from a tap on something like an "Enable notifications" button. Apple documents the requirements in its guide to web push for web apps. If notifications are central to the product, your reach on iPhone is limited to the people who installed.

Stored data is a cache. Browsers can clear a site's stored data when the device runs low on space, starting with the sites used least recently. Keep the server as the source of truth, upload what the user enters as soon as there is a connection, and never leave the only copy of someone's work in browser storage.

Hardware access is narrower. Safari does not implement the web APIs for Bluetooth, NFC or USB. If the product pairs with a device, that decides the question.

Stores, review and payments

On the web you publish by deploying. Nobody reviews the release, and you take payment through whichever provider you already use.

On Android a PWA can also be listed in Google Play. The usual route is a Trusted Web Activity, a thin Android package that opens your site full screen in Chrome and proves, through a Digital Asset Links file on your domain, that the app and the site have the same owner.

The App Store is stricter. Apple's review guidelines say an app should offer more than a repackaged website, so a thin wrapper around your site risks rejection. We list the other common causes in App Store and Google Play rejections.

Payments differ as well. Apps distributed through the stores that sell digital content or features fall under the stores' in-app purchase rules, which vary by region and change over time. Physical goods and real-world services are treated differently. Read the current text of both stores' policies before you build a business model on either side of that line.

The options in between

PWA first, native when the data asks for it

Launch the PWA, then watch who returns and what they ask for. Build the native app when a concrete need appears, such as notification reach on iPhone or a background feature, and reuse the same API.

One codebase for both stores

Flutter and React Native produce real store apps for Android and iOS from a single codebase, with access to the device features a browser lacks. This closes much of the cost gap between a PWA and two separate native apps. Our comparison of Flutter, React Native and native development covers the choice, and Flutter app development is the cross-platform route in our own stack.

Both, sharing one back end

Many products end up with a web app for reach and desktop use, and a mobile app for their most engaged users. The cost that matters is building the API properly once, so both clients use the same rules and data.

Making the call

Write down the device features the first version cannot ship without. Check each one against the iPhone column of the table. If they all pass and a store listing is not essential, build the PWA: it is the cheaper experiment and nothing in it is wasted if a native app follows. If one fails and it is central to the product, go native or cross-platform from the start.

When you are unsure, prototype the single riskiest feature and try it on a real iPhone before you commit the budget. It is a small piece of work, and it replaces an argument with a result. PWAs are part of our web application development work, and native and cross-platform builds sit with our mobile app development team, so we can scope either path, or both against the same API.

Frequently asked questions

Can a PWA send push notifications on iPhone?

Yes, with conditions. The web app has to be added to the Home Screen, the device needs iOS 16.4 or later, and the user must grant permission after tapping a control in your interface. A site that is only open in a Safari tab cannot send push notifications on iPhone.

Can I publish a PWA in the App Store or Google Play?

Google Play accepts a PWA packaged as a Trusted Web Activity, provided it meets the store's policies. For the App Store you need a native project around the web content, and Apple expects features beyond what the website already offers, so plan real native functionality and not a wrapper.

Does a PWA work without an internet connection?

Only the parts you build to work offline. The service worker serves the screens and data you chose to cache, and the app can queue what the user enters and send it later. On iPhone, plan for that sending to happen the next time the app is opened, because background sync is not available there.

Is a PWA cheaper than a native app?

Usually, because one codebase serves the website, Android, iPhone and desktop, and releases need no store review. The gap narrows with a cross-platform framework, and it can reverse if you spend months working around a platform limit that a native app would not have.