pwa-install 0.7.0 adds Web Install API support

The khmyznikov/pwa-install project published release v0.7.0 on 2026-09-14, and the first item under its own Highlights heading is Web Install API support for Chromium 155 and later, with a safe fallback to beforeinstallprompt. In this drop-in install dialog a second, promise-based install entry point therefore coexists with the event-based one developers have targeted until now (the v0.7.0 release notes).

The rest of the notes cover in-app browser detection, guided installation flows for Apple and Android devices, per-browser installation instructions, Android fallback detection, and build changes. Each group of changes is taken below in the wording the release notes and the Web Install API explainer use (the v0.7.0 release notes).

What the release notes list

The notes are organised under three headings of their own: Highlights, Browser Compatibility and Fixes, and Events and Developer Experience. They also record a new contributor, @joeblew999, whose first contribution the notes attribute to pull request 170, and they link a full changelog comparing v0.6.4 with v0.7.0 (the v0.7.0 release notes).

The Web Install API entry point

The first Highlights bullet states that the release adds Web Install API support for Chromium 155+, including manifest-id, current-document and cross-app installation, improved availability detection, detailed failure reporting, and safe fallback to beforeinstallprompt, and attributes it to pull request 168. The explainer defines the two call shapes as navigator.install() and navigator.install({ manifest, manifestId }); the dictionary form enables cross-app installation (the Web Install API explainer).

The Events and Developer Experience group makes that dual path observable from application code. The notes state that the release adds a pwa-install-backend-event to report whether installation uses the Web Install API or beforeinstallprompt, including the fallback reason, and that it exposes isWebInstallSupported and expands install failure event details with backend, error, and fallback information (the v0.7.0 release notes).

In-app browsers and Apple devices

The second and third Highlights bullets are about surfaces where the install flow is a sequence of instructions. The notes state that the release adds in-app browser detection and guided installation flows for Apple and Android devices, including copying or opening the app link in Safari, with updated demo coverage; and that it adds native-look compatibility for iOS, iPadOS, and macOS 27+, with updated Aqua styling, blur effects, icons, and installation instructions. The fourth adds a Thai th locale, attributed to pull request 170 (the v0.7.0 release notes).

Under Browser Compatibility and Fixes the notes state that the release adds and refines installation instructions for Yandex Browser, Microsoft Edge, Opera, and Firefox on Apple devices; fixes iOS webviews without Service Worker support being incorrectly treated as non-Apple browsers, referencing issue 161; fixes the Apple mobile dialog layout in landscape orientation; and improves Android fallback detection when a native install prompt is unavailable (the v0.7.0 release notes).

That last pair of items is where a component like this earns its keep, because the browser-specific split is documented. MDN states that on Android the only browsers that install PWAs as WebAPKs are Chrome on devices with Google Mobile Services and Samsung Internet on Samsung devices, while Firefox, Edge, Opera, and other browsers add a browser-badged home-screen shortcut instead. On Apple platforms it states that on iOS 16.3 and earlier PWAs can only be installed with Safari, and that on iOS 16.4 and later they can be installed from the Share menu in Safari, Chrome, Edge, Firefox, and Orion (MDN, Making PWAs installable).

Events, declarations, and build changes

The remaining Developer Experience items are packaging rather than behaviour. The notes state that the release refactors installation logic and improves generated TypeScript declarations and custom-element metadata; adds build-time type checking and declaration generation, switches TypeScript transpilation to esbuild, and explicitly targets ES2021; and refreshes dependencies, generated bundles, localization catalogs, documentation, screenshots, demo manifest, and PWA resources (the v0.7.0 release notes).

What the Web Install API specifies

The feature the release names is specified in the Web Install API explainer, whose status section gives the document as Active with an expected venue of the WebApps WG. The explainer defines navigator.install() as the JavaScript entry point and states that it also defines the shared install algorithm used by every entry point, covering manifest fetching, parsing and validation, user activation, sandbox and cross-origin gates, the consent UI contract, and the error taxonomy returned to callers (Web Install API explainer).

Both call shapes the release notes mention appear there. The explainer states that a developer calls navigator.install({ manifest: <url> [, manifestId: <url>] }), that the developer may omit manifestId if and only if the JSON at manifest contains an id, and that the dictionary object may be omitted entirely, in which case the manifest of the loaded page is targeted for install. Among its goals it states that the API extends the functionality of beforeinstallprompt, which cannot install content other than the current loaded web application (Web Install API explainer).

The explainer’s error list is the detail behind the release notes’ “detailed failure reporting”. It states that the promise resolves if the installation was completed, and rejects with a DOMException of AbortError when the user aborted the installation flow, or DataError when there was a problem with the data provided, listing an invalid manifest URL, failure to fetch the manifest, a malformed manifest file, omitting manifestId when none is declared in the manifest, and providing a manifestId that does not match the one computed by the browser. Its step lists add that a call without transient user activation rejects with NotAllowedError, and that a sandboxed frame or cross-origin subframe rejects with InvalidStateError (Web Install API explainer).

One of those conditions has a measured cost attached. The explainer states that according to the manifest specification, if there is no id member present the computed string resolves to that of the start_url, and it states that only around 4% of web apps, as of 2024, have defined ids in their manifest. It also states that for apps which do not define id, the API caller must include the expected computed id, and that this computed id is accessible in the Application tab of developer tools in Chromium-based browsers (Web Install API explainer).

Why it matters for PWA developers

The practical consequence is that an install button now has two possible backends with different failure semantics, and the release notes’ pwa-install-backend-event exists to say which one ran. MDN describes the older path as event-driven and unscheduled: the beforeinstallprompt event fires when the browser has detected that a website can be installed as a Progressive Web App, there is no guaranteed time at which it fires though it usually happens on page load. An in-page install button built on that event is therefore only as available as the event is (MDN, beforeinstallprompt event).

The promise-based path inverts that relationship, which is why the explainer’s gates matter more than its happy path. It states that a call without transient user activation rejects with NotAllowedError and that user consent is always required, listing silent or unattended installation among its non-goals. A button wired to navigator.install() can be called when the developer chooses rather than when an event arrives, but only from a real user gesture, and only in a frame that is neither sandboxed nor a cross-origin subframe (Web Install API explainer).

The manifest id requirement is the part most likely to surprise an existing codebase. The explainer states that omitting manifestId is permitted only when the manifest itself contains an id, and that a mismatch between a supplied manifestId and the browser’s computed id rejects with DataError. It also states that only around 4% of web apps, as of 2024, have defined ids in their manifest, and that for apps which do not define id the API caller must include the expected computed id (Web Install API explainer).

On iOS, MDN states that the beforeinstallprompt technique is not supported, and that the installation paths it lists there are Safari on iOS 16.3 and earlier or the Share menu in several browsers on iOS 16.4 and later (MDN, Making PWAs installable). The release notes list guided installation flows for Apple devices and refined per-browser installation instructions among the changes (the v0.7.0 release notes).

Related entries on this site

• Workbox: follow this cross-reference for separate background on service-worker build tooling.
• Debugging service workers: the release fixes iOS webviews without Service Worker support being treated as non-Apple browsers, and the explainer states that a manifest’s computed id is readable in the Application tab of Chromium developer tools; follow this cross-reference alongside both.
• Lighthouse and the removed PWA category: follow this cross-reference for separate background on PWA auditing.

Open and unverified

• Whether Chromium 155 ships the Web Install API enabled by default is not confirmed.
• Whether the version of the API the release implements matches the explainer’s current navigator.install() signature, including the manifestId member spelled manifest-id in the release notes, is not confirmed.
• What the fallback reason values carried by pwa-install-backend-event are, and whether they are enumerated anywhere, is not confirmed.
• Whether “macOS 27+” in the native-look bullet qualifies only macOS or also the iOS and iPadOS versions listed alongside it is not confirmed.
• Which iOS or webview versions were affected by the Service Worker detection bug referenced as issue 161, and which Apple device sizes the landscape layout fix covers, are not confirmed.
• Whether the Web Install API’s consent UI appears on the platforms where the component falls back to instructions is not confirmed.

Sources

• pwa-install v0.7.0 (github.com)
• Web Install API explainer (github.com)
• Window: beforeinstallprompt event (developer.mozilla.org)
• Making PWAs installable (developer.mozilla.org)