PWA Resources and Specifications¶

This page is a curated, verified index of the primary sources behind Progressive Web Apps: the specifications and their maturity as of September 2026, the IETF RFCs behind Web Push, official documentation from each browser vendor, the trackers that tell you what ships where, the standards-position repositories that tell you what will ship, and the tools, libraries and books worth your time. Every link was checked in September 2026. Use it when you need the authoritative answer rather than a summary, and pair it with the API Cheat Sheet and the Manifest Cheat Sheet for quick lookups.

How to read a specification's status¶

A specification's maturity level tells you how stable its API is and how many engines have committed to it. It does not tell you what ships. Some Recommendations are implemented in only one engine, and some Community Group drafts ship in browsers that hold most of the market. Read the status together with the support data and the standards positions below.

Core PWA specifications¶

Status as of September 2026, read from each document's header. "Pages on this site" links to the deep dives.

A few notes on this table:

• The Service Workers /TR/ page is titled "Service Workers Nightly". The Working Group publishes the full, current feature set, including Static Routing and InstallEvent.addRoutes(), as the Candidate Recommendation Draft. An older "Service Workers 1" document covered only the original core, so cite the nightly draft for modern behavior.
• beforeinstallprompt is not in the main manifest specification. It lives in Manifest Incubations and is implemented only by Chromium. A pull request to move it into the Web Application Manifest led to position requests at both other engines: WebKit opposes it and Mozilla has not taken a position (see the table of positions below).
• The Push API and Notifications API move independently. Declarative Web Push, which Safari ships, was proposed as a pull request to the Push API. Mozilla's position on it is positive.

The IETF RFCs behind Web Push¶

The browser side of push is the Push API. The server side, which your code talks to when it sends a message, is defined by four IETF RFCs. Every push service (Firebase Cloud Messaging for Chrome, Mozilla's autopush for Firefox, Apple Push Notification service for Safari, Windows Push Notification Services for Edge) implements them.

Apple documents its extra constraints and error responses in Sending web push notifications in web apps and browsers. How these fit together, with a byte-level walkthrough, is on The Web Push Protocol.

Related platform specifications¶

PWAs lean on general-purpose specifications that are not PWA-specific. These are the ones this site cites most often:

Browser vendor documentation¶

Vendor documentation is the best source for behavior that the specs leave to the browser: install criteria, quotas, prompts and platform quirks.

MDN Web Docs¶

MDN is the cross-browser reference. Its compatibility tables come from the same browser-compat-data project that this site uses for version numbers.

• Progressive web apps: guides, tutorials and the index of PWA-related APIs.
• Web application manifest: a per-member reference with compatibility data.
• Making PWAs installable: the installability requirements, compared across browsers.
• Service Worker API, Push API and Notifications API: interface references with per-member compatibility tables.
• Firefox release notes for developers: what each Firefox version shipped, including recent service worker and notification changes.

web.dev and Chrome for Developers¶

Google's two developer sites split the work. web.dev holds cross-browser guidance and courses. developer.chrome.com holds Chrome-specific capabilities, DevTools, Workbox and release notes.

• Learn PWA: a free, structured course that covers the manifest, service workers, caching, installation and capabilities.
• Progressive Web Apps collection: articles and case studies.
• What does it take to be installable?: Chromium's current installability criteria. Chrome dropped the service worker (fetch handler) requirement for installing from the browser menu in Chrome 108 on Android and 112 on desktop; the automatic prompt still required a fetch handler at that time, and current Chromium's install promotion has no service worker check.
• The service worker lifecycle and the Offline Cookbook: the two classic explanations of lifecycle and caching strategies.
• Capabilities and the Project Fugu API Showcase: Chromium's capability APIs (File System Access, File Handling, Window Controls Overlay and others) with demo apps.
• Workbox documentation: modules, recipes and build tools.
• Debug Progressive Web Apps: the DevTools Application panel, manifest and service worker debugging.
• Get Installed Related Apps: the only complete description of the verification rules per platform.
• Trusted Web Activity overview: packaging a PWA for Google Play.
• Chrome release notes: per-version feature lists, deprecations and origin trials.

WebKit and Apple¶

Apple documents web apps mostly through the WebKit blog and the Safari release notes. There is no single "PWA" guide, so these pages are the primary sources for anything about iOS, iPadOS and macOS.

• Web Push for Web Apps on iOS and iPadOS: the iOS 16.4 announcement that defines the Home Screen requirement, badging and the rules for requesting permission.
• Meet Declarative Web Push: the declarative JSON format, window.pushManager and the fallback model.
• Safari release notes: the authoritative list of what each Safari version fixed or added. For example, the Safari 27 notes record Service Worker Static Routing support and maxAge in the Cookie Store API.
• WebKit Feature Status: WebKit's own feature tracker.
• Sending web push notifications in web apps and browsers: server requirements for APNs-backed Web Push.

Microsoft Edge¶

Microsoft drives much of the desktop PWA work (Window Controls Overlay, protocol handling, the Web Install API) and documents it well.

• Overview of Progressive Web Apps: the entry point to Edge's PWA documentation, covering OS integration on Windows.
• Publish a PWA to the Microsoft Store: packaging with PWABuilder and submitting to the Store.
• Microsoft Edge web platform release notes: per-version changes, origin trials and deprecations.
• MSEdgeExplainers: explainers for features the Edge team proposes, including the Web Install API.
• MicrosoftEdge/Demos: working demo apps, including the Web Install API demo.

Android and Firefox tooling¶

• Overview of Trusted Web Activities: Android's own documentation for TWAs and Digital Asset Links.
• about:debugging: Firefox's tool for inspecting, starting and unregistering service workers, and for remote debugging Firefox for Android.

Browser support and status trackers¶

Different trackers answer different questions. The version numbers on this site come from MDN's browser-compat-data (release 8.1.3, published September 24, 2026) and the vendors' release notes.

Two caveats apply. BCD records when an API became available, which is not always when it became usable: iOS Push, for example, is recorded as 16.4 but works only in Home Screen web apps. And support in "Chrome" usually carries over to Edge, Opera and Samsung Internet at the same Chromium version, but not always. Samsung Internet, for instance, tracks Chromium with a delay and its own feature choices.

Checking support from a script¶

When you maintain a support table, query browser-compat-data directly instead of copying numbers by hand. This Node.js script prints the first supporting version per browser for any list of BCD paths, and flags partial, prefixed and flagged support:

// Usage: npm i -D @mdn/browser-compat-data
//        node scripts/support.mjs api.PushManager api.Navigator.setAppBadge api.InstallEvent.addRoutes
import bcd from "@mdn/browser-compat-data" with { type: "json" };

const BROWSERS = ["chrome", "chrome_android", "edge", "firefox", "firefox_android", "safari", "safari_ios"];

function lookup(path) {
  // Walk "api.PushManager.subscribe" down the BCD tree.
  return path.split(".").reduce((node, key) => node?.[key], bcd)?.__compat;
}

function describe(statement) {
  if (!statement) return "?";
  // A browser may have several statements (e.g. prefixed, then unprefixed); the first is current.
  const s = Array.isArray(statement) ? statement[0] : statement;
  if (s.version_added === false) return "no";
  if (s.version_removed) return `removed ${s.version_removed}`;
  const notes = [s.partial_implementation && "partial", s.prefix && `prefix ${s.prefix}`, s.flags && "flag"]
    .filter(Boolean);
  return `${s.version_added}${notes.length ? ` (${notes.join(", ")})` : ""}`;
}

const paths = process.argv.slice(2);
if (paths.length === 0) {
  console.error("Pass one or more BCD paths, for example api.PushManager");
  process.exit(1);
}

console.log(`BCD ${bcd.__meta.version} (${bcd.__meta.timestamp.slice(0, 10)})`);
for (const path of paths) {
  const compat = lookup(path);
  if (!compat) {
    console.log(`${path}: not found in BCD`);
    continue;
  }
  const row = BROWSERS.map((b) => `${b}=${describe(compat.support[b])}`).join("  ");
  const flags = [compat.status?.experimental && "experimental", compat.status?.deprecated && "deprecated"]
    .filter(Boolean).join(", ");
  console.log(`${path}${flags ? ` [${flags}]` : ""}\n  ${row}`);
}

The script needs Node.js 22 or later for the with { type: "json" } import attribute. Run it in CI after each BCD release and compare the output with your documentation, so support tables don't silently go stale.

Standards positions and design reviews¶

Chromium ships many PWA capabilities first. Whether the other engines follow depends on their published positions, which are the best predictor of cross-browser support you have.

• Mozilla standards positions (GitHub): positions are positive, neutral, negative, defer or not yet set.
• WebKit standards positions: positions are support, neutral, oppose or blocked, with the concern named in labels (privacy, security, venue and so on).
• W3C TAG design reviews: the Technical Architecture Group's reviews of new APIs, often the most detailed critique of a design.

Positions on PWA-related proposals, read from both repositories in September 2026:

How to use this table: a negative or oppose position means you should design the feature as a Chromium-only enhancement indefinitely, as with Background Sync, where an IndexedDB outbox with an in-page retry is the real mechanism and sync is a bonus. Defer and no position mean nobody has done the work to decide yet. A positive or support position does not promise an implementation date. Mozilla's positive position on Static Routing, for example, has not yet produced a Firefox release.

Tools and libraries¶

Versions are the latest on npm as of late September 2026. Check each project's changelog before upgrading across a major version.

Learning resources and demos¶

Beyond the specs and vendor references, these resources are worth reading in full:

• The Offline Cookbook by Jake Archibald: the original catalog of caching strategies (cache-first, network-first, stale-while-revalidate and variations). Every strategy page on the web, including Caching Strategies, descends from it.
• The service worker lifecycle, also by Jake Archibald: still the clearest explanation of why the waiting phase exists.
• Web Push Book by Matt Gaunt: a free online book on the push flow from subscription to server, including the encryption steps.
• Learn PWA on web.dev: a course that goes from basics to capabilities.
• What PWA Can Do Today: a PWA that demonstrates capabilities live, so you can test a device's support by installing it.
• Project Fugu API Showcase: production apps that use Chromium capability APIs.
• Going Offline, read online: Jeremy Keith's book on service workers, now free to read on the web.

Books¶

Books on PWAs were mostly published between 2017 and 2020. Their explanations of the lifecycle, caching and the manifest are still sound. Their browser support statements, install criteria and push details are not: iOS had no service workers when the earliest of them were written. Read them for concepts and check APIs against MDN.

Keeping this knowledge current¶

PWA support changes with every browser release. Chrome moved from a four-week to a two-week release cycle with Chrome 153 on September 8, 2026 (the Extended Stable channel stays at eight weeks). Firefox ships roughly every four weeks, and Safari ships a major version each September plus point releases during the year. A sustainable routine:

1. Subscribe to the release notes of Chrome, Safari, Firefox and Edge (the links are in the trackers table). Search each one for "service worker", "manifest", "push", "notification" and "badge".
2. Re-run your support script against each new browser-compat-data release, and diff the output against your documentation.
3. Watch Chrome Platform Status for Intent to Ship and Intent to Deprecate posts that affect you. Background Fetch's November 2025 intent to deprecate and the Web Install API's 2026 intent to ship were both posted to blink-dev. Intents are proposals, not outcomes: as of Chrome 154, Background Fetch still ships, now with CORS enforcement and a Chrome 149 restriction on jobs started from a service worker.
4. Watch the standards-positions repositories for the proposals in the positions table. A change from no position to positive is the earliest signal that another engine may implement.
5. Test on real devices, particularly iOS Home Screen apps, whose behavior no desktop emulator reproduces. The Browser DevTools page covers remote debugging.

The site's History & Evolution page records when each capability shipped, and the Production Checklist turns current support into a release checklist.

Further reading¶

On this site

• API Cheat Sheet
• Manifest Cheat Sheet
• Glossary
• FAQ
• Platform Support
• History & Evolution
• Tooling & Frameworks

External references

• Service Workers (W3C)
• Web Application Manifest (W3C)
• Push API (W3C)
• MDN: Progressive web apps
• web.dev: Learn PWA
• Chrome Platform Status
• Mozilla standards positions and WebKit standards positions