PWA vs Native App: Pros, Cons and Costs

PWA vs native app is usually framed as a technology question. In budget meetings it is really three questions: how will people find the product, which device features does it need on day one, and how much can you afford to maintain? Get those answers right and the stack choice is often obvious.

A progressive web app (PWA) is a website that installs to the home screen, works offline where you design it to, and can send push notifications. A native app is a binary built for iOS or Android, distributed through the App Store and Google Play. Both are legitimate products. The mistake is choosing one for the wrong reason, usually “PWAs are cheaper” or “real companies have apps”.

This post compares them on capability, distribution, cost and maintenance, including where each one falls short. If you already know a web app is the right fit, our progressive web app development service page explains how we deliver one. If you are still choosing between store-based options, the native vs cross platform guide covers that decision.

The capability gap has narrowed, but it has not closed, and it is widest on iPhone. Three facts shape most decisions.

Install does not need a service worker any more

On Chromium browsers, a site becomes installable with a linked web app manifest (name or short_name, 192px and 512px icons, start_url, display) served over HTTPS. According to MDN’s installability guide, a service worker is not required for installability; you add one for offline support and caching. That makes the install bar low, but an installable site is not automatically a good app. Offline behaviour still has to be designed screen by screen.

Push on iOS works, with a catch

Web Push arrived for Home Screen web apps in iOS and iPadOS 16.4, using the standard Push API, Notifications API and service workers, alongside the Badging API. As WebKit’s release notes explain, the user must first add the app to the Home Screen, and the permission request must follow a user gesture. In practice that means a two-step funnel (install, then opt in) that a native app does not have. Plan your re-engagement strategy around that drop-off.

The EU scare is over, but WebKit still sets the ceiling

Apple planned to remove Home Screen web apps for EU users in iOS 17.4, then reversed on 1 March 2024 and kept the capability, as 9to5Mac reported. They remain built on WebKit. Whatever Safari does not support, your PWA on iPhone does not get, regardless of which browser the user prefers.

What stays native-only or native-first in practice: reliable background processing, Bluetooth Low Energy on iOS, HealthKit, widgets and Live Activities, Apple Watch and Wear OS companions, deep payments integrations such as in-app purchase, and fine control over camera pipelines. If your roadmap leans on any of these, that matters more than any cost table.

A PWA is the stronger choice when discovery happens on the web. If most users arrive from Google, a newsletter link or a QR code in a shop, every install step you add loses people. A PWA lets them use the product immediately and install later, once it has earned a place on the home screen.

It also wins when you ship often. Content platforms, booking tools, B2B dashboards and internal field apps change weekly. With a PWA, a fix goes live on the next load, and you never support five old versions in the wild. That alone removes a category of support tickets.

Search is the third advantage. Each product, listing or article in a PWA can be a crawlable URL, so the app and your SEO work are the same asset. A native app needs a parallel website to rank at all. If you are weighing a convert website to app project, start by asking whether a PWA upgrade of the existing site gives you most of the benefit.

Finally, PWAs suit markets where storage is tight or data is expensive, and users resist installing anything. A lightweight web app that works on a slow connection can beat a polished native app nobody downloads.

Native earns its cost when the product lives close to the operating system. Fitness apps reading health data, smart-home apps talking to devices over Bluetooth, media apps playing in the background, anything with a watch companion or home-screen widget: these are poor PWA candidates, and pretending otherwise leads to an expensive rebuild.

Native also wins when retention depends on notifications. On Android, browser push is workable. On iPhone, the install-then-opt-in funnel means a meaningful share of users will never receive your messages. If your model is a daily habit loop (reminders, streaks, delivery updates), see how we handle push notifications in native and cross-platform builds before deciding.

Store presence matters too. Some buyers judge legitimacy by an App Store listing, enterprise customers may require MDM distribution, and featuring or search inside the stores is a real acquisition channel for consumer apps. A PWA gives you none of that by default.

Native does not have to mean two separate codebases. Flutter or React Native gives you store distribution and most native APIs from one shared codebase. For many teams, the fairer comparison is PWA vs cross-platform, not PWA vs two native apps.

Cost is where the PWA argument is usually oversold. A PWA saves money mainly because you build one client instead of two, not because web work is inherently cheap. A PWA with serious offline support, background sync and a polished install flow is real engineering.

The table below uses an effort-hours model for one example product: a booking app with login, search, a listing detail screen, a booking flow with card payments, notifications, a user profile and a simple admin panel. These are typical estimates, not quotes, and they assume the same backend and the same design depth in each option.

Build cost is a one-off. The bigger difference over three years is what each option costs to keep alive.

Store fees and commission. Publishing natively means the Apple Developer Program at $99 per year and a one-time $25 Google Play Console fee, per SplitMetrics’ summary of store fees. If you sell digital goods or subscriptions inside the app, Apple takes 30% as standard (15% under the Small Business Program for developers with up to $1M in prior-year proceeds), and Google’s fee depends on market and billing method, starting at 10% on the first $1M in the US, UK and EEA (plus 5% with Google Play Billing) and 15% to 30% in markets the change has not reached. A PWA selling the same subscription through its own checkout pays only the payment processor. Physical goods and services are a different case: both stores require non-store payment methods for those, so the commission difference disappears.

Forced platform updates. Native apps carry annual deadlines. Since April 28, 2026, App Store uploads must be built with Xcode 26 or later, and from August 31, 2026, Google Play requires new apps and updates to target Android 16 (API level 36). Each deadline means dependency updates, deprecation fixes and a regression test. A PWA has browser changes to track, but no store gatekeeper refusing your next release.

Release overhead. Native releases need build signing, TestFlight and Play testing tracks, store screenshots and review time. Automation with Fastlane or Codemagic reduces the effort, but it never reaches zero. Our app maintenance cost guide breaks down the annual cycle in detail.

There is a middle path, and it is popular for good reasons. You can ship a PWA first, then wrap it for the stores, or build native for the core mobile audience and keep a PWA for desktop and casual users.

Wrapping a PWA for the stores

On Android, a Trusted Web Activity can put a PWA on Google Play with little extra code. On iOS, a wrapper is riskier. Apple’s App Review Guideline 4.2 on minimum functionality rejects apps that are essentially a repackaged website. A wrapped PWA needs native value on top (real push through APNs, offline content, device integration) or it will struggle in review. Our list of app store rejection reasons covers how this plays out.

Web first, native later

Launching as a PWA to validate demand, then building a native or cross-platform app once retention is proven, is a sound plan if you design for it. Keep business logic in the backend and APIs rather than in the browser, so the future app reuses them. Teams that bury rules in front-end code end up paying for the logic twice.

Treating “installable” as “done”. Passing the install criteria takes an afternoon. Making checkout, forms and saved items work on a flaky train connection takes design decisions per screen. Budget for it.

Ignoring the iOS push funnel. Teams launch a PWA, see healthy Android notification opt-ins, and assume iPhone will match. It will not, because users must add the app to the Home Screen first. Measure the two platforms separately from day one.

Building native for a content product. If the core experience is reading, browsing and booking, and you have no device-feature requirement, two native apps mostly buy you a store badge and a slower release cycle.

Comparing a PWA with two native apps when cross-platform exists. If the real need is store presence, the cost gap between a PWA and one Flutter app is far smaller than the headline comparison suggests. See the full app development cost breakdown for how platform choice moves budgets.