Custom icons for shortcuts: the setup order that holds up

The clicking part takes about two minutes on any route. What costs time is the week afterwards: the app opens the wrong page, the login turns out to be shared with the browser after all, the icon quietly reverts. None of those are mis-clicks. They are decisions that were never made, so a default filled the gap. Settle four things before the first menu opens and the rebuild never happens.

The four decisions, and which one cannot be undone

Most step lists start at step one and let defaults fill everything else. That works until the defaults turn out to be wrong, and then each item falls into one of two buckets: fixable in place, or rebuild.

• Which page opens. The front page, or the deep URL actually looked at every morning.
• Whether the session stays separate from the browser, and separate from other copies of the same site.
• What the app is called, and whether that name is distinguishable in the app switcher.
• Where the icon image comes from: the site's own artwork, or a file chosen deliberately.

Three of those four can be changed afterwards. The session question is the one that is decided by the route itself, which means it has to be answered first and everything else ordered behind it. Pick the isolation model, then pick the route, then set the page and the name, and leave the icon for last. Preparing the image first is a common way to waste effort, since a change of route can change what the image needs to be.

Sessions first, because the route follows from the answer

Anyone running a work account and a personal account on the same service is deciding this whether they realise it or not. Ordinary browser windows share one cookie store, so signing into the second account evicts the first.

Apple states the position plainly for the built-in route: a web app functions independently of Safari and shares no browsing history, cookies, website data, or settings with it. So one level of separation is available with no extra tooling, on macOS Sonoma 14 or later.

The limit sits one step further out. That documentation describes separation from Safari. It does not promise that two web apps built from the same site hold two different logins at the same time. If the daily reality is three or four accounts on one service, the requirement is not a Dock icon, it is a separate profile per app, and only some routes provide that.

A Finder alias sits outside this question entirely. An alias points at a local file or folder, not at a URL, so if the destination is a website the alias route is already eliminated no matter how good the icon looks.

Capture the URL before opening any menu

The screen opened every morning is rarely a service's front page. It is a board, a channel, a filtered queue. Copy that exact URL from the address bar before starting, and the app opens on the useful screen from day one.

Two categories of URL deserve a check first. A page that requires sign-in may bounce to a login screen on first launch, and whether it returns to the requested page afterwards depends on the site. Some do not, and for those the stable landing page is the better target. A URL carrying a date or a saved filter is the other case: register it once and it will eventually open an empty result set, because the filter refers to a moment that has passed.

On the Safari route this is recoverable. Open the web app, click its name in the menu bar, choose Settings, and the Application URL field accepts a new address or a Set to Current Page click. Getting it right up front is still cheaper than noticing a month later that the app has been opening the wrong board the whole time.

The Safari route, and everything it exposes afterwards

Open the page in Safari, choose File then Add to Dock from the menu bar, type a name, and click Add. The Share button in the toolbar offers the same command. The result is saved to the Applications folder inside the home folder, and it appears in both the Dock and Spotlight.

The settings panel that opens from the app's own menu covers more than most people expect:

Field	What it controls
Application Name	The label in the Dock and the app switcher
Application URL	The page loaded at launch
Icon	Replaced from a file picker
Show navigation controls	Whether back, forward, and share appear
Show color in title bar	Whether the title bar adopts the site's colour

Two tabs sit alongside those fields. Privacy opens the system privacy settings and clears the site's cookies and caches. Extensions enables or disables Safari extensions for this app specifically. That last word matters: Safari extensions, not Chrome Web Store extensions. An ad filter or password manager installed in Chrome has no presence here.

Notifications need one deliberate action at first launch. Answer the site's permission prompt inside the web app rather than in Safari, and the app then appears in Notifications settings under its own name, with unread counts rendered as a red badge on the Dock icon. Answer it in Safari instead and the badge never arrives.

The Chrome route, and the icon that can change under you

Chrome's equivalent is Install page as app, found in the More menu under Cast, save, and share, and sometimes as an install button at the right end of the address bar. Installed apps are managed at the browser's internal apps page.

This route has one behaviour the Safari route does not. Chrome's help explains that when a web app wants to update its name or icon on screen, Chrome notifies the user, who can accept the update, ignore it, or uninstall the app. The same page warns that a name change or an icon suddenly resembling a different app can indicate a malicious change, and advises uninstalling in that case.

Nothing is replaced silently. But for anyone who deliberately set a custom image, accepting that update means losing it, so ignore is the setting to remember. The choice of icon on this route is a standing decision, not a one-time action.

Uninstalling has two depths. Open the app, choose Uninstall from the More menu, confirm. Tick the option to also delete data from Chrome and the session goes with it, meaning a fresh sign-in next time. Leave it unticked when rebuilding the same app and the login survives the rebuild.

Set the image last, and know which verb reverts it

Icon replacement is the same operation for files, folders, and applications. Open the image in Preview, choose Edit then Copy. Select the target, choose File then Get Info. In the info window, click the small icon at the top under the title bar, then choose Edit then Paste.

When Paste is greyed out, Apple's documentation names the reason: the large icon under the preview may be selected instead of the small one at the top. The second cause is location, since Applications, Library, System, and Users are listed as built-in folders that cannot be customised, while the home folder can be.

Reverting uses Cut, not Delete. Select that same small icon in the info window and choose Edit then Cut. It is not a discoverable verb, which is why people assume a custom icon is permanent.

Resolution deserves thirty seconds of attention. Preview handles HEIC, JPEG, JPEG 2000, OpenEXR, PDF, PNG, and TIFF. A file that looks acceptable in the Dock will look soft in the app switcher and in list views, because those render at different sizes. A large, roughly square source holds up everywhere.

Check three things, then learn the removal path

Before closing everything, confirm three things while the context is still fresh. Clicking the Dock icon lands on the intended screen rather than a login wall. The name and icon are distinguishable from their neighbours in the app switcher. If notifications matter, the app is listed by name in Notifications settings.

Removal differs by route, and one detail catches people out. Apple's Dock documentation states that dragging an item out of the Dock removes the alias only, and the item itself stays on the Mac. Gone from the Dock is not gone from the disk. A Safari web app is deleted by opening the Applications folder inside the home folder and dragging it to the Trash. If an app icon was pulled out of the Dock by accident, open the app, Control-click its icon, and choose Options then Keep in Dock.

One more Dock property is worth knowing before assigning positions to memory. Up to three recently used apps appear automatically, separated by a divider, and that set rotates. Anything meant to be clicked by position should sit on the permanent side of the line.

Naming rules pay off at the fifth app, not the first

With one app, none of this matters. The cost of a loose naming habit only appears once five or ten sites live in the Dock, and by then renaming them all is an afternoon rather than a minute.

Two failure patterns show up repeatedly. The first is naming by service alone. Two accounts on the same service produce two identically named entries with identical artwork, and the app switcher becomes a coin toss. Adding the role to the name, rather than only the service, fixes it at creation time: the account that matters is the distinguishing fact, not the brand.

The second is mixed icon sources. Some apps inherit a small favicon, others carry a hand-picked image, and the row ends up visibly uneven because the resolutions differ. Choosing one source policy up front, either always inherit or always supply, keeps the row consistent without any later cleanup.

There is a practical ceiling worth planning for as well. Past roughly ten permanent Dock items, clicking by shape stops being reliable and position takes over, which is exactly when the rotating recents zone becomes a hazard. Grouping related apps next to each other, and keeping the ones opened first thing in the morning at one end, does more for daily speed than any icon artwork.

Names are editable after the fact on every route described here, so none of this is irreversible. It is simply cheaper at creation. A convention written down once and applied to each new app costs nothing per app and removes the rename session entirely.

What to change first

Answer the session question before anything else, because it selects the route and the route decides what can be adjusted later. If one account per service is enough, the built-in Safari route covers it at no cost. If several accounts, or Chrome extensions, need to survive inside the window, choose a route that assigns a separate profile per app and check the scope under Features or the walkthrough in the Guide first. For a mainstream service, look at Supported services before hand-collecting a URL and an icon, and compare free limits at Pricing before building the fifth one. A tool such as Kagemusha exists for exactly the multi-profile case.