PWA or native, install friction decides

Progressive web app vs native app: what is the actual difference?

A progressive web app is a website a browser can install. It ships a web app manifest and a service worker, opens in its own window from the home screen, and keeps working when the connection drops. A native app is built with the platform SDK, distributed through an app store, and granted full access to device hardware and operating system APIs. In 2026 the choice between them rarely turns on rendering speed. It turns on how a user installs the thing, and on which device capabilities you cannot do without.

For content, commerce and most transactional products, the two now feel close enough on a mid-range phone that users do not notice the architecture. What differs is everything around the product: how people find it, how many taps sit between interest and installation, and whether your roadmap needs the camera, the Bluetooth stack or a background location feed.

What makes a web app installable?

Three things, and the browser checks all of them. The site must be served over HTTPS. It must link a valid web app manifest declaring name, icons and display mode. It must register a service worker, the background script that caches assets and serves them when the network is unavailable. Chrome only offers its install prompt once all three conditions are met.¹

This is where the platforms diverge, and it is the most underrated fact in the comparison. Meet the criteria on Android and the browser itself offers to install the app: one tap, no store, no tutorial. Safari on iOS offers no prompt at all. The user has to open the Share sheet, find Add to Home Screen and confirm.⁴ Counting user-initiated steps, a store install is one tap on the download button, an Android PWA install is one tap on the browser prompt, and an iOS PWA install is three.

A two-step difference looks trivial on a chart and behaves like a cliff in a funnel. Any step a product has to teach is a step most people will skip, which is why iOS PWA install rates collapse without an in-page prompt, an onboarding card or a post-purchase nudge that walks the user through the Share sheet.

The hard part of PWAs on iOS is not offline support. It is that nothing on the screen tells the user the app can be installed at all.

What are the real PWA iOS limitations in 2026?

Push notifications work, with conditions attached. A PWA can deliver web push on iOS 16.4 and later, and only to the copy installed on the home screen. An open Safari tab receives nothing.⁴ Teams that assume web push reaches every iPhone quietly lose their pre 16.4 audience plus every user who never completed the install, which on iOS is usually most of them.

Region now matters as much as version. Apple removed standalone home-screen PWA support for users in the EU under the Digital Markets Act, so a PWA opened there falls back to a Safari tab with no standalone window and no push.⁵ The practical consequence is that progressive web app vs native app no longer has one answer for a global product. A single install tutorial shipped worldwide will be wrong for part of your audience, so treat install messaging as region-aware content rather than a static help page.

What this does not break

Offline still works. The service worker caches the shell and whatever data you tell it to hold, on iOS as on Android, and that behaviour is independent of the install prompt problem. Standalone display, home-screen icons and queued actions that sync on reconnect are all available to an installed iOS PWA outside the EU. The constraint is reach, not capability.

What are the PWA benefits that show up in the numbers?

Weight, reach and search visibility. The published case studies are the strongest evidence, and they point the same direction even though each company measured something different. Twitter Lite reported 65 percent more pages per session, 75 percent more tweets sent and a 20 percent lower bounce rate after moving to a PWA.² Pinterest reported core engagement up 60 percent and time spent up 40 percent.² Starbucks reported that its PWA doubled daily active users on the web.³

Read those as directional rather than as a benchmark. They are self-reported, they cover different metrics on different products, and each launch replaced a slow mobile site rather than a well-built one. The mechanism behind them is what transfers: a smaller payload reaches users on weak networks who used to bounce before the first screen rendered.

User preference points the same way, though the evidence is softer. Aggregated research cited across PWA vendor documentation puts the share of users who would rather use a PWA than download a native app at around 70 percent.¹ Treat that as a signal about install reluctance, not a precise measurement. Money is following it either way: the PWA market is estimated at USD 3.14 billion in 2026, up from USD 2.47 billion in 2025, with forecast growth above 30 percent a year.⁶

The benefit nobody puts in a case study is indexability. A PWA is made of URLs. Every screen can be crawled, linked, shared and cited by an answer engine, which is why a web app compounds with your web development and content investment while a native app sits outside the index entirely. If organic discovery is a real acquisition channel, that asymmetry usually outweighs every feature comparison in the room.

Where does native still win outright?

Where the operating system is the product. Background location, Bluetooth peripherals, ARKit, tight camera and sensor pipelines, widgets and system-level integrations have no web equivalent, and no amount of PWA maturity closes that gap. Anything in mobile app development that depends on hardware access, or on running while the app is closed, belongs in native code.

Distribution is the second edge. The store is a discovery surface with its own search, ranking and install flow, and it is enormous: global app downloads are projected to reach 528.48 billion in 2026.⁸ A store listing also carries ratings, review counts and update mechanics that a home-screen bookmark cannot imitate.

That conversion multiple deserves the caveat attached to it. People who install an app have already declared intent, so part of the gap is selection rather than interface quality. The honest reading is that native converts better among users who install, which makes install rate the variable deciding whether the multiple ever pays for a second codebase.

How to decide: progressive web app vs native app

Work through requirements, not preferences. The table below is the shortlist that settles most of these arguments in a single meeting.

Two rows decided with no contest, and you have your answer. Rows that split evenly mean you are looking at a sequencing problem rather than an architecture choice.

What does a sensible sequence look like?

Ship the PWA first. It covers both platforms from one codebase, it is indexable from day one, and it produces real usage data before anyone commits to two native builds. Then build native only for the segment that genuinely needs offline-heavy or hardware-heavy features, rather than picking an architecture in a room before a single user has touched the product. That is the pattern practitioner teams keep converging on, and it fits the way a disciplined software development life cycle defers expensive commitments until the evidence arrives.

Instrument the sequence or it decides nothing. Three measurements are enough to run the call:

• Install prompt acceptance on Android. If users decline a one-tap prompt, the problem is the product, not the platform, and a native build will not rescue it.
• Standalone sessions on iOS. Detect standalone display mode and track it separately. That number is your true installed iOS base, and it caps everything you plan to deliver by push.
• Feature requests that need the OS. Log every request a web runtime cannot serve. When the log stops being a trickle, the native business case has written itself.

The mistake worth avoiding is treating this as a permanent verdict. Platform rules moved twice in recent years, once when web push arrived on iOS and once with the EU fallback, and they will move again. Teams that build the install path as a measurable surface, review it each quarter, and keep their engineering options open will keep making a better call than teams that picked a side at kickoff and stopped looking.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.