Site specific browsers on the Mac, explained
The term shows up in old blog posts, in the changelog of a tool that has not shipped in years, and in the middle of a thread about keeping a support console out of the way of everything else. It sounds like jargon from another decade, and in a sense it is, but the problem it names has not aged at all. A browser is built to visit anything. Some sites are not visited, they are inhabited, and putting those two behaviours in the same window is what produces a Mac with forty tabs and no way to find the calendar.
What the term means and why it keeps coming back
The definition is narrow and useful.
Site-specific browsers simplify the more complex functions of a web browser by excluding the menus, toolbars and browser graphical user interface associated with functions that are external to the workings of a single site. Source: en.wikipedia.org
Read that as a subtraction, not an addition. Nothing is gained that the site did not already offer. What goes away is the address bar, the tab strip, the back button pointing at somewhere else entirely, and the constant possibility that the window is now showing a different site. What comes back in exchange is the thing macOS does well: applications with icons, positions, keyboard reachability and their own line in Notifications.
The idea has been rebuilt roughly once per decade. Bubbles brought it to Windows in late 2005. Mozilla published Prism in 2007, originally under the name WebRunner, and the project was listed as inactive by 2010. Fluid arrived on macOS in the same year and is still downloadable. Chrome added a command for creating application shortcuts in 2008. Apple shipped the route into Safari itself in macOS Sonoma. The pattern is that the feature keeps being reinvented because browsers keep growing sideways, and the fix for a browser that does everything is a window that does one thing.
The three routes that exist on a Mac today
| Safari, Add to Dock | Chrome, install page as app | Dedicated tool | |
|---|---|---|---|
| Requirement | macOS Sonoma 14 or later | Any current Chrome | A separate install |
| Engine | System WebKit | Chromium | Depends on the tool |
| Session | Isolated from Safari | Shared with the Chrome profile | Usually isolated per app |
| Two accounts, one service | Yes, sign in again in the app | No, it follows the profile | Yes |
| Custom icon | Yes, in the app's settings | No, taken from the site | Usually yes |
| Extensions | Safari extensions, per app | Chrome extensions from the profile | Varies |
| Editable address later | Yes, in the app's settings | No, recreate the app | Varies |
| Cost | Free | Free | Free trial or paid, varies |
The table settles the common case. The rest of this page is the detail that decides the uncommon ones.
Sessions are the part that surprises people
The single biggest behavioural difference between these routes is where the cookies live, and it shows up in the first five seconds. Apple states it plainly for the Safari route.
It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com
So the new app opens to a login screen. That is the feature, not a bug. An isolated session is what allows a second account of the same service to stay signed in at the same time as the first, in a separate window, with a separate icon, without a single profile switch. For anyone juggling a work identity and a personal identity on the same platform, this alone is the reason to use a site specific browser at all.
Chrome's route inverts that. The installed app runs inside the profile that installed it, so it is signed in immediately, autofill works, and extensions come along. The cost is that the app is downstream of the profile: rename or delete the profile and the app goes with it. There is no correct answer here. A client dashboard that must never touch a personal login wants isolation. A tool used with a single account all day is faster with the shared session.
Apple also documents where the result lands, which matters the first time one needs to be deleted or moved.
Web apps are saved to the Applications folder of your home folder. Source: support.apple.com
That is the Applications folder inside the home folder, reachable from Finder with Go then Home, not the one at the root of the disk. Apps created there do not appear where most people look first.
The rough edge is external links
Every tool in this category has to answer one awkward question: what happens when a link inside the site points somewhere else. A ticket that references a vendor page, a message containing an article, a confirmation mail with a payment link. A window with no tabs has nowhere to put that page.
The three usual behaviours are to open it in the default browser, to open it in a plain window inside the app, or to load it in place and quietly turn the site specific browser into a general one. The third is the worst outcome, because it destroys the property the whole exercise was for. Before committing to any tool, click one external link and watch where it goes. That single test separates tools that were designed for this from tools that wrapped a web view and stopped.
Two smaller edges are worth checking in the same minute. Downloads should land in the normal Downloads folder rather than somewhere inside the app. Printing should produce the same output as the browser, since some minimal web views ship a reduced print path. Neither is common enough to be a deal breaker, and both are annoying to discover three weeks later.
What the Mac gains once the site is an application
The subtraction described above is only half of it. The other half is everything macOS does for applications and refuses to do for tabs.
A site specific browser holds its own slot in Command Tab, so the site is reachable in two keystrokes whether or not the browser is even running. It appears by name in Mission Control instead of as one of nine identical browser windows. It can be assigned to a fixed desktop from the Dock icon's context menu under Options, which is what makes a chat window land in the same place every time. It can be added to Login Items so the morning starts with the window already open. And it gets its own line in System Settings under Notifications, which is what allows a Focus mode to let one site through while silencing the browser completely.
Two smaller behaviours are worth testing on the first day. Whether the Dock icon shows an unread badge, since Apple documents that behaviour for the Safari route but third party tools vary. And whether the app opens at the view actually used rather than the site's front page, which is purely a matter of pointing it at the right starting address. A support queue that opens on a marketing homepage every morning gets deleted within a week, and the reason is never the tool.
Rebuilding on a new Mac is part of the decision
Applications created this way live on one machine. They are not synced by an account, and a migration does not always bring them across cleanly, because the app bundle and the isolated session data are separate things. Anyone who has set up a Mac twice knows how this ends: the second machine has three of the seven apps, created at different times with different names.
The fix is to treat the set as a list rather than a collection of one off creations. Keep a plain text note with one line per app, holding the name, the exact starting URL, and the icon source. That single file turns an hour of rediscovery into a few minutes of rebuilding, whichever route is used.
This is also the honest way to compare tools. Feature lists are hard to judge before use, but recreation cost is easy: how long does it take to rebuild seven apps from a list. A route that reads a name and a URL and produces the app immediately costs almost nothing to leave. A route that needs twenty minutes of configuration per app has quietly become a dependency. The cheapest tool to adopt is the one that is cheapest to abandon, and that stays true whether the reason for leaving is a price change, an abandoned project, or a new machine.
Which sites deserve one
The failure mode is enthusiasm. Ten wrapped sites means ten icons, ten update paths, and a Dock that is harder to read than the tab strip it replaced. Three tests keep the list short.
It is opened every working day
Daily earns an icon. Weekly does not, because an icon that is rarely the target still has to be visually skipped every time the Dock is scanned. Bookmarks are free and cost no attention.
It needs to be reachable without going through the browser
A notification that should be seen, a window that should survive a browser restart, a click from the Dock while the browser is buried under other windows. If none of that applies, a pinned tab already solves the problem.
It needs an identity of its own
A second account, a client environment, an administrative console that should not be one keystroke away from the public site. Isolation is the one thing a pinned tab genuinely cannot provide, so this test is usually the decisive one.
Three to six sites typically clear all three. Checking the Supported services list first is quicker than configuring each one by hand, and the Features page is where to see whether a given tool covers icons, isolated sessions and link handling rather than just opening a window.
What to do about tools that stopped
This field is littered with abandoned projects, so the maintenance question belongs before the feature comparison. Nativefier, the command line tool behind most tutorials written between 2016 and 2022, was archived on GitHub on 29 September 2023 and is read only. Fluid still lists version 2.1 as a 6.3 MB download and states a requirement of Mac OS 10.12 or later. Apps already built with either tool keep running until something underneath them changes, and then they do not.
The useful question is not whether a tool is maintained today but how expensive it would be to leave. A tool that recreates a full set of apps from a list in a couple of minutes carries almost no lock in. A tool that took twenty minutes of configuration per app carries a lot. Read the Guide for the recreation path before building a dozen apps on top of any single tool, and check the Pricing page against what the free routes already do, because for two or three sites they often do enough.
What to change first
Take the site that gets opened first every morning, put it in its own window by whichever route is already installed, and live with it for a week. If the tab hunting stops and the notifications land where they should, add the next two. Kagemusha is one way to build that set quickly, and the built in Safari and Chrome routes cost nothing to test the idea with first.
Frequently asked questions
What is the difference between a site specific browser and a bookmark in the Dock?
A bookmark opens the site in the default browser as another tab, so it inherits the browser's tabs, session and clutter. A site specific browser is a separate application with its own window, its own entry in Command Tab, and on most routes its own cookie store. The visible difference is that closing the browser does not close it.
Do site specific browsers work on Intel Macs?
The built in routes follow the browser and the system, so Safari's version needs macOS Sonoma 14 or later on any Mac that runs it, and Chrome's version works wherever current Chrome runs. Third party tools state their own minimum, and older ones often list requirements from several releases back. Check the requirement line on the download page before installing.
Can two accounts of the same service be open at once?
Yes, on any route that gives each app an isolated cookie store, which includes Safari's Add to Dock and most dedicated tools. Create one app per account and sign each one in separately. Routes that inherit a browser profile cannot do this, because both apps read the same session.
What happens when the site is updated or redesigned?
Nothing special. The app loads the live site on every launch, so a redesign appears immediately, exactly as it would in a tab. The only case that breaks is a change of address, and then the fix is either editing the target URL in the app's settings or recreating the app, depending on the route.
Is it worth wrapping a site that already has a native Mac app?
Usually not. A native client generally handles notifications, offline state and system integration better than any wrapper can. The exception is running a second account alongside the native app, since the native client is often limited to one signed in identity at a time.