Site shortcuts in the Dock: how to decide what you need

Instructions for site shortcuts in the Dock are everywhere, and none of them help, because the instructions were never the missing piece. Two decisions are open at once: which site deserves to leave the tab strip, and which of the available routes should build it. Comparison posts answer the second question and skip the first, which is why reading three of them changes nothing. Put the target decision first and the route decision becomes mechanical. The four tests below usually cut a list of twenty daily sites down to two or three.

Why the comparison stalls

The usual framing is Safari against Chrome against a purpose built wrapper, scored on speed, cost, and features. That comparison cannot finish, because nothing in it depends on which site is being turned into an app. Speed matters for a site opened forty times a day and is irrelevant for one opened twice. Account separation matters for a service with two logins and is noise for a service with one.

The target decision is what supplies those inputs. Once a specific site is named, three properties become known facts rather than preferences: whether it needs separate logins, whether it pushes notifications, and whether it depends on browser extensions. With those three settled, the route list shrinks on its own, and the comparison table takes a minute to read instead of an afternoon.

There is a second cost to skipping the target decision. Without a shortlist, the natural move is to promote every site that comes to mind. The tab strip then empties into the Dock, and the same search behaviour restarts against a row of small icons. The reader who could not find the right tab now cannot find the right icon. Selecting a target is mostly the work of deciding what stays in the browser.

What each route assumes today

Two of the routes changed recently enough that older instructions describe screens that no longer exist.

Safari can save an open page as an app. Apple's documentation states that this requires macOS Sonoma 14 or later, and the path is File then Add to Dock in the menu bar. The result lands in the Applications folder inside the home folder rather than the one at the root of the disk, which is worth noting now because it decides where to look later.

Chrome split one menu item into two in 2024. From Chrome 128 onward, Create shortcut produces a bookmark that opens in a tab, and the windowed app behaviour moved to a separate item named Install page as app. Any guide that mentions ticking an Open as window checkbox predates that change, and the checkbox is gone rather than relocated.

Dragging a URL onto the right hand side of the Dock is the third route. It takes two seconds and produces a launcher that opens the default browser in a tab. No separate window, no separate session, no icon of its own. It satisfies the literal request of site shortcuts in the Dock and nothing beyond it, which is fine as long as that is what was wanted.

The fourth route is a dedicated tool that builds the app for you. What it assumes varies by product: the macOS floor, the licence model, and the cap on how many apps can exist all differ. Those are worth checking after a target is chosen, not before.

Test 1: can the tab be closed

The instinct is to rank sites by how often they get opened. Frequency is the wrong axis. A site opened ten times a day and closed each time gains almost nothing from a Dock slot, because the bottleneck is the search that precedes it, not the click.

The sites that gain are the ones that never get closed. Time tracking, the team chat, a ticket queue, a monitoring dashboard. They stay open because closing them costs something, and because they stay open they end up buried among thirty other tabs that also stayed open. That is the exact condition a separate app fixes.

A three day check settles it without guesswork. Each time the browser is about to be quit, note which tabs provoke a reluctance to close. Those are the resident tabs. Most people end up with around five, and only the top two or three of those are worth promoting.

Resident tabs share one more trait worth naming. Every browser restart requires reopening them, which is usually delegated to a restore session setting. That setting works until the day it does not, and then all of them vanish at once. A separate app turns reopening into a single click on a Dock icon, with no dependency on session restore behaving.

Test 2: how many accounts the site carries

The second test asks whether the same service is used under more than one login. Sites that pass this test are the strongest candidates, because the tab version charges an account switch every single time.

A Safari built app helps here by design. Apple's documentation states that a web app shares no browsing history, cookies, website data, or settings with Safari. Building two apps from the same site under different names therefore holds two separate logged in sessions. The blank login screen on first launch is that same behaviour, not a fault.

On the Chrome route, account separation and profile separation are the same operation. Split the profiles first, then install from each one. That adds a step, and in exchange the app stays aligned with whichever browser profile already holds the credentials.

For a service with exactly one login, this test simply does not apply. Run it only against the sites that survived test 1, and use it to rank them rather than to eliminate them.

Test 3: does the site push, or does it get fetched

The third test separates services that send something from services that get visited.

Apple's documentation notes that when a site is granted notification permission inside the app, the number of unread notifications appears as a red badge on the Dock icon. For a chat client or a support queue, that badge is most of the value, since the point of promoting the site was to stop missing things.

The detail that trips people is where permission is granted. It has to be answered inside the built app, not in Safari. Permission already given to the site in the browser does not carry across, so a newly built app sits silent while its owner assumes notifications are broken. Build it, open it, answer the prompt, then judge it.

Fetch style sites behave differently. An accounting dashboard or an internal request form sends nothing and never needs a badge. What matters there is time to usable state and the ability to return with one keystroke from the app switcher. Comparing a fetch style site on notification support produces a meaningless answer, which is why the two groups get split before any route is picked.

Anyone unsure which group a site belongs to can count the emails it sends. A service whose notification emails get opened purely to click through to the site is a push service wearing a disguise.

Test 4: what breaks once it leaves the browser

The fourth test looks for things that stop working outside the tab strip. Skipping it produces the most annoying outcome, which is building the app and quietly drifting back to the browser a week later.

Browser extensions are the first thing to check. Password managers, translation tools, expense capture, internal debugging helpers. Business sites tend to be used in combination with at least one of them. Whether the same extension is reachable inside a built app depends on the route, so build one candidate and look at the toolbar before committing the rest.

External sign in is the second. Sites that authenticate through a Google or Microsoft screen sometimes hand the flow to the default browser partway through, and occasionally the completed session does not come back to the app. This is binary and takes one attempt to determine, so start with the candidate that uses external sign in. If it completes, that site becomes the pilot. If it does not, move to the next resident tab on the list.

A third item is worth adding for anyone whose resident tabs involve documents. Printing, saving a generated file, and dragging an attachment in from the Finder all behave slightly differently once a site runs in its own window, and the difference is easiest to establish by doing the task once rather than by reading about it. Pick the single action performed most often on that site, do it inside the new app on day one, and the question is answered permanently.

Clearing these checks first means the decision to keep the app is made on habit rather than on a broken login. The capability side of this is set out under Features, which is worth a look before building rather than after.

Picking the route, and capping the count

With a target chosen, four columns are enough to settle the route.

Route	Requirement	Session separation	Cost model
Safari built app	macOS Sonoma 14 or later	Separate from Safari	Included with macOS
Chrome install page as app	Chrome 128 naming	Per Chrome profile	Included with Chrome
URL dragged to the Dock	None	None	None
Dedicated tool	Varies by product	Varies by product	One time or recurring

Read it by deleting rows. A Mac held below Sonoma loses row one. A site with one account, no notifications, and no need for a separate window is fully served by row three. A reader who wants separate sessions, consistent icons, and the same build process across several sites is looking at row four, where three questions cover most of the ground: how far back macOS support goes, whether the number of apps is capped, and whether the price is paid once or repeatedly. Those three decide the three year cost far more than the headline figure, and the shape of each model is laid out under Pricing.

One practical note about row four: it is impossible to tell from the Dock alone which route built an existing icon. The quickest way to find out is to look for the app in the Applications folder inside the home folder, since that is where the Safari route puts its output. Knowing which route produced an app matters the moment something needs changing, because the settings live in completely different places depending on the answer.

Then cap the count. Three to five is a workable ceiling, because Dock icons shrink as they multiply and the search problem reappears at around a dozen. Adding a sixth means retiring one. Anything unopened for two weeks gets retired automatically. Safari built apps live in the Applications folder inside the home folder, so retiring means deleting them there rather than only dragging them off the Dock.

What to change first

Spend three days noting which tabs resist being closed, and stop reading route comparisons until that list exists. Build exactly one app from the top of it, check extensions and external sign in on that one, and give it a week before building a second. Supported services shows the kinds of sites that tend to leave the tab strip cleanly, and Kagemusha walks through the build itself once the target is settled.