Making a website behave like an installed Mac app

To make a website into an app on a Mac, the quickest route is already installed. On macOS Sonoma 14 or later, open the site in Safari and choose File, then Add to Dock. The site gets its own icon in the Dock, its own window, and its own entry in Command Tab. Chrome offers the same idea through its menu, under Cast, save, and share, then Install page as app. A third route is a dedicated builder, a separate tool that wraps a site in its own app with more control over the engine, the session and the icon.

Which route fits depends on what the app is supposed to fix. A lost tab is solved by any of them. Two accounts side by side, browser extensions, or control over where links open are where the routes start to differ. This guide walks through each route with the steps and settings as documented by Apple, Google and the tool makers, checked on October 18, 2026, and then matches them to the problems they solve. This site is run by the developer of a site to app tool for macOS.

Route one: Safari's Add to Dock

Apple's page on Safari web apps on Mac lists the steps. It requires macOS Sonoma 14 or later.

1. In Safari, open the webpage to turn into an app.
2. From the menu bar, choose File, then Add to Dock. The Share button in the toolbar has the same item.
3. Type a name, then click Add.

The app is saved to the Applications folder inside the home folder, not the main Applications folder, and it can be opened from the Dock or Spotlight. To remove it, open that folder in Finder (Go, then Home, then Applications) and drag the app to the Trash.

The most important property is spelled out on the same page.

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

In practice this means a fresh login right after creating the app, and it also means a second account can live in the web app while the first stays in Safari.

Once the app is open, clicking its name in the menu bar and choosing Settings shows what can be changed:

• Application Name and Application URL, including a Set to Current Page button
• Icon, by choosing a new image file
• Show navigation controls, which toggles the back and forward buttons, the Share button and extension buttons
• Show color in title bar
• A Privacy tab to clear the site's data, including cookies and caches
• An Extensions tab to turn Safari extensions on or off for that app

Notifications work if the site sends them. Permission has to be granted inside the web app, not in Safari. When it is, the unread count appears as a red badge on the Dock icon, and the app shows up by name in System Settings, Notifications. Apple also notes that a web app can be added as a login item so it opens at login.

The cost is zero, and nothing else needs to be installed. The limits are the Safari engine itself and the fact that the app has no tabs. Apple's page says that when bookmarks or tabs are needed, the Share button offers Open in Safari.

Route two: Chrome's Install page as app

Google's help page on using web apps in Chrome gives these steps for a computer.

1. Open Chrome and go to the site.
2. At the top right, select More, then Cast, save, and share, then Install page as app.
3. On some sites, an Install button appears at the right end of the address bar instead.
4. Follow the on screen instructions.

The installed app opens in its own window and appears in the Dock. Settings live in the app window under More, then App info, then Settings. Chrome also documents a safety behavior worth knowing: when an installed web app tries to change its name or icon, Chrome shows an App update available notice and asks to review, update, ignore or uninstall. Google advises uninstalling the app if the change looks like an attempt to imitate a different app.

The same menu has a separate item, Create shortcut. According to Chrome's shortcut help, it creates a shortcut to the website with a chosen name. For a window that behaves like an app, Install page as app is the one to use.

The main difference from Safari is the session. An app installed from Chrome runs inside the Chrome profile it was installed from, so it starts already signed in wherever that profile is signed in. That skips the extra login, and it also means the app is not a separate account. For a second account, the app has to be installed from a second Chrome profile.

Chrome's page also notes that some web apps add features such as offline storage, notifications, file system access and icon badges, and that apps which work offline may not work completely without a connection. Those features come from the site. Installing the app does not add them.

Route three: a dedicated builder

Dedicated builders are separate Mac apps whose only job is to turn a URL into an app. Two broad designs exist.

The first design wraps the site in Apple's WebKit engine, the same engine Safari uses. Fluid is the long running example. Its home page states that Fluid is free, that any number of apps can be created, and that a $5 license unlocks three extras: pinning apps to the menu bar, userscripts and userstyles, and full screen mode. The page lists version 2.1 with a requirement of Mac OS 10.12 or later. The Fluid changelog shows 2.1.2 as the latest entry, and the 2.0 entry describes a rewrite onto Apple's WebKit2 API.

The second design uses a Chromium based browser as the engine. Some tools in this group bundle their own copy of Chromium. Others point at a browser already installed on the Mac, such as Chrome, Brave or Edge, so the app picks up that browser's updates. The practical draws of this design are that Chrome extensions such as password managers and ad blockers can run in the wrapped app, and that each app usually gets its own browser profile, so sessions stay separate the way they do with Safari web apps.

What a builder adds over the built in routes is mostly control:

• Choosing the engine per app
• A separate profile per app, with its own cookies and logins
• Extensions turned on per app
• Prepared names and icons for common services, so nothing has to be drawn
• Settings for popups, tab bars and where external links open

What it does not add is anything inside the page. Speed, offline support and notifications still depend on the site.

Which route fits which problem

Most people who search for this want one or two specific behaviors, not every feature. Matching the behavior to the route keeps the choice short.

What is needed	Safari Add to Dock	Chrome Install page as app	Dedicated builder
Own window, Dock icon, Command Tab entry	Yes	Yes	Yes
Works with no extra install	Yes, macOS 14 or later	Yes, with Chrome	No
Separate login from the main browser	Yes, by default	No, follows the Chrome profile	Usually yes, per app profile
Chrome extensions inside the app	No, Safari extensions only	Yes, from the profile	Yes on Chromium based tools
Replace the icon	Yes, in Settings	Follows the site's own icon	Yes
Tabs inside the app	No	No	Depends on the tool
Badge with unread count	Yes, if the site sends notifications	Yes, if the site supports badges	Depends on the tool and the site
Cost	Free	Free	Free tiers and paid licenses vary

A simple order works for most cases. Start with Safari's Add to Dock if the site works well in Safari and only one account is needed. Use Chrome's Install page as app if the site depends on Chrome extensions or is signed in through a Chrome profile already. Reach for a dedicated builder when two or more accounts on the same service must be open at once, when a specific engine is required, or when many apps need consistent names and icons.

Choosing which sites to turn into apps

The route matters less than the choice of site. A wrapped site pays off when it is opened from the same place every day, and pays nothing when it is reached through search.

Good candidates share three traits:

• Opened several times a day. Mail, chat, a calendar, a project board or an admin panel. Each saved tab search adds up.
• Kept open for long stretches. A window that stays put, with its own size and position, beats a tab that moves as other tabs open.
• Used with more than one account. Work and personal mail, or several client dashboards, are the cases where a separate session changes the day.

Poor candidates are sites found mid research, reference pages opened once a month, and anything usually reached by clicking a link in another app. Links clicked elsewhere open in the default browser, so the wrapped app sits unused.

Volume is the other trap. Past roughly ten wrapped apps, finding the right Dock icon starts to cost as much attention as finding the right tab did. Setups that last tend to hold three to five apps, with names that resolve in Spotlight after two or three characters, such as Mail Work and Mail Personal rather than two apps both called Mail.

What wrapping does not change

Some expectations are worth setting before any route is chosen, because no route changes them.

• Speed. The page is rendered by the same kind of engine as in a browser. Load time depends on the site and the connection.
• Offline use. Only sites built for offline use work offline. Chrome's help page says this directly about web apps.
• Features of the site. Notifications, badges and file access appear only if the site supports them. Many internal tools never implemented web notifications, so they stay silent in any wrapper.
• Redesigns. The app shows whatever the site becomes. A wrapped app does not freeze the old interface.
• Keyboard conflicts. Shortcuts defined by the site can still collide with standard macOS shortcuts.

The gain is in the container: a window that survives closing the browser, a single keystroke to reach it, a Dock icon that can carry a badge, and, on some routes, a session of its own.

What to change first

Pick the one site opened most often today and run it through Safari's Add to Dock or Chrome's Install page as app. If that leaves a gap, such as a second account or an extension that must run inside the window, check whether the site is listed among the supported services and compare the pricing of a dedicated builder like Kagemusha.