Claude as a Mac app: the setup order that holds up

Building the app is the short part. Whichever path is chosen, the click to click work takes a few minutes. The time goes somewhere else: signing in twice, discovering a week later that notifications never arrived, watching every link bounce out to the browser, and eventually deleting the thing and starting again. Every one of those outcomes traces back to a decision that was never made before the build. This is the order those decisions should be made in, followed by the build steps themselves and the short verification pass that catches the rest.

Decide in the order that is hardest to undo

Four things get decided: the account, the engine underneath, the window behavior, and the way the app gets called. That sequence is not arbitrary.

Cost of reversal is what sets the order. Changing the account after the fact means the stored session is in the wrong container, so the app gets rebuilt. Changing the engine means the bundle itself gets rebuilt. Window behavior and invocation, by contrast, are almost always editable from a settings panel after the app exists.

Working from the cheap end toward the expensive end is what produces rework. Icons get polished, window chrome gets tuned, and then the login problem appears and all of it is discarded. Working from the expensive end down means nothing built has to be thrown away.

Budget roughly ten minutes for the build and longer for the decisions. That ratio feels wrong and is correct.

Decision one: which account opens it

The first question is which identity this app is for.

If work and personal accounts both exist, this is the whole ball game. An app installed through a browser runs on the browser profile that created it, so the browser and the app always agree on who is signed in. Switching in one switches the other. Two accounts open simultaneously is not possible on that path.

Keeping both open at once requires a tool that gives each app its own profile directory. Then the browser can be signed into anything at all and the app never moves.

The test is simple. Anyone who moves between two or more accounts during a normal working day needs isolation. Anyone with a single account does not. When the answer is genuinely unclear, pick the isolating path anyway, because collapsing two isolated apps into one is trivial while splitting a shared session into two is a rebuild.

A managed laptop adds a second layer to the same question. On a company owned Mac, installing new software may be restricted outright, which quietly removes two of the three paths before any preference is expressed. The browser route survives that restriction because nothing new is installed and the result lands in the user Applications folder rather than the system one. Checking the device policy first takes a minute and prevents choosing a path that the machine will refuse to take.

There is a third wrinkle for anyone who shares a Mac with a family member. A shared macOS user account means a shared browser profile, which means an app built through the browser shows whoever signed in last. Separate macOS accounts solve it cleanly, and an isolated per app profile solves it without logging anyone out.

Decision two: what powers it

The engine decision has three answers, and each carries a published floor.

The official desktop build requires macOS 11 Big Sur or later. It covers exactly one service, so it is the shortest path when the target is Claude and nothing else.

The browser route costs nothing and needs no new software. Chrome states the path plainly.

On your computer, open Chrome. Go to a website you want to install. At the top right, select More Cast, save, and share Install page as app. Source: support.google.com

Safari offers the equivalent as Add to Dock from the File menu on macOS Sonoma 14 and later.

The third answer is a site to app tool, and choosing it means choosing an engine inside it. Chromium based means browser extensions keep working inside the app window. WebKit based means a lighter memory footprint and no extensions. An ad blocker or a password manager in daily use settles this immediately.

Note that the engine choice also sets the ceiling for the next decision. A path that has no concept of profiles cannot be configured into having one later.

Decisions three and four: window behavior and invocation

Window behavior comes down to three switches: the tab bar, link routing, and the quit prompt.

Hiding the tab bar produces a content only window that reads as a native app. Showing it allows several pages in one app. Chat only work argues for hiding it, while research that keeps reference pages open alongside argues for showing it.

Link routing decides where a clicked link lands: in place, in the default browser, or in another dedicated app. Frequent reference clicking argues for handing links to the browser so the app window stays on one thing.

The quit prompt matters more than it sounds. As a browser tab, Command Q was survivable. As a standalone app, it ends that app and anything half typed inside it.

Invocation is the fourth decision: Dock icon, keyboard, or menu bar. The official build ships a keyboard route already, where double tapping the Option key opens an input box over any application, available on macOS 12 and later. Its voice companion needs macOS 14 or later and claims the Caps Lock key, which is why it starts switched off. Wrapped apps generally offer a menu bar residency option and a setting to stay out of the Dock entirely. A full list of the switches a tool of this kind exposes is published in its Guide, and reading it before building removes most of the trial and error.

Building it

With four decisions settled, the build is mechanical.

For the official build, download the macOS version from the downloads page, open the file, launch from the Applications folder, and sign in. Both Apple Silicon and Intel versions are offered.

For Safari, open the site, choose Add to Dock from the File menu, confirm the name and icon, and add.

For Chrome, follow the menu path quoted above. Afterwards the app is listed at chrome://apps, where a right click offers shortcut creation and launch at sign in.

For a wrapper, enter the URL and a name, pick an icon, and create. Tools that ship presets skip the URL entirely and fill in the official icon and name from a list, which matters once the count of apps goes past one or two. The catalog of Supported services is worth scanning at this point, because the sites that will be turned into apps next month are usually already on it.

One detail on icons: a raw favicon often looks squarer in the Dock than the native apps around it. Tools that apply the macOS rounded mask handle this automatically. Otherwise an image has to be prepared by hand. It sounds cosmetic, and it is, right up until the Dock holds a dozen icons and the eye has to find one of them several times an hour.

Decide the total count before starting as well. The plan is almost never one app. A tool with a cap on how many apps the free tier can create will hit that cap in the middle of a session, and the moment to learn the number is before the first build rather than during the fourth.

The six checks to run in the first five minutes

This is the step that gets skipped, and it is the cheapest insurance available.

Sign in, watching whether the authentication window opens. A blanket popup blocker swallows it and the screen simply appears stuck.

Attach a file by dragging it in, confirming that local files reach the window.

Paste a screenshot straight from the clipboard.

Download something the app produces, and note where the file lands.

Grant notification permission inside the app, then confirm the app now appears by name in the macOS notification settings.

Quit with Command Q, reopen, and confirm the session survived. Failing this last one usually means the app is launching in a private or incognito mode that discards its profile on exit.

Run a seventh check when a hardware security key is in use, since recognition inside a standalone window varies by engine and window type. Finding that out on day one costs five minutes. Finding out in week three costs the whole setup.

The reason to run all of these on the first day rather than as problems appear is that the cost of a fix rises steeply with time. On day one, a failing check means changing a setting or rebuilding an app that contains nothing yet. After two weeks of daily use, the same failure means reconstructing whatever was missed in the meantime, and in the case of notifications there is no log to reconstruct it from. Silence is indistinguishable from nothing having happened.

Writing the results down is worth the extra minute when more than one app is being built. Most people do not build a single app and stop. The settings that worked for the first one become the template for the next five, and a short note saying which engine, which profile, and which link routing setting was chosen turns the second build into a copy rather than a fresh set of decisions. Tools that support saving default options for new apps automate exactly this, which is a small feature that pays back quickly at volume.

Maintenance and moving

Two items decide whether this arrangement survives past the first month.

Browser updates arrive every few weeks, and apps that borrow a browser binary can be left pointing at a stale path. A generic icon in the Dock is the early symptom, a refusal to launch is the late one. Tools differ on whether they detect the update and repair themselves or expect a manual rebuild each time.

Deletion is the other one. Dragging the .app to the trash usually leaves the profile directory behind, so removal through the tool is the clean route. The same applies when moving to a new machine: copying the bundle alone does not carry the signed in state, so an export and import feature is worth checking for in advance. Answers to both of these are normally published in advance, and the FAQ is faster to read than a rebuild is to perform.

Deep links are the last piece of maintenance worth knowing. The official build answers the claude:// scheme, so a shortcut or a script can open a new chat with the prompt field already filled, with prefilled text truncated at roughly 14,000 characters. Recurring, near identical prompts belong there rather than in muscle memory.

What to change first

Settle the account question today, before anything is built, because it is the only one of the four that cannot be edited afterwards. If one account and one site covers the situation, the official build closes the matter at no cost. If the answer involves two accounts or a row of other pinned tabs, pick a method that applies to all of them and check what the isolated profile approach covers in Kagemusha.