Progressive web app guide: PWA vs native vs hybrid (2026)

If your app is mostly screens, forms, and data – build a progressive web app. It costs $20,000–$80,000 instead of $60,000–$200,000+ for native. You maintain one codebase instead of two. You skip App Store review cycles. You deploy updates instantly. For 80% of business applications, a PWA is the correct answer.

The other 20%? If you need Bluetooth, NFC, ARKit, or your business model depends on being in the Apple App Store – you need native. That’s not a drawback of PWAs. That’s a different product category.

Every PWA article online is either a developer tutorial or a cheerleading piece. None of them tell you when a PWA is the wrong choice, what iOS actually supports in 2026, or how much each option costs by project type. This one does.

What a progressive web app actually is

Three sentences, not a tutorial. A PWA is a website with three extras: a service worker (handles offline caching and background sync), a web app manifest (tells the OS to treat it like an app – icon, splash screen, standalone window), and HTTPS (required for service workers to run). When a user “installs” a PWA, the browser creates a home screen shortcut that opens the site without browser chrome. The user gets an app. You get a website you can deploy with git push.

That’s it. No SDK. No app store submission. No waiting 3–14 days for Apple’s review team.

The cost table

We’ve built PWAs, native apps, and hybrid apps. Here’s what each actually costs, based on our project data and industry benchmarks:

	Progressive Web App	Native (iOS + Android)	Hybrid (React Native / Flutter)
MVP development	$20,000–$80,000	$60,000–$200,000+	$40,000–$120,000
Ongoing maintenance	$3,000–$8,000/yr	$15,000–$50,000/yr	$8,000–$25,000/yr
Time to first release	6–12 weeks	12–24 weeks	10–18 weeks
Codebases to maintain	1	2 (iOS + Android)	1 (with platform-specific patches)
App Store dependency	No	Yes	Yes
Update deployment	Instant (server push)	1–14 day review cycle	1–14 day review cycle

The native column isn’t more expensive because it’s better. It’s more expensive because you’re building the same app twice – once in Swift for iOS, once in Kotlin for Android – then maintaining both forever. Every feature ships twice. Every bug gets fixed twice. Every design change gets implemented twice.

PWAs are 30–75% cheaper than native, depending on complexity. For a detailed breakdown of what drives these numbers, see our software development cost guide.

The companies that proved it

These aren’t hypothetical. These are publicly documented results from companies that switched to PWAs.

Twitter Lite. Twitter rebuilt their mobile web experience as a PWA in 2017. The result: 65% more pages per session, 75% more tweets sent, and 20% lower bounce rate [1]. The entire app loads in under 5 seconds on a 3G connection. For a platform serving users across Africa, South Asia, and South America – where data plans cost real money – this wasn’t a tech decision. It was a market access decision.

Starbucks. Their PWA is 99.84% smaller than the iOS app [2]. Not a typo – the iOS app was over 200MB; the PWA is 233KB. Daily active users doubled after launch. For a company whose customers open the app to order coffee in line, load time matters more than platform-exclusive features.

99.84%

[2] Starbucks case study

Pinterest. After rebuilding their mobile experience as a PWA: 40% more time spent, 44% more ad revenue from users, and 60% higher engagement across the board [3]. Pinterest’s previous mobile web was essentially a bounce page that tried to funnel users into the native app. When they made the web experience actually good, people stayed.

Flipkart. India’s largest e-commerce platform saw a 70% conversion increase after launching their PWA, Flipkart Lite [4]. Again – a market where most users are on low-end Android phones with limited storage. A 200MB native app competes with photos of their kids for storage space. A PWA doesn’t.

Nikkei. Japan’s largest business newspaper built a PWA and saw 2.3x organic traffic and 58% more subscriptions [5]. The speed improvement alone – page loads dropped from 12 seconds to 2 – explains most of that lift. People don’t subscribe to products that make them wait.

The iOS reality in 2026

Every PWA guide either ignores iOS or pretends the problems are solved. Neither is honest. Here’s the actual situation.

Push notifications work. Since iOS 16.4 (March 2023), PWAs can send push notifications on iPhone and iPad [6]. This was the single biggest blocker for years and it’s gone. But there’s a catch: the user must add the PWA to their home screen first. You can’t prompt for notification permission from Safari – only from the installed PWA. That means your onboarding flow needs to guide users through the “Add to Home Screen” step before you can engage them with push.

Apple App Store still rejects PWAs. You cannot wrap a PWA in a WebView and submit it to the App Store. Apple’s guideline 4.2 explicitly rejects apps that are “simply a web site bundled as an Application” [7]. Google Play, by contrast, accepts PWAs via Trusted Web Activity (TWA) – a full-screen Chrome tab that looks and behaves like a native app, with access to Play Store distribution, ratings, and payments.

The EU situation. In early 2024, Apple announced plans to disable PWAs entirely in the EU under the Digital Markets Act. The backlash was immediate and fierce – from developers, regulators, and the European Commission. Apple reversed course within weeks [8]. PWAs remain fully functional on iOS in the EU and everywhere else. But the episode revealed something important: Apple views PWAs as a competitive threat to the App Store. Plan accordingly.

What’s still missing on iOS: background sync (periodic updates without the app being open), Bluetooth Web API, NFC, and reliable badge counts. These work on Android. They don’t work on iOS. If your app depends on any of them, you need native – at least for iPhone.

Five questions that tell you what to build

Stop reading architecture blogs. Answer these five questions and the decision makes itself.

1. Does your app need hardware access – Bluetooth, NFC, ARKit, camera beyond basic photo capture? Yes → native. PWAs can’t access Bluetooth or NFC on iOS and have limited support on Android. No shortcut here.

2. Is App Store presence a business requirement – not a preference, a requirement? Yes → native or hybrid. If your enterprise sales team needs “download from the App Store” in their pitch deck, a PWA won’t work politically – even if it works technically. Google Play accepts PWAs via TWA; Apple does not.

3. Are you targeting users on low-end devices or slow connections? Yes → PWA, strongly. A 233KB PWA beats a 200MB native app every time on a phone with 16GB of storage and a 3G connection.

4. Is your budget under $60,000? Yes → PWA. You can’t build a quality native app for both platforms under $60K. You can build a solid PWA for $20K–$50K. If you need a mobile-first experience on a startup budget, PWA is the path.

5. Do you need to ship fast – under 10 weeks to v1? Yes → PWA. One codebase, no app store review, deploy on your schedule. We cover the broader approach in our MVP development guide.

“Yes” to question 1 or 2 → go native or hybrid. “Yes” to questions 3, 4, and 5 → go PWA. Mixed signals? Hybrid frameworks like React Native or Flutter split the difference – one codebase, native-like performance, App Store presence.

When a PWA is the wrong choice

PWAs are our default recommendation. But defaults have exceptions.

Games. Anything beyond casual 2D games needs GPU access, low-level audio APIs, and frame-rate control that the browser can’t match. Unity, Unreal, and even lighter engines like Godot output native builds for a reason. WebGL exists but the performance gap is real and noticeable.

Hardware-intensive apps. Fitness trackers that sync with Bluetooth heart monitors. Payment terminals that read NFC. AR apps that use LiDAR. The browser doesn’t have access to these APIs on iOS, and Android support is inconsistent. If hardware integration is core to your product, native is the only honest choice.

Apps that must be in the Apple App Store. Not “it would be nice” – must. Enterprise apps where the IT department requires MDM distribution. Consumer apps where your CAC model depends on App Store search. B2B apps where the client’s procurement process requires an App Store listing. If the App Store is a hard requirement, build native or hybrid.

Offline-heavy apps with complex sync. PWAs can work offline – service workers cache assets and data, and background sync pushes changes when connectivity returns. But if your app requires conflict resolution across multiple offline users editing the same data (think field service teams in remote areas), the sync logic in a PWA becomes fragile. Native apps with SQLite and custom sync engines handle this better.

The architecture decision behind the PWA

A progressive web app still needs sound architecture. The service worker is a separate JavaScript thread with its own lifecycle – cache invalidation, update strategies (cache-first vs network-first vs stale-while-revalidate), and offline fallback pages all need to be designed, not bolted on.

The good news: modern frameworks handle most of this. Workbox (by Google) generates service worker code from your build config. Astro, Next.js, and SvelteKit all have PWA plugins that wire up caching, manifest generation, and offline support with minimal configuration.

What still needs human judgment: what to cache and when. Cache your app shell and static assets aggressively. Cache API responses selectively – user-specific data with short TTLs, reference data with long ones. Never cache authentication tokens in the service worker cache (use IndexedDB with appropriate security). These aren’t framework decisions. They’re architecture decisions that affect performance, security, and data freshness.

---

We build both PWAs and native apps. The difference between us and most agencies: we’ll tell you which one you actually need before we quote you. Most founders we talk to need a PWA and don’t know it yet – they’ve been quoted $120K for native apps that would work better as a $40K PWA. Tell us what you’re building and we’ll tell you which path saves you money without cutting corners.

References

[1] Google Developers, “Twitter Lite PWA – 65% increase in pages per session, 75% increase in Tweets sent, 20% decrease in bounce rate,” developers.google.com, 2017.

[2] Formidable Labs, “Starbucks Progressive Web App Case Study,” 2018. formidable.com; Google Developers, Starbucks PWA metrics.

[3] Pinterest Engineering, “A Pinterest Progressive Web App Performance Case Study – 40% more time spent, 44% more ad revenue,” medium.com/pinterest-engineering, 2017.

[4] Google Developers, “Flipkart Lite – 70% conversion increase with Progressive Web App,” developers.google.com, 2016.

[5] Google Developers, “Nikkei achieves a new level of quality and performance with their Progressive Web App – 2.3x organic traffic, 58% more subscriptions,” developers.google.com, 2018.

[6] Apple, “Web Push for Web Apps on iOS and iPadOS,” webkit.org, 2023. Available from iOS 16.4+.

[7] Apple, “App Store Review Guidelines – 4.2 Minimum Functionality,” developer.apple.com, 2025.

[8] European Commission, Digital Markets Act enforcement; Apple reversal on PWA removal in the EU, February 2024. Multiple sources including The Verge, Ars Technica.