What Is a Progressive Web App (and Do You Actually Need One)?
· 6 min read · Mona Technologies
A progressive web app (PWA) is a regular website built with three extra capabilities bolted on: it can be installed to a phone's home screen without an app store, it can keep working (at least partially) with no internet connection, and it can send push notifications. It's not a separate technology or a framework you buy — it's a set of standards (a manifest file and a service worker script) layered onto a site you already have. The question worth asking isn't "what is a PWA" so much as "does the install-and-notify behavior actually change how my customers use my business".
What a PWA actually adds to a website
Three pieces do the work. A web app manifest is a JSON file that tells the browser your app's name, icon, and colors so it can be added to a home screen and opened in its own window instead of a browser tab. A service worker is a background script that intercepts network requests, which is what lets pages load instantly on repeat visits and lets some content work with no signal. And a small set of browser APIs (push, badging, and — on some platforms — file handling and background sync) let an installed PWA behave more like a native app once it's on the device.
- Installable — added to home screen/dock, opens in its own window, no app store listing needed
- Works offline or on poor connections — cached pages, assets, and sometimes data still load
- Push notifications — re-engage users without an SMS or email budget
- One codebase — the same site serves desktop browser, mobile browser, and the installed app
Where it genuinely beats a native app
The strongest case for a PWA is distribution friction. Getting a customer to open your website costs you nothing extra; getting them to find your app in a store, tap install, wait for a large download, and grant permissions costs you most of them. If your product's value is discovered through a link — a shared cart, a QR code on packaging, a Google search, a social post — a PWA lets that same link lead straight to an installable experience, with no store approval process in the way. It's also one codebase instead of a web app plus separate iOS and Android apps, which is the difference that matters most for a small team's maintenance budget.
Where it still falls short of native
The gap has narrowed but hasn't closed, and it narrows unevenly by platform. Apple didn't allow home-screen web apps to send push notifications at all until iOS 16.4, released in March 2023 — before that, a PWA on iPhone was mute no matter how well it was built. Since then, push works, but only for PWAs actually added to the home screen via Safari's Share menu, not for a tab left open in the browser, and Safari still gates deeper device integrations that Chrome on Android exposes more freely. If your business depends on iOS users receiving timely notifications, or on device features a browser sandbox won't grant, a native app is still the safer bet, at least for that platform.
Who should build one
The decision usually comes down to how people find you and what they expect once they're in.
- Ecommerce and content sites where speed and shareable links drive traffic — a PWA cuts load time on repeat visits and lets customers install without leaving your checkout funnel
- B2B tools and dashboards used daily by a defined set of logged-in users, where an app-store listing adds friction without adding discoverability
- Regional or emerging-market products where users are download-averse on limited data plans — install size stays small next to a native app
- Anything where notifications are the main iOS use case and can't tolerate the post-16.4 caveats above, or where you need App Store/Play Store presence for trust and discoverability — those still lean native
What building one actually requires
Per Google's own installability criteria for PWAs, a site has to be served over HTTPS, needs a valid manifest with icons and a name, needs a registered service worker, and — on Chrome specifically — won't prompt for install until a visitor has interacted with the page and spent a minimum amount of time on it, so installability is earned by real engagement, not forced on page load. None of this is exotic engineering; it's a manifest file, a caching strategy for the service worker, and a decision about what should still work offline versus what should just fail gracefully. The cost is closer to a focused sprint on an existing site than a second product to build and maintain.
The short version
Build a PWA when your customers arrive through links, not app-store search, and when "install this and get notified" would meaningfully change how often they come back — it's cheap to add to a site you already have and it removes the store gatekeeper entirely. Don't build one if your business genuinely needs deep iOS integration or app-store presence for trust; in that case, spend the budget on native instead of trying to make a PWA do a native app's job on Apple's terms.