Progressive Web App

A progressive web app is a website built with capabilities that allow it to behave more like an installed application: it can be added to a device's home screen, launched without browser chrome, work offline or on unreliable connections, and in supported environments receive push notifications. It is a set of capabilities applied to a normal website rather than a distinct technology.

The technical foundations are a service worker, which is a script running separately from the page that can intercept network requests and serve cached responses, and a web app manifest describing how the application should appear when installed. Both require the site to be served over a secure connection. Beyond these, the capabilities are progressive: a browser that supports them provides the enhanced experience while others receive the ordinary website.

The offline and unreliable-connection handling is the capability with the clearest practical value. A service worker can cache the application shell and previously viewed content, so a visitor on an intermittent mobile connection sees content rather than an error page, and a return visit loads from cache rather than from the network. For audiences on poor connectivity this is a substantial improvement rather than a refinement.

Installation removes the friction of app store distribution, which is the main commercial argument. There is no submission process, no review delay, no store commission, and updates deploy immediately without waiting for users to install them. For businesses whose application does not require deep platform integration, this avoids a significant ongoing cost and a dependency on platform gatekeepers.

Platform capability differences remain the principal limitation, and they have narrowed unevenly. Support for installation, notifications, and background capabilities varies between platforms, with iOS historically more restrictive than Android, and storage limits and eviction policies differ. Assessing what is actually available on the platforms an audience uses, rather than assuming parity, is necessary before committing to an approach that depends on a particular capability.

Discovery is a genuine trade-off in both directions. Web distribution means the application is reachable by link and discoverable in search, which is a substantial advantage over store distribution where discovery depends on ranking within a store. It also means the application does not appear in the store where many users look for applications, and there is no equivalent of the install prompt a store listing provides.

Push notifications warrant a more sceptical assessment than they usually receive. The capability is genuinely valuable for time-sensitive, individually relevant messages, and it is widely abused for promotional content that recipients did not anticipate. Because permission is requested once and refusal is effectively permanent, prompting before establishing any value reliably produces refusals that cannot be recovered later when there is something worth sending.

Service worker caching introduces its own risks that require deliberate handling. A caching strategy that serves stale content indefinitely produces users seeing outdated information with no obvious way to refresh, and a badly deployed service worker can be difficult to remove from devices that have already installed it. Versioning, update strategies, and a mechanism for forcing refresh are necessary rather than optional.

Because the approach spans front-end architecture, caching strategy, and distribution decisions, it is a product decision rather than a technical one. In practice the capability set is chosen within product development against the actual needs of the audience, the caching and delivery implications sit with web performance work, and the discovery trade-off between web and store distribution is normally weighed alongside the wider channel strategy in strategic planning and consulting.