The web apps a Mac never came with

A new Mac arrives with applications for mail, calendar, notes, photos, messages, and music. Almost none of them are the ones that get used. The calendar that matters is at calendar.google.com, the notes are in a shared workspace at a company address, the design files are in a browser tab, and the admin console for the tool that runs the business has no installer at all. The Dock is full of software nobody opens, and the actual working day happens inside one browser window holding between twelve and forty tabs.

Searching for web apps for Mac is usually an attempt to fix that. The results split into two very different things, and telling them apart is most of the work.

Two meanings of the same phrase

The first meaning is a service that publishes a real Mac application. Slack, Notion, Figma, Spotify, and many others ship native or Electron builds, and installing one is an ordinary download. If a Mac app exists for a service, use it. Nothing below improves on a first party application.

The second meaning is a website turned into something that behaves like an application. No new software is written and no features are added. A page that already worked gets taken out of the tab strip and given a window, an icon, and a place in the Dock. This is the only route available for services that never shipped a desktop build, and there are more of those than most people expect.

The important question is not whether a site can be made into an app, but what the resulting app is attached to. Every route below produces something that looks similar on day one and behaves very differently six months later, and the difference is always ownership: whether the app belongs to a browser profile or belongs to the Mac.

The services that never got a Mac application

Google is the clearest case. Google publishes Calendar, Gmail, Docs, Sheets, Drive, and Keep for Android and iOS and as web applications, with no desktop builds for macOS. Google's own help page for Calendar states plainly that it cannot be downloaded and installed on a computer, and points to offline mode in the browser instead.

That pattern repeats far beyond Google. Most business software sold in the last decade is delivered as a web application only. Billing systems, analytics dashboards, applicant tracking, support desks, warehouse consoles, and the internal tools built by a company for its own staff all live at addresses rather than in the Applications folder. Some of these are opened twenty times a day.

There is no reason to expect this to reverse. Shipping one web application is cheaper than shipping a web application plus a Mac build plus a Windows build, and the people deciding are not the people with forty tabs open.

So the realistic question is not how to get the missing apps. It is what to do with the sites that are never going to become apps.

Safari: Add to Dock

Starting with macOS Sonoma, Safari can save any webpage as a web app. Open the page, then choose File, then Add to Dock, or use the Share button in the toolbar and choose Add to Dock. Name it, click Add, and an icon appears in the Dock and in Spotlight.

What comes out is better than it first appears. The web app runs independently of Safari, with a simplified toolbar and no tab strip. If the site was already signed in, the web app is usually signed in too. It shares no browsing history, cookies, website data, or settings with Safari, which keeps it genuinely separate rather than cosmetically separate. Notifications arrive from it as they would from any other application.

The limits are worth knowing before building six of them. Safari web apps have no extension support, which rules out password managers that work as extensions and any workflow that depends on one. There is no profile management, so the separation is per site rather than per account. And the whole feature is tied to Safari, which is fine if Safari is the browser of choice and awkward if it is not.

Chrome: Install page as app

Chrome offers the same idea through a different menu. Open the page, click More at the top right, choose Cast, save, and share, then Install page as app. Some sites offer an install button directly in the address bar instead. Installed apps are listed and managed at chrome://apps.

The result opens in its own window without a tab strip, and gets an icon that can be kept in the Dock. Extensions installed in Chrome are available to it, which is the main practical advantage over Safari's version.

The catch is the profile. A Chrome installed app belongs to the profile it was created from, and carries that profile's sign in. Installing a work mailbox and a personal mailbox from the same profile produces two icons signed into the same account. Installing them from two Chrome profiles works, but then the profile has to be kept straight forever, and switching profiles in Chrome is not something everyone remembers to do at the right moment.

There is also a quieter failure. If the profile behind an installed app is reset or removed, whether by the person, by a browser problem, or by an administrator wiping a managed work profile, the app goes with it. The Dock icon frequently stays behind and simply stops working, which is a confusing thing to diagnose months later with no memory of how the icon got there.

Route	Own window	Separate session per app	Extensions	Survives a browser profile reset
Browser tab	No	No	Yes	Yes
Safari Add to Dock	Yes	Per site, not per account	No	Tied to Safari
Chrome Install page as app	Yes	Per Chrome profile	Yes	No
Site to app tool	Yes	Per app	Depends on the tool	Yes
Official Mac app, where one exists	Yes	Yes	Not applicable	Yes

Where the browser routes stop being enough

For one site and one account, either browser feature is fine, and nothing else is needed. Three situations break them.

The first is two accounts on the same service. A personal calendar and a work calendar, two Gmail addresses, two accounts in the same project tool. Browser installed apps inherit the profile's session, so the second account either signs the first one out or requires a second browser profile to be maintained by hand.

The second is a handful of sites rather than one. Six installed apps from one browser profile means six icons whose fate is decided by that profile. Whatever happens to it happens to all of them at once.

The third is telling them apart. Sites converted this way take their icon from whatever the site provides, which is often a small square logo designed for a browser tab. Six of them in the Dock at Dock size look like six coloured squares, and the muscle memory that finds an application by shape never develops.

A tool that turns a website into a standalone Mac app addresses the same three points differently. The output is an ordinary application bundle in the Applications folder, with its own name and its own icon, and its own isolated cookies and session. Two accounts on one service become two apps, both permanently signed in, with no switching and no shared profile between them. Nothing behind them can reset and take them all away. The Features page covers what per app profiles and icons involve in practice, and the Supported services list holds prepared entries for common sites, so the address and icon do not have to be assembled by hand each time.

Choosing which sites deserve one

Converting everything is a mistake that takes a fortnight to become obvious. A Dock full of twenty site icons is the same problem as a browser full of twenty tabs, moved one layer down.

Three traits make a site a good candidate. It is opened most days rather than most months. It is somewhere work is done rather than somewhere information is read once. And it benefits from being found instantly, either because it is checked constantly or because it raises notifications that matter.

Three traits make a site a poor one. It is reached by following links from elsewhere, in which case the link will open in the default browser anyway and the app will sit unused. It is read occasionally, where a bookmark is the right tool and costs nothing. Or it is a site that constantly sends the reader outward to other sites, since every outbound click leaves the app and lands in a browser, and the window that was supposed to contain the task becomes a starting point for a new pile of tabs.

A realistic count for most people is between three and six. Mail, calendar, the main work tool, and whichever admin console pays the bills. That set is small enough to learn by shape and position, which is the point of having icons at all.

Start with one, live with it for a week, and add the second only when its absence is annoying. Sites added because they were on a list, rather than because they were missed, are the ones that end up dragged out of the Dock a month later.

What none of this fixes

Being honest about the ceiling matters, because the wrong expectation turns a reasonable result into a disappointment.

Every route here renders the same web page in the same engine. Nothing gets faster. Nothing gains offline access it did not already have, and most web applications have very little. Keyboard shortcuts stay the site's shortcuts, printing behaves as it does in a browser, and a site that is heavy in a tab is exactly as heavy in a window of its own.

What changes is location and attention. The page stops competing with thirty tabs. It has a fixed place in the Dock and can be reached with a keystroke. Its notifications arrive under its own name rather than the browser's, which also means they keep arriving when the browser is closed. Switching between two accounts stops being an act of signing in and out. Those are the gains, and for a page opened twenty times a day they compound quickly. They are also the entire list.

What to change first

Pick the one site that gets opened most often and give it a window of its own, using Safari's Add to Dock or Chrome's Install page as app, which cost nothing and take a minute. Use it for a week. If it sticks, and particularly if a second account or a second site is already wanted, move to a site to app tool such as Kagemusha, where each app carries its own icon and its own session instead of borrowing a browser profile's.