Native app vs web app vs PWA: when a PWA is enough

Picture a meeting where someone says “we need an app”. A few weeks later, the company is already comparing quotes for two native apps, even though nobody has asked how often people will open the product or whether they need anything a browser cannot handle.

The choice of platform is determined by how often and where people will use the product, what the device needs to be able to do and what it costs to maintain several versions at once. The native app vs web app vs PWA decision should therefore not come down to your supplier’s preferences.

“We need an app” is a reflex, not a brief

Requests for an app often arise from looking at competitors, and they name a solution before anyone has named the problem. The sensible order is the reverse: first understand the business and the process, remove unnecessary steps, then design the user experience, and only at the very end choose the technology. In the company layer model, the choice of platform belongs to the Experience layer: it determines where people encounter the product and how much effort that costs them.

The options, explained for the leadership team

A native app is software written specifically for one operating system, separately for iOS and separately for Android. That means two codebases, in other words two separately maintained bodies of source code.
A cross-platform app is the product of cross-platform development: a single codebase is used to build the app for both iOS and Android. One example is Google’s Flutter, which, according to its own FAQ (updated 14 September 2026), makes it possible to bring developers together into a single team and align releases; this is, however, the vendor’s own claim. Flutter calls native code through what are known as platform channels, so iOS and Android expertise does not disappear from the team entirely.
A web app runs in the browser with no installation. In its Learn PWA course (updated 20 September 2024), Google notes that the web does away with packaging, additional content review and delays to updates.
A PWA, or progressive web app, is a web app that can be installed. According to the same course, once installed it has an icon on the home screen and its own window without the browser interface. Offline mode, meaning the ability to work without a network connection, is provided by a service worker: a script that the browser runs as needed and which, according to Mozilla’s MDN documentation, can store the app’s files in a local cache.

The criteria that settle the question before technology does

Frequency of use. A tool opened several times a day deserves an icon on the home screen, but a PWA can provide that too. For a service a customer uses a few times a year, installation merely adds a step before the first use.
Context. A technician in a basement with no signal, a warehouse operative wearing gloves, a driver in a vehicle. With offline mode, you need to define precisely what should happen without a connection: reading, writing, synchronisation and resolving conflicts between edits.
Device capabilities. Camera, background location, Bluetooth, NFC, notifications, biometrics. For those you cannot do without, verify support on the target devices as at the date of your decision, because it changes. Be careful with background processing: MDN (13 September 2026) states that a service worker does not run continuously and that Chrome is likely to terminate it after, for example, 30 seconds of inactivity.
Distribution. A web app opens from a link or a QR code. According to Google, native apps on mobile devices are installed mainly from app stores, which decide who may publish what.
Updates. According to Google, a native update requires repackaging, signing, approval and installation. Until users have installed it, your server has to support the older version as well.
Target audience. Employees are given the tool, whereas customers have to be won over, so with customers every extra step can cost you a share of conversions.

The costs a first quote will not show you

Development and codebases. Two native apps plus the web version add up to three codebases. Every feature is built, tested and released three times, the versions drift apart over time, and both the error rate and the cost of support rise.
App Store review is the check in which Apple assesses every app and every update before publication. Apple itself states that, on average, it reviews 90% of submissions in less than 24 hours. What matters more than the wait is that the decision to publish is not yours: under section 2.1 of the App Review Guidelines (updated 8 June 2026), Apple rejects incomplete apps and apps that crash.
App store fees. Commissions apply to sales of digital content and digital services, and they come straight out of your margin. Section 3.1.1 of these guidelines requires In-App Purchase to be used to unlock features, content or subscriptions, with regional exceptions. Physical goods and services consumed outside the app, by contrast, must be paid for by other means. For apps distributed in the EU, Apple’s terms effective from 1 October 2026 set a commission of 26% on sales through In-App Purchase, and 15% for members of the App Store Small Business Program. Google states that 97% of developers distribute apps on Google Play free of charge, and for transactions in the EEA from 30 June 2026 it charges 10% plus a 5% fee for its billing system on the first USD 1 million of annual earnings.
Operating system updates. Every major change to iOS or Android is a reason to test the app and often to release it again, and with two native apps you do this twice. Google describes testing on new versions of operating systems and browsers as mandatory for PWAs as well.

PWAs in practice: what they can and cannot do today, especially on iOS

Installation. According to MDN (7 September 2026), a browser will only offer installation for a website that has a manifest (a file describing the app) and a secure HTTPS connection. A service worker is not a requirement, so offline mode has to be designed deliberately. On Android, only Chrome on devices with Google Mobile Services and Samsung Internet on Samsung devices install a PWA as a fully fledged app. Other browsers merely create a shortcut that opens the website in the browser.
iPhone and iPad. According to MDN, on iOS 16.4 and later a PWA is installed from the Share menu. iOS does not support a custom install button on the website, so users have to be guided through the steps. In iOS 26 and iPadOS 26, according to the WebKit blog (15 September 2025), every site added to the home screen opens as a web app by default, even without a manifest.
Push notifications are messages from a server that the device displays even when the app is not running. On 16 February 2023, Apple announced on the WebKit blog that iOS and iPadOS 16.4 bring Web Push to web apps added to the home screen, so according to that announcement push is tied to this step. The announcement also states that permission may only be requested in response to a direct user action.
Background processing. If the browser supports it, Background Sync attempts to complete a task once the connection is restored. According to MDN (13 September 2026), however, the task can only be registered while the app is open, and browsers limit both the number and the duration of attempts. According to the same source, no browser supports silent push without a visible notification.
App stores. According to MDN, a PWA can also be packaged for Google Play or the App Store, but section 4.2 of Apple’s guidelines requires more than a repackaged website.
Regulatory risk. According to TechCrunch (1 March 2024), Apple reduced PWAs in the EU to simple shortcuts in the iOS 17.4 beta, citing the Digital Markets Act (DMA), and backed down after criticism. A European Commission staff working document dated 28 April 2026 states that Apple has continued to support home screen web apps.

Our reading: a PWA is a workable option on iOS, but its limits are set by Apple, just as the limits of a native app are set by the store’s rules. Every option carries platform risk.

Internal tools versus customer-facing apps

Unlike customers, employees are brought to an internal tool by the process: a link on the intranet, a company login, a browser bookmark. The argument that an app has to be in a store for people to find it does not apply here.

Internal tools often handle forms, approvals and overviews with no special hardware requirements. The exceptions are warehousing, field work and production, where the device is a working tool. What is more, a change made on the web reaches people without anyone having to install an update. No platform, however, will rescue a tool that makes people’s work harder, as we wrote in The most expensive system is the one your people do not use.

Illustrative scenarios

The scenarios below are hypothetical and serve only to illustrate the reasoning.

Field technician

A service company’s technicians log jobs even when there is no signal. If offline entry with synchronisation once the network is back is enough, a PWA is a sensible pilot, and tests on the technicians’ phones will show whether synchronisation is reliable. If the company needs continuous location tracking throughout the whole shift or a Bluetooth connection to a measuring instrument, a cross-platform or native app is the safer choice.

Online shop

Customers buy a few times a year and arrive via a search engine or a newsletter. An app would put an installation and a login between the customer and the purchase. Investing in a website that is easier to understand will deliver more, because an app will not fix an unclear offer, as we discuss in When customers do not understand your website, you pay for traffic that goes to waste.

B2B ordering

A wholesaler’s trade customers repeatedly order long lists of items. What matters is fast reordering, import from a spreadsheet and integration with the ERP, the company’s enterprise resource planning system. A web app can handle this, but first check whether the B2B module of the online shop or the ERP the company already has would be enough.

Loyalty programme

A café chain should first check whether its point-of-sale system already offers a loyalty feature. A middle route is a PWA with push notifications, available on iPhone only after it has been added to the home screen. A native app makes sense when a pilot shows that customers use the programme often and that this very step is what holds them back.

Internal approval tool

A company approves invoices and leave requests by email. Start by scrapping approval steps that check nothing, and verify whether an accounting or HR system the company already pays for could cover the process. If not, a web app with a company login, or possibly a PWA, is enough. Two native apps would add development and release costs here without any benefit to offset them.

A phased route: web, measurement, and only then a native app

For a product without a clear native requirement, we recommend a step-by-step approach:

First version as a web app or PWA: one codebase, instant updates and a quick answer to whether people want the product.
Measurement: how often people come back, on which devices, how many have installed the PWA and which limitations keep recurring.
A threshold set in advance: management decides what result would justify a native app. Without one, the decision slides back into reflex.
A native app where the data justifies it, often only for the most active user group.

Common practice is to separate the server side, with its data and logic, and expose it through an API, an agreed interface through which programs exchange data. A native app then connects to the same data and rules, and the web remains a fully fledged channel, as we explain in A premium website is not about aesthetics. It is commercial infrastructure. If, however, you know from the outset that the product rests on a capability the web cannot cover, the phased route is an unnecessary detour.

When a native app is the right choice

The product depends on continuous background processing, such as tracking location throughout a whole shift. According to MDN, a service worker does not run all the time, which is why, in our view, the web is not enough for this.
The app makes in-depth use of Bluetooth, USB, files or contacts, areas that Google lists among the strengths of native apps.
The app is itself the product that people use every day, and performance is part of its value.

Even then, consider cross-platform development with a single codebase first. Only put the “native app vs web app vs PWA” question on the table once the problem, the user and the environment have been precisely defined.

Key takeaways

Replace “we need an app” with these questions: who uses the product, how often, where, and what the device needs to be able to do.
Calculate costs over the entire lifecycle: every native platform adds a codebase, store review and testing, and, if you sell digital content, a store commission as well.
Insist that claims about PWA capabilities are backed by a dated source, especially for iOS, where the conditions have changed several times since 2023.
For internal tools, start with the web and consider a native app only for field work, the warehouse or work with hardware.
Before the first version, agree a measurable threshold that would justify a native app.