Progressive web apps vs. native apps: how to make the right call for your product

Every time we talk with a client about mobile app development, the question comes up: "Should we build a native app, or is a progressive web app good enough?" Most agencies respond with a technical breakdown of rendering engines and API support. That's rarely what you actually need.

At Livewall, we reframe the question: what do you want users to do, how often will they do it, and what is your budget over the next two years? Those three questions determine the right call more reliably than any technical specification.

In this article we'll cover what PWAs can and can't do today, when native genuinely wins, and when you're wasting money going native when a PWA would serve you just as well.

What a PWA can and can't do today

A progressive web app is a website that behaves like an app. Users can add it to their home screen, it works offline via service workers, and it can send push notifications. On Android, this all works well. On iOS, the story is more nuanced.

Apple deliberately limited PWA support for years. Web push notifications only arrived in iOS 16.4, and only when the user has added the PWA to their home screen. Background tasks, Bluetooth access, and NFC are still off-limits for PWAs on iOS. Camera access works, but with constraints compared to native.

None of this makes PWAs weak. For most digital products, from portals and community platforms to internal tools and lighter consumer apps, a well-built PWA delivers everything required. The gaps matter when you need hardware integration or when your audience is predominantly iOS users who depend on push notifications as a core retention mechanic.

When native genuinely wins

There are situations where native is the right call, full stop.

Hardware access is the clearest case. If your app needs Bluetooth connections, deep camera controls, NFC, or wearable device communication, you need native. A PWA simply cannot reach those APIs.

App store distribution matters in certain categories. If your audience discovers apps through the App Store or Google Play, and if your category depends on rankings and reviews, a store listing gives you a visibility advantage that a PWA cannot match.

Performance-intensive features like real-time video editing, augmented reality, or complex animations run noticeably smoother on native. The gap is closing, but it exists.

A clear example from our own work is Dumpert. Dumpert serves over 150 million video views per month. A platform at that scale, with that intensity of media streaming, community interactions, and the requirement for a fast, fluid video playback experience, needed a native solution. The choice was not a preference but a product requirement.

When a PWA is the smarter choice

A PWA wins on several points that most clients underestimate.

Budget and speed. One codebase for all platforms. No duplicate development for iOS and Android, no two separate app store review processes, no two independent technical debts to maintain. In our experience, this saves 30 to 40 percent on initial build costs for an average product.

Faster iteration. With a PWA, you deploy directly to users. No waiting for app store review. If you're in an early stage and want to test with real users quickly, this is a significant advantage. It fits directly with our rapid prototyping approach: start small, validate fast, build on what works.

Cross-platform reach without friction. Users don't need to install anything. They open a link and they're immediately in your product. For campaign-related digital products, short-lived activations, or B2B tools where installation is a barrier, this is a meaningful advantage.

No app store dependency. Apple and Google don't decide when your update goes live or whether your app complies with their current guidelines. That gives you freedom, especially if your product changes frequently.

The AvroTros example: when native is the right call

For the AvroTros Eurovision voting app, native was the right choice, but for reasons beyond technical limitations. The app needed to handle real-time voting for 141,000 users during one of the most-watched television events of the year. App store presence was essential: people were actively searching for the app in the store, rankings were influenced by media coverage, and the credibility of an official app store listing matched the scale of the event. The app reached the number one position in the Dutch App Store.

That is a fundamentally different scenario from a B2B platform or a membership environment. Context determines the choice, not the technology itself.

The middle ground: React Native and cross-platform

Between a pure PWA and fully native sits a third path: frameworks like React Native or Flutter. You write largely one codebase, but the result is a real native app that can be listed in the app stores and has access to hardware APIs.

This is not a magic solution. React Native performance sits close to native for most products, but falls behind on complex animations or heavy media. The tooling is mature, but you need developers who genuinely know the framework. And you still have two app store accounts, two review processes, and platform-specific quirks to manage.

For an MVP that you want to validate on both iOS and Android without the budget of two native teams, cross-platform is often the right interim choice. If the product grows and performance or hardware integration becomes a real constraint, you can migrate to native at that point.

The choice is never final. Technology moves. PWA support on iOS keeps improving. The right question is: what does this product need now, and what will it need in two years?