1. Introduction
Websites have been installable on various platforms for well over a decade. When installed, a website is added to the home screen, taskbar, dock, or launcher of the operating system, and registered with it. When launched, it can appear as a standalone application: in its own window, full-screen, or whichever presentation is customary on the operating system.
From the user’s perspective, the process of installing a website works very differently depending on the browser used, and might not be obvious at all. Website authors report that they resort to native apps instead, and regularly ask for programmatic APIs that let them trigger install prompts themselves.
This finding is intended to guide user agent and operating system vendors.
Note: This finding focuses on same-origin installs. Cross-origin installs are currently not widely implemented across the platform. This topic might be revisited in a future version of this finding.
2. Installation is a core capability of browsers
Installable websites date back to at least 2008 (see Use Cases and Requirements for Installable Web Apps § introduction). By now, the installation of websites is possible on all relevant engines and operating systems. The Web Application Manifest (see [APPMANIFEST]), developed since 2013, allows website authors to specify metadata for installable web applications.
Installed websites fulfill a user need that otherwise can only be addressed by native apps: a persistent presence on the device, and launching from the same place as other applications. Unlike native apps, they do so while staying within the web’s security and privacy model, including its permission model and sandbox.
Given well over a decade of implementation experience and standardization, we declare the installation of websites a core capability of general-purpose browsers, and we expect them to offer it.
NOTE: This expectation does not extend to specialized user agents, such as text-mode browsers, kiosks, or web views embedded in applications, although they may still choose to offer installation.
3. Expectations on user agent and operating system providers
In this section, we set out our expectations on user agent and operating system vendors.
3.1. Obvious Install UI
We expect user agents to make installation an obvious affordance to users. Specifically, we expect the install option to clearly name the action, and to be easily reachable from the browser’s UI. An entry inside a menu with an unrelated label (such as Share), or several menu layers deep, does not meet this expectation. We also expect users to be informed about what happens when they decide to install a website. The exact UI is left to user agents.
A stable and obvious affordance also benefits website authors. They have repeatedly reported that updating their install instructions after a new browser or operating system release is tedious.
4. The role of programmatic install APIs
Users often do not know that their browser can install websites, and browsers often do not know the appropriate time to inform them (see [CHROME-INSTALL-TELEMETRY]). Websites have more information about whether visitors are likely to want to install the site and when a good time is to educate those visitors. However, websites also have incentives to nag users.
Website authors repeatedly ask for an API that lets them trigger the browser’s install flow themselves.
Chromium-based browsers have exposed such an API since 2015, the beforeinstallprompt event (see [MANIFEST-INCUBATIONS]).
Its design stems from a time when browsers prompted users spontaneously, and when installation was subject to meeting certain criteria, such as the presence of a service worker.
Since then, browsers have found that users do not want these spontaneous prompts, and only show them after the website has asked for them.
The Web Applications Working Group has found consensus that installation should not depend on install criteria, but that any website is an installable web application.
What remains is a browser-sent event that provides a handle to trigger the install prompt, which is a rather unusual design.
The TAG has reviewed several proposals for new programmatic install APIs, both same-origin and cross-origin, most recently the manifest-first Web Install API. We encourage vendors to explore same-origin programmatic install APIs, as long as they trigger the user agent’s own install flow, with the user agent retaining control over timing, eligibility, and abuse mitigation. Providing such an API does not relieve a user agent from following the expectations in § 3.1 Obvious Install UI.