Put a web app on the Mac desktop and Dock

Gmail, Slack, Notion and a project tracker all live in the same browser window, and finding the right tab takes longer than the task itself. The obvious fix is to give each one its own icon, so it opens like a normal application instead of a tab buried behind twenty others. macOS supports this in two different ways, and they behave differently in the one place that matters most: which account the window opens with.

Three different things "add to desktop" can mean

The phrase covers three separate mechanisms, and choosing the wrong one is why some icons feel like real apps and others feel like a bookmark with extra steps.

The first is a web app, created by Safari or by Chrome. It gets its own icon, its own entry in the application switcher, its own window with no address bar, and its own storage. This is the one most people are actually looking for.

The second is a URL file. Dragging the padlock or the address from the browser bar onto the desktop creates a .webloc file. Double clicking it opens the page in the default browser, in a normal tab, in whatever account happens to be signed in there. It cannot be pinned to the application side of the Dock, because the Dock only accepts applications on the left of the divider and files on the right.

The third is a browser profile launcher: a small script or wrapper application that starts the browser with a specific profile. That approach is covered in detail on the profile launcher guides, and it solves a different problem. It launches a browser, not an app.

Only the first mechanism produces something that behaves like software. The rest of this article deals with that.

Safari: File, then Add to Dock

Safari has built this in since macOS Sonoma 14. Open the page, choose File in the menu bar, then Add to Dock. A dialog asks for a name and shows the icon the site provides. The result is saved into the Applications folder inside the home folder, which means it also shows up in Spotlight and in the application switcher.

The important part is what happens to the session:

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

That isolation is the feature. A Safari web app for one Google account will not be affected by a different Google account signed in inside Safari itself. It is also the first surprise: the new web app asks for a login on first launch, because it starts with an empty cookie jar.

The window is stripped down. Back, forward, share, and any Safari extensions that are installed. There are no tabs and no address bar. For sites that send push notifications, the Dock icon can carry an unread badge, which is the closest a browser page gets to behaving like a mail client. The web app can also be added as a login item so it opens at sign in.

Two limits are worth knowing before committing. The icon and name come from the site unless changed at creation time, and a page that is really a single view of a larger application, such as one specific Notion database, will still navigate anywhere the site links to.

Chrome: Install page as app

Chrome calls the same idea an installed web app, and the menu path has moved over the years. In current versions it is the three dot menu, then Cast, save, and share, then Install page as app. Sites that publish a proper manifest also show an install control at the right end of the address bar.

A web app is an app built for the web that you can access on any device. You can use web apps to have a website work as an app and access it on your computer or mobile devices through the launcher or home screen. Source: support.google.com

The list of installed apps lives at chrome://apps, and the launchers are written into a Chrome Apps folder inside the home Applications folder. Removing one is done from the app's own menu, with a checkbox that decides whether the stored data goes with it.

Chrome differs from Safari on the point that decides everything. A Chrome web app belongs to the profile that installed it, and it opens with that profile's cookies. Installing Gmail while the personal profile is active produces a personal Gmail icon. Installing it again from the work profile produces a second icon, with a second set of cookies, and the two do not collide. The catch is that both icons look almost identical in the Dock, so the account is identified by position and memory rather than by anything visible.

What each option actually gives

Safari web app Chrome installed app URL file on the desktop
Own window with no tabs Yes Yes No
Separate cookies from the browser Yes, always Per profile No
Dock badge for notifications Yes, for sites that send them Depends on the site No
Appears in the application switcher Yes Yes No
Extensions available Safari extensions Chrome extensions Browser default
Requires a specific macOS version Sonoma 14 or later No No

The table hides one asymmetry. Safari gives isolation for free but gives one instance per site, so two accounts on the same service means creating the web app twice and telling two identical icons apart. Chrome ties the app to a profile, which makes multiple accounts workable, but only if the profiles were set up properly first.

The account question is the one that bites

Most people arriving at this problem do not have one Gmail. They have a personal address, a company address, and a shared inbox, plus two Slack workspaces on different emails and a client's Notion.

Web apps handle that badly for a specific reason. The icon carries the site, not the identity. Six icons in the Dock for three services and two accounts each look like six near identical squares. Opening the wrong one is silent. Nothing warns that the message was drafted in the wrong account until it is sent.

Chrome's profile binding is the closest thing to a fix, and it works, but it moves the setup cost earlier. Every account needs its own profile before any app is installed, and every installation has to be done while the right profile is in front. Get the order wrong and the icon has to be removed and recreated.

There is also the reverse case. Some services never expected to be two apps at once. A tool that is documented for use in a browser and is checked against the list of supported apps will behave predictably in an app window, while a niche internal dashboard behind a single sign on portal may bounce out to the default browser mid login, which drops the isolation entirely.

Setting it up so the icons stay readable

The order of operations matters more than the clicks, because a web app inherits its identity at the moment it is created and there is no way to reassign it afterwards.

Decide the account before installing

In Chrome, open the profile that owns the account first, confirm it by looking at the avatar in the top right, and only then install. In Safari, sign out of the site inside Safari if the wrong account is currently active, because the isolation applies from creation onward and a session already carried into the window is awkward to unwind. Creating the web app from a private window is not a workaround. The installed app keeps its own persistent storage regardless.

Rename at creation time

Safari's Add to Dock dialog accepts any name. Use the account, not the service. "Slack" and "Slack" tell nothing apart, while "Slack client" and "Slack internal" survive a glance at the Dock. Chrome takes the name from the site, but the launcher in the Chrome Apps folder can be renamed in Finder like any other application, and the Dock picks up the new name after the icon is removed and added again.

Give the duplicates different icons

Two icons for the same service will be identical by default, which defeats the purpose. The launcher is a normal application bundle, so selecting it in Finder, opening the Get Info panel, and pasting an image over the small icon at the top left of that panel changes it. A coloured border or a different shade is enough. The goal is to be able to tell two windows apart without reading a single word, because the moment identification requires reading, the icon has stopped saving time.

Test the reset path

Web apps break in ordinary ways. A password change, a forced re-authentication, or a single sign on redirect can push the session out. Before relying on the setup, sign out inside the web app once and sign back in, and confirm the login completes inside the window rather than bouncing to the default browser. If it bounces, that service will keep bouncing, and it belongs in a browser profile rather than in an app window.

What the Dock icon does not solve

An icon fixes finding the app. It does not fix the rest of the day.

Switching still runs through the application switcher, and now that switcher holds ten entries instead of one browser. Notifications arrive per app, which is better for the two that matter and worse for the six that do not. Window position resets, so the layout of the workspace has to be rebuilt each morning unless every app is a login item.

The deeper issue is grouping. Work is rarely organised by service. It is organised by context: one client, one project, one shift. Those contexts each use four or five of the same services with different accounts. A flat row of Dock icons has no way to express that, which is why a set of windows grouped by context, described on the Workspaces page, ends up being the structure people build by hand with spaces and tags anyway.

Web apps are still worth setting up for the two or three services used constantly. They are a poor fit as a filing system for twenty. The test is simple. If a service is opened every day, in one account, and the window is expected to stay open, it earns an icon. If it is opened twice a week, or in whichever account happens to be relevant that day, it stays a tab and loses nothing.

What to change first

Start with the single service that is opened most and always in the same account, and give that one a web app. Leave everything else in tabs for a week and watch whether the switching problem moved or just changed shape. If the answer is that the accounts, not the tabs, were the real cost, a browser that keeps each account in its own window, such as SpaceDeck, is the next thing to try rather than a longer row of icons.

Frequently asked questions

Can a website be pinned to the Dock without making it a web app?

Not on the application side of the Dock. A .webloc file dragged from the address bar can sit on the desktop or on the right side of the Dock next to the Downloads stack, but it opens as a normal tab in the default browser. To get an icon that behaves like an application, the page has to be added through Safari's Add to Dock or installed through Chrome.

Will the web app stay signed in to the right account?

A Safari web app starts with no cookies at all, so the first launch asks for a login, and it keeps that session separately from Safari. A Chrome installed app uses the cookies of the profile that installed it. Installing the same site from two different Chrome profiles produces two icons that stay signed in to two different accounts.

Why is the install option missing from the Chrome menu?

The path changed between versions, and it now sits under Cast, save, and share rather than under More tools. If it is absent there, the browser is likely a Chromium based product that removed the feature, or the page is being viewed in a guest or incognito window, where installing is not offered.

Do web apps use less memory than tabs?

No. The page still runs in the same rendering engine, so a web app and a tab of the same site cost roughly the same. What changes is attention rather than memory. The window is dedicated, so the page is not competing with thirty other tabs for a strip of tab bar.

Back to all posts