Progressive Web App vs Native Mobile App: How to Decide

October 12, 2026

A practitioner's guide to progressive web app vs native mobile app decisions: the capability gates, iOS limits, and distribution trade-offs that decide it.

Share:LinkedInXCopy link

Nobody Wants to Install Your App

The request almost never arrives as an engineering question. It arrives as "we need an app." Someone saw a competitor's App Store listing, or a sales prospect asked whether there's a mobile version, and now there's a line item.

So the progressive web app vs native mobile app debate starts in the wrong place: with the artifact instead of the constraint. Teams argue about reach and feel and "native experience," and six weeks later they're maintaining two codebases to deliver a form and a dashboard that a browser handled fine.

Here is the uncomfortable part. For most B2B products, the deciding factor is not user preference. It's a short list of platform capabilities. Either your product needs something the web engine won't give you, or it doesn't. Everything else — performance, polish, distribution — is negotiable with engineering effort. Capability gates are not.

The Question Behind "Should We Build an App?"

Strip the request down and it's usually one of three things:

A customer wants a home-screen icon. A stakeholder wants App Store presence as a credibility signal. Or the product genuinely needs hardware, background execution, or offline behaviour that a website can't do.

Only the third is an engineering requirement. The first is solved by a web app manifest. The second is a marketing requirement that happens to have an engineering cost — and on iOS, it is the expensive one, because Apple's App Store Review Guideline 4.2 rejects repackaged websites and 4.2.2 targets "web clippings." A progressive web app cannot be listed in the App Store. If someone needs that listing, you are shipping something native, and the conversation is over before it starts.

Naming which of the three you're actually solving takes ten minutes and saves a quarter.

Progressive Web App vs Native Mobile App: The Four Things That Decide It

Four axes, in descending order of how binding they are.

1. Capability gates. Does the product require an API the engine doesn't expose? This is binary and it is the first question. Not "would it be nicer natively" — can it run at all.

Control: Write the capability list before any estimate. One blocked API changes the architecture, not the timeline.

2. Distribution and discovery. How do users arrive? A PWA is indexable, linkable, and A/B-testable; you ship a fix in minutes with no review queue. A native app owns push, the home screen, and store search, but every change goes through review and users have to update. On Android you can have both: a Trusted Web Activity wraps your PWA for Play Store distribution. iOS has no equivalent.

Control: Decide whether acquisition is search-and-link or store-and-notification. They pull in opposite directions.

3. Performance envelope. Modern WebKit and Blink handle list virtualisation, offline caching through service workers, and 60fps CSS transforms competently. Where the web still loses is sustained compute and frame-perfect gesture work: real-time video effects, 3D, heavy on-device inference, complex multi-touch canvases.

Control: Prototype the single hardest interaction on a mid-range Android device. Not a flagship, and not the simulator.

4. Maintenance surface. One codebase versus two, plus store accounts, signing certificates, provisioning profiles, SDK deprecations, and an annual OS migration on each platform. Teams consistently underestimate this because it shows up as a slow tax, not a project.

Control: Count platforms you will support for three years, not features you'll ship in three months.

What iOS Still Won't Give a PWA

Android is permissive; iOS sets the ceiling. Every browser on iOS runs on WebKit — as of early 2026 no browser had shipped on Apple's BrowserEngineKit route — so Safari's capability roadmap is the platform's capability roadmap.

What is still missing or constrained:

• Web Push works, but only after "Add to Home Screen." A user in a Safari tab gets nothing. Silent and data-only push are unavailable, so you cannot wake code in the background to sync.
• No Background Sync, Periodic Background Sync, or Background Fetch. There is no announced timeline for any of them. A queued offline mutation sends when the user next opens the app, not before.
• No Web Bluetooth, Web NFC, WebUSB, Web Serial, or Web MIDI. Apple declined to implement a set of device APIs on fingerprinting and privacy grounds, and that position has held. Basic accelerometer and gyroscope access remains.
• No geofencing or background location. The W3C Geofencing proposal is effectively abandoned.
• Storage is evictable. Safari 17 raised quotas substantially, but under storage pressure it evicts least-recently-used origins. The Persistent Storage API can request protection — and it leans on notification permission to do it. PWA storage is weaker than native storage, full stop.
• No install prompt. Safari has no beforeinstallprompt. The user must find "Add to Home Screen" in the Share sheet, which means your install funnel is a tutorial.

That last one is the quiet killer. Teams build an excellent PWA and then discover that iOS installation is a four-tap manual flow nobody completes without being told.

The Capability Gate Checklist

Run this before you estimate anything. A yes on any line pushes you toward native, or toward a native component alongside the web app.

1. Do you need to talk to hardware over Bluetooth, NFC, USB, or serial? Medical devices, access control, payment terminals, industrial sensors. Yes means native on iOS.
2. Do you need code to run while the app is closed? Background location, geofenced alerts, scheduled sync, silent push. Yes means native.
3. Do you need guaranteed offline durability? Field work with no connectivity for days, where evicted data means lost data. Yes means native, or a sync server that treats the client as disposable.
4. Do you need App Store or Play Store presence as a commercial requirement? Procurement checklists, MDM deployment, enterprise app catalogues. Yes means native on iOS, TWA-wrappable on Android.
5. Do you need sustained GPU or heavy on-device compute? Live video processing, AR, local model inference beyond small quantised models. Yes means native.
6. Do you need deep OS integration? Share sheet targets, widgets, Siri or Assistant intents, HealthKit, CarPlay. Yes means native.
7. Is reliable push to iOS users a core retention mechanism? Push after a manual home-screen install, with no silent delivery, is a materially worse funnel. Probably native.

Zero yeses and you are almost certainly looking at a web app, and the native project is a reflex rather than a requirement.

Side by Side

The Third Option Everyone Forgets

The framing is a false binary. The pattern that holds up in production is a shared web core with native shells where they earn their place.

Build the product as a PWA. Ship it to desktop and Android immediately, and wrap it in a Trusted Web Activity if you need Play Store presence. Then, if and only if a capability gate demands it, build a thin native iOS client that hosts the same web views and implements the three or four native capabilities you actually need — push registration, secure storage, one hardware integration.

This is not elegant. It is cheap, and it fails in predictable places. You get one business-logic codebase, store presence where it matters, and a native surface small enough for one engineer to maintain. The alternative — two full native clients plus a web app, built before anyone validated demand — is how a mobile roadmap quietly consumes a year.

At Kuaray we tend to argue for the PWA first and the native shell second, because the decision is reversible in that order and not in the other. It is the same logic behind how we scope an MVP: defer the expensive, irreversible commitment until a real user has forced it. The structure of the decision mirrors a build vs buy framework — identify which constraints are genuinely binding, and refuse to pay for the ones that aren't.

The Uncomfortable Summary

Most progressive web app vs native mobile app arguments are settled by a checklist, not a debate. If nothing on your capability list is blocked, the web app wins on release velocity, maintenance surface, and discoverability — and you can add native later. If something is blocked, no amount of web engineering fixes it, and you should stop evaluating and start building native for the platform that needs it.

The failure mode isn't picking wrong. It's picking before writing the capability list, then discovering in month four that the one feature the product is built around doesn't work on iOS.

Write the list first. It's a morning's work and it decides everything else.

If you want a second opinion on where your product actually sits, we do this as a scoped technical review — capability audit, platform recommendation, and an architecture that doesn't paint you into a corner. Our mobile development and web development work mostly starts here.

Talk to Kuaray about your mobile platform decision.