Turning a website into an app with Safari

Turning a website into an app with Safari takes about a minute. The menu item sits under File, called Add to Dock, and the result appears in the Dock with its own icon. The question worth answering before clicking it is a different one. Safari also offers profiles, which separate cookies and history in a way that sounds similar, and the built in route has limits that only show up later. Knowing what kind of container gets built, and where that container runs out, decides whether this is the last step or the first one.

The menu item exists only from macOS Sonoma 14

Treating a web page as an app is not new. Chrome has offered an install as app item for years, and dedicated wrapper tools predate both. Safari gained the capability in macOS Sonoma 14, which is why a Mac that has not been updated shows no such item under File. Checking the macOS version is faster than hunting through menus.

Apple describes the resulting container in one sentence that most of the practical consequences follow from:

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

The phrase that gets skipped is "functions independently". Read as a cosmetic feature, the first launch showing a signed out page looks like a defect. Read correctly, that isolation is the design, and it is the reason to choose this route for some sites and reject it for others.

There is no additional cost, since the feature ships with the operating system. Dedicated tools are sold both as one time purchases and as subscriptions. With a free route already installed, the sensible order is to build a few, find the specific thing that is missing, and only then look at what else exists.

What the container carries, and what it does not

Nothing is compiled and nothing is downloaded from the site. The same WebKit engine renders the same page, inside a different frame. Four things come with that frame.

A permanent Dock icon. A separate entry in Command Tab and Mission Control, so the site is one keystroke away instead of a hunt through browser windows. A window with no tab strip and no address bar, which removes the route by which a focused session turns into unrelated reading. And an individual row in System Settings under Notifications, so alerts from that one service can be tuned without touching every other site that has ever asked.

The list of things that do not come with it is just as firm. Pages do not load faster. Nothing works offline that did not before. No capability the site withholds from a browser tab appears because the frame changed. Memory use does not fall, and several always running web apps reserve their resources separately rather than sharing one browser process. Anyone expecting performance will be disappointed, and anyone trying to stop losing a site inside a row of tabs will get exactly what was intended.

Isolation cuts in both directions, and both directions are worth knowing before building anything. Signing out inside a web app does not sign out Safari, and clearing Safari's website data does not touch what the web app stored. Each container has to be cleaned on its own terms. The same applies to anything cached for offline reading, to site permissions such as camera and location access, and to whatever a site remembers about display preferences. Granting a permission once in Safari does not carry over, so the first few minutes with a new web app usually involve granting the same things again.

One consequence catches out anyone wrapping an internal company system. Single sign on that redirects through an external identity provider does not complete in every container, and the failure looks like an endless redirect rather than an error message. Testing one wrapped app end to end, from cold launch through the identity provider and back, is worth doing before suggesting the approach to a team.

The steps, and the two places people get stuck

Open the page in Safari, choose File then Add to Dock, type a name, and click Add. The Share button in the toolbar leads to the same item.

The name is the first place to be careful. It shows under the Dock icon, in Command Tab, in the Force Quit list, and in the Notifications list in System Settings. Building three apps from one company's services and naming all three after the company produces three identical rows that cannot be told apart later. Names like Mail Work and Calendar Personal remain readable long after the reason for creating them has been forgotten.

The second is the save location. The app goes to the Applications folder inside the home folder, not the shared one at the root of the disk. That is the entire explanation for the common report that the app was created and then could not be found. In Finder, choose Go, then Home, then open Applications there. Spotlight and the Dock find it either way. Deleting works from the same folder: drag the app to the Trash. Removing the Dock icon hides the shortcut and leaves the app in place, which is why unused web apps accumulate quietly.

The settings that actually matter

Opening the settings for a built web app exposes the application name, the application URL, the icon, whether navigation controls are shown, whether the title bar shows color, privacy and security options, website data clearing, and control over which Safari extensions are enabled.

Application URL is the one that earns its place. When a site moves the address behind its login, the container keeps requesting the old one, and the window comes up blank or bounces to a sign in page. Editing that field to the current address fixes it in under a minute, and knowing this saves rebuilding the app from scratch.

Navigation controls decide whether back and forward buttons appear. They are off by default. Admin panels with deep page hierarchies usually want them on. Single screen dashboards are better without them.

The extension control matters most to anyone whose browser of choice is already Safari. Password managers and content blockers installed as Safari extensions can be enabled per web app, which keeps a wrapped site usable for daily work. A workflow that depends on a Chrome only extension has no path here at all, and that fact alone rules out the Safari route for those particular sites.

Notifications have exactly one place to check when they fail to appear: the Notifications list in System Settings. Permission granted to a site inside the browser does not carry into the web app, so the app has to ask and be granted separately. Once it appears there, the payoff arrives: a single service can be allowed through a focus session while every other site stays silent, which is not possible while that site lives inside a browser that occupies one shared row.

Clearing website data from within the settings is the blunt instrument for a wrapped app that has gone wrong in a way the URL field does not explain. It signs the app out and discards what the site stored locally, which is closer to rebuilding than repairing, so it belongs after the URL check rather than before it.

Web app or Safari profile

Profiles keep history and cookies apart too, so the two features overlap in description and diverge in purpose.

	Safari profile	Safari web app
Scope	A whole set of sites	One site
Window	Normal Safari window with tabs	Standalone window, no tabs, no address bar
Command Tab	Still Safari, one slot	Its own slot
Notifications	Grouped under Safari	Its own row in System Settings
Best for	Switching context across many sites at once	One site kept open all day

A profile wins when ten work sites share one identity and need to be swapped in and out together. A web app wins when a single site is opened in the morning and closed at the end of the day. If the goal includes any of the three things a profile cannot do, appearing separately in Command Tab, being addressable per site in Notifications, or losing the address bar, then a profile is not a substitute.

A workable rule: sites closed as soon as the task is done belong in tabs or a profile. Sites closed only when the laptop is closed belong in the Dock.

The two also combine without conflict. A profile can hold the twenty sites that make up a working context, while the two or three that stay open regardless of context get promoted to web apps. Nothing about building a web app removes the site from Safari, and nothing about using profiles blocks Add to Dock. The decision is made per site rather than once for the whole machine, which is why a list of candidate sites is more useful here than a general preference for one feature over the other.

Three points where this route runs out

Sticking with the built in feature is the right answer until one of three things happens.

Icons come first. They can be replaced through settings, one image at a time, which is fine for four apps and tedious for a dozen. Distinguishable icons in the Dock are most of what makes the setup pay off.

Volume comes second. Beyond roughly ten wrapped sites, including internal dashboards and per client environments, the repeated manual work of naming, sourcing an icon, and adjusting settings becomes a task in its own right.

Outbound link handling comes third. Deciding whether a link inside the app opens in place or hands off to the default browser is not exposed by the built in route, and for a wrapped admin panel that behavior is often the difference between usable and irritating.

Hitting any of those is the signal to compare dedicated tools. Not hitting them means the built in feature is doing the job.

Comparing tools, if the built in route stops

Two things settle a comparison faster than a feature matrix. The first is the catalog: the range of ready made templates a tool ships shows which use cases it was built around, and checking whether the services in daily use are already listed takes a minute on the Supported services page, with the per app settings documented under Features and the actual workflow shown in the Guide. The second is the licence: one time purchase or subscription, how many Macs it covers, and the oldest macOS version supported.

What to change first

Add one site to the Dock. Choose the one that stays open longest, live with it for a week, and judge the separated login and the missing address bar on real use rather than description. If the icons, the volume, or the link handling are what fall short after that, the pricing and licence terms on Kagemusha are the next thing to read.