Progressive web app vs native app: when a PWA is enough

A progressive web app (PWA) is often enough. If your customers or staff need an icon on their phone, a fast screen that still opens on a weak connection, and notifications, a PWA gives you all three from one web codebase, with no Play Console, no Apple Developer account and no store review. You need a store app when the product depends on hardware the browser can't reach, when people will look for you inside the App Store, or when an iPhone notification has to arrive without the user ever installing anything.

If you've been told you need an app, check which of those two lists your plan sits on before anyone opens a store account. The rest of this post is about telling them apart.

What is a progressive web app, in plain terms?

MDN describes a PWA as an app built with web technologies that gives a user experience like a platform-specific app. It runs on many devices from one codebase, it can be installed, and it can work offline and in the background.

In practice it's your website or web app with three additions:

• A web app manifest. A small JSON file with the app's name, icons, start page and display mode. This is what turns "a bookmark" into "an app" on the home screen.
• HTTPS. Installation and service workers both require a secure connection.
• A service worker. A script that sits between the app and the network. It can serve saved pages and data when the connection drops.

Once installed, web.dev notes, the PWA leaves the browser tab and opens in its own standalone window from the home screen or taskbar. To the person tapping the icon, it looks like any other app.

If you're still deciding between a website, a web app and a store app in general, start with our overview of what to build first. This post assumes you already need something app-like and asks whether the web version will do.

What does a PWA save you compared with a store app?

The store overhead.

On Android, a new personal Play Console account must run a closed test with at least 12 testers, opted in for 14 days in a row, before it can publish to production. We walked through that process in publishing an Android app on Google Play from Nepal. On iPhone, Apple says distributing apps needs an Apple Developer Program membership, and the paperwork for a Nepali company is its own project (see opening an Apple Developer account from Nepal). Then every release goes through review on both stores.

A PWA skips all of that. You deploy to your server and users get the new version without downloading a store update. There's no review queue for a bug fix, no store listing to keep in sync and no account that has to be renewed or transferred.

For internal tools this is often decisive. A field sales team logging visits, a clinic's front desk taking bookings, staff at three branches checking stock: none of them need to find the app in a store. They need a link, an icon and a screen that doesn't break when the signal does.

Can a PWA really work offline?

Yes, but only the parts you build for it. The Service Worker API lets the app intercept network requests and decide what to do when the network isn't there: serve a cached page, queue a form submission, or show the last data it saw.

That decision is design work, not a switch. Someone has to say which screens must open offline, what happens to an order entered with no signal, and how a conflict is handled when two people edit the same record. A PWA that skips those questions is a website with an icon. Write the offline cases into your requirements before you ask for a quote.

Where does a PWA fall short on iPhone?

This is where the "you need a real app" advice comes from, and some of it is out of date.

Notifications work, with conditions. Since iOS and iPadOS 16.4, WebKit supports web push for web apps, but only for web apps the user has added to the Home Screen. The manifest's display mode has to be standalone or fullscreen, and the app may ask for notification permission only in response to a user action, such as tapping a "turn on alerts" button. A customer who visits your site in Safari and never adds it to the Home Screen can't receive a push from you. Apple doesn't require a developer account for this.

Installation is manual. MDN's guide to making PWAs installable notes that on iOS 16.4 and later, a PWA can be added from the Share menu in Safari, Chrome, Edge, Firefox and Orion, but the browser install prompt event isn't supported on iOS. You can't put an "Install app" button that triggers the install. You have to show iPhone users the Share, then Add to Home Screen steps yourself, and some won't follow them.

Badges work too. The same WebKit release added the Badging API, so an installed web app can show a count on its icon.

If your business depends on reaching iPhone users who haven't installed anything, such as a promotion pushed to everyone who once visited, a PWA won't do it.

And on Android?

Installation is smoother, with one catch. According to MDN, only Chrome on devices with Google Mobile Services and Samsung Internet on Samsung phones install a PWA as a proper app (a WebAPK). Other browsers, including Chrome on phones without Google services, add a home-screen shortcut with the browser's badge that opens the site in the browser. It still works, but it looks less like an app.

Chromium browsers also check the manifest before offering to install: a name, a 192px and a 512px icon, a start URL and a display mode. Miss one and the install prompt doesn't appear.

Which hardware features need a store app?

Web apps can use many device features, but some aren't available in every browser. MDN marks Web Bluetooth as experimental, and MDN's compatibility data shows no support in Safari, including Safari on iPhone. Web NFC, for reading NFC tags, is listed for Chrome on Android only.

So if the app has to talk to a Bluetooth printer, a weighing scale or a card reader on iPhones, or read NFC tags on both platforms, plan for a store app. Check each device feature against MDN's compatibility tables before you decide, not after the build.

A quick way to decide

If your app needs	PWA	Store app
An icon, offline screens, quick updates	Yes	Yes
Push to iPhone users	Only after they add it to the Home Screen	Yes
A one-tap install button on iPhone	No	Yes, from the store
Bluetooth or NFC on iPhone	No	Yes
To be found by searching the App Store or Play	No, unless packaged for a store	Yes
Release without store review	Yes	No

Store discovery deserves one more note. MDN says an installable PWA can be packaged and published to stores including Google Play. That route brings the Play Console account and its rules back, so treat it as a later step once the web version has proved itself.

Frequently asked questions

Is a PWA cheaper than a native app?

It removes the store accounts, review cycles and separate release routine, and one codebase serves Android, iPhone and desktop. Whether the build itself costs less depends on what you'd otherwise build, so compare quotes for the same feature list.

Does a PWA work on old phones?

Web push on iPhone needs iOS or iPadOS 16.4 or later, and before 16.4 only Safari could add a PWA to the Home Screen. On an older phone the app should still work as a website, just without notifications, so build it to cope with that.

Can we start with a PWA and build a store app later?

Yes, and it's a sensible order. If the PWA talks to your backend through an API, a later Flutter or React Native app can use the same API, and the PWA keeps serving web and desktop users.

Will my PWA show up on Google?

The pages of a PWA are web pages, so public pages can be indexed like any website. Pages behind a login won't be, which is fine for internal tools.

Building one

Our web development team builds Next.js and React applications for businesses in Nepal and Australia. If someone has told you that you need an app and you want a second opinion on whether a PWA will do, describe what it has to do and we'll go through the list with you.