Progressive web app vs native app: what actually decides it

This question arrives already framed as a contest, usually by whoever asked last. It is not a contest. A progressive web app and a native app are two different distribution and capability trade-offs, and the right one falls out of a short list of things your product must be able to do.

The list is short because most of what people assume is native-only stopped being native-only some years ago, and the parts that are still out of reach are specific rather than general.

What a PWA is, in the definition that matters

Google's own framing is the useful one. A progressive web app is a web app "built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase". The two halves of that sentence are the whole trade: enhanced capabilities on one side, one codebase and no install step on the other.

The capability list is longer than most people expect. Push notifications, geolocation, camera and microphone through WebRTC, WebGL, WebAssembly, file system access and clipboard integration are all available to the web now. Installing a PWA moves it out of the browser into its own window, so the thing your users end up with does not look like a browser tab.

Google is also direct about the ceiling, and quotes it plainly: "some capabilities are still out of the web's reach." That sentence is the entire decision. Your job is to find out whether anything you need sits on the wrong side of it.

The three questions that settle it

Ask these in order and stop at the first yes. If you reach the end without one, build the PWA, because you will get the same product for less money and ship it to every device at once.

• Does it need deep, always-on hardware or OS integration? Background location tracking while the app is closed, Bluetooth peripherals, health and fitness sensors, tight integration with the system contacts or telephony stack. These are the clearest native cases and they are not close calls.
• Does the business model require the app stores? Not "would like to be listed", but requires: in-app purchase of digital goods on iOS, or a buyer procurement process that will only accept something with a store listing. This is a commercial constraint rather than a technical one and it decides just as hard.
• Does discovery depend on the store rather than search? Consumer apps often live or die by store placement. B2B and internal tools almost never do, and for them a store listing is a cost with no matching benefit.

Where the money actually goes

The row people underweight is release friction. A store review sits between you and every fix, which changes how a team behaves: batching, longer QA cycles, and a reluctance to ship small corrections. For an internal tool or a B2B product that iterates weekly, that friction is a real recurring cost and it never appears in the build quote. The related reading on how long it takes to build a web app covers the schedule side of the same problem.

The case we see most often

The typical request is an internal or B2B tool, used on a laptop most of the day and a phone occasionally, by a known set of people who will be told to use it. Every part of that description argues for a PWA. There is no discovery problem to solve, no store to satisfy, and the desktop use is the majority case rather than an afterthought.

The teams that go native anyway usually do so for one of two reasons, and both are worth naming out loud. Either somebody senior believes an app on a phone signals seriousness, which is a positioning argument dressed as a technical one, or the vendor quoting the work builds native and priced accordingly. Neither is illegitimate, but neither should be mistaken for a requirement. Our note on choosing a software development company covers how to tell a genuine constraint from a supplier preference.

Performance is not the differentiator people think

"Native feels faster" is often true in practice and rarely true in principle. A slow PWA is usually a badly built web app rather than evidence about the platform, and the fix is the same one any web app needs. The measurable version of feel is published: Google's Core Web Vitals put good at 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint and 0.1 for Cumulative Layout Shift, assessed at the 75th percentile of page loads.

Those are achievable numbers for a well built web app, and a PWA that hits them does not feel like a website. A PWA that misses them badly will lose the comparison, but it would have lost it as an ordinary site too. If that is the situation you are in, the mobile slowness diagnostic is the more useful starting point than a rewrite.

The honest limits

Two things we will not tell you are simple. iOS support for web platform features has historically lagged, and specific capabilities can behave differently or arrive late there. If your product depends on a particular API, check that API on iOS before committing to either path, because the answer changes over time and any general statement in an article like this one goes stale.

And if you genuinely do not know whether you need a store listing, that is not a technology question and no engineer can settle it for you. It is a distribution question, and it is worth answering before anybody scopes a build. Scoping the project properly exists partly to force that answer out early, while it is still cheap to change.

Where the decision is close, the cheaper experiment is almost always the PWA first. It ships to every device at once, it can be installed, and if a hard native requirement surfaces later you will have learned it from real usage rather than from a meeting. Going the other way, from a native build to the web, means paying twice.