A Progressive Web App (PWA) is a website built with standard web technologies (HTML, CSS, JavaScript) that behaves like a native mobile app: users can install it to their home screen, it works offline, and it can send push notifications. The difference from a native app is that there’s no separate iOS or Android codebase, no app store submission, and no platform-specific development required.
PWAs sit in an awkward middle ground in 2026. They’ve matured significantly since the term was coined a decade ago, iOS finally supports most of the important features, and the tooling has gotten genuinely good. At the same time, most small business websites get exactly zero benefit from being a PWA.
The plain-English definition
Strip away the marketing language and a PWA is just a website with three extra pieces bolted on that let it behave more like an app. When a user visits a PWA in a modern browser, they can tap “Install” (or “Add to Home Screen” on iOS) and get an icon on their phone that opens the site without browser chrome. The site can keep working when the user has no internet connection, and on supported platforms it can send push notifications even when the browser is closed.
The three technical pillars
1. The Web App Manifest
This is a JSON file (usually called manifest.json or manifest.webmanifest) that tells the browser how to treat your site when installed. It includes the app’s name, the icons to use, the theme color, the display mode, and the start URL.
The manifest is the easy pillar. A plain text file, a few dozen lines long, written in fifteen minutes.
2. The Service Worker
The service worker is where the real work happens. It’s a JavaScript file that the browser runs in the background, separate from the page itself. It intercepts network requests, decides what to cache, serves cached content when the network is unavailable, and handles push notifications.
This is the complicated pillar. Service workers have a specific lifecycle (install, activate, fetch), and getting them wrong can mean serving stale content for months. Most developers use Workbox (maintained by Google) instead of writing the logic by hand.
3. HTTPS
Service workers refuse to run over plain HTTP. In 2026 this is barely a hurdle since virtually every host offers free TLS certificates, but the requirement is absolute.
A short history
The term “Progressive Web App” was coined in 2015 by Alex Russell, a Google engineer. Google went all-in early. Apple dragged its feet on iOS for years.
The big shift came in March 2023 when Safari 16.4 finally added support for push notifications and other PWA features on iOS. That was the moment PWAs became a credible cross-platform option. By 2026, iOS support is good enough that you can build a single PWA and have it work reasonably well on both platforms.
What a PWA can do
- Install to home screen on iOS, Android, and desktop.
- Work offline or on flaky connections.
- Push notifications. Supported on Android and on iOS 16.4+.
- App-like UI without going through app store review.
- Single codebase for web, Android, and iOS.
- Background sync to retry failed requests when connection returns.
- Hardware access through web APIs: camera, geolocation, Bluetooth, payments.
PWA vs. native app
| Factor | PWA | Native App |
|---|---|---|
| Development cost | Lower, single codebase | Higher, separate iOS and Android apps |
| Time to ship | Faster | Slower (app store review) |
| App store fees | None | 15-30% on in-app purchases plus annual fees |
| Updates | Instant, like a website | User must update via app store |
| Device API access | Limited but growing | Full access |
| Performance | Good for most use cases | Better for graphics/compute-heavy apps |
| Discoverability | Through search engines | Through app store search |
If you need specialized hardware, high-end graphics, or app store discoverability, build a native app. If you mostly need an installable, offline-capable version of your existing website and you don’t want to maintain two native codebases, a PWA is genuinely a good option.
PWAs and SEO
Here’s where I have to push back on common SEO advice. Being a PWA does not, by itself, improve your search rankings. Google does not have a “PWA bonus.” What people pick up on is that the things you do to build a good PWA (fast loading, mobile-friendly, HTTPS, good performance) are also things Google rewards. The benefit comes from the underlying work, not the PWA label.
Crawlability and rendering
PWAs are still websites. Google still crawls them. The wrinkle is that many PWAs are built as single-page applications using React, Vue, or Angular. When a crawler hits an SPA, it has to execute JavaScript to see the content. Google does execute JavaScript, but JS rendering happens in a second pass that can be delayed.
The fix is to use server-side rendering (SSR) or static site generation (SSG) so that the HTML served on the initial request already contains the page content. Frameworks like Next.js, Nuxt, Astro, and SvelteKit all support this.
Core Web Vitals still apply
PWAs are typically heavier than plain HTML pages. That weight has to be paid for somewhere, usually in LCP and INP. If your PWA implementation makes the site slower without offering a corresponding benefit, you’re losing on both UX and SEO.
Standard on-page SEO is unchanged
Title tags, meta descriptions, heading structure, internal linking, schema markup, canonical tags, sitemaps, all work the same on a PWA as on any other site.
When a PWA makes sense
- Sites with significant repeat usage. Ecommerce stores customers return to weekly, content publishers with loyal readers, SaaS dashboards.
- Audiences in regions with unreliable connectivity. A huge driver of PWA adoption in India, Southeast Asia, and parts of Africa and Latin America.
- Brands that want a mobile presence without committing to native apps.
- Content sites where readers benefit from offline access. News, recipes, travel guides.
- Apps that need to bypass app store gatekeeping (cost, policy, speed reasons).
When a PWA doesn’t make sense
- Simple brochure sites. Visitors aren’t going to install your roofing site to their home screen.
- One-and-done visit patterns. Sites people land on once via search and never return to.
- Performance-sensitive sites where JS overhead hurts more than caching helps.
- Sites without a clear engagement model. If you have no reason for users to come back, no offline value, no notifications worth receiving, don’t ask.
A reality check for small businesses
The number of small businesses that should be PWAs is small. Most small business websites need to rank for relevant queries, load fast on mobile, and make it easy to contact the business. A well-built responsive site on solid hosting with good Core Web Vitals does all that without ever touching a service worker.
If an agency is pitching you a PWA conversion for your plumbing site or restaurant, ask them what problem it solves. “It’s more modern” isn’t a problem.
Implementation
From scratch
Next.js, Nuxt, SvelteKit, Astro, Remix, and Angular all have PWA plugins or built-in capabilities. A few days of work, not weeks.
Converting an existing site
Microsoft’s PWA Builder is the dominant tool. Free, works on any site, produces packaged versions for app stores.
WordPress
Several plugins exist. The PWA plugin maintained by Google contributors is the most credible. SuperPWA is a popular alternative with more user-friendly configuration. Quality varies considerably, a PWA plugin on WordPress is rarely as well-tuned as a purpose-built implementation. Audit service worker behavior carefully.
Discoverability and app stores
PWAs can be listed in Google Play via a Trusted Web Activity (TWA), which wraps your PWA as a normal Android app. Microsoft Store accepts PWAs directly. Apple’s App Store is more restrictive.
For most PWAs, the realistic distribution path is: users discover the site through search, use it once or twice, the browser shows them an install prompt, and a fraction of them install it.
Common myths
“PWAs will replace native apps”
No. The capability gap is smaller than it was, but native still owns categories like high-end games, professional creative tools, and most consumer apps where users expect app-store-grade polish.
“PWAs automatically improve SEO”
No. There’s no ranking factor for PWAs. SEO benefits come from underlying performance, mobile-friendliness, and HTTPS, which you can have without being a PWA.
“Every site should be a PWA”
Most sites should not. Adding PWA functionality to a five-page brochure site is engineering effort spent on a feature no one will use.
“PWAs are the same on iOS and Android”
Close, but not quite. iOS support has improved dramatically, but installation flow is less prominent on iOS, some web APIs are limited, and storage limits work differently. Test on both platforms.
The bottom line
A PWA is a useful piece of technology for the right project. It’s a way to build something that feels like an app, ships on web infrastructure, and reaches users across iOS, Android, and desktop from a single codebase.
The SEO question is straightforward: a PWA is still a website, so all the normal SEO rules apply. Make sure it’s crawlable (use server-side rendering for any JavaScript-heavy site), keep Core Web Vitals strong, and don’t expect any ranking bonus just from being a PWA.
Build a PWA when you have engaged users who will benefit from installing, offline access, or push notifications. Skip it when you don’t. For most small businesses, a fast, responsive, well-optimized regular website is what’s actually going to move the needle.