Adding any website to the Dock from Safari

On a Mac, adding a website to the Dock from Safari takes two menu choices and a name. The instructions are short enough to fit in a sentence, which is why almost every guide stops there. The two decisions that actually determine whether the result is useful sit on either side of those instructions. One is which page to be looking at when the menu item is chosen. The other is which sites deserve this treatment at all, because for most sites the result is a decorative bookmark that takes up a Dock slot.

The feature arrived in macOS Sonoma 14

Treating a webpage as an application is not a new idea, and dedicated tools for it existed long before Safari shipped one. What changed with macOS Sonoma 14 is that Safari users stopped needing a second browser or a third party tool to do it. Whether a particular Mac qualifies is visible under About This Mac in the Apple menu.

Apple's support page defines the result in two sentences, and they explain most of what happens afterwards:

When you use a webpage as a web app, it looks and behaves just like it does in Safari. Yet the experience of using a web app differs in several ways. A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

Looks identical, stores nothing in common. That combination is why a brand new web app opens to a login screen, and why a password saved in Safari appears not to work at first. Nothing is broken. The separation is the feature, and it is the reason to pick this route for some sites and skip it for others.

The route costs nothing, since it is part of macOS. Trying it first and cataloging what falls short is a cheaper way to evaluate a paid tool than reading feature lists.

The page open at the time becomes the app's starting point

This is the decision that matters most, and it is invisible in the instructions. Add to Dock freezes the current URL as the app's home. Run it on a marketing homepage and the app opens on a marketing homepage every morning. Run it on the board, dashboard, or inbox that actually gets used, and it opens there.

For anything used daily, the correct move is to navigate all the way to the working screen first. Building from the top level page means repeating the same three clicks every time the app launches, which cancels out most of the benefit.

Some URLs make poor starting points because they carry information that expires:

• Search results or filtered views whose conditions live in the query string
• URLs containing a session identifier or a temporary token
• Share links that were issued with an expiry date
• Any URL captured mid redirect during a login flow

A safe test is whether the URL would still work as a plain bookmark next month. Opening the same address in a Private window shows quickly whether it depends on an existing session.

The starting URL is editable afterwards. Open the web app, click its name in the menu bar, choose Settings, and the Application URL field appears with a Set to Current Page button next to it. Navigating to the right screen and pressing that button is faster than rebuilding the app.

Which sites earn a Dock slot

Four axes decide it. The more that apply, the more a dedicated window is worth having.

Axis	Worth it when	Not worth it when
Session length	Open for hours at a time	Closed as soon as the task ends
Frequency	Opened at the same time daily	Once a week, or when remembered
Notifications	Sends alerts that get acted on	Sends nothing
Account split	Work and personal accounts differ	One account covers everything

Long sessions benefit most, because the window has no tab strip and no address bar. The path from a focused work session into unrelated reading simply is not present. A site used for lookups and then closed gains nothing from that, and only adds an icon to scan past.

Sites that send notifications have the clearest case. A web app shows unread counts as a red badge on its Dock icon, but only when the notification permission is granted inside the web app rather than in Safari. Once that happens the app appears in System Settings under Notifications by its own name, so alerts from that one service can be tuned without touching every other site that ever asked.

The account split axis uses the cookie separation directly. A web app signed into a work account leaves Safari free to stay signed into a personal one. The account switcher disappears from the morning routine, which for some people is the entire reason to build one.

A site matching none of the four axes produces an icon and nothing else. A site matching three or more shows its value the next morning. When picking the first one to build, start with whatever scores highest, because a convincing first result makes the rest of the decisions easier.

Names and icons are worth deciding before the dialog appears

The name typed into the Add dialog resurfaces in more places than expected. It appears under the Dock icon, in the Command Tab switcher, in Spotlight results, in the Force Quit list, and in System Settings under Notifications. Apple's page notes specifically that web apps are listed there by their name rather than by the website's URL, which makes a vague name genuinely hard to identify later.

The first characters carry most of the weight. Three web apps built from the same company's services and all named with that company's name first will split the Spotlight candidate list no matter how much gets typed. Leading with the purpose fixes it: Books Xero, Standup Notion, Support Gmail. So does leading with the account: Gmail Work, Gmail Personal. Either pattern keeps the first two characters distinct, which is usually the difference between two keystrokes and five.

Icons default to whatever the site provides. When that comes out blurry, or when several converted sites end up looking alike in the Dock, the Settings panel accepts a replacement image. For anyone planning to keep three or more of these in the Dock, choosing icons with clearly different dominant colors does more for retrieval speed than any keyboard configuration.

For the one site opened every single morning, the opening step can be removed entirely. Apple notes that a web app can be added as a login item so that it opens automatically at login. The setting is in System Settings under General, in Login Items and Extensions. A window that is already on screen needs no shortcut at all.

What the Settings panel controls

Everything that could not be decided at creation time lives in one place. Open the web app, click its name in the menu bar, choose Settings.

• Application Name changes what appears in the Dock, Command Tab, Spotlight, and the Notifications list at once.
• Application URL changes the starting screen.
• Icon accepts any image file and replaces the default.
• Show navigation controls decides whether the toolbar carries back, forward, Share, and extension buttons.
• Show color in title bar decides whether the title bar picks up the site's color.

Navigation controls are worth thinking about rather than accepting the default. A single screen tool feels cleaner without them. Anything with real internal navigation is frustrating without a back button. Leaving them on and turning them off later, once the app has been used for a few days, is the order that produces fewer regrets.

The Privacy tab clears that site's cookies and caches without touching Safari's data, which is a genuinely useful escape hatch when a login gets into a bad state. The Extensions tab enables or disables Safari extensions for that specific web app. Turning on a password manager extension here removes most of the friction from the separate sign in.

What breaks, and where to look

Failures cluster into a few recognizable shapes.

A login screen on first launch is the design, not a fault. Signing in once settles it. If credentials are requested on every launch, the site is expiring its own cookies aggressively, and no container will change that.

Navigating to a different domain can eject the session from the window. Links pointing outside the app's own domain hand off to the default browser, which reads as being thrown out of the app mid task. Checking how much of a workflow crosses domains before building the app avoids the surprise.

Single sign on is the sharpest version of that problem, because authentication redirects through an identity provider on another domain. If the handoff lands in the default browser, the web app can end up still signed out after a successful login elsewhere. Confirming that a service's login completes within one domain is worth doing before committing to this route.

A missing browser extension is the failure that no amount of configuration solves. Safari extensions carry into a web app and can be toggled per app. Extensions written for a different browser do not exist on this route, so a workflow that depends on one settles the question before any of the other axes are considered. The same applies to services that only support a browser engine other than the one Safari uses.

An app that cannot be found is usually being looked for in the wrong folder. Web apps are saved to the Applications folder inside the home folder, not the shared one at the root of the disk. In Finder, choose Go, then Home, then open Applications. Deletion happens from the same folder by dragging to the Trash. Pulling an icon out of the Dock only hides it, which is how abandoned web apps pile up.

Reading the presets as a shortlist

The prepared catalogs that dedicated site to app tools ship with double as evidence of which sites people actually convert. More than 240 services are available as ready made presets, and the composition matches the four axes above: chat, task boards, accounting, design tools, and internal dashboards. The full list sits on Supported services. A site that appears there has already passed somebody else's version of this decision.

Where a paid tool differs from the built in route is documented on Features, and the questions that come up before building anything are collected on the FAQ.

What to change first

Pick the single site that stays open longest, add it to the Dock from the screen that actually gets used, and live with it for a week before converting anything else. If nothing in the failure list above shows up, the built in route is the whole answer. If two or three do, Kagemusha exists to close exactly those gaps.