How to turn a website into an app on a Mac

The trigger is almost always the same. There are thirty tabs open, three of them are the ones that actually matter, and finding the calendar again takes two seconds of squinting at favicons. The fix people reach for is to turn the site into an app so it has its own icon, its own window, and its own place in the Command Tab list. macOS supports that in more than one way, and the routes are not interchangeable. They differ in where the login lives, whether notifications work, and what happens the day the browser updates.

What "an app" actually means here

A website turned into an app is still a web page rendered by a browser engine. Nothing is compiled and nothing is downloaded from the site's servers beyond what a normal visit downloads. What changes is the container around it.

A real container gives you five things. A separate icon in the Dock. A separate entry in Command Tab and Mission Control, so the window can be reached without hunting through browser windows. A window with no tab strip and no address bar, which means there is nothing to accidentally navigate away to. A separate entry in System Settings under Notifications, so alerts from that one site can be tuned without touching every other site. And, on some routes, a separate cookie store, which is what lets a second account of the same service stay signed in at the same time.

Any route that gives you fewer than those five is a bookmark with a nicer icon. That distinction is the whole decision. Before comparing menus, decide which of the five you actually need, because the cheapest route covers three of them and the most involved route covers all five plus icon control.

The three routes side by side

	Safari, Add to Dock	Chrome, Install page as app	Dedicated wrapper
Requirement	macOS Sonoma 14 or later	Any current Chrome	A separate purchase or install
Cookies and session	Not shared with Safari	Shared with the Chrome profile that installed it	Own store, isolated
Second account of same service	Works, sign in again inside the app	Blocked, it follows the profile	Works
Notifications	Yes, with an unread badge on the Dock icon	Yes, through Chrome	Depends on the tool
Custom icon	Yes, in the app's own Settings	No, taken from the site	Usually yes
Where it is stored	Applications folder in your home folder	Managed by Chrome, listed at chrome://apps	Normal application bundle
Breaks when	Safari or the site changes its URL	The Chrome profile is deleted or renamed	The tool stops being updated

The table is the short answer. The rest of this page is why each row is there.

Safari's Add to Dock, and the thing people miss about it

Since macOS Sonoma 14, Safari can save any page as a web app. Open the page, choose File then Add to Dock from the menu bar, or use the Share button and pick Add to Dock, then name it and click Add.

The part that surprises people comes right after. Apple's support page is explicit about what the result is:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

So the first launch shows a signed out page, and the login has to be done again inside the app. That reads like a bug for about a minute, then it turns into the reason to use this route at all. Two web apps built from the same service hold two separate sessions, which covers the personal and work account problem without profile switching.

The saved app lands in the Applications folder inside your home folder, not the system wide one, and it is reachable from the Dock and from Spotlight. Open it, click its name in the menu bar, choose Settings, and you can change the display name, replace the icon with any image file, point the app at a different URL, and switch the toolbar's navigation controls off so the window is nothing but the site. There is a Privacy tab for clearing that site's cookies and caches, and an Extensions tab for turning your installed Safari extensions on or off for this app specifically.

Notifications have one trap. The permission prompt has to be answered inside the web app, not in Safari, for the app to appear in the Notifications list in System Settings and for the unread count to show as a red badge on the Dock icon.

Chrome has two menu items and they do different jobs

In current Chrome, both live under the three dot menu, in Cast, save, and share. Install page as app creates a web app, which is the one worth using. Create shortcut now only makes a launcher that opens the page as a normal tab, because the old "Open as window" checkbox is gone from that dialog.

Anyone following an older tutorial ends up in the wrong dialog and concludes the feature was removed. It was split. Installed apps are managed at chrome://apps, and a wrongly created one is removed from the app's own three dot menu with the Uninstall command, which also offers to delete the data it stored.

The trade-off is the session. A Chrome web app runs inside the profile that installed it, so it inherits that profile's logins, cookies, and extensions. If you already run one Chrome profile per client, that is convenient, because the app is signed in the moment it opens. If the goal was to separate one service from everything else, this route does not deliver it. Deleting or renaming that profile also breaks the app.

Extensions are the honest advantage on this side. Content blockers, password managers, and clipping tools you already trust keep working in the app window, and that matters when the site is heavy or ad supported.

Wrappers, and where they stop

The third route is a tool that builds a standalone application bundle around a URL, usually on Chromium through Electron or on the system WebKit engine. Some are command line projects, some are commercial apps, and there is a spread in price, in whether they are still maintained, and in how much of the window they let you control.

What they buy you is control. Isolated storage per app so several accounts coexist. An icon you choose. A window that opens links to other domains in your default browser instead of drifting inside the app. Sometimes a menu bar mode, a keyboard shortcut that summons the window, or a per app user agent. If a list of ready made presets exists for the service you have in mind, most of that configuration is already decided for you, and browsing a tool's Supported services list before installing anything is a fast way to see whether your service is covered.

Three limits are worth knowing before you commit. Some identity providers refuse to complete a sign in inside an embedded browser view, so single sign on can fail in a wrapper that a normal browser handles fine. Protected video services need a decryption module that many wrappers do not ship, so streaming can play audio only or refuse outright. And a Chromium based wrapper carries its own engine, so five wrapped sites means five engines resident in memory, while a WebKit based one borrows what macOS already has loaded.

Choosing which sites deserve this

Wrapping everything recreates the original problem in the Dock instead of the tab strip. A site is worth an app when it is opened almost every day, when it does one job rather than being a starting point for browsing, when its notifications are ones you would act on, or when you need two accounts of it at once. Chat tools, project boards, ticket queues, mail, internal admin panels, and the AI assistant you keep going back to all fit.

A site is not worth an app when it is a research destination that spawns twenty tabs, when it is visited weekly rather than daily, when it depends on an extension a given route does not support, or when it is protected video. Documentation, search engines, and shopping sites belong in the browser.

A practical way to decide is to look at your browser history for one week and count how many separate days each site appears on. Five days out of five is an app. Two days is a bookmark. Sites that appear every day but always as the second step of something else, opened from a link rather than from intent, stay in the browser too.

There is also an order effect. Wrap the noisiest site first, live with it for a week, and see whether the tab count actually fell. If the same site is still being opened in the browser out of habit, the app was not the problem and adding four more will not help. A feature list such as Features is easier to read once you know which of the five properties above you are actually short of.

What breaks later

Three failure modes account for most of the complaints. A site changes its URL scheme and the app opens a redirect page forever, which is fixed by editing the app's URL, or rebuilding it if that route has no settings. A sign in flow bounces through a second domain and the app either blocks it or leaves it stranded in a window with no address bar, which is why toolbar navigation controls are worth leaving on for anything with a corporate login. And an operating system upgrade changes how the browser stores data, which for a browser based route is fixed by the browser and for an unmaintained wrapper is not fixed at all.

None of that is a reason to avoid the approach. It is a reason to keep the build reproducible, meaning you know which route made each app and can make it again in two minutes.

Two small habits cover most of it. Keep a plain text note of which route built which app, because six months later the menu you used is not obvious from the icon. And when a corporate tool is involved, build one app, use it through a full sign in cycle including the point where the session expires, and only then build the rest. A single sign on flow that fails on day fourteen is far more annoying than one that fails on day one, and the only way to find it is to let a session run out.

It is also worth deleting aggressively. These apps cost almost nothing to rebuild, so anything that has not been opened in a month should go. The value of the Dock comes from being able to find an icon without reading, and that stops working somewhere around a dozen items.

What to change first

Pick the single site you open most and give it one app by the cheapest route that covers what you need, then use it for a week before touching anything else. If the sticking point turns out to be a second account, a custom icon, or links leaking back into the browser, that is when a dedicated builder such as Kagemusha earns its place.