What Is a Progressive Web App (PWA) and Do You Need One?

A progressive web app, usually shortened to PWA, is a website built to behave like an installed app once someone visits it a few times. It can be added to a phone's home screen, it can work offline or on a bad connection, and it can send push notifications - all without going through an app store. It's still a website under the hood. The difference is a handful of browser features layered on top: a service worker that caches assets and handles offline logic, a web app manifest that tells the browser how to display the icon and splash screen, and HTTPS, which all of this requires by default.

What you actually get

The real, practical benefits of turning a site into a PWA come down to three things.

• Reliability on bad networks. A service worker can serve cached pages and assets when the network drops, so the app doesn't just go blank the moment a signal is lost. For content that doesn't change every second, this alone can be worth the effort.
• A install-free install. Someone can add the site to their home screen in two taps, with no app store review, no update rollout schedule, and no five-star-review gate standing between a fix and the person using it.
• Push notifications, which used to be an app-only feature and are now available (with the user's permission) straight from the browser on most platforms.

What it doesn't replace

A PWA is not a substitute for a native app in every case, and it's worth being honest about where it falls short. Deep integration with the operating system - Bluetooth, background location tracking, tight camera or NFC access, complex offline data sync - is still handled better, and sometimes only possible, in a native app. iOS support for PWA features has historically lagged behind Android's, so if your users are mostly on iPhones and you need background push or deep offline behavior, test the specific features you need before committing to the PWA route rather than assuming parity with Android.

A PWA also won't show up in the App Store or Google Play by default, which matters if App Store Optimization and discovery through app store search are part of how you expect to acquire users.

Do you need one?

The question that actually matters isn't "is a PWA cool" - it's "does my product's core use case need something a website with a service worker can't already provide." A content site, an e-commerce storefront, a booking tool, an internal dashboard, a marketplace listing app - these are usually strong PWA candidates, because the value is in fast access to information and a few well-defined actions, not deep hardware integration.

A few honest signals that a PWA is the right call:

• Your users are on the site often enough that "add to home screen" would actually get used, not ignored.
• Poor connectivity is a real, recurring problem for a meaningful share of your users - field service, delivery, rural or mobile-data-heavy markets.
• You want to ship fixes and features on your own schedule, not an app store review cycle.
• You don't need background processing, deep OS integration, or app-store discovery as a primary acquisition channel.

If most of those don't apply, or if the app is genuinely mobile-first with heavy camera, background location, or hardware use, a native or cross-platform app is usually the better investment - you can always build the PWA as a lightweight companion later.

What building one actually involves

None of this is exotic technology at this point - service workers and web app manifests are supported across every major modern browser - but doing it well takes more than dropping in a manifest file. Caching strategy matters: cache too aggressively and users see stale content after a deploy; cache too little and you lose the offline benefit entirely. Icons and splash screens need to be generated at the right sizes for each platform. And the whole thing needs to be tested on real devices, not just a desktop dev tools emulator, since install prompts and offline behavior differ meaningfully between Android and iOS.

This is the kind of work we do as part of our web development projects at Burncode - building the caching and offline logic into a site properly rather than bolting a manifest file on at the end, so the app actually holds up the way people expect once it's on their home screen.