Progressive web app

Why it matters

It gets most of the engagement benefits of a native app, home screen presence, offline access, push notifications, without an app store approval process, a store fee on transactions, or the cost of building and maintaining separate iOS and Android codebases. It also matters for update speed: a PWA update is live the moment a new version is deployed, with no app store review process standing between a bug fix and the people actually affected by it. It also benefits from background sync, where an action taken offline, like adding an item to a cart, is queued and completed automatically once connectivity returns, rather than simply failing.

What goes wrong when it's handled badly

The most common gap is assuming offline behaviour happens automatically; it requires a service worker deliberately built to cache the right content, and a PWA without one just shows a browser error offline like any other website. A push notification permission asked for immediately on page load, before the visitor has any reason to want it, is a routine way real PWAs get that permission denied and lose the feature for good on that visitor. A concrete example is a cached version of the app serving stale pricing or inventory data because the caching strategy was not built to distinguish content safe to serve offline from content that genuinely needs to be current every time. Testing the app with the network explicitly disabled during development, not just assuming the service worker configuration is correct, is what catches a caching strategy that does not actually work as intended.