PWA vs Native App: Which Should You Build?

When a business decides it needs "an app," the first real decision is PWA vs native app. A progressive web app is a website built so it can be installed and used like an app. A native app is built for iOS and Android specifically and distributed through the App Store and Google Play. Each has a place, and choosing the wrong one usually costs months and a rebuild.

What each one actually is

Google's web.dev course describes a PWA as a web app that can be installed and, once installed, shows an icon on the home screen and in the app launcher, opens in its own standalone window without browser controls, and can work offline. The offline part comes from a service worker, a script that caches what the app needs. Because it is a website underneath, it has one codebase, a URL anyone can open, and updates go live the moment you deploy.

A native app is built with each platform's own tools (or a cross-platform framework that compiles to them), installed from a store and updated through store releases. It gets the deepest access to the device and the store's discovery and payment systems, and it goes through each store's review process.

Where the gap has closed

For years the strongest argument against PWAs was the iPhone. That has changed:

• Installation on iOS. web.dev notes that Safari has supported installing PWAs since iOS 11.3, and that from iOS and iPadOS 16.4 third-party browsers can install them too.
• Push notifications on iOS. WebKit announced in February 2023 that iOS and iPadOS 16.4 brought Web Push to Home Screen web apps. Two conditions matter: the user has to add the app to the Home Screen first, and the permission request has to come from a direct user action, such as tapping a "subscribe" button.
• Badges. The same release added the Badging API, so an installed web app can show a count on its icon.
• Store listings. PWAs can be published to Google Play through a Trusted Web Activity, which Chrome's documentation describes as a way to open your PWA from an Android app, with the app and site verified as the same developer through Digital Asset Links. web.dev also lists the Microsoft Store and, with some limitations, Apple's App Store as optional distribution channels, each with its own rules.

So a PWA can now be installed, send notifications and sit in some stores. The practical gap is narrower than most people assume.

Where native still earns the cost

Native is still the better choice when:

• You need device features the web does not expose reliably on iOS. Make a list of every device feature you need (Bluetooth medical devices, background location, advanced camera control, health data) and check each one's support in Safari on iOS specifically. If any must-have feature fails there, that decides it.
• App Store discovery is part of your plan. If customers will search a store to find you, you need to be in that store as a real app.
• The experience is heavy. Complex 3D, long offline sessions with large local data and intensive background work are easier to do well natively.

App Store rules that change the math

Two of Apple's App Review Guidelines regularly surprise people.

Guideline 4.2, Minimum Functionality, says an app should include features, content and UI that take it beyond a repackaged website, and that an app that is not particularly useful, unique or app-like does not belong on the App Store. Wrapping your website in a thin app shell and submitting it is a common way to get rejected.

Guideline 3.1.1 says that if you sell access to features or content inside the app, such as subscriptions or premium content, you must use in-app purchase. If your business model is a digital subscription, read this guideline before you decide, because it affects how you take payment inside a native iOS app. The current text treats the United States storefront differently, allowing buttons and links to other ways of paying there, so check the rules for each country you sell in. A PWA takes payment through your own checkout on the web.

PWA vs native app: a decision framework

Answer these in order. The first "yes" usually decides it:

1. Is there a must-have device feature that fails in iOS Safari? If yes, build native.
2. Will customers find you mainly by searching an app store? If yes, build native, or a PWA plus store listings where allowed.
3. Is most of your audience already arriving from search, email, text links or QR codes? If yes, a PWA meets them where they already are, with no install step before first use.
4. Do you need to ship changes weekly without review delays? A PWA updates on deploy.
5. Is budget for two platforms plus a website realistic? If not, start with a PWA.

How that plays out in businesses we work with:

• A home care agency's caregiver portal for shift updates and notes: PWA. Caregivers open it from a text link, and push now works on iPhone once installed.
• A restaurant's ordering app: usually a PWA or a well-built ordering site, since customers come from Google and Instagram.
• Healthcare software paired with a Bluetooth device: native, after checking the device's requirements.
• A consumer subscription app that wants to be found in the App Store: native, with careful reading of guideline 3.1.1.

For the budget side, our guide to what drives web app costs breaks down where the money goes.

Starting with a PWA, then going native

A PWA is often the right first step even when native is the long-term plan. You learn which features people use, build the backend and data model once, and go native later only for the platforms and features that need it. The web app keeps working as the entry point from links and search.

That is how we are building our own product. Our AI goal planner installs as a web app today, and native iOS and Android apps are planned.

How we decide with clients

At Pinn.Media we start every app conversation with the feature list and where your users come from, then recommend the smallest build that covers both. Sometimes that is a PWA, sometimes native from day one. If you are weighing the two, bring your feature list to a discovery call at /contact#book.