A progressive web app is a website built so a phone or desktop can install it with its own icon and its own window, skipping the app store entirely. Chrome will only offer that install prompt once a visitor has tapped the page at least once and stayed on it for at least 30 seconds, with a manifest listing icons at 192px and 512px, served over HTTPS — specific, checkable requirements, not a vague "make it feel like an app" brief.
What actually makes a website installable
Two files do the work. A web app manifest tells the browser what to call the app, which icon to show, and whether it opens full-screen or inside its own window rather than a normal browser tab. A service worker sits between the browser and the network, caching the pages and assets someone has already visited so they can still open without a connection. Meet Chrome's criteria — HTTPS, a valid manifest with the right icon sizes and a standalone-style display mode, plus that one-tap-and-30-second engagement bar — and Chrome offers to install the site itself; nothing about it needs submitting anywhere for approval.
Where Android and iOS pull apart
Android and desktop Chrome handle this evenly: once the criteria are met, Chrome shows its own install banner, and the same service worker that caches pages can also receive push notifications. iOS is the asymmetric case. Safari never prompts anyone to install a PWA — a visitor has to find "Add to Home Screen" in the Share menu themselves, with no banner nudging them toward it. Web push only works at all from iOS 16.4 onward, and only once the PWA is already sitting on the Home Screen, per WebKit's own announcement of the feature. For a business weighing a PWA as a re-engagement channel, that gap between platforms is worth planning for up front, not discovering after launch when half the customer base can't get a notification the other half takes for granted.
What a PWA still doesn't do
Service worker caching covers pages a visitor has already seen — it is not the write-offline-and-sync-later architecture our offline access guide covers for apps that genuinely need to keep working somewhere with no signal at all; that still needs its own local database and its own conflict-handling rule, PWA or not. A PWA also can't reach hardware a browser API doesn't expose — a persistent Bluetooth peripheral connection, continuous background location tracking — which is the same dividing line our native-versus-web guide already draws between building a web app and building native. Where a PWA earns its place is the middle distance: an icon on a customer's home screen and a lightweight offline shell, without taking on an app-store review queue the business doesn't actually need. That queue is a real clock — Apple's review typically runs one to two days, Google's usually faster, as our update-cadence guide covers for native apps — and a PWA skips it completely, updating the moment the website itself does.
We treat this the same way as the rest of our web-app-first approach: a PWA is often the right answer once "installable" is the actual requirement, rather than a reason to default straight to native. When the job genuinely needs more, that's covered under our app development work.
Frequently asked questions
What makes a website installable as a PWA?
Chrome's own installability criteria: the site must be served over HTTPS, carry a web app manifest with a name, a start URL, a display mode of standalone, fullscreen, or minimal-ui, and icons at 192px and 512px — plus the visitor must have tapped the page at least once and stayed on it for at least 30 seconds before Chrome offers its install prompt.
Can a progressive web app send push notifications?
On Android and desktop Chrome, yes, through the same service worker that powers offline caching. On iOS, only from iOS 16.4 onward, and only after the PWA has already been added to the Home Screen — Safari never shows its own install prompt, so every iOS install depends on someone finding "Add to Home Screen" in the Share menu first.
Does a PWA still need app-store review?
No. It isn't distributed through the App Store or Play Store, so there's no review queue to sit in. That removes the one maintenance clock a native app has that a website never does — an update to a PWA goes live the moment the website itself updates.
Is a PWA the same thing as a cheaper native app?
No. A PWA's offline ability comes from a service worker caching pages and assets someone has already visited, which lets a cached page still open without a signal. That is not the same as a genuine write-while-offline-and-sync-later architecture, which needs its own local database and conflict-handling logic regardless of whether the shell around it is a PWA or fully native.
When does a business still need to go fully native instead of a PWA?
When the job needs hardware or background behaviour no browser API exposes — a persistent Bluetooth peripheral connection, continuous background location tracking — the same dividing line that already separates a web app from a native one, regardless of whether the web app happens to be installable.