Opening one URL like an app on a Mac

The goal behind the search is usually narrow. One URL, opened without hunting through a row of tabs. What comes back from a search engine is broader than that: instructions for dragging a link to the desktop, instructions for a Chrome menu that changed names, and instructions for binding a key combination. All three get called a shortcut, and all three leave something different on the Mac. Picking the wrong one produces a file that opens in the wrong browser, or an icon that lands in an ordinary tab, which is exactly the thing the search was trying to avoid.

Three different things answer to the same name

The first is a bookmark file. Dragging the small icon at the left of the address bar onto the desktop produces a .webloc file containing a single URL. Double clicking it opens the page in whatever browser is set as the system default, not necessarily the browser it was dragged from. On a Mac where Safari is still the default, a .webloc dragged out of Chrome will open in Safari. The file also inherits a generic browser icon, so ten of them on a desktop are indistinguishable from each other.

The second is an installed app. Chrome can take the current page and produce a bundle that opens in its own window with no tab strip and no address bar. It gets a Dock icon, an entry of its own in the application switcher, and a Spotlight result under whatever name was typed during setup. If the point of the exercise is to get a site out of the tab row, this is the only one of the three that does it.

The third is a keyboard binding. The Shortcuts app and Automator can both open a URL from a key combination or a menu bar item. That is genuinely useful for a page visited a few times a week, but the page still opens as a tab in the existing browser window. Nothing about the window changes, so the tab count keeps growing.

There is a fourth thing occasionally meant by the phrase, and it is worth ruling out. Chrome's own address bar shortcuts, configured under search engine settings, let a keyword typed into the address bar jump straight to a URL pattern. That is fast, it costs nothing, and it stays entirely inside the browser. For a URL opened three times a week and never left open, it is often the right answer and it adds no icon anywhere.

Search results mix these together because one word covers all of them. Deciding between them is not a question of which steps to follow. It is a question of what should exist after the steps are finished: a file, an app, a key, or nothing at all.

Any URL now qualifies, including internal tools

For years, the windowed app route was restricted. A page could only become a standalone app if the site had opted in by shipping a manifest and meeting a list of installability criteria. Internal dashboards, old admin panels, and small self hosted tools failed that test and were pushed back into a tab. That restriction is gone. Chrome allows manual installation of any page, and the reasoning was published by the team that made the change.

Research at Google has shown that users also want to install any web experiences, even if they don't meet the install criteria or offer a customized install flow. Source: developer.chrome.com

The current path on a Mac runs through the three dot menu at the top right, then Cast, save, and share, then Install page as app. Sitting directly above it is an item called Create shortcut, which sounds like the thing being searched for and is not. Since Chrome 128 that item produces a bookmark that opens the page in a new tab. The name survived a change of behaviour, which is why following an older set of instructions produces the wrong result while appearing to work.

The install dialog offers one field: the name. It is worth using. A raw URL turned into a Dock label is unreadable at icon size, and a two word name means the app can be summoned from Spotlight by typing two characters.

What the Mac actually gets

An installed app is a real bundle, filed under a Chrome Apps folder inside the user's own Applications folder rather than the system wide one at the root of the disk. Anything sitting there is an installed app. The address chrome://apps lists the same set and nothing else, which makes it the fastest way to work out what a site set up months ago actually is.

	.webloc on the desktop	Installed app	Shortcuts or Automator
Opens in	The default browser	Its own window, no tab strip	A tab in the existing window
Dock presence	None	Own icon, own switcher entry	None
Findable in Spotlight	By filename	By app name	By shortcut name
Session used	The default browser's	The profile that installed it	The browser's current profile
Removing it	Delete the file	Uninstall from the app menu	Delete the shortcut

The row that causes the most trouble later is the session. An installed app is not a separate program. It is the same browser drawing the same page with the window furniture removed, and it uses the cookies, the saved passwords, and the signed in account of the profile that created it. Two accounts on the same service cannot become two installed apps inside one profile, because the second one opens already logged in as the first. The workaround is a second browser profile, which then produces its own copy of the app with the profile name appended, or a tool that assigns each app a profile of its own.

The starting URL is captured, not configured

The install command has no URL field. It takes whatever is in the address bar at that moment and records it as the app's starting point. That single detail explains most of the complaints about these apps opening on the wrong page.

Installing while signed out records the sign in page. Installing from a redirect that has not finished records the intermediate URL. Installing from a page with a session token in the query string records a token that will be dead by the following week. In every case the app works, opens, and starts somewhere other than intended.

The fix is procedural rather than technical. Open the exact page, sign in, wait for the address bar to settle on the URL that should be the starting point, and install from there. Deep URLs are fine, including filtered views and query strings, as long as they are stable without a session. A saved search in an issue tracker or a specific board in a project tool both survive this test. A URL containing a one time token does not.

Changing the starting URL afterwards means uninstalling and installing again, which also means choosing the name again. That is a minute of work the first time and an annoyance by the fifth. Tools built for this job take the URL, the name, and the icon as three fields at creation time, which removes the round trip. The Features page lists what is adjustable at that stage, and the Guide walks through the same sequence with screenshots.

Where the window hands the page back to the browser

An app opened from one URL does not stay a single page. Following a link inside the site keeps the app window. Following a link that leaves the site hands the page to an ordinary browser window, which appears in front and takes focus.

This behaviour is invisible for some sites and constant for others. An internal admin panel rarely links outward, so the app window keeps the session for hours. Email and chat link outward on almost every message, so reading two messages and clicking through both puts the browser in front twice. Neither outcome is wrong, but they lead to different conclusions about which URLs are worth installing.

There is a second consequence worth planning for. Because the app window has no address bar, there is no obvious way to see where a page has navigated to. A redirect chain that ends somewhere unexpected simply shows a different page. Turning on the small navigation controls, where the tool being used offers them, restores a back button and a way to check the current address without leaving the window.

Opening a URL from the command line

Chromium accepts a switch that opens a single URL in a window with no tab strip, which is the same window shape the install command produces. On a Mac it is invoked through open:

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

Two details decide whether this works. The -n flag forces a new instance. Without it, and with Chrome already running, the arguments are handed to the existing process and quietly ignored, which looks like the switch not working at all. The --profile-directory value selects which profile the window belongs to, and therefore which account is already signed in.

The limitation is packaging. A command is not a Dock icon. Turning it into something clickable means wrapping it in a Shortcuts action, an Automator application, or a shell script saved with a .command extension, and then finding an icon for it. For one or two URLs that is a reasonable afternoon. Past roughly ten, the wrapper files themselves become the maintenance problem, and a tool that generates the bundle is doing the same work with fewer moving parts.

Deciding which URLs earn an icon

Most of these apps stop being used because of what was chosen, not how it was built. A URL is worth installing when three things are true at once:

• It is opened on most working days.
• It is opened deliberately, not arrived at from a search result or an email link.
• The signed in session on it is worth keeping separate.

Mail, calendar, chat, issue trackers, and internal dashboards usually pass. Documentation, reference pages, and anything opened a few times a month usually fails, because a tab is easier to close than an app is to ignore. One exclusion is worth applying on top: a site that depends on a browser extension to be usable at all needs a container that can carry extensions, which rules out the WebKit based routes and keeps the choice among the browser based ones.

The distribution of what people actually install is a better guide than a blank text field. The Supported services list is close to that distribution, and it skews heavily towards mail, calendar, chat, generative AI, notes, and code hosting. Search engines and news sites are almost absent. They are opened constantly, but the next destination is never the same twice, so a fixed URL buys nothing.

What to change first

Pick the single URL that gets opened first every morning, sign in, and install that one page as an app from the address bar it actually settles on. Live with one icon for a week before adding a second, because the week will show whether the window is worth having or whether a tab was fine. If the count is heading past three and each one needs a name and an icon chosen by hand, that is the point where a dedicated builder such as Kagemusha removes the repetition.