The three technical pieces that make it a PWA
The web app manifest is a JSON file listing the app's name, icons, and theme colors — it's what lets a browser show an "Install" prompt and gives the installed app a proper icon and name instead of just a bookmark.
The service worker is a background script that can intercept network requests, cache assets, and keep working when there's no connection — it's the single piece of technology that makes offline support and push notifications possible, and it only runs on HTTPS for security reasons.
What a PWA actually gets you over a regular website
The most concrete win is distribution without an app store: no review process, no 15-30% platform cut, and an update ships the moment you deploy it — every user is always on the latest version, unlike a native app waiting on users to update.
The tradeoff is real, too: iOS support for PWA features has historically lagged Android's (push notifications only arrived in recent iOS versions, and even then with more limitations), and a PWA can't access some device APIs a fully native app can — Bluetooth, certain background processing, deep OS integration.
When a PWA is the right call
Content-first products — a news site, a documentation portal, most e-commerce, an internal business tool — are usually a great fit: the core value is already a webpage, and a PWA adds installability and offline reading on top of a codebase you already maintain.
A native app still makes more sense when the product genuinely depends on deep OS integration (real-time Bluetooth, complex background location tracking, heavy on-device processing) or needs to be discovered primarily through app-store search rather than the web.