Native app, hybrid app or PWA: which should you choose?

"Can't we just build a PWA? It's cheaper." The question comes up in almost every one of our scoping workshops. It is a fair one. A Progressive Web App means one codebase, no store commission, no waiting for approval, and an update that everyone sees within minutes.

But a PWA is not a cut-price app. It is a different product, with its own strengths and precise limits, especially on iPhone. Choosing between native, hybrid and PWA starts with knowing what your product has to do, then checking which family makes it possible.

Three families, not two

The word "hybrid" causes confusion. It covers two very different approaches, which need to be separated from the outset.

The first three rows are apps in the strict sense: a binary published on the stores and installed by the user. The difference between them is mainly a matter of budget and performance, and we have covered it in detail in React Native, Flutter or native: how to decide. Keep one benchmark in mind: on an iOS + Android project, cross-platform saves 30 to 40% compared with two native apps.

The fourth row is different in kind. A PWA is not installed from a store: it is your website, behaving like an app once added to the Home Screen. Its capabilities do not depend on you but on the browser. On iPhone, it is WebKit, Safari's engine, that sets the rules.

What a PWA can do in 2026

Things have moved a great deal over the last three years, especially on Apple's side. Many of the opinions still doing the rounds predate those changes.

Installation

On Android, Chrome (on devices with Google Mobile Services) and Samsung Internet turn the PWA into a WebAPK: a real Android package, generated and signed by a trusted provider, which appears in the launcher and in settings like any other app. The site can show its own install prompt. Other Android browsers, such as Firefox, simply create a shortcut that opens the site in the browser.

On iPhone, there is no install prompt: the beforeinstallprompt event is not supported. Users have to open the Share menu and choose "Add to Home Screen". Since iOS 16.4, this works from Safari, but also from Chrome, Edge, Firefox and Orion. And since iOS 26, any site added to the Home Screen opens as a web app by default, even without a manifest. WebKit sums it up: there are now no requirements at all for "installability" in Safari.

The practical consequence: on iPhone, installation is technically simple, but it depends entirely on the user. You have to explain it to them, on screen, at the right moment.

Push notifications

This is what has changed most. Since iOS and iPadOS 16.4, a PWA installed on the Home Screen can receive web push notifications. They appear on the Lock Screen, in Notification Center and on a paired Apple Watch, and they respect Focus modes, just like those of a native app. The Badging API also lets the app show a count on its icon.

Two conditions limit their use. The PWA must be installed, otherwise there is no push on iPhone. And the permission request can only be triggered in response to a direct user action, such as an "Enable alerts" button. So you cannot ask for permission at first launch, as many apps do.

On Android, Chrome and Firefox support web push.

Offline and storage

A service worker can cache the interface and the data, so the app opens without a network connection. For a catalogue, documentation or a simple form, that is enough.

Storage has its own rules. On iPhone, an installed PWA gets the same quota as the site opened in Safari, and WebKit may delete the data of a site the user has not interacted with for some time. An app can request persistent storage with navigator.storage.persist(), and WebKit takes that into account, in particular if the site is opened as a web app from the Home Screen. But approval is not guaranteed.

The real limit lies elsewhere: background synchronisation. The Background Sync API, which automatically sends data entered offline as soon as the network returns, is supported neither by Safari on iOS nor by Firefox. It works on Chrome for Android. For a field team working all day without a signal, that is a deal-breaker; we cover this case in our article on offline apps for field teams.

Store presence

On Google Play, a PWA can be published through a Trusted Web Activity: a small Android app that opens your site full screen in the browser. You have to prove, through Digital Asset Links, that the site and the app come from the same publisher, and the Bubblewrap tool generates the project. Google is explicit: the content must first be accessible and useful in the browser.

On the App Store, there is no equivalent. You have to build an iOS app that loads the site in a web view, and Apple is clear in guideline 4.2: an app should include features, content and UI that elevate it beyond a repackaged website. A bare wrapper around a PWA stands a good chance of being rejected. The most common rejection reasons are covered in our article on App Store and Google Play rejections.

What a PWA cannot do, or does badly

Web Bluetooth is classed as experimental and not "Baseline" by MDN, which means it does not work in several major browsers. Web NFC exists only in Chrome on Android. And geofencing is among the capabilities web.dev lists as unusable in a PWA.

In other words, anything involving hardware or background work remains the territory of native and cross-platform apps.

When a PWA is the right choice

Your traffic comes from Google. A PWA is first and foremost a website: it is indexed, shareable by link and usable without installing anything. If your users find you through a search and come back now and then, forcing a download on them costs them a step, and costs you users. That is the reasoning we develop in e-commerce app or mobile website.

It is an internal tool. A mobile back office, a room booking tool, a dashboard for the team: no store, no review, immediate deployment. You can even install the PWA yourself on company devices.

Use is occasional. Ordering at the table, tracking a delivery, filling in a registration form, checking an event programme. Nobody wants to download an app to use it once.

You are testing a market. A PWA lets you validate a journey with real users before committing the budget for an iOS + Android app. If the usage is there, the interface and the back end will serve as the foundation for what comes next.

When it is not

Your retention relies on iPhone notifications. Push exists, but only after a manual installation that many users will not do. If your model depends on a daily reminder, an app installed from the App Store remains the most reliable route.

The product depends on hardware. Bluetooth, NFC, badge reading, sensors, background location: that means native or cross-platform, no debate. For very hardware-heavy uses, native keeps an edge.

Offline work must be reliable. With no background synchronisation on iPhone, and storage the system can clear, a PWA is not a sound foundation for a field team.

App Store visibility matters. For a consumer audience that searches the store for "an app", not being there means not existing for them. And Apple will not publish a bare website wrapper.

The "we'll start with a PWA" trap

It is a line of reasoning we hear often: PWA first, app later. It works, on one condition: that the move to an app is planned from the start.

What can be reused: the back end, the API, the data, the design and a good share of the business logic. What cannot be reused, or only badly: the interface, if you move to React Native or Flutter, and everything that was patched together to work around the limits of the web. A PWA that has piled up workarounds to imitate a native feature costs more to migrate than a lean product.

The right reflex, then, is to design the API as if a native app were going to consume it tomorrow. The extra cost is small at the start, and it saves you from rebuilding everything at the very moment the product takes off.

And the budget?

A PWA generally costs less than an app: one codebase, no publication on two stores, no review for every version. But comparing quotes at a single point in time is misleading. The real calculation covers two or three years.

On our side, a full iOS + Android app represents 3 to 4 months of development and 120 to 200 person-days; a mobile MVP on a single platform, 4 to 8 weeks and 30 to 60 person-days. Maintenance then represents 15 to 20% of the initial cost per year. If a PWA lets you avoid that step during the validation phase, it is an excellent decision. If it has to be rebuilt as an app six months later because an essential feature is missing on iPhone, the saving turns into paying twice. To place these tiers, our article on the cost of a mobile app sets out the ranges.

Our position is simple: a PWA is the right choice when your three essential features work on iPhone without workarounds. In every other case, a cross-platform app is almost always a better investment, and native remains justified when hardware is at the heart of the product.

Going further: our mobile app development page explains how we choose the technology at scoping, and why that choice is made before the first mock-up.

Sources

• WebKit, "Web Push for Web Apps on iOS and iPadOS"
• WebKit, "WebKit Features in Safari 26.0"
• WebKit, "Updates to Storage Policy"
• MDN, "Making PWAs installable"
• MDN, "Web Bluetooth API"
• MDN, "Background Synchronization API"
• web.dev, "Installation" (Learn PWA)
• web.dev, "Capabilities" (Learn PWA)
• Android Developers, "Trusted Web Activities"
• Apple, App Store Review Guidelines, guideline 4.2
• Can I use, Push API
• Can I use, Background Sync
• Can I use, Web NFC