A friend of mine just spent 0,000 building separate iOS and Android apps for his restaurant chain. I told him a progressive web app would’ve done the same job for maybe ,000. He looked at me like I’d suggested serving food on napkins. Six months later, he admitted I was probably right — the native apps had identical features to what a PWA could handle, and the ongoing maintenance was eating his budget alive. This argument has been going back and forth for years now, and the data is getting harder to ignore.
I built my first PWA for a client’s e-commerce platform roughly two years ago. Skeptical the whole time. My background was native iOS, and I carried all the assumptions that come with that: web apps are slow, they can’t work offline, users won’t trust something that doesn’t come from the App Store. Every one of those assumptions got challenged by the time we shipped. The PWA loaded in about two seconds on a mid-tier Android phone over a spotty connection, it cached the product catalog for offline browsing, and conversion rates jumped 30% compared to the old mobile site. Not magic — just good engineering applied to a platform that had quietly gotten a lot more capable than I’d given it credit for.
So what actually makes something a PWA? At its simplest, you’re looking at three pieces: a service worker that handles caching, offline functionality, and background tasks; a web app manifest that tells the browser how to display the app when installed; and HTTPS. That’s the foundation. On top of those, modern browsers expose APIs for push notifications, background sync, camera and microphone access, geolocation, Bluetooth, NFC, USB devices, and a growing list of hardware capabilities that used to be native-only territory. The “progressive” part means the app gracefully degrades — someone on an ancient browser still gets a working website, while someone on the latest Chrome gets the full app-like experience with offline support and home screen installation. Native apps can’t offer that kind of fallback. You either download the APK or you don’t use the app at all.
Performance is where the conversation usually starts, and where it gets interesting. The old wisdom said native code runs on the metal, web code runs through layers of abstraction, therefore native wins. True in 2015. Misleading in 2026. V8, the JavaScript engine inside Chrome, has gotten absurdly fast. JavaScriptCore in Safari isn’t far behind. WebAssembly opened the door for computationally heavy workloads to run at near-native speeds inside the browser. And rendering engines have been optimized for smooth 60fps scrolling and animation to the point where, for content-heavy apps, e-commerce platforms, social feeds, and productivity tools, users genuinely can’t tell the difference between a well-built PWA and a native app. I’ve watched people use both side by side without realizing one was web-based. It might sound like an exaggeration, but it’s not.
Twitter Lite is probably the most famous example, and it deserves the attention. When Twitter shipped their PWA, pages per session jumped 65%. Tweets sent increased 75%. Bounce rate dropped 20%. The app loaded in under three seconds even on slow 3G, consumed less than 1MB of storage versus the 100MB+ native app, and used up to 70% less data. Those numbers aren’t incremental improvements — they represent a different class of reach. People who couldn’t or wouldn’t download a heavy native app suddenly had access to the full Twitter experience through something that weighed almost nothing. Starbucks tells a similar story. Their PWA comes in at 99.84% smaller than their iOS app. Customers can browse the menu, customize orders, and fill their cart while completely offline. After launching it, web orders from desktop users doubled. For a company serving hundreds of millions of people worldwide, many of them in places where bandwidth is expensive and phones have limited storage, that size difference translates directly into money.
Distribution might be where PWAs hold their most underrated advantage. Think about what happens when you want someone to use your native app. They have to open an app store, search for you (and hope they spell it right), tap install, wait for a download that could be 50 to 200 megabytes, then finally open it. Research consistently shows that each step in a conversion funnel drops around 20% of users. By the time someone actually launches your freshly installed native app, you’ve already lost a significant chunk of people who just… gave up. With a PWA, someone taps a link and they’re using your app. Immediately. If they like it, they can add it to their home screen with a single tap. No store, no download wait, no “update available” nag screens. Updates happen silently on the server side. Service workers handle caching so returning visits load instantly. The friction difference is enormous, and friction is where businesses lose customers.
Then there’s the money side of distribution. Apple takes 15 to 30% of every in-app purchase and subscription through the App Store. Google’s cut on the Play Store is similar. If digital transactions are a big part of your business model, that commission represents a staggering amount of revenue you’re handing over for the privilege of being in someone else’s store. PWAs live on the open web. You own your distribution. No commission. The EU’s Digital Markets Act and similar regulations in other places have started pressuring these fees downward, but even with regulatory changes, the math still favors PWAs for a lot of business models. Why surrender a third of your revenue if your app doesn’t actually need native capabilities?
Offline support used to be the clearest dividing line. Native works offline; web doesn’t. Service workers shattered that assumption. A service worker acts as a programmable proxy between your app and the network. It intercepts requests, serves cached responses, queues user actions for later sync, and handles push notifications — even when the app isn’t open. With a solid service worker implementation, a PWA can cache the entire application shell, pre-load important data, and use background sync to hold onto form submissions or messages until connectivity returns. From what I’ve seen, the Starbucks offline menu browsing is a perfect illustration. But I should be fair: native apps still have more flexibility with local storage. IndexedDB, the main storage option for PWAs, has limits that vary by browser and can get cleared by the system when storage pressure builds. Native apps can access the full filesystem and store gigabytes without worrying about eviction. If your app needs to cache massive datasets or media libraries locally, native gives you more control there. Could be wrong about how much this matters for most apps, though — the majority of them don’t need gigabytes of local data.
Hardware access is the area where native held what seemed like an unbeatable lead, and the lead has gotten much thinner. Modern web APIs cover cameras, microphones, geolocation, accelerometers, gyroscopes, Bluetooth via Web Bluetooth, USB via WebUSB, NFC via Web NFC, and filesystem access via the File System Access API. That’s a wide set of capabilities. But some things remain native-only. Deep iOS integration through HealthKit, certain Bluetooth Low Energy profiles, advanced augmented reality through ARKit and ARCore, sustained background location tracking on Android — these still require platform-specific code. If your app depends on those at a basic level, a PWA won’t cut it alone.
Apple’s PWA stance remains a sore spot for web developers. Safari has added service workers and, as of iOS 16.4, push notifications — a feature that took years longer than it should have. But Safari still lags behind Chrome in Web API support, and Apple has clear business incentives to keep the App Store as the primary way people get software onto their iPhones. This is a real problem if your audience skews heavily iOS. On Android, the picture is much brighter. Chrome supports Trusted Web Activities, which let you package a PWA as an Android app and distribute it through the Google Play Store with full web API access. You get store presence and discoverability without sacrificing the web-based development workflow. Samsung’s browser also provides strong PWA support, and Samsung devices make up a massive share of the global Android market.
Cost is often what tips the scales, so let’s get specific. Building native apps for both iOS and Android means two codebases. Two sets of developers, or a cross-platform framework like React Native or Flutter that introduces its own complexity. Two testing pipelines. Two deployment processes. Plus a web team for your website. That’s three platforms to build and maintain. A PWA is one codebase. It runs on desktop, mobile, and tablet across any operating system with a modern browser. Your web team builds it, deploys it to a server, and it’s immediately available to everyone. No app store review process. No waiting for users to pull down updates. No backwards compatibility headaches from users running app versions from 2023 because they never tap “update.” Industry estimates put the cost of building and maintaining native apps for both platforms at two to three times the cost of an equivalent PWA when you factor in development, maintenance, and salaries. For a startup watching every dollar, that multiplier can be the difference between building the product and not building it at all. Even larger companies find it hard to argue against redirecting that budget toward features instead of platform upkeep.
React Native and Flutter have narrowed the native cost gap, sure. Write once, deploy to iOS and Android. But you’ve still got a separate web codebase, plus the overhead those frameworks bring — React Native’s bridge performance issues, Flutter’s smaller Dart ecosystem, the never-ending game of keeping up with platform changes on both mobile operating systems. They’re good tools. They’re not free lunches.
Engagement metrics get brought up a lot in favor of native. Users who install native apps tend to spend more time in them and come back more often than mobile web visitors. That’s true, but it’s a biased sample. Someone who went through the effort of downloading and installing your app was already more committed than the average browser visitor. You’re measuring motivation, not platform quality. PWAs have shown they can drive strong engagement when they’re built well. Push notifications, home screen presence, fast loading — these create the same sticky patterns native apps rely on. And the lower barrier to entry means you’re capturing people who never would have bothered installing your native app. Pinterest’s PWA saw a 60% jump in core engagements. Trivago reported 150% more engagement from users who added the PWA to their home screen. Alibaba saw 76% more conversions across browsers after shipping their PWA. These are production numbers from some of the biggest consumer apps on the planet, not projections from a slide deck.
None of this means native development is dead. Some categories still need it. If your app relies on heavy platform-specific hardware features — advanced camera processing, deep AR integration, health and fitness sensor access — you need native. If you’re building something that runs in the background for long stretches with the screen off, like a navigation app or a music player or a workout tracker, native gives you more reliable background execution. Graphically intense games still benefit from the direct pipeline native provides, even though WebGL and WebGPU have made impressive progress. Casual and puzzle games work fine as PWAs, but don’t try to ship a AAA 3D title through a browser. And apps that need OS-level integration — home screen widgets, share sheet extensions, Siri or Google Assistant hooks, inter-app communication — require native code for those touchpoints. Web APIs just don’t have equivalents for most of them yet.
If app store visibility matters to your acquisition strategy and your audience finds apps primarily through store browsing and search, the presence of a native listing on the App Store and Play Store has value. You can list TWAs on the Play Store, but Apple doesn’t offer anything equivalent for PWAs, and organic app store discovery remains a meaningful channel for certain categories of apps.
For content-driven apps, though — news, e-commerce, social, reference, productivity — a PWA should probably be the default unless you have a specific, concrete reason to go native. Development speed, cost, universal reach, and update simplicity all point in the same direction. This goes double if your target audience includes emerging markets. In regions where data is expensive, phone storage is tight, and connectivity is unreliable, a PWA that loads in under three seconds on 3G and takes up 1MB of storage will reach users that a 100MB native app never will. If growth in India, Southeast Asia, sub-Saharan Africa, or Latin America matters to your roadmap, PWAs give you a structural edge that native apps can’t match.
Companies with existing web applications have an even easier path. If you’ve already built a responsive web app, adding PWA capabilities is incremental work. Drop in a service worker for offline support. Add a manifest for installability. Wire up push notifications. You’re enhancing what you already have, not building from scratch. The return on that incremental investment tends to be outsized.
Something that doesn’t get talked about enough: you don’t have to pick one. Lots of successful companies run a hybrid model where the PWA serves the broad audience and native apps cater to power users who need advanced features. Twitter does exactly this — their PWA targets markets where data costs are high and devices are less powerful, while native apps provide the complete feature set for users on flagship phones with fast connections. The PWA captures the wide top of the funnel; native apps serve the deeply engaged core. They coexist fine. You could also use a PWA as your MVP to validate the market and build traction, then invest in native once you’ve got product-market fit and revenue to justify the extra development cost. Seems like a particularly smart approach for startups that need speed and can’t afford three platforms on day one.
When you’re benchmarking a PWA, focus on the metrics that actually move your business. Time to Interactive should be under five seconds on a mid-range device with a 3G connection. First Contentful Paint should hit under two seconds. Lighthouse PWA scores in the 90+ range are achievable with modern tooling and proper optimization — code splitting, lazy loading, image compression, smart caching. If your PWA hits those marks, most users won’t perceive any difference from a native app. Native app performance is typically measured by cold start time, frame rates, and memory consumption. A well-optimized native app on current hardware will load marginally faster and maintain slightly smoother animations. But that difference is often a few hundred milliseconds — visible in controlled benchmarks, not noticeable when someone’s just trying to order coffee or read an article.
The trajectory is what makes this conversation fascinating. Web capabilities keep expanding. Browser engines keep getting faster. Project Fugu — a collaboration between Google, Microsoft, Intel, and others — is systematically bringing native-class capabilities to the web platform, one API at a time. WebGPU is delivering native-quality graphics in the browser. WebTransport enables low-latency bidirectional communication. The File System Access API provides local read/write access. Web Bluetooth, WebUSB, and Web NFC connect to hardware. Web Authentication handles biometrics. Each new API chips away at the argument that native apps can do things web apps can’t.
At the same time, native platforms are becoming more web-friendly. Android’s Trusted Web Activities blur the boundary. Apple’s (belated) addition of push notifications for PWAs on iOS was a significant concession, even if it was years overdue. Both major mobile platforms are trending toward greater parity between web and native capabilities, not less.
The question isn’t whether PWAs will eventually match native apps feature for feature. The question is whether the remaining gaps matter for your specific application. For most apps, the answer is already no.
My own thinking on this has shifted completely. I started as a native-first developer who thought PWAs were a gimmick. Building them, measuring results, and watching the platform evolve changed my mind. For the majority of applications — maybe 70 to 80%, if I had to guess — a PWA is the right default choice. Not because native is bad. Native development is excellent at what it does. But for most teams, the economics, the reach, the development velocity, and the user experience all tilt toward the web. And the web keeps getting more capable every year, while the arguments for going native-only keep getting narrower.
Where this all ends up, though — I honestly don’t know. Will Apple eventually open up iOS to full PWA parity, or will they keep dragging their feet to protect App Store revenue? Will WebGPU mature fast enough to make browser-based gaming competitive with native? Will some new device category, maybe AR glasses or ambient computing, reset the whole native-versus-web debate entirely? These days, the line between the two keeps getting blurrier, and I’m not sure anyone can predict with confidence where it stabilizes. Maybe it doesn’t stabilize. Maybe the distinction itself just… fades away, and five years from now we’ll look back and wonder why we ever argued about it so intensely. Or maybe native finds a new reason to matter that nobody’s anticipated yet. I genuinely don’t know which way it goes from here, and I think that uncertainty is what makes this such a compelling space to work in right now.
(0) Comments