How Installable Progressive Web Apps Work

What does “installable” mean?

It means the browser can hand the application to the operating system as something the user launches directly: an icon in the launcher, dock or home screen, opening in its own window rather than a browser tab. The application itself is unchanged. What changes is the entry point and the framing around it.

A PWA still starts with a URL

This is the property most worth protecting. The product is delivered over the web, reachable by anyone with a link, and shareable by email, message or search result. Someone can use it fully without ever installing it, and installation becomes an option for the people who return often enough to want it.

That ordering matters commercially. A native app asks for commitment before first use. A web application earns the commitment afterwards.

What makes a PWA installable?

• A web app manifest — a small file declaring the app name, icons, theme colours, start URL and how the app should be displayed when launched.
• Secure delivery over HTTPS, which current platforms treat as a precondition.
• Sensible application metadata: an icon set that renders well at small sizes, a launch target that makes sense as a starting screen, and a name that reads correctly under an icon.
• A service worker in most implementations — required where caching, offline behaviour or push messaging are involved, and expected by some browsers as part of their install criteria.
• The browser's own installability criteria, which differ between browsers and change between versions.

That last point is the one to plan around. Because the criteria are set by browser vendors rather than by you, the correct posture is to meet them and treat installation as an enhancement — never as the only way in.

What happens after installation?

• An icon appears on the home screen, desktop, dock or application launcher, alongside other apps.
• Launching it opens a standalone window using the display mode declared in the manifest, typically without an address bar.
• The application shell and cached assets load quickly, because they are already on the device.
• Session state and stored data persist between launches in the same way as in the browser.
• The app can usually be found through the platform's own app search or task switcher.

How installation works on desktop

On Chromium-based desktop browsers, an install control generally appears in the address bar or the browser menu once criteria are met. The installed app receives a shortcut and appears in the taskbar, dock or launcher, and can typically be opened, pinned and closed like any other desktop application. Support in other desktop browsers varies and is worth checking against the browsers your users actually run.

How installation works on Android

On Android, Chromium-based browsers commonly surface an install prompt or an install option in the menu. The installed app appears in the app drawer and behaves like other installed applications in the task switcher. Because the prompting behaviour is controlled by the browser and has changed over time, the in-app path to installation should be explicit rather than dependent on a banner appearing.

How installation works on iPhone and iPad

On iOS and iPadOS, installation is a manual step in Safari: Share, then Add to Home Screen. There is generally no automatic prompt, so products that want installation on Apple devices usually need a short in-app instruction. The capabilities available to an installed web app on these platforms have historically differed from Android, so anything your product depends on — notifications, storage behaviour, background activity — should be verified against current support rather than assumed.

Does a PWA need an app store?

No. The browser and operating system handle installation directly, which removes submission, review queues and per-platform release management from the delivery path. Store distribution remains available as a separate choice — either through routes that accept web applications or by wrapping the app in a native container — but store policies vary and change, so treat it as a decision to verify at the time, not a settled property.

Updating an installed PWA

This is where the delivery model differs most from a traditional app release. You deploy to the web, and users get the new version on a subsequent load — no store review, no version fragmentation across a long tail of users who never updated.

The nuance is caching. Where a service worker caches the application shell, its update strategy decides whether a new version activates immediately, on the next launch, or after a prompt. That is a deliberate design decision, and getting it wrong is the usual cause of an installed app that appears stuck on an old version.

What installation does not automatically provide

• Unlimited device access — the app still operates within what the web platform exposes on that operating system.
• Full offline operation — only what has been deliberately cached is available without a connection.
• Identical native capability — background execution, sensor access and system integration remain more limited than in a native build.
• Unrestricted background processing — platforms constrain what any web application can do while it is not in use.
• Automatic discovery — being installable does not create demand; people still have to find the product first.

If the open question is whether installability is enough for your product, PWA vs native app works through the trade-offs, and PWA SEO covers the discovery side. We design and build installable products under application and PWA development.