# Tools

> The service worker libraries, store packagers, and audit tools a PWA build relies on, with versions, requirements, and commands read from their docs in 2026-10.

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.

## How it works

Nothing on this list is required to ship a PWA; a hand-written manifest and a short
service worker meet the Chromium [installability criteria](/compatibility/install-prompt/). 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

[Workbox](https://developer.chrome.com/docs/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](https://vite-pwa-org.netlify.app/)
(`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.

### Packaging for Google Play

[Bubblewrap](https://github.com/GoogleChromeLabs/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.

### Packaging for the Microsoft Store

[PWABuilder](https://www.pwabuilder.com/) 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.

### Auditing

[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) 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 |

## Observed behaviour

:::observed
When the PWABuilder report card passes, clicking **Package For Stores** opens a dialog that
reads "Awesome! Your PWA is store ready!" (English UI); the Windows download that follows is a
`.zip` whose two files are named an `.msixbundle` and a `.classic.appxbundle`, and Partner
Center's **Packages** step accepts both in one submission (Microsoft Learn, "Publish a PWA to
the Microsoft Store", updated 2026-09-02).
:::

## See also

- [Workbox](https://developer.chrome.com/docs/workbox) (developer.chrome.com)
- [Bubblewrap CLI](https://github.com/GoogleChromeLabs/bubblewrap/blob/main/packages/cli/README.md) (github.com)
- [Lighthouse v12.0.0 release notes](https://github.com/GoogleChrome/lighthouse/releases/tag/v12.0.0) (github.com)
- [Distribution](/ecosystem/distribution/)
- [Store policy](/ecosystem/stores/)
- [Service worker reference](/reference/service-worker/)
- [Caching strategies](/guides/offline/caching-strategies/)

← Back to the [Ecosystem](/ecosystem/) overview.