Skip to content

Tools

Published

Four kinds of tool recur in PWA projects: a service worker library, a build-time plugin that emits the manifest and worker, a packager for each store, and an auditor. This page records what each one does, what it requires, and the version read when the page was checked; it is an editorial shortlist with no paid placement.

Nothing on this list is required to ship a PWA; a hand-written manifest and a short service worker meet the Chromium installability criteria. The tools exist to generate those files from a build, to wrap the result in a store package, and to check the output.

Service worker libraries and build plugins

Section titled “Service worker libraries and build plugins”

Workbox is Google’s set of modules for routing and caching in a service worker, published as separate packages (workbox-window, workbox-streams, and workbox-range-request among them). The release in use when this page was checked is 7.4.1, published 2026-05-05; the 7.0.0 line raised the minimum to Node 16, and the 7.3 and 7.4 releases are described as dependency updates. Vite PWA (vite-plugin-pwa, 1.2.0, MIT) wraps Workbox for Vite projects: it injects the web app manifest, generates the service worker, reloads on new content, and ships integrations for SvelteKit, VitePress, Astro, Nuxt 3, Remix, and îles. The trade-off of a generated worker is that its precache list grows with every hashed asset, so a large build precaches files a user may not open.

Bubblewrap is the command-line generator for a Trusted Web Activity project; PWABuilder’s Android output is “powered by Bubblewrap and uses the same underlying core”. It requires Node.js 14.15.0 or later and JDK 17, and offers to download the JDK and Android command-line tools on first run. The commands that matter: init reads a web manifest and writes twa-manifest.json; build produces app-release-signed.apk and app-release-bundle.aab; update regenerates the Android project after a manifest edit; validate checks the PWA against the TWA quality criteria; fingerprint generateAssetLinks writes the assetlinks.json to host; doctor confirms the JDK and SDK paths and versions. The cost is a signing key you must keep for the life of the listing, because the asset-links fingerprint is derived from it.

PWABuilder is the route Microsoft documents. The flow, with the labels of its English UI: enter the URL under Ship your PWA to app stores and click Start; fix anything in the report card’s Action Items; click Package For Stores; under Windows click Generate Package; in Windows Package Options paste the Package ID, Publisher display name, and Publisher ID copied from Partner Center; click Download Package. The download is a .zip containing an .msixbundle and a .classic.appxbundle, both of which go into the Packages step of the Partner Center submission. A manifest change requires repeating the flow; a code change does not.

Lighthouse runs from the DevTools Lighthouse panel, from the CLI after npm install -g lighthouse, as a Node module in CI, or through PageSpeed Insights, and reports Performance, Accessibility, Best Practices, and SEO. It no longer audits installability: release 12.0.0 (2024-04-22) states “As per Chrome’s updated Installability Criteria, Lighthouse has removed the PWA category” and points to the DevTools PWA documentation instead, so the manifest and service worker checks live in DevTools > Application. Bubblewrap’s validate command is the remaining automated check that a PWA meets the Trusted Web Activity criteria.

Tool Role Version read Requirement
Workbox Service worker routing and caching 7.4.1 (2026-05-05) Node 16 or later for the build tooling
Vite PWA Manifest and worker generation at build time 1.2.0 Vite
Bubblewrap TWA project generator and signer CLI README, 2026-10 Node.js 14.15.0 or later, JDK 17
PWABuilder Store packages from a URL Web app, 2026-10 Partner Center identity values
Lighthouse Performance, accessibility, best-practice, SEO audits 12.0.0 removed the PWA category Chrome, or Node for the CLI

← Back to the Ecosystem overview.