VKT Toolkit · October 8, 2026 · 9 min read

PWA vs Native App: An Honest Comparison for 2026

Most "PWA vs native app" articles are written by someone selling one of the two. This one is written by a team that shipped a PWA — nine small tools, no app store, no review queue, no install banner — and would still tell you to build native if your product needs it.

So here is the honest version. A PWA is a website plus three things: a manifest that lets it install to the home screen, a service worker that lets it work offline, and HTTPS. A native app is a binary you submit to a store, get reviewed, and ship. Everything that actually decides the question comes down to four things — money, updates, capabilities, and how people find you.

The real difference, in one line

A native app is three products — an iOS build, an Android build and a web presence — that you maintain separately. A PWA is one codebase you serve over HTTPS, which happens to be installable. That is the whole architecture argument, and everything else follows from it.

One number that used to sink PWAs is no longer a problem: service workers — the piece that makes offline work possible — now reach roughly 96% of users worldwide. "It won't work on enough devices" is not a reason to avoid a PWA in 2026. The reason to avoid one is a specific capability gap, and those live almost entirely on iOS.

The money: fees, builds and maintenance

There are two different costs here and they get mixed up constantly. What you pay to build it, and what you pay to distribute it.

Distribution is where the surprise lives. A PWA runs on your own domain and takes payment through your own gateway: no registration fee, no commission, no gatekeeper. Native apps pay both, and the commission is the expensive half — it is a percentage of revenue, forever. Apple takes 30% as standard, or 15% under the Small Business Program (under $1M a year). Google takes 15% on the first $1M and 30% after that. Registration itself is small: Apple charges $99 a year, Google $25 once.

This shifted in 2025 and 2026, and the details matter. After the Epic v. Apple injunction, US apps on iOS can now link out to their own web checkout, and Apple has proposed a fee of around 15% on those external-link purchases — a number still being argued over, not settled. Google opened external billing to the US, UK and EEA on 30 June 2026, but still charges a service fee on link-out sales (10% for subscriptions, 20% for other digital items). So on Google, linking out saves you the extra 5% billing fee rather than the whole commission. Physical goods and services are generally exempt from store commission on both platforms — which is why e-commerce apps sidestep the whole argument.

The honest counterpoint: if your app sells nothing digital, the commission argument evaporates and the store's discovery may be worth more to you than the fee you avoided. Do not build a PWA purely to dodge a fee you were never going to pay. Store review is also faster than its reputation — Apple now clears most submissions inside a day — so "no review queue" is a nice-to-have, not a reason on its own.

What a PWA still cannot do (mostly on iOS)

The gaps have narrowed a lot, and it is worth saying so plainly, because the "PWAs are crippled" line is out of date. Push notifications arrived for installed PWAs on iOS in 16.4 (March 2023). Safari 18.4 added Declarative Web Push and Screen Wake Lock. And in iOS 26, any site you add to the Home Screen opens as a standalone app by default — no browser chrome, no ambiguity.

What has not moved is the list below. If any of these is on your critical path, you are not choosing between a good option and a worse one; you are choosing between native and a weaker product.

A few of these deserve a sentence more. Storage is not a database on iOS. WebKit may clear a site's script-writable storage if it has been left unused for a stretch, so treat anything cached locally as a cache and keep the authoritative copy on your server. Every browser on iOS runs on WebKit — Chrome and Firefox inherit Safari's rules, so there is no engine competition pushing iOS PWA features forward, which is why this table changes slowly. And push on iOS needs the install first, which quietly raises the stakes on your install flow: at most 5% of websites get that far, and far fewer explain how.

Android, for contrast, is excellent at this. Chrome fires an install prompt on its own, rich push works, hardware APIs are available, and a Trusted Web Activity lets you publish the same PWA into Google Play if you want a listing. If your audience is mostly Android, the PWA case gets much stronger.

Reach versus retention

This is the part of the comparison that is not about technology at all.

Reach favours the PWA, structurally and by a wide margin. A PWA is your website, so every page can be crawled, indexed and ranked — and read by AI answer engines, which is where a growing share of questions now get answered. A native app is invisible to all of it: you compete in store search instead, against everyone else who paid the same $99. If your growth model is "people search for the problem I solve", a PWA is the only one of the two that can even play.

Retention favours native, and push is why. A native app can send rich push without any precondition, refresh data in the background, and sit in a widget on the home screen. A PWA can do none of the background parts on iOS and can only push after the manual install. So on a mostly-iPhone audience, if notifications are your retention loop, that single fact decides it.

Which is why the honest answer for many teams is not either/or: ship a PWA for acquisition and a native app for your best customers. The PWA catches everyone who arrives from a search result; the native app looks after the people who already love you enough to download something. Both are real strategies, and they share a backend.

Worth knowing, so you are not quoting stale numbers: the famous PWA wins — Twitter Lite, Pinterest, Starbucks — date from 2017. Treat them as history that proved the idea, not as benchmarks you can promise. The market itself is healthy though: PWAs are estimated at around $3.14 billion in 2026, growing near 30% a year.

How to decide

Forget general advice. Count how many of these sit on the critical path of your product:

• Bluetooth, NFC, USB or deep sensor access;
• Reliable background sync, background location or anything that must run while closed;
• Home-screen widgets or a lock-screen presence;
• Rich or silent push as the core loop, on a mostly-iPhone audience;
• Being discovered by people browsing the app store;
• Graphics-heavy work: games, video or photo editing, AR.

Two or more: build native. You will not engineer around those on iOS, and you will ship a compromise and call it a design choice.

One or none: a PWA is almost always the better first bet. One codebase, updates that ship in minutes instead of a review cycle, no commission, and search traffic that compounds instead of being rented from a store. If you are unsure, ship the PWA first and measure — adding a native app later is cheaper than discovering you did not need one.

And if your idea is small — a counter, a checker, a two-minute thing to fidget with — it is not a close call. Nobody downloads a 40 MB app to pop bubble wrap once. That is exactly the case our own suite lives in: nine tiny tools that install in one tap and keep working offline, because the alternative is asking a stranger to spend three minutes in a store for thirty seconds of play. A link beats a download, every time.

FAQ

More guides in the VKT blog.