What Is a Progressive Web App (PWA) for WordPress

If you’ve heard the term “Progressive Web App” thrown around and aren’t entirely sure what separates it from a regular mobile-friendly website, you’re not alone — the boundary is genuinely a little fuzzy, even among the engineers who coined the term. But the practical definition matters a great deal for any WordPress site owner deciding whether this is worth setting up.

The Plain-English Definition

A Progressive Web App, or PWA, is a website built using standard web technologies — HTML, CSS, and JavaScript — that delivers an experience closely resembling a native mobile app, without requiring a visitor to download anything from an app store. Mozilla’s MDN Web Docs, the authoritative technical reference for web standards, defines it directly: a PWA is an app built using web platform technologies that provides a user experience like that of a platform-specific app.

The term itself was coined in 2015 by Google engineer Alex Russell and designer Frances Berriman, who had been observing a new class of web applications and decided the category deserved its own name. A decade later, the concept has matured from an experimental idea into a mainstream strategy used by major companies — Starbucks built a PWA that lets customers browse the menu and build an order entirely offline, while Pinterest reported a 60% increase in core engagement after rebuilding as one.

The Three Technical Components That Actually Define It

Vague marketing descriptions aside, there’s genuine technical consensus on what makes a website a true PWA rather than just a mobile-friendly site. Web developer and author Jeremy Keith addressed the confusion directly in a widely cited 2017 analysis, arguing the criteria boil down to three concrete requirements — and that consensus has held up well in the years since.

The service worker is the most technically significant of the three. It sits between the browser and the network, intercepting requests and serving cached content when connectivity is poor or absent entirely — which is what gives a PWA its offline capability and is also the same underlying mechanism that makes push notification delivery possible. A site without HTTPS, a manifest, or a registered service worker can look and feel modern, but it isn’t technically a PWA — it’s just a well-designed website.

What Actually Changes for a Visitor

From a visitor’s perspective, the practical differences from a regular website are concrete and immediate. They can add the site to their home screen and launch it like any other app, without an app store download. Once installed, the PWA opens in standalone mode — full screen, with the browser’s address bar and navigation chrome hidden, so it visually presents like a native app rather than a website. Previously visited pages remain available even with no internet connection, thanks to the service worker’s caching. And with permission granted, the site can send push notifications the same way a native app would, re-engaging a visitor without requiring them to actively return and check.

The iOS Situation, Honestly

Apple’s relationship with PWAs has been slower and more conditional than Google’s, and it’s worth understanding exactly where the limitations sit before assuming a PWA will behave identically across every device. Android and Chrome support PWA installation with minimal friction — the browser can prompt the user directly. iOS has never offered that automatic prompt. Adding a PWA to the home screen on iPhone requires a manual sequence through Safari’s Share menu, and the option isn’t visible at all unless the visitor is using Safari itself — Chrome and other browsers on iOS run on Apple’s WebKit engine under the hood and can’t replicate the install flow.

Push notifications followed an even longer timeline. Apple didn’t add web push support to Safari until iOS 16.4, released in March 2023 — roughly eight years after Android gained the same capability. And the condition that remains true today: push only works for a PWA that has already been added to the home screen through Safari. A visitor browsing in an open Safari tab, or in Chrome on iOS, has no access to push notifications at all, regardless of iOS version, because every browser on iOS is bound by the same WebKit-level restriction.

Why WordPress Doesn’t Handle This Out of the Box

WordPress itself has no native concept of a PWA. None of the three required components — HTTPS aside, which is now standard hosting practice — are generated automatically by WordPress core. A site owner who wants genuine PWA functionality needs a plugin that creates the web app manifest, registers a service worker, and manages the install experience for visitors.

Historically, this has meant running two separate plugins on the same WordPress site: one dedicated PWA plugin to handle the manifest, icons, and offline caching, and an entirely separate push notification plugin to handle subscriber opt-ins and message delivery — two different settings panels, two different sets of icons to upload, and frequently, two plugins that were never built with each other in mind, occasionally conflicting over which one controls the service worker file.

For a WordPress site specifically, that means the manifest, icons, offline page, and the install experience itself — including a smart shortcode that shows Android visitors a one-tap install button while guiding iPhone visitors through Safari’s manual steps — are handled by a single plugin rather than two that have to be configured and kept compatible separately.

If you’re searching for a wordpress pwa plugin or trying to figure out how to add push notifications to a wordpress site without running two separate tools, that’s the exact gap this overlap creates an opportunity to close. A site owner shouldn’t need to learn two plugin settings panels, upload icon sets twice, or troubleshoot which plugin actually owns the service worker file when something breaks. One properly built plugin can register the manifest, cache offline content, and deliver push notifications from the same underlying mechanism — because, as covered above, that’s genuinely what the technology already does under the hood.

Who knew the difference between a website and an app was never the app store — it was three quiet technical components most visitors never notice are even there.