What Is a PWA? (Deep Dive)

A brief history

The web has always been installable in spirit — bookmark it and it is always there. But for years a gap remained between what websites could do and what native apps could do: offline access, push notifications, home screen presence, fast launch times.

In 2015, Alex Russell and Frances Berriman coined the term Progressive Web App to describe a set of techniques — not a new technology — that closed that gap. The key insight was that browsers had quietly shipped the necessary primitives (service workers, the Cache API, the Web App Manifest) and developers just needed to combine them intentionally.

Since then, every major browser has added PWA support, and the capabilities have expanded far beyond the original spec. Today a PWA can access the camera, microphone, clipboard, file system, Bluetooth (on supported platforms), and payment APIs — capabilities that were exclusive to native apps just a few years ago.

Real-world examples

The proof is in production. The most thoroughly documented case is Twitter’s:

Twitter Lite rebuilt Twitter’s mobile web experience as a PWA using the app shell model. The published results: a 65% increase in pages per session, 75% more Tweets sent, and a 20% drop in bounce rate — all from a roughly 600 KB initial download versus a 23.5 MB native Android app (about 97% smaller). (web.dev/twitter, verified 2026)

Several other high-traffic retail, productivity, and news sites have since reported similar directional gains — smaller installs, faster repeat loads, and higher engagement — after adopting the same app-shell-plus-service-worker approach. Treat specific percentage claims from any single write-up with caution: verify against a live source before repeating a number, and prefer citing your own measurements once you ship.

These gains came without publishing to an app store, without requiring a download, and without a separate development team for each platform.

The three hard requirements

A site is a PWA when it satisfies all three of the following. Miss any one and browsers will not offer the install prompt, and offline capabilities will not work.

1. Served over HTTPS

Service workers can read and modify every network request the page makes. Browsers enforce that they only run on secure origins. In practice this means:

https:// in production — full stop.
http://localhost and http://127.0.0.1 are explicitly exempted for local development.
Any other plain http:// origin will fail silently or throw a SecurityError on registration.

2. A Web App Manifest

A JSON file linked from <head> that describes how the app should appear when installed:

<link rel="manifest" href="/manifest.webmanifest" />

The manifest must include at minimum a name (or short_name), a start_url, a display mode of standalone or fullscreen, and at least one icon sized 192×192 or larger:

{
  "name": "My PWA",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#5A0FC8",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Without a valid manifest the browser install prompt will not appear.

3. A Registered Service Worker

The page must successfully register a service worker that controls its scope. At minimum it must handle fetch events (even if the handler just passes requests through) — this is the signal to the browser that the app has an offline strategy. A service worker that only handles install and activate satisfies the registration requirement but gives you no offline capability.

// sw.js — minimal service worker that qualifies a page as installable
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cached) => {
      return cached ?? fetch(event.request);
    })
  );
});

PWA capabilities vs. native

PWAs cover a surprisingly large portion of what native apps can do. The table below reflects the state of browser APIs as of 2025. “Limited” means the API exists but has platform gaps (typically iOS/Safari lags behind Chrome/Android).

Capability	PWA	Native	Notes
Offline access	Yes	Yes	Via Cache API and service worker
Home screen install	Yes	Yes	No app store review needed for PWAs
Push notifications	Yes	Yes	Limited on iOS Safari prior to 16.4
Camera / microphone	Yes	Yes	Via `getUserMedia` — requires permission
Background sync	Yes	Yes	`BackgroundSyncManager`; limited on iOS
File system access	Yes	Yes	File System Access API; not on Firefox
Payments	Yes	Yes	Payment Request API
Bluetooth	Limited	Yes	Web Bluetooth API; not on Firefox or iOS
NFC	Limited	Yes	Web NFC; Chrome on Android only
SMS / phone calls	No	Yes	No web API equivalent
App store listing	Optional	Required	PWA Builder can wrap a PWA for stores
Auto-update	Yes	Manual	New SW version activates silently
Deep OS integration	Limited	Yes	Shortcuts, share targets, protocol handlers available; lock-screen widgets not yet

The most significant remaining gap is deep OS integration — lock-screen widgets, always-on background processes, and low-level hardware access (NFC on iOS, Bluetooth on Firefox). For most consumer-facing use cases — content, commerce, productivity — a PWA covers everything users need.

Installability criteria in practice

“Installable” is not a single universal bar. Each browser engine applies its own heuristics on top of the three hard requirements:

Chromium (Chrome, Edge, Samsung Internet) — shows an install prompt once the three requirements are met and the user has interacted with the page. The exact engagement threshold is intentionally vague and changes over time.
Safari (iOS and macOS) — does not show an ambient install prompt. Users must tap the share sheet and choose “Add to Home Screen” manually.
Firefox — dropped its own install UI but still supports service workers and manifests; users can install via extensions.

This means your PWA must always work well as a plain website. Enhanced installability is progressive — hence the name.

Trade-offs

Option	Benefit	Cost
PWA (web-based)	Reachable through a single URL, no app-store gate before a user can try it	Access to some device APIs is more limited than a full native app
Native app	Full access to hardware/OS APIs	Must go through an app store; users must download before trying it

Common mistakes

Assuming “it has a manifest, so it’s a PWA” — while it still lacks HTTPS or a successfully registered service worker.
Treating PWA and native app as mutually exclusive — many teams ship both (PWA for reach, native for power users).
Overlooking iOS Safari’s limitations (no ambient install prompt, more restricted storage) and designing as if every platform behaves identically.