Quick answer: In the PWA vs native app choice, a progressive web app is one web build that installs from the browser, works offline and can send push notifications, including on iPhone once it is added to the Home Screen. A native app wins when you need store discovery, Bluetooth, NFC, background work or deep OS features.

Most PWA vs native app articles stop at “PWAs are cheaper, native is more powerful.” That’s true, but it won’t tell you whether your feature list works in a browser on the phones your customers carry. Our mobile app development guide covers the main ways to build an app, and our native vs cross-platform comparison covers cost and speed across all of them. This post goes one level down: what a progressive web app can and can’t do on iPhone and Android today, where it costs you, and how to test the idea before you commit a budget.

What is the difference between a PWA and a native app?

A PWA is a website built to behave like an app. A native app is software written for one operating system and installed from the App Store or Google Play.

The PWA runs in the phone’s browser engine. It uses a web app manifest so it can be installed with its own icon and open in its own window, and a service worker so it can cache files, load without a connection and receive push messages. MDN’s progressive web apps documentation is the clearest reference for how those pieces fit together. A native app is written in Swift or Kotlin (or in a cross-platform framework that compiles to native), goes through store review, and gets full access to the operating system’s APIs.

Users notice whether the app opens fast, remembers them, works on a weak connection and pings them at the right moment. You need to know which of those you can deliver from the web.

PWA vs native app: which features work where?

Core features such as installing, offline use, camera and push now work in a PWA on both platforms. Hardware access and background work are where the web still falls short, especially on iPhone.

Feature	PWA on Android (Chrome)	PWA on iPhone (iOS / iPadOS)	Native app
Install with its own icon	Yes, the browser can prompt	Yes, through Share > Add to Home Screen; no automatic prompt	Yes, from the store
Works offline	Yes, through a service worker	Yes, through a service worker	Yes
Push notifications	Yes	Yes on iOS 16.4 and later, only after the app is added to the Home Screen and the user taps to allow	Yes
Camera, microphone, location while open	Yes, with permission	Yes, with permission	Yes
Bluetooth and NFC	Partly, through Chrome-only web APIs	No	Yes
Background sync and background location	Limited	No	Yes, within OS rules
Widgets, health data, deep OS integrations	No	No	Yes
Store listing	Possible, by wrapping the PWA (Trusted Web Activity)	Not as a plain website	Yes
Updates	Instant, on your server	Instant, on your server	Through store review and user updates

Browser support changes with every release, so treat this table as a starting point and check the current status of any feature you depend on before you sign off a plan (last checked 31 October 2026).

Do PWAs really send push notifications on iPhone now?

Yes, with two conditions. Apple’s WebKit team explains in its post on web push for Home Screen web apps that from iOS and iPadOS 16.4, a web app added to the Home Screen can ask for notification permission, and the request has to come from a direct user action such as tapping a subscribe button.

That changes your onboarding. On Android a visitor can allow notifications from the browser tab. On iPhone they first have to install the app from the Share menu, open it from the icon, and then tap your button. If notifications are central to your product, design and test that install screen early, because many iPhone users have never used Add to Home Screen.

Can a PWA go on the App Store or Google Play?

Google Play accepts PWAs packaged as a Trusted Web Activity, which opens your web app full screen inside an Android app shell. Apple’s App Store is stricter: section 4.2 of its App Review Guidelines says an app should include features, content and UI that “elevate it beyond a repackaged website.” If an App Store listing matters to your customers, plan for a real iOS app.

When is a PWA the right choice over a native app?

A PWA suits products that people reach through a link, use in short sessions and don’t need hardware for. It also suits teams that want to ship weekly without waiting for store review.

Typical fits:

• Customer portals and dashboards, where users log in to check orders, invoices or bookings.
• Internal tools for staff, such as field forms, stock checks and approvals, where you control which phones people use.
• Booking and ordering flows that customers open from WhatsApp, email or a QR code.
• Content and catalogue apps that need to rank in Google, because every PWA screen can be a normal, indexable web page.
• Early versions of a product, where the goal is to learn what people use before paying for two store apps.

That last point overlaps with how we think about MVPs in general. Shahrukh’s guide on how to build an MVP walks through cutting a product down to the smallest version worth testing, and a PWA is often the cheapest container for that version.

When should you build a native app instead?

Go native, or cross-platform with native modules, when the app has to work while it is closed, talk to hardware, or be found in a store.

Concrete signs: a delivery or fitness app that tracks location in the background; a product that pairs with a Bluetooth device such as a scale, printer or wearable; anything that needs home screen widgets, Apple Health or Google Health Connect data; a consumer app where people expect to search the App Store for you; or an iPhone-heavy audience you can’t count on to install from the Share menu. If you land here, the next decision is which framework, and our Flutter vs React Native comparison picks up from there.

What do you give up by choosing a PWA?

You give up store discovery, the trust that comes with a store listing, and some reliability on iPhone. In return you get one codebase and instant updates.

Without a store page there are no store ratings or reviews, and no store search, so a PWA depends on your website, search rankings and links to bring users in. Install is less obvious on iPhone, so fewer people end up with your icon on their screen. And because the PWA runs inside the browser engine, a browser update can change how a feature behaves, which means testing on real devices is part of maintenance, not a one-off job.

On the plus side, a bug fix is live the moment you deploy it, nobody has to update anything, and the same product works on desktop without extra work. For portals and internal tools, that often matters more than a store listing.

Can you start with a PWA and move to a native app later?

Yes, if the backend is built as an API from day one. The native app then becomes a second front end on the same data, and you don’t rebuild the business logic.

If the PWA talks to a clean REST or GraphQL API, with authentication, roles and business rules on the server, a later iOS or Android app reuses all of it. If the logic is tangled into the web pages, going native means a rewrite. A good web app requirements document shows how to list features in a way that makes the “web now, native later” split visible before anyone writes code.

How do you test whether a PWA is enough for your app?

Take your must-have features, build the riskiest ones as a small prototype, and try them on a real iPhone and a real Android phone.

1. List the must-haves. Write every feature the first version can’t launch without, then mark any that touch hardware, background work, notifications or payments.
2. Check support for the marked features. Look each one up on MDN, then confirm on devices. Pay most attention to iPhone, where all browsers use Apple’s WebKit engine.
3. Serve it over HTTPS. Service workers only run on secure origins, so a PWA needs an SSL certificate even in testing. ResellerBytes explains what to look for in web hosting with free SSL.
4. Walk through install and notifications as a new user. On iPhone, follow the Add to Home Screen path yourself and check that your on-screen instructions are clear.
5. Test offline. Switch on airplane mode and check what loads, what fails, and what message the user sees.
6. Decide with the results. If every must-have passes on both phones, a PWA is a sound first release. If one fails on iPhone and most of your users are on iPhone, budget for a native or cross-platform app.

FAQ

Is a PWA the same as a responsive website?

No. A responsive website adapts its layout to the screen. A PWA adds a manifest and a service worker so it can be installed, open in its own window, work offline and receive push notifications.

Do PWAs work on iPhone?

Yes. iPhone users can add a PWA to the Home Screen from the Share menu, and from iOS 16.4 an installed web app can send push notifications. Bluetooth, NFC and background tasks are not available to web apps on iPhone.

Are PWAs good for SEO?

They can be, because each screen can be a normal web page that search engines crawl and index. Native app screens don’t appear in Google search results the same way, so content-heavy products often gain from the web version.

Can a PWA take payments?

A PWA can use the same online payment gateways as any website. Selling digital goods inside a store-listed app is different, because Apple and Google have their own billing rules for apps in their stores.

Talk to us about your web app

If you’re deciding between a PWA and a native app, send us your must-have feature list and the phones your customers use. Diligent Creators builds web applications with Next.js and TypeScript, and RESTful and GraphQL APIs that serve both web portals and mobile apps, so the web version can grow into a store app later. See our web application development services to start the conversation.