Claude as a Mac app: how to decide what you need

Claude lives in a browser tab for most people who use it every day. The tab drifts. It ends up behind fifteen others, and reaching it stops being one action: click the browser, scan a row of identical favicons, or open the tab search and type. Giving Claude a window of its own fixes that. The complication is that there are now at least three different ways to do it on a Mac, they cost different amounts, they break in different ways, and the right one depends on four things about how the Mac is actually used.

Three different things get called the same thing

The phrase "make Claude a Mac app" covers three routes that have almost nothing in common under the surface.

The first is the official desktop app. Anthropic ships it for macOS, Windows, and Linux in beta. The help centre lists macOS 11 (Big Sur) or higher as the floor, which is unusually low for an AI desktop app. It is a real installed application with a real Dock icon, and it carries features that the browser version does not have, including quick entry, which opens a capture box anywhere on the Mac when the Option key is double tapped.

The second is Safari's built in web app. Since macOS Sonoma 14, File then Add to Dock turns the current page into a standalone item. Apple documents where it lands and what it can do.

The web app is saved to the Applications folder of your home folder, and you can also open it from the Dock or Spotlight. Source: support.apple.com

The third is a site to app tool: a small utility that generates a standalone .app bundle around a browser engine and points it at one URL. Some of these sit on top of a browser already installed on the Mac. Others bundle their own engine.

These are not three brands of the same product. They differ in what they can sign into, what they ask the operating system for, what happens when the underlying browser updates, and what they cost. The four questions below sort them out faster than reading three feature lists.

Question one: how many Claude accounts are in play

This is the question that decides the most and gets asked the least.

Session state lives in a profile directory. One directory holds one set of cookies, which means one signed in account at a time. A single installed copy of any app, official or generated, that points at one data directory will hold one session. Switching accounts means signing out and signing back in, and whatever was open goes with it.

That is fine for one account. It stops being fine the moment a work seat and a personal account both exist. A Team plan seat and a personal Pro subscription are separate logins, and people who have both tend to need both live during the same hour: one for work context, one for anything that should not touch the company org.

Three answers exist. Run the official app for one account and use the browser for the other, which means the second account is back in the tab pile. Run two generated apps, each pointed at its own profile directory, which keeps both in the Dock with separate icons. Or accept the sign out and sign in loop. The route that supports the second answer is a tool that lets each generated app carry its own profile, and that is a property worth checking before paying for anything.

Testing this takes a minute and settles the argument. Open the account menu in whatever is installed now, switch to the second account, and watch what happens to the conversation that was on screen. If the answer is acceptable, question one is closed and the cheapest route wins. If it is not, the requirement is two windows with two profiles, and that requirement survives every other consideration in this article.

There is a related case that looks like the same problem and is not. Enterprise and Team organisations can enforce single sign on, and the sign in flow then goes through an identity provider rather than an email code. That flow is picky about what kind of browser it runs inside, which is a separate question covered further down.

Question two: how much of the Mac is being handed over

The official desktop app is no longer only a chat window, and this is the single largest difference between the routes.

Claude Cowork installs automatically with the macOS download. Anthropic's deployment notes for macOS state it plainly: Cowork is installed when Claude Desktop for macOS is installed. Cowork runs code in an isolated virtual machine on the computer, with file reads and writes limited to folders that have been connected. The Linux setup notes give a sense of the footprint, listing about 25 GB of free disk space for the workspace image and at least 8 GB of RAM, with the workspace using 4 GB while it runs.

Quick entry asks for more still. Apple's permission model requires explicit grants, and the documentation lists three: Screen Recording to capture screenshots and share application windows, Accessibility for quick entry itself, and Speech Recognition for voice dictation on macOS 14 or later.

None of that is a fault. For someone handing off multi step work on local files, that is precisely the reason to install it. For someone who sends twelve questions a day and wants them out of the browser, it is a large amount of machinery to accept, and it is the reason a plain window still has a place. A generated app that only renders claude.ai asks for nothing beyond notification permission, and its resident footprint is the browser engine it already shares with the browser that is running anyway.

The honest way to answer this question is to look at what Claude is actually used for on this Mac during a normal week. If local files are never involved, the heavier route is paying rent it does not need.

The case where the answer is neither

Some people want an app for one reason only: a single key that opens a fresh prompt. That goal can be met without choosing between the routes at all. Claude for macOS, Windows, and Linux responds to the claude:// URL scheme, and a link such as claude://claude.ai/new?q=Summarize%20this opens the desktop app with the prompt field already filled in. Anthropic documents the formats, the parameters each one accepts, and the note that prompt text passed in q is truncated to roughly 14,000 characters. Anything that can open a URL can trigger it, including a launcher, a shortcut, or a one line shell script. If the real requirement is speed of entry rather than a separate window, that is a shorter path than installing anything else.

Question three: what the window has to inherit

Two things decide whether a generated app feels finished on day one: whether the login carries over, and whether extensions still work.

A tool that builds on a Chromium browser already installed on the Mac inherits both. The generated app opens already signed in, because it reads the profile that the browser uses. Extensions such as a password manager continue to run. When the browser updates, the engine inside the app updates with it, because there is only one engine on the machine.

A tool that bundles its own engine inherits neither. The first launch starts at a login screen, extensions are gone, and each generated app carries a copy of an engine that updates on its own schedule. For a site behind single sign on, that first login is the part that hurts, because it can involve an identity provider, a second factor, and a device check.

Safari's web apps sit in between. Apple documents an Extensions tab in web app settings where Safari extensions can be enabled or disabled per app, and a Privacy tab that clears that site's data, including cookies and caches. The engine is Safari's, so it updates with the system.

There is a second inheritance question that only shows up later: notifications. Apple's guidance is specific and easy to get wrong. The notification permission request has to be answered inside the web app, not in Safari, for the web app to appear in Notifications settings and show an unread badge on its Dock icon.

Question four: what macOS is on the Mac

This question is boring and it eliminates options faster than any other. Support floors have moved apart, and several of the tools people recommend to each other will not install on a machine that is two or three years behind.

Route	macOS floor	Price as listed
Claude Desktop (official)	macOS 11 Big Sur	Free download, plan sold separately
Quick entry in Claude Desktop	macOS 12 (macOS 14 for voice)	Included, all plans
Safari Add to Dock	macOS 14 Sonoma	Free
Coherence X6	macOS 13.5	From $39.99, one time
Unite Pro	macOS 15	From $39.99, one time
Fluid 2.1	Mac OS 10.12	Free, $5 licence for extras

Two rows deserve attention. Unite Pro now requires macOS 15 or greater and states that it is designed for macOS 26 Tahoe, so an older machine is out regardless of budget. Safari's Add to Dock needs macOS Sonoma 14 or later, which rules it out on anything still running Monterey or Ventura. At the other end, the official Claude app and Fluid both reach a long way back.

Check the version first. It is one click in the Apple menu, and it turns a long list of candidates into a short one.

Who maintains it after the decision is made

Whatever gets chosen has to survive the next twelve months of updates without anyone thinking about it, and the routes differ sharply here.

The official app updates itself, with one documented catch worth knowing on a managed Mac. Anthropic's macOS deployment notes state that an install in ~/Applications can be updated without administrator privileges, while an install in /Applications needs administrator access and write permissions to the app and everything inside it. On a company machine without admin rights, the second case is how an app quietly falls behind. Administrators on Team or Enterprise plans can deploy the .pkg through Jamf, Kandji, or Microsoft Intune instead.

Generated apps depend on the tool's maintenance, and that is not a given. Nativefier, the command line tool that a large number of older tutorials still recommend, carries a note at the top of its README stating that it is unmaintained, and its repository was archived by the owner on 29 September 2023. It still runs for some people. Nobody is fixing it when it stops.

This is also where a subscription and a one time price diverge. Over three years, a one time purchase at $39.99 and a subscription at $5 per user per month are not close, and the subscription keeps charging whether or not anything new ships. The counter argument is real too: a subscription that is actively maintained repairs breakage that a dormant one time purchase will not. The list of what a given tool supports and how many apps its free tier allows is usually on the pricing page, and the Supported services page shows whether the sites in question are already covered without hunting for URLs.

What to change first

Answer question one on paper before spending anything, because a second account is the case that silently rules out half the routes. Then check the macOS version, which removes the rest. When the answer points at a generated window rather than the official installer, Kagemusha builds one on top of a browser already on the Mac, and its first three apps cost nothing.