On November 17, Chrome gets a real "install this app" button. Use it instead of your homemade banner

The argument

If your business has a web app that customers or staff use every day, a booking tool, a portal, an ordering app, you have probably been through the "should we build a native app?" conversation. One of the reasons people give for building native is that web apps are awkward to install. The browser's install prompt shows up when it decides to, teams write custom banners to coax it out, and most people never find the option in the menu.

Chrome 158 changes part of that. Scheduled for stable release on November 17, 2026, it adds a way for a web page to ask the browser, directly, to install a web app. Our argument is simple: if you have a web app, plan now to use the new install button in Chrome, retire the homemade prompt logic where you can, and revisit the install question in your next "native or web?" decision with this on the table.

What Chrome is adding

The release notes describe two entry points to the same capability:

• The Web Install API. A page calls navigator.install() with a manifest URL and an optional manifest ID, and Chrome asks the user whether to install that web app.
• The install element. The same thing, declared in HTML, with no JavaScript needed.

Two details matter. First, the app being installed doesn't have to be the page you're on. Chrome says this enables cross-origin installation. Your marketing site at one address can offer to install the app that lives at another. Second, Chrome describes it as a better developer experience than handling beforeinstallprompt, the event that teams have been catching and stashing to build their own install buttons.

The install button stops being a trick you pull off and becomes a link you place.

Why it matters for the business, not just the developers

Install matters because an installed app gets its own window, its own icon, and a spot where people look for it every morning. For a staff tool, that's the difference between "open Chrome, find the bookmark" and "click the icon." For a customer app, it's the difference between a tab that gets closed and an icon on the dock.

The cross-origin part is the bigger deal for many businesses. Plenty of companies run their public site on one platform and their app on another. Until now, the place where people learn about the app couldn't easily offer to install it. Now an "install the app" button can sit on the pricing page, the help center, or a welcome email's landing page.

It also changes the trade-off in the native-or-web conversation. Native apps still have advantages: app store presence, some device features, and the habits of people who look for apps in a store. But if "people can't install it properly" was one of the reasons on the list, that reason just got weaker in Chrome.

Picture a regional cleaning company with a scheduling app its crews use on shared laptops in the office. Today, each new hire gets a sticky note with a web address. With the install element, the onboarding page they already open on day one can carry a single button that puts the app in the taskbar. It's a small thing. Small things are what decide whether people use the tool you paid for, or text the office manager instead.

What it doesn't solve

Be careful not to overreach.

• This is a Chrome release. The release notes don't speak for other browsers. Keep a fallback: a short instruction or your existing prompt for browsers that don't support the element.
• The user still decides. It's a request, not an install. The button has to sit somewhere the user expects it, with a reason to click.
• Your app still has to be installable. A valid manifest, sensible icons, and a start URL that doesn't dump people on a login loop.
• IT departments may turn it off. Chrome gives administrators two controls: an enterprise policy, WebAppInstallByUserEnabled, that can disable user installs broadly, including those started through the new button, and a permissions policy, web-app-installation, to allow or block the feature on origins they control. If you sell a web app into companies, ask your larger customers how they manage installs before you design onboarding around this.

There's also a judgment call about restraint. An install button on every page quickly becomes another banner people learn to ignore. Put it where someone has just shown they'll be back: after the second visit, after sign-up, after they saved their first piece of work. Asking at the moment the app has proved useful is more respectful, and it tends to work better.

What to do before November 17

1. Find your install logic. Most teams have a beforeinstallprompt handler somewhere, often written once and forgotten. Know where it is.
2. Pick the places the button belongs. The welcome screen after sign-up, the help article about "using the app on your desktop," the marketing page about the app.
3. Test on Chrome Beta. Chrome 158 is on the Beta channel now. Try the element with your real manifest and see what the prompt looks like to a user.
4. Keep the fallback. Detect support and show the old path where the new one isn't available.
5. Check with your IT-managed customers. If installs are blocked by policy, the button won't help them, and your onboarding should say what to do instead.
6. Measure installs, not clicks. Decide how you'll know the button worked before you ship it.

None of this needs a big project. For most teams it's a few days of work and one design review. The bigger opportunity is the conversation it reopens about where your app lives and how people reach it. Write down what you decide, so the next person who asks "why don't we have an app?" gets a real answer.

Where we come in

If you're weighing a web app against a native one, or your current app is a website that people keep forgetting to open, our web applications team can help you decide and build it. Get in touch and tell us where your customers first hear about your app.

Related work: Paddle8.