# The N+1 install problem

> Why an installed web app belongs to the browser that installed it, so one site can exist as several independent, data-isolated installs on one device, which platforms deduplicate and which do not, and what a page can and cannot detect about it.

The N+1 install problem is the consequence of web app installation being an action of a browser rather than of the operating system: each browser that installs a site produces its own app, with its own storage and its own knowledge of the installed state, so a device can hold N browsers' copies plus one more from the next browser the user tries. Chromium browsers (Chrome 73, Edge 79), Safari on iOS 16.4 and macOS 14, and Firefox 143 on Windows each own their installs this way (MDN "Installing and uninstalling web apps", web.dev "Installation").

## How it works

An installed web app runs inside the browser that created it. Chrome's desktop app window is a Chrome process reading Chrome's profile storage; Edge's is an Edge process reading Edge's; a Safari Home Screen web app on iOS uses its own data store separate from Safari tabs. Three consequences follow, each documented by MDN and web.dev:

1. **Installed state is private to the installing browser.** Edge knows a site is installed from Edge and offers "Open" when the site is visited again; Chrome, visiting the same site, offers "Install" because it has no record of the Edge app. Installing from Chrome as well yields two apps on the device.
2. **Storage is per install.** Cache Storage, IndexedDB, cookies, and `localStorage` live in the installing browser's profile (or, on iOS, in the web app's own container), so a user signed in to the Edge copy is signed out in the Chrome copy, and offline data cached by one is absent from the other.
3. **Uninstall is per install.** Removing the Edge copy from `edge://apps` leaves the Chrome copy in `chrome://apps`, and vice versa.

Within one browser the behaviour depends on the platform:

| Platform | Second install of the same site from the same browser | Identity key |
|---|---|---|
| Chrome and Edge, desktop (Windows, macOS, Linux, ChromeOS) | Refused; the install surface disappears and the browser offers to open the existing app | Manifest `id`, falling back to `start_url` |
| Chrome, Android (WebAPK) | Refused; one WebAPK per manifest `id` per browser | Manifest `id` |
| Chrome, Android (shortcut fallback when the WebAPK server is unreachable) | Allowed; each shortcut points to the same browser storage | Shortcut only |
| Safari, iOS and iPadOS | Allowed, by design, with the user-chosen name distinguishing copies; each copy has isolated storage | Manifest `id` plus the name typed when adding |
| Safari, macOS 14+ | Allowed; a second "Add to Dock" creates a second web app | Name typed when adding |

The manifest `id` member is what lets a browser recognise a site it has already installed even after `start_url` changes; without it the identity is the `start_url`, and changing that URL turns an update into a new app on Chromium. On iOS the same `id` is deliberately not a deduplication key: WebKit documents multiple installs (work and personal accounts) as a feature and uses `id` together with the user's name for the app to keep Focus and notification settings separate per copy.

A page cannot query the other browsers' installs. `getInstalledRelatedApps()` reports an installed PWA only when the manifest lists it under `related_applications` and only from the same browser, and `display-mode: standalone` says only that this copy is running installed. The design choice for a site is therefore whether to make duplication cheap (stateless pages, account sign-in that restores data on any copy) or to steer users to one browser with explicit copy, accepting that the page has no way to enforce the steering.

## Observed behaviour

The following are reproducible on a single machine with two Chromium browsers installed and on an iPhone.

:::observed
On Windows 11 with Chrome and Edge (English UI), installing the same site from both browsers produces two entries in Settings › Apps › Installed apps whose names are identical except for the publisher shown as "Google Chrome" and "Microsoft Edge", and two separate app windows that do not share sign-in state; `chrome://apps` lists only the Chrome copy and `edge://apps` only the Edge copy. On an iPhone running iOS 16.4 or later (English UI), adding the same site twice from the Share sheet with different names yields two Home Screen icons, each of which prompts for sign-in independently, matching WebKit's description of per-install storage for Home Screen web apps.
:::

Re-adding a site on iOS without changing the name still creates a second icon; the system does not merge them. On Chrome desktop, by contrast, visiting an installed site no longer shows the install icon in the address bar, and the three-dot menu item changes from "Install [app name]…" to "Open in [app name]".

## See also

- [Installing and uninstalling web apps](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Installing) (developer.mozilla.org)
- [Web Push for Web Apps on iOS and iPadOS](https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/) (webkit.org)
- [Web Application Manifest: id member](https://www.w3.org/TR/appmanifest/#id-member) (w3.org)
- [`id` manifest member](/reference/manifest/id/)
- [getInstalledRelatedApps()](/reference/installation/get-installed-related-apps/)
- [Uninstalling an installed PWA](/reference/installation/uninstall-retention/)
- [iOS Add to Home Screen](/reference/installation/ios-add-to-home-screen/)