Site shortcuts in the Dock: the setup order that holds up

The creation step in site shortcuts in the Dock takes about thirty seconds. Everything that goes wrong afterwards traces back to a decision that was never made, or was made by a default. Which account the app runs under, what it is called, where links go when they are clicked, what its starting address is. None of those are hard questions, but answering them after twelve apps exist is a different job than answering them before the first one. The order below is arranged so that the expensive decisions come first and the cheap ones come last.

Decide four things before opening anything

Write these down before touching a creation screen. All four can be specified at creation time, and each costs something different to change later.

Decision	What settles it	Cost of changing later
Account	Work, personal, or both at once	Often a rebuild
Name	What gets typed in Command Tab	Editable in settings
Icon	Whether two similar apps stay distinguishable	Replaceable image
Link policy	How much external traffic the service carries	Editable in settings

Only the first one is genuinely expensive. In a build that isolates cookies, switching the account later means signing out or creating a second app, so that row deserves a real answer before the others. The remaining three can be revised, which means they should not hold up the first attempt.

Link policy is the row most often left to a default, and it is the one felt daily. Services that deliver a stream of outside links belong on the send outward setting. Internal panels whose navigation is internal belong on the keep inside setting. Getting it wrong produces a small tax on every click rather than an obvious failure.

Step 1: pick one site by counting, not by feel

Building twelve apps in one sitting makes it impossible to tell which of them helped. Start with one, chosen by a count rather than an impression.

Open the browser history and read one day of it. The service opened three or more times in a day repays a Dock slot. The one opened once does not, and putting it there only consumes space. Reading the timestamps adds a second signal: whatever gets opened first every morning is the strongest candidate of all, because that is the moment when hunting through tabs is most expensive.

The count usually disagrees with the impression. Services that feel central turn out to be opened twice a week, and the tool actually opened nine times a day is one nobody would have nominated.

There is a second reason to start with exactly one. The point of the exercise is to find out whether a standalone window solves the problem at all. For some workflows it does not, because the friction was never the tab strip but the number of services in play. One app answers that question in a week, at a cost of five minutes, and the answer determines whether the rest of the work is worth doing.

Step 2: fix the engine and the profile before creating

In several routes, the browser and profile used at creation become the contents of the app. Skipping this step produces a work dashboard that opens under a personal account, discovered a week later.

Two considerations settle it. If a content blocker or password manager is part of the daily routine, build with the engine that holds those extensions. If two accounts on the same service need to be open simultaneously, choose a route that isolates cookies. Needing both points toward a tool that can name a profile explicitly at creation.

System requirements belong in this step as well, because they can eliminate a route outright. Saving a webpage as a web app in Safari requires macOS Sonoma 14 or later; on anything earlier the menu item is simply absent. Paid tools each state a minimum too, and reading that line before paying avoids the worst version of this problem, which is a license for software the machine cannot run.

Step 3: choose the starting address carefully

The URL entered at creation is the page the app opens on every launch. Setting it to a service's home page means navigating to the real destination every morning, which cancels out most of the benefit.

Use the address of the screen that actually gets used. The specific board, the specific dashboard, the specific queue. Copying it out of the address bar while that screen is open is the whole technique.

One category to avoid is any address carrying a search query or a date range, because that state freezes at creation and the app opens on stale criteria tomorrow. Addresses that require a login are fine; an unauthenticated launch simply lands on the sign in screen and continues from there.

Step 4: create, then finish the login in the same sitting

In Safari, open the page, choose File, then Add to Dock, name it, and confirm. The bundle is filed in the Applications folder inside the home directory. The Share button reaches the same command.

In Chrome, open the three dot menu, then Cast, save, and share, then Install page as app. On qualifying sites an install icon also appears at the right end of the address bar. Google's help describes what the command produces.

You can use web apps to have a website work as an app and access it on your computer or mobile devices through the launcher or home screen. Source: support.google.com

Whichever route is used, launch the result immediately and drive it all the way to the screen that was the point of the exercise. Sign in now, while there is time to deal with a second factor, rather than at the start of a meeting tomorrow.

Step 5: keep it, and decide where it sits

A freshly created icon may be visible only because the app is running. Quitting removes it. Right click the icon, open Options, and choose Keep in Dock. Skipping this one command is the entire explanation for most icons that seem to disappear overnight.

Position is worth deciding now rather than drifting into. The Dock places applications to the left of the separator, so a new bundle lands somewhere in that group. Parking it at one end makes it findable by position, which is faster than reading icons. Anything left in the middle shifts every time the set changes.

If the strip is getting crowded, turning on magnification in the Desktop and Dock settings keeps small icons clickable. That setting starts to matter somewhere around ten icons.

It is also worth setting an upper bound now. Past roughly fifteen icons the strip stops being scannable, and launching shifts to Command Tab or Spotlight anyway. At that point the apps still earn their keep, but the Dock slots do not, so reserving the strip for services that stay open all day keeps the count from creeping.

Step 6: settle notifications and launch behavior immediately

The site's notification prompt usually appears once, right after first load. Answer it deliberately. Declining now means returning through system settings later.

For a service that should report without interrupting, open the notification list in system settings, select the app by name, and turn off banners and sound while leaving the badge on. That combination reports a count on the Dock icon and nothing else, and it is only available because the app exists as its own entry.

For a service opened every single morning, adding it as a login item removes the launch step entirely. That is available from the General section of system settings, or from the same right click menu on the Dock icon.

Step 7: set the conventions before the set grows

The first app needs no conventions. The sixth does. Three of them prevent most of the mess.

• Name apps consistently. Service name alone, or service plus purpose, as in Gmail Work and Gmail Personal, so that Command Tab stays readable.
• Differentiate icons for duplicates. Two apps for the same service look identical when both inherit the site's favicon.
• Review monthly. An app that has not been opened in four weeks is holding a Dock slot for nothing.

Knowing where the files live helps later. Bundles created by a browser go into the Applications folder inside the home directory, not the one at the root of the disk. That distinction answers the question of what created a given app months after the fact. Tools that keep a management list make the same question a one click answer, while apps built from browser commands have to be opened one at a time to inspect their settings.

Before building the second one, verify four things

One week with a single app answers questions that no amount of reading does. Four checks cover the cases that later force a rebuild.

Does a link clicked inside the app land where it should. Does a file upload from the service complete, since that path runs through the engine rather than the site. Does the session survive a restart of the machine, or does the app ask for a password every morning. Does the app appear correctly in Command Tab and in the notification list under the name it was given.

A failure on any of these is cheap to fix while one app exists and expensive once eight of them share the same flaw. That is the entire argument for building one and waiting, rather than converting the whole tab strip on a Sunday afternoon.

Step 8: know the removal path for the route taken

Removal differs by route, and mixing routes leaves debris.

A Safari web app is removed by dragging its bundle out of the Applications folder inside the home directory. A Chrome installed app offers Uninstall from its own menu, with a checkbox for deleting the data the site stored. A dedicated tool removes its apps from its own list.

Keep in mind that removing an icon from the Dock and deleting the bundle are separate operations. Dragging the icon away leaves the app on disk. Deleting the bundle while the icon remains produces an icon with a question mark on it.

What to change first

Build one app, for the service that topped yesterday's count, under the account it will actually be used with. Run it for a week before building anything else. If the standard route covers the extension requirement and the multiple account requirement, nothing further is needed and nothing was spent. If it does not, that missing piece is the specification, and the second and third app take under a minute each when a preset library fills in the address, the icon, and the name. Check the Supported services list first so the services from yesterday's count are covered, and see where the free tier ends in Pricing before committing to anything. The step by step creation flow is documented in the Kagemusha guide.