Tooling and frameworks¶

PWA tooling automates the parts of a progressive web app that are tedious and easy to get wrong by hand. That means generating a revisioned precache manifest on every build, writing and bundling the service worker, producing dozens of icon and splash-screen sizes, and packaging the app for app stores. Almost every mainstream tool in 2026 is built on the same core: Workbox, or its fork Serwist. That shared ancestry is why their options, cache names and failure modes look so alike. This section documents the tools in depth. This page maps the landscape and helps you choose.

The PWA toolchain in layers¶

A PWA toolchain has six layers. Most projects use tools from three or four of them.

flowchart TD
    A["Service worker runtime: Workbox or Serwist libraries, or hand-written code"] --> B["Build integration: workbox-build / CLI / webpack plugin, vite-plugin-pwa, @serwist/*"]
    B --> C["Framework integration: @vite-pwa/nuxt, @vite-pwa/sveltekit, @serwist/next, @angular/service-worker"]
    D["Assets and manifest: @vite-pwa/assets-generator, pwa-asset-generator"] --> C
    C --> E["Deploy to the web (HTTPS)"]
    E --> F["Packaging and distribution: PWABuilder, Bubblewrap"]
    E --> G["Testing and auditing: DevTools, Playwright, Lighthouse"]

Versions at a glance¶

The versions below come from the npm registry on 25 September 2026. The dates are the publication dates of those versions.

Tooling versions change monthly. Check npm view <package> version before you copy a version range from any article, including this one.

Service worker libraries¶

You can write a service worker by hand. The service workers and caching sections of this site show exactly how. A library earns its place by handling the tedious edge cases correctly: revision-keyed precaching that only downloads changed files, cache: "reload" for unhashed URLs, copying redirected responses, opaque-response rules, LRU expiration metadata in IndexedDB, background-sync fallbacks, and lifecycle helpers for the page.

A realistic Workbox worker bundles to about 30 KB minified, or under 10 KB gzipped. Advanced Workbox lists measured sizes. That is small next to most apps, but it isn't nothing for a site that only needs an offline page. A 60-line hand-written worker is a perfectly professional choice for that case.

Build integrations¶

Every build integration does two jobs: it produces a precache manifest (a list of {url, revision} entries, where the revision is a content hash) and gets it into the worker, and it bundles the worker. The differences are in how much of the worker it writes for you:

• workbox-build / workbox-cli / workbox-webpack-plugin. generateSW writes the whole worker from configuration. injectManifest replaces self.__WB_MANIFEST in a worker you wrote. The CLI adds an interactive workbox wizard. Workbox fundamentals covers every option.
• vite-plugin-pwa. Wraps workbox-build's two modes (strategies: "generateSW" | "injectManifest") and adds what Vite users need: manifest generation and injection, a virtual registration module (virtual:pwa-register plus React, Vue, Svelte, Solid and Preact variants) with prompt or autoUpdate behavior, a development-mode service worker, and integration with @vite-pwa/assets-generator. See Vite PWA plugin.
• Serwist build packages. @serwist/build, @serwist/cli, @serwist/webpack-plugin and @serwist/vite all implement injectManifest with the self.__SW_MANIFEST injection point. Framework packages such as @serwist/next hide that step.

Whatever you use, the same few mistakes recur: precaching source maps or huge images, a navigation fallback without a denylist, skipWaiting in an SPA, and forgetting that the manifest only changes when content changes. Precaching and Updating service workers explain the mechanisms behind all four.

Framework integrations¶

Framework integrations has configuration, routing caveats (SSR navigation fallbacks, streaming, RSC payloads) and update handling for each.

Asset and manifest generators¶

The web app manifest and the platforms need many image variants: any and maskable icons at several sizes, an Apple touch icon, favicons, and on iOS a separate launch image for every device size and orientation. Two generators dominate:

• @vite-pwa/assets-generator is a "zero-config" CLI and library. From one SVG or PNG it produces icons, maskable icons, Apple touch icons, favicons and optionally Apple splash screens, according to presets such as minimal2023Preset. It uses sharp (libvips), so it's fast and has no browser dependency. Version 2.0.0 (September 2026) is ESM-only and requires Node.js 20.19+. vite-plugin-pwa can run it during the build and inject the resulting <link> tags and manifest icons.
• pwa-asset-generator renders its sources in headless Chrome through puppeteer-core. It can therefore take an HTML page or SVG with CSS as input and render splash screens with real layout. It can also rewrite your manifest.json and index.html with the generated entries. Version 8.x requires Node.js 22.12+.

Generated assets still need design review. The safe zone of a maskable icon is the central circle, with a radius of 40% of the icon size. See Icons and maskable icons and Splash screens and theming.

Packaging for app stores¶

A PWA doesn't need a store, but stores bring discoverability, and on some platforms installation habits. Two tools do the packaging:

• PWABuilder is an open-source project hosted by Microsoft. You enter the URL of a deployed PWA. It audits the manifest and service worker, then generates packages: an MSIX for the Microsoft Store, an Android App Bundle for Google Play (a Trusted Web Activity generated with Bubblewrap), and an Xcode project for the Apple App Store, which its documentation labels experimental (a native Swift app hosting the PWA in a WebView). Store developer accounts are separate. Microsoft's current Partner Center onboarding flow charges no registration fee for individual or company accounts, Google Play charges a one-time $25 registration fee, and PWABuilder's App Store documentation notes Apple's $99-per-year developer program. The project also maintains the PWABuilder Studio extension for VS Code and a pwa-starter template, and lists the <pwa-install> web component.
• Bubblewrap (@bubblewrap/cli, from Google Chrome Labs) is the command-line tool behind PWABuilder's Android packages. bubblewrap init --manifest=https://example.com/manifest.webmanifest generates an Android project from your manifest, and bubblewrap build produces a signed APK and App Bundle. You still have to publish /.well-known/assetlinks.json with your signing key's SHA-256 fingerprint. Without it the app shows a browser URL bar. See Trusted Web Activity.

Store packages load your live site, so a web deploy updates the app without a store resubmission. Changing the package itself (icons, name, signing key, Android API level) still requires one. Publishing to app stores covers review policies per store.

Testing and auditing tools¶

The PWA category was removed from Lighthouse 12.0. Its release notes cite Chrome's updated installability criteria and direct users to DevTools' PWA documentation instead. Installability and offline behavior are now best asserted in your own end-to-end tests: that the manifest is parsed, that beforeinstallprompt fires where it should, that the app shell loads offline, and that an update prompt appears after a deploy. See Automated testing and Lighthouse and auditing.

Choosing a toolchain¶

flowchart TD
    Q1{"Which framework?"}
    Q1 -->|"Next.js"| N["@serwist/next (or manual worker per Next.js guide)"]
    Q1 -->|"Angular"| A["ng add @angular/pwa"]
    Q1 -->|"Nuxt / SvelteKit / Astro / plain Vite"| V["vite-plugin-pwa or its framework package"]
    Q1 -->|"webpack app"| W["workbox-webpack-plugin (or @serwist/webpack-plugin)"]
    Q1 -->|"No bundler / static site generator"| S["workbox-cli generateSW, or a hand-written worker"]
    V --> Q2{"Need push, sync or custom routes?"}
    W --> Q2
    S --> Q2
    Q2 -->|"No"| G["generateSW-style configuration"]
    Q2 -->|"Yes"| I["injectManifest: write your own worker, let the tool inject the manifest"]

Some concrete guidance:

• Content sites and documentation. A hand-written worker or workbox-cli generateSW with network-first pages, a precached offline page and cache-first images. Precache very little, and let runtime caching do the rest.
• Single-page apps. vite-plugin-pwa or the webpack plugin, with a precached app shell, a navigateFallback with a strict denylist, and a prompt-to-update flow. Avoid skipWaiting without a prompt.
• Apps with push, background sync or complex offline data. injectManifest from day one. The worker becomes real application code, with tests and code review. Offline-first architecture covers the data side.
• Store distribution. Build a solid web PWA first, then add PWABuilder or Bubblewrap. Store packaging doesn't fix a weak PWA; reviewers reject thin wrappers.
• Long-lived codebases on Workbox. Staying on Workbox 7 is fine. Plan a Serwist migration only when you need its features or framework support. Advanced Workbox has the migration checklist, including the cache and IndexedDB renames that make it more than a find-and-replace.

Legacy and unmaintained tools¶

Old tutorials still recommend tools you should not adopt in 2026:

• sw-precache and sw-toolbox. Workbox's predecessors, deprecated since Workbox's release in 2017.
• next-pwa (last published August 2022) and @ducanh2912/next-pwa (last published September 2024; its README recommends migrating to @serwist/next).
• @nuxtjs/pwa (last published January 2021, for Nuxt 2). Use @vite-pwa/nuxt.
• @pwabuilder/pwainstall (last published 2020). The maintained successor listed by PWABuilder is @khmyznikov/pwa-install.
• Lighthouse "PWA" badges and scores. They no longer exist; don't gate CI on them.
• workbox-sw from the Google CDN in new projects. It still works for classic workers, but a bundled worker avoids the third-party request and the lazy-loading pitfalls. See Workbox fundamentals.

Pages in this section¶

Further reading¶

On this site

• Workbox fundamentals
• Advanced Workbox
• Vite PWA plugin
• Framework integrations
• PWABuilder
• Precaching and runtime caching
• Trusted Web Activity
• Production checklist

External references

• Workbox documentation
• Serwist documentation
• Vite PWA documentation
• PWABuilder documentation
• Opening a Microsoft Store developer account (Microsoft Learn)
• Bubblewrap on GitHub
• pwa-asset-generator on GitHub
• Angular service workers guide
• SvelteKit service workers
• Next.js PWA guide
• Playwright: service workers