Creating a web app from Safari on a Mac

Safari has been able to save a page as a standalone app since macOS Sonoma 14, and the menu item is easy to walk past. It sits under File, called Add to Dock. Two clicks later the site has its own icon, its own window, and its own slot in Command Tab. The surprise arrives on first launch, when the brand new app shows a signed out page. That is not a bug, it is the design, and it is the single fact that decides whether this route fits the site you had in mind.

What Add to Dock actually produces

The result is not a bookmark and not a downloaded program. It is the same page, rendered by the same WebKit engine, inside a different container. Apple's support page states the boundary plainly:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. In this way, it keeps your browsing separate, similar to using a Safari profile. Source: support.apple.com

Four things change once that container exists. The site gets a Dock icon that can be kept there permanently. It gets a separate entry in Command Tab and Mission Control, so the window is reachable in one keystroke instead of a hunt through browser windows. It gets a window with no tab strip and no address bar, which removes the path by which a focused work session turns into forty minutes of unrelated reading. And it gets its own line in System Settings under Notifications, so alerts from that one service can be tuned without touching every other site that ever asked for permission.

What does not change is anything about the site itself. Nothing is compiled, nothing is installed from the site's servers, and the page has no more access to the Mac than it had in a tab. A web app that stops working almost always stopped because the site changed its URL, not because the container failed.

The steps, and where the file lands

Open the page in Safari while signed in. From the menu bar choose File, then Add to Dock. The Share button in the toolbar has the same item if the menu bar feels slower. Type the name that should appear under the icon, then click Add.

The name matters more than it looks. It is what shows in the Dock, in Command Tab, in the Force Quit list, and in the Notifications list in System Settings. Naming three separate Google apps "Google" produces three identical rows that cannot be told apart later. Names like Mail Work, Calendar Work, and Drive Personal stay readable a year on.

The saved app goes to the Applications folder inside the home folder, not the shared one at the root of the disk. That distinction explains most of the "the app is not in Applications" confusion. In Finder choose Go, then Home, then open Applications there. Spotlight and the Dock both find it regardless of which folder it sits in.

Deleting one works the same way. Open the home Applications folder, drag the app to the Trash, and it is gone. Removing the icon from the Dock alone does not delete anything, it only hides the shortcut, which is why old web apps pile up unnoticed.

Why the new app opens signed out

The first launch showing a login screen reads like a defect for roughly a minute. Then it becomes the reason to pick this route at all.

Because the web app keeps its own cookie store, two web apps built from the same service hold two live sessions at the same time. A work Google account and a personal Google account can both stay signed in, in two windows, with no account switcher and no profile juggling. The same holds for two Slack workspaces, two Notion accounts, or a client dashboard that is otherwise signed in to the wrong tenant every morning.

The cost is a one time sign in per app, and a second cost that is easier to miss. Password managers that live as Safari extensions do carry over, but anything that depends on a browser extension from the Chrome Web Store does not exist on this route at all. If the daily workflow leans on a Chrome only extension, that fact alone settles the choice before any other comparison starts.

Two smaller consequences follow from the isolation. Signing out inside the web app does not sign out Safari, and clearing Safari's website data does not sign out the web app. Each container has to be cleaned on its own.

The Settings panel, field by field

Open the web app, click its name in the menu bar, and choose Settings. The list is short and every item earns its place.

Application Name renames the app after the fact, which is the fix for the three identical "Google" icons. Application URL repoints it, and the Set to Current Page button is the practical way to use it: navigate to the exact view you want as the starting point, such as a filtered project board rather than the service's home page, then set it. Icon takes any image file from disk, which is how sites that ship a low resolution favicon stop looking blurry in the Dock.

Show navigation controls decides whether the toolbar keeps the back button, forward button, app name, Share button, and any Safari extension buttons. Turning it off produces a window that is nothing but the site, which suits a dashboard and does not suit anything where following a link and coming back is part of the work.

Show color in title bar lets the title bar pick up the site's own color, which is the cheapest way to tell two similar looking apps apart at a glance.

The Privacy tab clears that one site's cookies and caches without touching Safari. The Extensions tab enables or disables installed Safari extensions for this app specifically, so a content blocker can run in one web app and stay off in another.

Notifications, and the step that decides whether they work

Notifications are the most common thing to get wrong here, and the cause is always the same. The permission prompt has to be answered inside the web app, not in Safari. Apple's page is direct about it: respond to the website's notification request in the web app, and the web app then appears in Notifications settings.

Answer it in Safari instead and the permission attaches to Safari. The web app never shows up under System Settings, Notifications, and no red badge ever appears on its Dock icon.

If a site already has permission granted in Safari from months ago, the new web app may never prompt at all, because from the site's point of view the answer was already given somewhere else. The fix is to revoke the permission in Safari under Settings, Websites, Notifications, then open the web app and let it ask again.

Web apps are listed in System Settings by their app name rather than by URL, which is the second reason to name them properly at creation time.

Where the Safari route stops

The honest summary is that Add to Dock is excellent at the four things listed at the top and does not attempt anything past them.

	Safari, Add to Dock	A dedicated site to app tool
Cost	Included with macOS	Free tier or a paid license
Browser engine	WebKit only	Chrome, Brave, Edge, Vivaldi and others
Chrome Web Store extensions	Not available	Supported, toggled per app
Session isolation	Yes, one store per app	Yes, one profile per app
Custom icon	Yes, from an image file	Yes, usually with presets
Tab bar inside the app	Not available	Often optional per app
Several services in one window	Not available	Available in some tools
Setup time per app	Under a minute	Under a minute with a preset

Three gaps do the most damage in practice. The first is the extension gap already covered. The second is engine choice: a site that renders correctly in Chrome and badly in Safari cannot be fixed on this route, because there is only one engine available. The third is scale. Building four web apps by hand is pleasant. Building twenty five, each needing a name typed and an icon located, is an afternoon, and a tool with a preset library exists precisely because that afternoon is avoidable. The Supported services list gives a sense of which services usually come preconfigured that way.

None of that makes the Safari route a lesser choice. For a small set of sites that behave well in Safari and need nothing from the Chrome extension ecosystem, it is the shortest path available and it costs nothing.

Choosing which tabs deserve one

Turning ten sites into ten apps and using three of them is the usual outcome of enthusiasm. A tighter filter works better.

Look for a tab that is open every working day, that is opened by clicking rather than by following a link from somewhere else, and that keeps a session worth protecting. Mail, calendar, chat, an issue tracker, and a company admin panel usually qualify. Documentation, anything reached from search results, and anything used a few times a month do not, because the browser is genuinely better at those.

Then apply one exclusion. If the site needs a browser extension to be usable, needs a specific engine, or spends most of its time opening popup windows for authentication, it is a poor fit for a WebKit only container and belongs on a different route. A rundown of what the alternative containers control is on the Features page, and the Guide walks through the same choice with screenshots.

A second pass a month later is worth scheduling. Web apps that stopped being useful do not announce themselves, because removing the icon from the Dock hides the shortcut without deleting anything. Open the home Applications folder, look at what is actually there, and drag the dead ones to the Trash. Anything that survives two of those reviews has earned its place, and the set that remains is usually smaller and more stable than the set built on day one.

There is also a quiet benefit to keeping the count low. Each web app maintains its own cookie and cache store, so twenty of them means twenty sessions to keep signed in, twenty sets of notification permissions, and twenty icons competing for space in Command Tab. The routes that scale to twenty five apps exist for people who genuinely need twenty five. Most desks need between three and six, and the ones that matter are obvious after a week of use rather than after an evening of planning.

What to change first

Pick the single tab that gets clicked most often and make one web app out of it today, with a clear name and the URL pointed at the view actually used. Live with it for a week before building any more. If the sign in cost, the missing extensions, or the WebKit only rendering turns out to be the blocker, that is the point to look at what a Kagemusha style tool does differently, rather than deciding on either route in advance.