Web Install API in Edge 148 — one site installs another as a PWA
Microsoft Edge 148 shipped the Web Install API. Now one site can prompt the user to install a different site as a PWA. What it does, who needs it, and where the traps are.
Microsoft shipped Edge 148 in May. One of the new platform pieces is the Web Install API. The idea is simple: site A can prompt the user to install site B as a PWA. Until now, you could only trigger PWA install from the same origin that was being installed. Not anymore.
Sounds small. It changes the logic of how web apps get distributed. Let me walk through it.
What it actually does
The API is navigator.install() and takes the URL of the app to install. The call brings up a native browser dialog — the user sees which site is being installed and either accepts or declines. The full call:
const result = await navigator.install('https://app.example.com/');
if (result.installed) {
// user installed
}
Three conditions are required:
- HTTPS on the initiating origin
- A user gesture — you cannot call this from arbitrary code, a click or tap is mandatory
- The target site must have a valid manifest.json and service worker, same as any PWA
Why anyone would want this
A few obvious scenarios:
- App marketplaces and directories — list PWAs and install each one right from the listing, no redirect to a separate site
- B2B product promo — a corporate portal shows recommended tools as cards and installs each with one click
- Cross-promo between products — if you have several related services, you no longer shuttle the user across domains. Install the rest from the main one
- Education platforms — a course offers to install a bundle of tools needed for it, one click
Where the traps are
The main risk is phishing. If site A installs site B, the user may miss the difference. The installed PWA icon lands on the desktop with a name controlled by site B. Faking a "Yandex Mail" icon that leads to a spoof page is easier than before.
Microsoft partly covered this with a confirmation dialog that shows the URL being installed. We all know how users read dialogs. They do not.
Second risk is abuse via iframes and redirects. The spec is not fully clear about what counts as the initiating origin when the call comes from an iframe on a third domain. On the Edge beta channel researchers already found a way to trigger install from a domain the user never saw in the address bar. Microsoft promised a fix in Edge 149.
Worth wiring up right now
Chrome and Safari do not have the API yet — Microsoft is solo for now. Chromium 130 has it behind a flag, Firefox is not even on the roadmap. From our logs, Edge sits at 9-12% on desktop in Russia, less on mobile. For most projects this is not enough scale to build new logic around.
A few exceptions:
- If you already run a PWA and have adjacent products, adding a
navigator.install()call on a promo page is an hour of work. Edge users gain convenience, everyone else loses nothing - Corporate internal portals where Edge is mandated by policy — perfect case, ship it now
- Educational products with a Windows-laptop audience — there is a real chance to catch users here
What to do today
If your app is already a PWA, add feature detection and an optional install CTA that calls the API on your main promo pages. When Chrome catches up (rumours point at the December release), the code is already there. You just drop the Edge-only flag.
If the app is not a PWA yet, spend the week on a manifest, a service worker, and decent offline. The Web Install API will not help you without that, and you raise baseline quality along the way.