Install a website as an app in Safari on a Mac, step by step

A site that gets opened every morning does not belong in a tab. It slides behind twenty others by eleven o'clock, it loses its scroll position whenever a session is restored badly, and its notifications arrive as a number on the Safari icon that says nothing about which site produced them. Since macOS Sonoma 14, Safari can turn that site into something the Dock treats as an application, with its own icon, its own window and its own badge.

The feature takes about fifteen seconds to use. It also has two consequences that are easy to miss until after the fact: the new app does not inherit the logins already sitting in Safari, and it does nothing about being signed in to the same service twice. Both are worth knowing before eight of these icons are sitting in the Dock.

What Safari actually creates

The result is called a web app. Apple's own page on the feature states that starting with macOS Sonoma 14, Safari can save any webpage as a web app, and that a web app shares no browsing history, cookies, website data or settings with Safari. That sentence is the whole design in one line.

Two things follow from it. The first is practical: opening a freshly created web app for Gmail or Notion or Linear usually lands on a sign-in screen, even though the same site was signed in inside Safari a moment earlier. The cookie store is new and empty. That is not a bug to work around, it is the point of the feature.

The second is where it stops. Because the isolation is documented against Safari, and not between one web app and another, nothing published says what two web apps built from the same URL do with each other's cookies. Test that pair before building a workflow on it rather than assuming either answer.

A web app is a real bundle, not a bookmark. Apple's documentation notes that web apps are saved to the Applications folder of the home folder, which is ~/Applications, and are removed by dragging them to the Trash from there. That location matters twice: it is where to look when an icon has vanished from the Dock, and it is the reason these apps survive a Safari update without needing to be rebuilt.

The steps

Decide the account before the first click

This is the step that gets skipped and then costs an afternoon. A Safari web app starts with an empty cookie store and then keeps whichever account signs in first. For a service with one account, that does not matter. For a service where a personal address and a work address both exist, the first sign-in decides what that icon means for as long as it stays in the Dock.

So pick the account first, and if two are needed, plan on two web apps and a way to tell them apart.

Add to Dock

Open the page in Safari. Not the site's marketing homepage: open the exact view that should appear on launch, because the URL captured is the one in the address bar. For a mail service that means the inbox. For a project tool it usually means one board rather than the account switcher.

Then choose File, then Add to Dock from the menu bar. The same command sits behind the Share button in the Safari toolbar. A small dialog appears with a name field and an Add button.

Name it at creation time

The dialog offers the page title, which is often something like "Inbox (12) - [email protected]" or just the product name. Replace it with the name that will make sense in Mission Control at four in the afternoon, and make it distinct if a second copy of the same service is coming. Renaming later is possible in Finder, but the Dock, Spotlight and the Cmd+Tab switcher all pick up the creation-time name in slightly different ways, so setting it once is cleaner than correcting it in three places.

Click Add. The icon appears in the Dock and the app appears in ~/Applications.

The settings worth fixing right away

A Safari web app has its own settings sheet, and the defaults are conservative. Apple documents that the name and the URL can both be changed after creation, that a custom icon can be supplied from a file, that the toolbar can be configured to show or hide the back button, the forward button, the app name and the Share button, that the title bar can be told to adapt to the site's colour, that the website's data including cookies and caches can be cleared from inside the app, and that Safari extensions can be enabled or disabled per web app.

Three of those are worth touching on day one.

The custom icon is the difference between a Dock that works and a Dock that has to be read. Two web apps for the same service arrive with the same favicon, at which point the visual shortcut is gone and every launch becomes a guess. Supplying two different images, or even the same image tinted differently, restores the thing the Dock is for.

Navigation controls are the second. A mail client does not need a back button and looks less like a browser without one. A documentation site that gets browsed rather than used does need one, and hiding it turns the window into a dead end where the only way back is the keyboard shortcut.

The extensions toggle is the third, and it is the one people discover late. Content blockers and password managers do not automatically apply inside a web app just because they are installed in Safari. If a password manager is how sign-in happens, enable it in the web app before concluding that the web app cannot sign in.

Notifications, which is why most people do this

The badge is usually the real motive. Apple's page describes it plainly: the number of unread notifications appears as a red badge on the app's icon in the Dock. What it also says is that permission has to be granted through the web app itself rather than through Safari.

That catches people who already allowed notifications for the same site months ago in Safari. The permission lives with the cookie store, and the web app has a new one, so the site has to ask again inside the new window. If the prompt never appears, it is usually because the site only asks after an interaction, so open the part of the site that would send a notification and let it ask.

One more detail decides whether the badge is trustworthy. A badge counts what the site reports as unread, and sites differ on what they count, so a mail service may badge every message while a chat service badges only direct mentions. Watching the number for a couple of days is the only way to learn what a given site means by it, and a badge that turns out to count everything is worse than no badge, because it trains the eye to ignore the icon.

There is a matching failure at the system level. A Mac in a Focus mode, or with notifications turned off for that app in System Settings, will show nothing regardless of what the site was allowed to do. Check the app's own row in System Settings before rebuilding the web app.

What this route does not fix

The Dock icon solves placement. It does not solve identity, and it does not solve scale.

Every web app made this way is a separate top-level application in the eyes of macOS, which is good for Cmd+Tab and bad for tidiness once there are ten of them. They do not group. They do not share a single quit. They each hold their own window state, and a Mac that restarts after an update will bring back the ones that were open in whatever order it likes.

Window placement is a related irritation. macOS remembers the size and position of a web app window per app, which is helpful, but a web app has no tabs and no second window of its own by default, so a link clicked inside it hands the page to the default browser instead. For a mail client that is usually correct behaviour. For a project tool where half the work is following links between issues, it means the web app becomes a launcher for Safari and the tidy window disappears within a minute.

Offline is the other gap, and it bites hardest on the exact services people install first. Google's documentation for working offline in Docs, Sheets and Slides states that offline files work in the Google Chrome or Microsoft Edge browsers, that the Google Docs Offline extension is required, and that only one account per browser profile can have offline enabled. A Safari web app is neither Chrome nor Edge, so a Safari web app for a spreadsheet is an online-only window, however app-like it looks.

Route	Own Dock icon	Separate login store	Offline for Google files	Cost
Safari, Add to Dock	Yes	Yes, empty at creation	No	Free, built in from macOS Sonoma 14
Chrome, Install page as app	Yes	No, uses the installing profile	Yes, with the offline extension	Free
Chrome, Create shortcut	No	No	Not applicable	Free, and from Chrome 128 it opens a new tab rather than a window
A browser built around one window per app	Yes	Yes, per space	Depends on the engine	A download, and a licence for the paid tiers

The row that surprises people is the third. From Chrome 128 onward, Create shortcut produces a bookmark that launches the page in a new tab, while Install page as app is the option that produces a windowed application. They sit near each other in the menu and do different things.

Removing one, and moving one

Deleting is the easy half. Open ~/Applications in Finder and drag the app to the Trash. That removes the bundle and its stored data together, which is why the same move doubles as a reset: delete and recreate is faster than hunting for a stuck session.

Moving a web app to another Mac is the half that does not work the way people expect. The bundle can be copied, but its logins were never inside it in a portable sense, so the copy arrives at a sign-in screen. Rebuilding half a dozen of these on a new machine takes about five minutes, and it is worth keeping a short list of the URLs used, because the URL captured in a web app is not always the URL a site advertises.

For anyone who ends up rebuilding this more than once, or who needs the same service open under two accounts at the same time, the per-site approach starts to show its cost. A browser designed so that each web app has its own window and its own session does the same job without a bundle per site, and the supported apps list and the features page are the places to check whether the specific services in play are covered. The pricing page is where the free and paid boundaries sit.

What to change first

Install two web apps, not eight, and choose the two that send notifications worth seeing. Give them custom icons in the settings sheet before closing it, then use them for a week and count how often the wrong window still comes forward. If the answer is daily, the problem was never placement, and a browser that keeps each account in its own workspace is the next thing to try, such as SpaceDeck.