You want to be on people's phones, but you have looked at what it costs to build and maintain two native apps plus a website, and the number is hard to justify. Someone mentions a progressive web app as the answer, and it might be — but PWA has become one of those terms that means something slightly different to everyone who says it. Before you commit engineering to one, it is worth knowing exactly what you are getting, what you are giving up, and when it is genuinely the right call.
What a PWA actually is
A progressive web app is a website built to behave more like an installed app. It runs in the browser like any site, but with a few additions it can be installed onto a home screen and launched without browser chrome, it can work offline or on a poor connection, and where the platform allows it, it can receive push notifications. It is the same web app your browser already runs, given the ability to feel less like a tab and more like software the user chose to keep.
The magic is smaller than it sounds. A background script the browser runs on your site's behalf can cache the app's files and data so it loads instantly and survives going offline. A small manifest file tells the phone the app's name and icon so it can sit on the home screen. There is no separate installer and no store — the user visits the site, chooses to install, and it is there. That directness is both the appeal and, on some platforms, where the limits begin.
The word progressive is the part people miss, and it matters. A well-built PWA works as an ordinary website for everyone, and layers the app-like abilities on top only where the device supports them. A visitor on an older browser still gets a working site; a visitor on a capable one gets the installable, offline version of the same thing. You are not building two products — you are building one that quietly does more where it can.
Where a PWA wins
The strongest argument is reach with one codebase. A PWA is a website, so it works on any device with a modern browser — one team, one codebase, one deployment reaching phones, tablets, and desktops at once. You are not staffing separate iOS, Android, and web efforts and keeping three roadmaps in sync; you ship once and everyone gets it.
The second argument is the absence of store friction. There is no review queue between you and a fix, no approval process, no revenue share on payments you route yourself, and no install barrier — a link is the whole distribution mechanism. For a tool people reach through a link, a service used occasionally rather than lived in, or anything where a trip to an app store would lose you users, a PWA removes a real tax. It updates the moment you deploy, the way a website does, because it is one.
There is a discoverability argument too, and it is easy to overlook. A PWA lives on the open web, which means search engines find it, links to it work, and a person can share a specific page rather than telling a friend to download an app and find the right screen. For most businesses, being findable on the web is not a nice-to-have alongside an app — it is the front door, and a PWA keeps that door and the installed experience as the same thing rather than two separate builds.
Where a PWA hits its limits
Honesty about the ceiling is what separates a good recommendation from a pitch. A PWA runs in the browser's sandbox, so it reaches only the device capabilities the browser exposes. Much is available now — camera, location, offline storage, notifications in many places — but deep hardware access, tight integration with the operating system, and the most demanding graphics or background behaviour are either limited or off the table.
The specific asterisk is Apple. Support for PWAs on iOS has historically trailed Android and the browser you are on, and the gaps land exactly where they hurt: push notifications and install behaviour have been more constrained, storage can be reclaimed by the system, and some capabilities simply are not there. If a large share of your users are on iPhones and your case depends on notifications or a truly native-feeling install, you must test that path early rather than assuming it works. A PWA is not a promise that every device treats it equally.
The right way to hold this is not as a dealbreaker but as a thing to measure against your actual audience. The limits only matter to the extent your product touches them, and for a great many products they never come up. The mistake is discovering the ceiling after you have built toward it — so find your own ceiling first, on the devices your users actually carry, and design inside it deliberately.
The smart middle path — and when it is not
A PWA is the right call more often than the native-by-default instinct suggests, but not always, and the deciding question is what your product fundamentally is. If it is content, a service, a tool, a dashboard, a shop — something a website already does well and you want it faster, installable, and offline-tolerant — a PWA gets you most of a native experience at a fraction of the cost and complexity, and it is usually the smart middle path.
You genuinely need native when the product's core depends on what only native gives you: heavy real-time graphics, deep camera or sensor work, tight background processing, integrations the browser will not expose, or a store presence that is itself part of how customers find you. The mistake in both directions is the same — deciding by fashion instead of by what the product actually has to do. Native because it feels more serious, or a PWA because it sounds cheaper, are both the wrong reasons. Decide by capability.
It is also not always a permanent, either-or choice. A common and sensible path is to start with a PWA to reach everyone quickly and cheaply, learn what people actually use, and only then decide whether a specific slice of the product earns a native app for the capabilities it genuinely needs. Starting with the reachable option and earning your way to the expensive one is usually smarter than committing to native on a hunch about features you have not validated.
It is still real engineering
The dangerous half-truth is that a PWA is just your website with a setting turned on. Made well, it is a genuine engineering effort. Offline support means deliberately deciding what is cached, how stale data is handled, and what happens when the user acts offline and the network returns — that reconciliation is real work, not a checkbox. The caching layer that makes the app instant is also the thing that can serve users a stale version after you deploy if you get its update strategy wrong, which is a class of bug that does not exist on an ordinary site.
Beyond that, an installed app is held to app standards, not web standards — it has to feel right launched from a home screen, behave when the connection drops mid-action, and handle being a long-lived thing rather than a page someone reloads. None of this is exotic, but all of it is deliberate. A PWA saves you the cost of a second and third codebase; it does not save you the cost of building the one codebase properly.
How to decide with confidence
Cut through it with three questions. First, what does your product actually need from the device — and specifically, does anything on that list sit outside what a browser can reach? Second, where are your users, and if a meaningful share are on iOS, have you tested the constrained parts of that path rather than hoped? Third, what does carrying multiple codebases cost you in money and in speed, honestly measured against building one well?
Answer those and the choice usually stops being a matter of taste. For a large class of products the PWA is the disciplined, cost-honest answer; for a specific class it is the wrong tool, and knowing which you are before you write code is the entire point. The worst outcome is not choosing a PWA or choosing native — it is choosing either one by reflex, discovering the mismatch halfway through the build, and paying to correct a decision that a few honest questions at the start would have settled.