Creating a Chrome shortcut for a site on a Mac

The steps take four seconds and the result is unpredictable, which is the whole problem. Two items in the same Chrome menu produce two different objects, one of them keeps the name people learned years ago, and neither dialog explains what will be sitting on the disk afterwards. The difference only shows up on first launch, by which point the site has been set up and the icon has been dragged into place. Knowing what each item leaves behind, and how macOS then treats it, turns a coin flip into a decision.

The item that kept the name and lost the job

Both candidates live under the three dot menu at the top right, in the section called Cast, save, and share.

Install page as app produces an application bundle. It opens in a window with no tab strip and no address bar, and macOS treats it as a program.

Create shortcut produces a bookmark. Since Chrome 128 it opens the page in a new tab of the existing browser window, matching the way the same wording has always worked on Android. Anyone following instructions written before that change will pick this one, tick nothing, and get a tab.

The old dialog had a checkbox labelled Open as window, and searching for it now finds nothing, because it was not moved into settings. The branch of behaviour it controlled became its own menu item, which left the checkbox with no decision to make.

One useful side effect of the split: the install command no longer requires the site to qualify as a progressive web app. Any page can be installed manually, including internal dashboards with no manifest and no service worker. Pages that used to refuse now accept.

The install button in the address bar, and when it is absent

There is a second route that skips the menu entirely. On sites that meet the browser's installability criteria, an install icon appears at the right hand end of the address bar, and clicking it does the same job in one action. When that icon is present it is the fastest route available, and it also carries a small piece of information: the site has been built with installation in mind, which usually means the icon and the app name have been chosen by the people who run it rather than derived from a page title.

The icon is missing on most internal tools, most older admin panels, and plenty of well known consumer sites that never shipped a manifest. Its absence says nothing about whether the page can be installed. The menu route works regardless, because manual installation of any page has been allowed since the two behaviours were separated.

Knowing which of the two happened is occasionally useful later. An app installed from a site that qualified tends to keep a sensible name and a proper icon on its own. An app installed manually from a page with no manifest takes whatever the page offered at the time, which is often a page title long enough to be truncated in the Dock and a favicon scaled up past the point of being readable.

What ends up on disk

An installed app is filed in a Chrome Apps folder inside the Applications folder of the user's home directory. That is a different place from the system wide Applications folder at the root of the disk, and the distinction is useful: anything in the home folder version is an installed web app rather than a program that arrived from a download.

The address chrome://apps lists the same set from the browser's side, and lists nothing else. A shortcut file on the desktop never appears there. When it is unclear which of the two a site was set up as months ago, that page answers the question in one look, and the right click menu on an entry offers both a removal command and a command to place a launcher on the desktop.

That second command is the piece the old single dialog used to bundle together. Installing the app and deciding where its launcher sits are now two steps. It reads as extra work the first time and stops mattering afterwards, because a launcher only needs placing once.

How macOS treats the result

Because the result is a real bundle, the rest of the operating system behaves as it does for any application.

It appears in Spotlight under the name given during installation, which is the strongest argument for typing a short name in that dialog rather than accepting a long site title. It appears in Launchpad. It gets its own entry in the application switcher, so the site becomes reachable without going through the browser at all. It can be pinned by Control clicking the Dock icon and choosing Options then Keep in Dock, and it can be added as a login item so that it opens automatically at sign in.

Two small details around the Dock are worth settling on the first day. Applications belong to the left of the divider; dropping one on the right produces a stack instead of a launcher. And if the icon appears while the app runs and vanishes when it quits, it was never pinned, it was showing in the recent applications section, which is a separate setting under Desktop and Dock in System Settings.

Spotlight is where a careless name costs the most. An app called by the site's full page title competes with every document and message containing the same words, so the launcher that was supposed to take two keystrokes takes six and a glance at the results list.

What it does not do is take over links. Clicking a link elsewhere on the Mac still opens the default browser, not the installed app, because the app is not registered as a handler for the site's addresses. Sending a colleague a link to a page inside an installed app opens it in their browser as a tab.

Inside the window, navigation that stays on the site stays in the app. Navigation that leaves the site is handed to an ordinary browser window, which comes to the front. For a site that rarely links outward this is invisible. For mail and chat it happens on most clicks, which is worth knowing before deciding those are the first two sites to install.

The name and the icon are not permanent

This is the detail that catches people who care about how the Dock looks.

The name and the icon of an installed app come from the site, and Chrome refreshes them when the site changes them. A service that rebrands can therefore relabel its icon in the Dock without anyone touching anything. Setting a custom icon through Get Info in Finder works in the moment and is not a durable arrangement, because the app can be regenerated underneath it.

Where several similar looking services are installed side by side, this matters more than it sounds. Three chat tools with three round blue icons are three identical Dock entries at the size the Dock actually draws them, and the ability to assign a distinct icon that survives is one of the specific reasons people move to a dedicated builder. The Features page lists what is adjustable at creation time on that kind of tool, and the Guide shows the same sequence step by step.

The profile the shortcut belongs to

An installed app is not a separate program. It is the same browser, drawing the same page, in a window with the furniture removed. It uses the cookies, the saved passwords, and the signed in account of the profile that created it.

Two accounts on one service cannot be two installed apps inside a single profile. The second one opens already signed in as the first. The standard workaround is a second browser profile, which then produces its own copy of the app with the profile name attached to it, and a profile switch every time the app is created or repaired.

Extensions carry over as well, which cuts both ways. A content blocker keeps working inside the app window and a password manager stays reachable. At the same time, an extension that injects itself into every page is also running inside what looks like a single purpose tool.

What a browser update does to it

Chrome updates every few weeks, and the app is a launcher for that browser rather than a self contained program. Most updates pass without anything visible. Major ones can leave an installed app with a reverted icon or a launcher that no longer starts, and the repair is to install the page again.

With three apps, that is a minor annoyance handled once or twice a year. With twenty five, it becomes a recurring task, and the amount of it that happens automatically varies by tool. This is the single most useful question to ask about any container built on top of an installed browser: what happens to it the week after the browser updates.

The counterweight is security. Because the engine is the browser, patches arrive on the browser's schedule with no action required. A packaged wrapper that bundles its own engine has the opposite profile: nothing breaks when the browser updates, and nothing gets patched either. Nativefier, the best known generator of that kind, was archived in September 2023, and its own notice recommends the browser install route on exactly these grounds.

Removing one without leaving debris

Uninstalling is done from inside the app. The three dot menu in the app window carries an Uninstall entry naming the app, followed by a confirmation. That route clears the registration at the same time as the bundle.

Dragging the bundle out of the home Applications folder does not. The entry stays at chrome://apps, which is how people end up with a list of apps that no longer launch anything. The tidy repair is to remove the leftover entry from that page.

Copying a bundle to a second Mac is not a substitute for installing there. The bundle is a launcher for an app registered inside a browser profile on the original machine. Setting up a new Mac means installing each site again, which is the point at which a list of twenty five hand made apps turns into an afternoon rather than a restore.

When the built in route runs short

	Chrome install	Safari Add to Dock	Site to app tool
Separate login per app	Needs a separate profile	Yes, by default	Yes, per app
Browser extensions	Yes, shared with the profile	Safari extensions only	Yes, per app
Custom icon that persists	No, refreshed from the site	Yes, in app settings	Yes
Engine choice	Chromium only	WebKit only	Several installed browsers
Cost	None	None	Free tier, then paid

Three sites, one account each, and no strong feelings about icons is a case the built in command covers completely. Two accounts on the same service, a workflow that depends on an extension, a site that renders correctly in only one engine, or more than a handful of apps to keep tidy are the four situations where people move on. The distribution of what actually gets installed is visible on the Supported services list, which is a faster way to judge whether a particular site is an ordinary case than reasoning about it from scratch.

What to change first

Install one site with the correct menu item, give it a short name in the dialog, and pin it. Use it for a week before adding a second, because the week decides whether a dedicated window earned its Dock slot or whether a tab was already fine. When the count grows past a handful, or a second account on the same service enters the picture, a builder such as Kagemusha handles the parts that stop scaling by hand.