Contents
Choosing between a Progressive Web App and a native mobile app commits a budget, a timeline and an acquisition strategy for several years. The decision is rarely technical: it is first and foremost an economic one.
A PWA is built on web standards (service worker, web app manifest, HTTPS) while still offering installation on the home screen, offline mode and notifications. A native app, developed separately for iOS and Android, keeps the edge for deep hardware access and certain graphics performance.
Cost of ownership: what each option really costs
The first gap comes down to the number of codebases. A native app covering iOS and Android requires two separate developments (Swift and Kotlin, for example), two testing cycles and two publishing processes. A PWA relies on a single codebase, served to every modern browser. This structural difference explains most of the budget gap.
The cost does not stop at delivery. You also need to account for:
- Developer accounts: $99 a year for the Apple Developer Program, a one-off $25 for the Google Play Console.
- App store commissions: 15 to 30% on in-app purchases, depending on revenue.
- Review cycles: every native update goes through store review, whereas a PWA updates instantly, like a website.
- Double maintenance: fixes, new iOS and Android versions and regressions all have to be handled twice.
Over three years, it is these recurring costs, more than the initial development, that widen the gap.
Acquisition: the real differentiator
The right question is not “which technology is the most powerful?” but “how many users actually make it to my app?”. Each store holds millions of apps: every step between intent and use costs you users.
A PWA opens from a simple web address. It is indexable by Google, shareable by link, usable immediately, then installable in one tap. A native app forces a detour through the store, an often heavy download and sometimes account creation before first use. As early as 2016, Google measured that 53% of mobile visits are abandoned when a page takes more than three seconds to load: the same logic applies to every installation step.
Public case studies document the effect of this reduced friction. After launching its PWA, Twitter Lite saw 65% more pages per session, 75% more tweets sent and a 20% drop in bounce rate. Trivago saw the number of users adding its app to the home screen grow by 150%, and clicks through to hotel offers by 97%. These figures do not prove that a PWA always wins, but they show that removing steps has a direct, measurable effect.
Features: where the PWA catches up, where native stays ahead
The gap has narrowed considerably. Since iOS 16.4, notifications are available on iPhone for PWAs added to the home screen, which removed the most common objection. Offline mode, geolocation, the camera, payments and local storage are supported by modern browsers.
Native remains the better choice in specific cases:
- intensive graphics processing (3D games, augmented reality);
- constant use of high-frequency sensors;
- deep system integration (advanced widgets, extensions);
- Bluetooth Low Energy on iPhone, which Safari does not support;
- a store presence required by your market.
If your product depends on one of these points, native is not a luxury: it is a constraint.
| Criterion | PWA | Native app |
|---|---|---|
| Codebases to maintain | 1 | 2 (iOS and Android) |
| Distribution fees | None | $99/year (Apple), $25 (Google), 15 to 30% commissions |
| Shipping a fix | Immediate | Subject to store review |
| Visibility | Indexable by search engines | Depends on app store ranking |
| Advanced hardware access (augmented reality, Bluetooth on iPhone) | Partial | Full |
| Installation | From the browser, in one tap | Download via the store |
How to decide for your project
Three questions are usually enough.
- Do you need a hardware feature that is unavailable on the web (augmented reality, Bluetooth on iPhone, heavy graphics)? If so, native is the way to go.
- Do your users arrive via Google, a shared link or campaigns? If so, a PWA converts better, because it removes the store step.
- What annual maintenance budget can you sustain? If it cannot fund two codebases, native creates technical debt that you pay for in late fixes.
My advice: start with a PWA to validate usage, measure, and only invest in native where a documented hardware constraint justifies it. A PWA can also be published to the stores later if your market requires it.
Sources: web.dev (Google), "What are Progressive Web Apps?" and the Twitter Lite and Trivago case studies; Google, "The need for mobile speed" (2016); WebKit Blog, "Web Push for Web Apps on iOS and iPadOS"; MDN Web Docs, "Progressive Web Apps"; official pricing of the Apple Developer Program and the Google Play Console.