Under the Share Sheet

On an iPhone, turning a website into an app begins by tapping Share.

Apple's current instructions continue from there: find Add to Home Screen, turn on Open as Web App, then tap Add. If the home-screen action is missing, scroll to the bottom, open Edit Actions, and add it first.

The directions are accurate. They are also a small tour of how thoroughly a browser can hide a capability while still claiming to support it.

Chrome on a computer takes another route. Its help page sends a person through More, then Cast, save and share, then Install page as app. Some sites receive an install icon in the address bar, but the ordinary fallback remains a menu whose name asks the person to understand installation as a kind of saving.

None of these words is absurd on its own. A home-screen app begins as a website somebody wants to keep. The difficulty appears when a person has to arrive already knowing that share or save is the entrance to install.

The W3C Technical Architecture Group has now made that mismatch unusually explicit. Its October finding, Installing Websites Must Be Easy, calls installation a core browser capability and asks browsers to give it a stable, obvious affordance. The document specifically says that an install action buried under an unrelated label such as Share, or several menu layers deep, is not enough.

This is more consequential than rearranging one menu item. Installation gives a website a persistent place in the operating system: an icon on the home screen, dock, taskbar, or launcher, and sometimes its own window. A web app manifest can describe the name, icon, starting page, and display mode. The site still runs inside the web's permission model and sandbox, and it can remain an ordinary website for anyone who never installs it.

That combination is peculiar and useful. A person can encounter a tool through a link, try it without a store visit, and later decide that it deserves a place beside other applications. The durable presence is optional. The web version remains the fallback rather than a preview for the real product.

The browser and the website still disagree about who should issue the invitation.

Chromium exposes a beforeinstallprompt event that lets a site show its own install button and then open browser-controlled confirmation. The event is not supported on iOS. Chrome shared Android flow data with the TAG showing that 70% of installations began in page-supplied UI, 20% through browser promotion guided by machine learning, and only 10% through the browser menu. Once somebody deliberately opened the menu flow, 93% finished it. The figures come from one browser team and its implementation is changing, but the shape is useful: menu installation attracts strong intent while remaining difficult to discover.

An in-page button can explain why installation would help at the moment the value becomes clear. A writing tool can offer it after the first document is saved. A field guide can mention offline use after somebody has chosen a route. The browser can still own the final confirmation and show which site will receive a permanent place on the device.

The same button can become another request to dismiss before reaching the work.

WebKit's standards-position discussion records the resistant case. When a site initiates the request, installation becomes a weaker signal of intent: people may tap through from habit, and sites have every incentive to ask early. Browser chrome is harder for a page to imitate and gives the decision a place outside the site's persuasion. WebKit currently opposes the Chromium event, citing annoyance, usability, complexity, and the risk of weakening deliberate choice.

Both positions are trying to protect something real. The site knows when installation might become useful. The browser is in a better position to make the invitation trustworthy, consistent, and dismissible. Leaving the action hidden protects people from nagging partly by ensuring that many never discover the choice. Giving every site a prompt solves discoverability partly by creating another prompt economy.

The TAG's stronger recommendation is therefore the quieter one: browsers should make their own install affordance obvious even if they also allow carefully bounded programmatic flows. Operating systems should let third-party browsers install websites through the same mechanisms as the default browser, and an installed site should reopen in the browser the person chose. Installation should not become a tollgate for ordinary web capabilities.

Those details make the icon on the home screen a record of several choices. The person chose to keep the site. The browser vouched for what the action meant. The operating system respected the browser behind it. The website remained useful before and after the decision.

The next time a product team writes a three-screen tutorial explaining where another company's browser has hidden Add to Home Screen, there is a simpler interface to ask for. Put Install somewhere a person can see it. Let the browser explain what will happen. Then leave the website working for everyone who says no.