Most companies asking for an app do not need one. They need something that works well on a phone, can be reached without a download, and does not require an app store review for every text change. That is usually a progressive web app. Sometimes it genuinely is not.
What a PWA can do today
- Install to the home screen on Android and iOS with its own icon and no browser chrome.
- Work offline through a service worker with cached content and queued actions.
- Access camera, location, files and, on Android, Bluetooth and NFC.
- Send push notifications, on iOS since version 16.4 for installed web apps.
- Be found through search engines and shared as a plain link.
For most business scenarios, that covers the requirement: an ordering tool for regular customers, a service portal, an event companion, an internal checklist for field staff.
Where native remains necessary
- Background location tracking over hours, for logistics or field service.
- Heavy on-device processing, such as continuous video analysis or 3D rendering.
- Deep hardware access: health sensors, secure element, advanced Bluetooth profiles.
- Store presence as a distribution channel, when customers genuinely search the app store for your category.
- Payment models that require in-app purchase for digital goods.
- Enterprise device management, where the app must be distributed and configured centrally by an IT department.
The cost comparison over three years
A solid PWA costs 18,000 to 40,000 EUR to build, with one codebase and no store fees. Two native apps for iOS and Android cost 55,000 to 120,000 EUR, or 35,000 to 70,000 EUR with a cross-platform framework such as React Native or Flutter. Add ongoing maintenance: native apps need annual updates for new operating system versions, review cycles and store accounts, which adds 6,000 to 15,000 EUR a year.
The store is not a marketing channel for most SMBs. Getting a customer to install anything is harder than getting them to open a link.
The distribution reality
Average users install very few new apps per month, and almost all of them are entertainment or messaging. A B2B tool for two hundred customers will not be found in the store; it will be sent as a link by an account manager. Conversely, a PWA is one tap away from any e-mail, invoice or QR code on a delivery note.
A pragmatic path
Build the PWA first. It becomes your mobile web experience anyway, so the work is not thrown away. Measure how many users install it, how often they return, and which capability they ask for that the web cannot deliver. If after six months there is a concrete, repeated requirement that only native satisfies, wrap the existing web application in a native shell or build the native client for that specific workflow.
Two details decide whether the PWA feels like an app or like a bookmark. First, the offline behaviour: a cached shell that loads instantly and a queue that sends actions once the connection returns. Second, the install prompt: shown at the right moment, with a short explanation of what installation gives the user. Teams that skip these two points usually conclude that progressive web apps do not work, when in fact they shipped a website with a manifest file.
Two questions that settle most cases
First: does the product need to run while the screen is off? Second: will customers actively search an app store for it? If both answers are no, a progressive web app is the cheaper, faster and more maintainable choice, and you can revisit the question with real usage data instead of assumptions. Whatever you decide, put the installation prompt where it belongs: after the first successful task, never on the first visit.
