Chrome app mode: three routes, and how to tell them apart

Chrome app mode is not one feature. The phrase covers a menu command that produces an application bundle, a launch flag that produces a window and nothing else, and a third menu command that used to produce the first thing and now produces a bookmark. All three end in a window without tabs, which is why instructions written for one of them appear to work for the others until something has to be changed later. Knowing which route was taken determines where the thing lives, whether it can be uninstalled, and whether it survives the browser's next update.

Route one: the menu command that installs

The current path is More, then Cast, save, and share, then Install page as app. On sites that qualify, an install icon also appears at the right hand end of the address bar and does the same job in one click.

What this produces is a real application bundle. On a Mac it is filed in a Chrome Apps folder inside the Applications folder of the user's home directory, which is a different place from the system wide Applications folder at the root of the disk. That distinction is useful later: everything in the home folder version arrived from a browser rather than from a download.

The browser keeps its own register of these at chrome://apps. That page lists installed apps and nothing else, so it answers the question of which route was taken months ago in a single look. Right clicking an entry there offers Create shortcut, which places a launcher on the desktop, and an option to start the app when signing in to the computer.

Uninstalling has a matching path. Opening the app and choosing Uninstall from its own menu removes it, with a separate checkbox to also delete the data the site stored in Chrome.

The important property of this route is that the app belongs to the Chrome profile it was installed from. It is not a free standing program that happens to open a URL. It is an entry in that profile's list of installed apps, wearing an application bundle as a launcher.

Route two: the launch flag

The second route uses a command line switch. Passing --app= with a URL opens that page in a window with no tab strip and no address bar. It is the oldest form of app mode and the one most blog posts mean when they use the phrase.

On macOS the command has a detail that catches people. Applications are bundles, not executables with arguments, so the flag has to be handed over at launch, and when Chrome is already running a plain launch will be absorbed by the existing process and the flag ignored. The launch has to be told to start a new instance:

open -na "Google Chrome" --args --app=https://example.com

Two things are true about this route that are easy to miss. It creates nothing. There is no entry in chrome://apps, no bundle in the home Applications folder, nothing to uninstall, and nothing that appears if the same question is asked from a different Mac. And it is a command line switch rather than a documented product feature, which puts it in a different category from the menu command when it comes to expecting it to behave the same way in two years.

For a one off, or for a script that opens a dashboard on a shared display each morning, this is the right tool precisely because it leaves nothing behind. For something used daily, the lack of a durable object becomes the problem.

The flag also decides nothing about which account is signed in, which trips people up on machines with several profiles. A launch that does not name a profile uses whichever one the browser considers current, so the window can open signed into the wrong account depending on what was open beforehand. Naming the profile directory in the same command removes that ambiguity, and it is the difference between a launcher that behaves identically every morning and one that behaves differently depending on yesterday.

One more thing follows from the flag being part of Chromium rather than Chrome. Browsers built on the same base accept it too, so the same command works with a different application name in front of it. That is convenient, and it is also the reason instructions found online sometimes fail in a way that looks like a Chrome problem: the command was written for a different Chromium browser and the application name was never changed.

Route three: the command that changed meaning

The third route is the source of most confusion, and it is a genuine change rather than a misunderstanding.

From Chrome 128, Create Shortcut creates a bookmark that launches a specific page in a new tab, matching the behaviour the same wording has always had on Android. The previous desktop behaviour of that menu item moved to Install page as app.

Anyone following a guide written before that change will pick Create Shortcut, look for the Open as window checkbox that the old dialog had, fail to find it, and end up with a tab. The checkbox was not relocated into settings. The branch of behaviour it controlled became its own menu item, which left the checkbox with nothing to decide.

One side effect of that split is worth knowing. The install command no longer requires the page to qualify as a progressive web app. Chrome's developer documentation describes manual installation of any page as a deliberate addition, on the grounds that people want to install experiences that were never built for it. Internal dashboards with no manifest and no service worker can be installed, and pages that used to refuse now accept.

What an app mode window actually does differently

The visible difference is the absence of the tab strip and the address bar. The behavioural differences take longer to notice.

Keyboard shortcuts that operate on tabs stop doing anything, because there are no tabs. The shortcut that focuses the address bar has nothing to focus. Anyone who navigates by typing URLs loses that habit inside the window and has to use links on the page instead.

Navigation that stays within the site stays in the window. Navigation that leaves the site is handed to an ordinary browser window, which comes to the front. For a dashboard that rarely links outward this is invisible. For a mail or chat interface it happens on most clicks, which is worth testing before deciding those are the first sites to convert.

Extensions still apply, because the window is still the browser. A content blocker or a password manager installed in the profile behaves inside the app window as it does in a tab. This is the single largest practical difference between an app mode window and a separate native application, and it is often the reason people prefer one over the other.

Links arriving from elsewhere behave the other way round. The app is not registered as the system handler for the site's addresses, so clicking a link in another program opens the default browser as a tab, not the app.

Cookies and sign in state come from the profile. Two profiles signed into two accounts produce two apps that stay separately signed in, which is the standard way to keep a work account and a personal account both open.

Who owns the name and the icon

This is the detail that decides whether the arrangement holds up over a year.

For an installed app, the name and the icon come from the site. Chrome's help documentation is explicit that when a web app wants to update its name or its icon, the browser notifies the user and offers to review the update, with choices to accept it, ignore it, or uninstall the app. It also advises uninstalling if the change looks like an attempt to resemble a different app.

That notice is a sensible safety measure and it also states the underlying arrangement plainly: the identity of an installed app is proposed by the site, not owned by the person who installed it. Setting a custom icon through Get Info in Finder works in the moment and is not durable, because the app can be regenerated underneath it.

For the flag route, the window inherits the browser's own identity entirely. There is no separate icon to set, because there is no separate application.

Where several internal tools are opened this way side by side, this stops being cosmetic. Three admin panels from the same vendor produce three near identical entries at the size the Dock actually draws them. A builder that turns a site into its own bundle sets the name and the icon locally at creation time, which is one of the adjustable pieces described on the Features page.

The three routes side by side

	Install page as app	The --app= flag	Create Shortcut
Result	Application bundle	A window, nothing stored	A bookmark
Opens in	Its own window	Its own window	A new tab
Listed in chrome://apps	Yes	No	No
Appears in Spotlight and the switcher	Yes	Under the browser	No
Can be uninstalled	Yes, from its own menu	Nothing to uninstall	Delete the bookmark
Tied to a Chrome profile	Yes	The one launched	Yes
Name and icon	Proposed by the site	The browser's	The site's

What breaks it later

Each route has a failure that shows up after the setup has been forgotten.

An installed app disappears when its profile is deleted, and a profile is exactly what people delete when they clean up a browser or hand a machine to someone else. The app icon remains in the Dock and stops working.

A flag based launcher breaks when the command is edited by hand and the quoting goes wrong, or when the site changes its address. There is no register to consult, so diagnosing it means finding the original command, wherever it was saved.

A shortcut created after Chrome 128 was never an app in the first place, which is why it opens in a tab. Nothing is broken. It is doing what that menu item now does.

A bundle produced by a site to app tool sits outside all three, because it is a normal application that borrows an installed browser as its engine. Browser updates and profile cleanups do not remove it, and the name and the icon stay where they were set. The Guide covers what building one involves, and the Supported services page lists the sites that already have a prepared configuration.

What to change first

Open chrome://apps before doing anything else. If the site is listed there, it is an installed app and the fix for anything wrong with it lives in that page's right click menu. If it is not listed, the window came from the flag or the shortcut is a bookmark, and the choice is between installing it properly and rewriting the command. For anything opened every working day, install it or build it as a bundle so that there is an object to manage, with Chrome's own install command or with Kagemusha.