Progressive Web Apps vs Native: An Honest Build Decision

Progressive web apps vs native is the decision underneath a story we tell often: we've talked a fair number of clients out of building a native app. Not because native is bad — because the thing they actually needed was a fast, installable web experience their customers could reach from a link, and a two-platform native build would have cost three times as much to do the same job worse. We've also watched a team ship a PWA for a product that genuinely needed Bluetooth and background location, then spend six months fighting iOS to do what a native app does on day one. The technology isn't the decision. The use case is — and mapping that correctly is the core of any custom software developer engagement worth paying for.

Progressive web apps versus native apps is one of the most consequential and most oversimplified choices in mobile. So here's the version we give clients: what each actually is, where each genuinely wins, and the framework we use to pick.

What is a progressive web app?

A progressive web app is a website built with web technologies that behaves like an installed app — it can be added to a home screen, run offline, send push notifications, and launch without browser chrome. Per MDN, a PWA "provides a user experience like that of a platform-specific app" while running from a single codebase across platforms, the way a website does.

Two pieces make it work. A web app manifest — a small JSON file naming the app and its icons — makes it installable. Service workers — background scripts that sit between the app and the network — handle offline caching, background sync, and push notifications. Underneath, it's still a website running on the browser's engine; the manifest and service worker are what let it graduate into something users install.

What is a native app?

A native app is built with a platform's own SDK and language — Swift or Objective-C for iOS, Kotlin or Java for Android — compiled for that platform and distributed through its app store. It gets first-class access to device hardware and OS background processes, and it's what people picture when they think "app." The catch is in the plural: native means a separate codebase per platform, so building for iOS and Android is, roughly, two builds to write and two to maintain.

Between the two sits a cross-platform category worth knowing. React Native builds mobile apps from a JavaScript/React codebase, bridging to native UI components; because it doesn't compile to native machine code, it can trail fully native performance on the heaviest workloads. Flutter compiles Dart ahead-of-time to native code and reuses up to ~90% of one codebase across platforms. Both distribute through app stores like native, but from one codebase like a PWA — which is why they're often the pragmatic middle.

Progressive web apps vs native: where each actually wins

The honest comparison isn't "which is better" — it's which trade-offs you're buying.

Dimension	PWA	Native (per-platform)	Cross-platform (Flutter/RN)
Codebases	One	Two (iOS + Android)	One
Distribution	URL / SEO — no store	App Store + Google Play	App Store + Google Play
Install friction	None (visit → install)	Store download	Store download
Hardware/OS access	Limited (esp. iOS)	Full	Near-full
Offline & background	Good on Android, limited on iOS	Full	Full
App-store commission	None	15–30%	15–30%
Update flow	Instant (like a website)	Store review	Store review
Relative build cost	Lowest	Highest	Middle

Reach and discovery favor PWAs. They're found by URL and indexed by search engines — no install step, no store listing, no 200 MB download before someone can try you. Capability and store presence favor native. If your product lives in the App Store's search results or needs deep hardware, the web can't fully replace it.

The iOS asterisk you can't ignore

Most PWA-versus-native debates gloss over the single most important constraint: on iOS, every browser is required to use Apple's WebKit engine, so a PWA's capabilities on iPhone are whatever WebKit supports — and that's a shorter list than on Android.

Concretely, iOS PWAs can't use Web Bluetooth, Web NFC, WebUSB, or several device sensors — Apple declined to implement a batch of those web APIs, citing privacy. There's no true background processing: sync happens only while the app is open, so no scheduled background updates or reliable background uploads. Storage is capped (the Cache API quota is reported around 50 MB), and script-writable storage can be evicted after a week of disuse.

Push did improve. Apple shipped Web Push for home-screen web apps in iOS 16.4 in early 2023 — but only for PWAs the user has installed to the home screen, not in a Safari tab, and permission must follow a direct tap. So push on iPhone is possible now, with an install-first asterisk that materially lowers opt-in versus native.

If your product depends on any of that — peripherals, NFC payments, heavy offline, background tasks — iOS is where a PWA hits a wall, and native (or cross-platform) is the honest answer.

Distribution and cost: the parts finance cares about

Two practical realities often settle the decision.

App stores take a cut and gate your updates. Apple's commission is 30%, dropping to 15% for Small Business Program members under $1M in annual proceeds — a real line item if you sell digital goods. Store review also stands between you and every update. A PWA has neither: no commission, and updates deploy instantly like any website, so users get the latest version on next load.

Can a PWA even be in the stores? On Google Play, yes — wrap it in a Trusted Web Activity with a tool like Microsoft's PWABuilder. On the Apple App Store, not as a raw PWA — you'd wrap it in a native shell (Capacitor/Cordova) to submit. So "PWA plus app-store presence" is achievable, but it's extra work on iOS.

On build cost, one codebase beats two. Native mobile builds commonly range from tens of thousands of dollars for something simple to several hundred thousand for a complex two-platform app (these are vendor ranges, not a fixed figure — treat them as directional). Cross-platform frameworks are widely reported to cut that by roughly 30–40% through code reuse, and a PWA — one web codebase serving mobile and desktop — is typically the leanest of all to build and maintain.

Does the web version actually perform? The case studies say yes

The fear with PWAs is that "just a website" means a worse experience. The evidence cuts the other way when they're built well. Twitter's PWA, Twitter Lite, drove a 65% increase in pages per session, 75% more Tweets sent, and a 20% lower bounce rate — while shipping in about 600 KB over the wire against a 23.5 MB native Android download. Pinterest rebuilt its mobile web as a PWA and saw time spent rise 40%, user-generated ad revenue climb 44%, and core engagements grow 60%.

Those gains trace back to one thing: speed and zero install friction. Google's research found that 53% of mobile visits are abandoned if a page takes longer than three seconds to load, and the probability of a bounce climbs 32% as load time goes from one to three seconds. A lightweight PWA that loads instantly and needs no download removes the two biggest reasons people never make it into your app at all.

The best app is the one your customer actually gets into. Sometimes that's a store download; often it's a link that opens in two seconds.

When to choose which

Here's the framework we actually use.

Lean PWA when the product is content, media, marketing, or most commerce — where discoverability by URL and zero install friction matter more than deep hardware access; when you need fast, affordable time-to-market on one codebase with instant updates; when avoiding the store commission and reaching web-plus-mobile from a single URL is valuable; and when offline needs are light-to-moderate.

Lean native (or cross-platform) when the app is hardware-heavy (Bluetooth peripherals, NFC/payments, advanced camera/AR, precise background location); when it's performance- or graphics-intensive like gaming; when offline and background work are mission-critical; or when app-store presence and reliable, high-opt-in push are core to the business model. And reach for cross-platform (Flutter or React Native) when you need app-store distribution and near-native capability but want one codebase and 30–40% lower cost than dual-native — a sensible default for a lot of teams.

Want a straight answer for your specific product instead of a general one? Book a free consultation and we'll pressure-test the decision against your use case, budget, and roadmap.

FAQ

Do PWAs work on iOS and iPhone? Yes, with limits. iOS PWAs run on Apple's WebKit engine, can be installed to the home screen, and work offline. But they can't access Bluetooth, NFC, or USB, have no true background processing, and cap storage around 50 MB — so hardware- or background-heavy products still need native on iPhone.

Do PWAs support push notifications on iPhone? Yes, since iOS 16.4 (early 2023) — but only for PWAs the user has installed to the home screen, not in a Safari tab, and the permission prompt must follow a direct tap. Opt-in tends to be lower than native push because of the install-first step.

Can a PWA be published in the Apple App Store and Google Play? On Google Play, yes — wrap it in a Trusted Web Activity using a tool like PWABuilder. On the Apple App Store, not as a raw PWA; you'd wrap it in a native shell (Capacitor or Cordova) to submit it for review.

Is a PWA cheaper than a native app? Usually. A PWA is one web codebase serving mobile and desktop, versus two separate native codebases to build and maintain, and it avoids the 15–30% app-store commission. Cross-platform frameworks land in between, cutting dual-native cost by roughly 30–40%.

Are PWAs still relevant in 2026? Yes. iOS added home-screen push in 2023, PWABuilder makes Play Store distribution straightforward, and case studies from Twitter and Pinterest still hold. For content and commerce, a PWA is often the highest-ROI choice; for hardware-heavy apps, native remains the answer.

What can a native app do that a PWA can't? Full hardware access (Bluetooth, NFC, USB, advanced sensors — especially on iOS), reliable background processing and sync, maximum performance for gaming or graphics, guaranteed app-store discoverability, and higher-opt-in push notifications.

The bottom line

Progressive web apps and native apps solve different problems. PWAs win on reach, speed, cost, and instant updates; native wins on hardware access, background work, performance, and store presence; cross-platform splits the difference. The expensive mistake is picking by fashion instead of fit — building native for a content app, or a PWA for a product that needs the phone's hardware. Start from your use case, budget, and where your users actually are, and the right architecture usually names itself. If you'd rather not guess, our team's custom web application development and mobile experience — and a look at the full range of CodeStringers capabilities across the software development technologies we work in — can turn the decision into a plan. Our write-up on React Native and cost efficiency in cross-platform development is a useful next read if the middle path interests you.

Ready to build the right thing once? Book a free consultation with our team.

By the CodeStringers Team — Zoho Experts & Custom Software. CodeStringers is a custom software engineering firm that ships web, mobile, and integration software for clients across industries.