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

The build itself takes about three minutes. Rebuilds are what eat the afternoon, and they happen because four decisions get made by accident during setup instead of on purpose before it. Which Google account goes in. Which browser sits underneath. Whether the tab strip stays. Where the thing lives. Only one of the four is expensive to reverse, which is exactly the one people skip.

The four decisions to make before starting

The account comes first. Personal, work, or both in rotation. Two accounts in daily use means two apps, not one app with two logins, because a single container forces a sign out and sign in every time the context changes. If a work or school account is involved, check before building that an administrator has enabled Gemini for the domain. An account blocked at that level stops at the sign in screen no matter how the window was made.

The browser underneath comes second. A site to app tool can build on Chrome, Chrome Canary, Chromium, Brave, Microsoft Edge, Vivaldi or Opera. There is no obligation to match the browser used for ordinary work. Brave suits anyone who wants blocking on by default, Edge suits an office standardised around it. This choice can be changed later, but changing it swaps the profile underneath, which means signing in again.

The tab strip comes third. For a window that only ever shows one service, hiding it returns vertical space and removes the temptation to open anything else there. For a workflow that constantly jumps to Docs or a search result, keeping it saves a trip back to the main browser.

Placement comes fourth. A permanent Dock slot suits something opened several times a day. Something opened twice a week does better living only in the application switcher, because a Dock crowded with twenty icons costs the same hunting time that the tab strip did. A rule of thumb that survives growth: pin it only if it gets opened three or more times a day.

Making these four calls takes a few minutes. The reason to make them first is arithmetic. A single rebuild costs more than the few minutes, and rebuilding after the account decision is the worst of the set, because sign ins and saved passwords have to be sorted out alongside it.

Order of operations for the official build

On an Apple silicon MacBook running macOS Sequoia 15.0 or later, Google's desktop build is available at no cost. The sequence runs like this.

1. Open gemini.google/mac and download the macOS version.
2. Open the .dmg and drag the icon into the Applications folder.
3. Launch it and sign in with whichever account was chosen in step one above.
4. Check the invocation shortcut and change it if it collides with something.
5. Decide whether screen reading is wanted, and if so enable Accessibility for it under Privacy and Security in System Settings.
6. Open the Gemini menu, choose Check for Updates, and get to the current version.

The default shortcuts are published rather than discovered.

macOS: Customizable shortcut: press Option + Space for a mini chat, or Option + Shift + Space for the full chat. Source: gemini.google

Option and Space is popular real estate. Launchers, clipboard managers and input method switchers frequently hold it already, so the symptom of a collision is a keypress that does nothing or summons the wrong thing. Sorting it out on day one takes ten seconds. Sorting it out three weeks later involves remembering which utilities were installed in between.

Step six is not optional housekeeping. Updates are manual here, and the help notes that some features do not work when the app is out of date. Anything described in a guide that seems to be missing is worth checking against the version before anything else gets blamed.

Order of operations through the browser

For Macs outside those requirements, or for a second account, the install function inside the browser does the job. In Chrome:

1. Open gemini.google.com in the profile already signed in to the right account.
2. Open the three dot menu and choose Cast, save and share.
3. Choose Install Page as App.
4. Confirm it landed in Chrome Apps, inside the Applications folder in the home directory.
5. Right click the running icon and keep it in the Dock if it belongs there.

Choosing Create Shortcut instead produces a bookmark that opens in a tab. The two menu items swapped roles in Chrome 128 during 2024, so picking by name alone gives the wrong result.

Step one carries the whole weight of this route. The window inherits the profile that created it, along with its cookies, its signed in account and its extensions. Building two windows from one profile produces two windows signed in to the same account. Separating accounts here means creating a second Chrome profile first, then building one window inside each. Doing that in the other order means doing it twice.

Order of operations with a dedicated window tool

The third route asks more questions at build time and leaves more of them reversible afterwards. The build itself is a URL, an icon and a button.

1. Enter the URL and a name. A match against the preset list fills in the official icon and name automatically.
2. Pick which of the seven browser engines sits underneath.
3. Decide whether the tab strip and address bar are visible.
4. Pick the icon from the presets, an uploaded image, or the site favicon.
5. Press create. The .app appears in a few seconds.

Each app receives its own browser profile automatically, so separating two accounts means building twice from the same URL, with no profile setup beforehand. Extensions are toggled per app rather than per profile, which keeps a work password manager out of a personal window. The full list of options is on the Features page and the build flow is in the Guide.

Three settings are worth deciding during the build rather than after. Popup handling offers block everything, smart, or allow everything, and smart is the safe default for any service that opens sign in flows in a separate window. Restoring the previous session, tabs and scroll position included, is a toggle. So is a confirmation prompt on Command and Q, which earns its place for a window that sits next to something else in the Dock.

Deciding where notifications land

Site notification permissions belong to the profile. Splitting windows therefore splits notifications, so a work window can be allowed to interrupt while a personal window stays silent. Two windows sharing one profile cannot do that, which is one more reason the profile question and the account question are really the same question.

The macOS side lists notifications per application. A window built as a real .app appears in System Settings as its own entry, which makes it addressable by Focus modes. A tab sitting inside a browser has no such entry, so the only available choices are silencing the entire browser or receiving everything it sends.

Gemini is not a service that generates constant alerts, unlike an inbox or a chat tool, so this decision is low stakes on its own. It is still worth making early. Adjusting notifications later means tracing which permission in which profile is actually in effect, and that trace usually takes longer than rebuilding.

The three checks that matter a month later

Working on the day it was built and working in November are different claims. Three checks cover the difference.

Does it survive a browser update. Chrome ships an update every few weeks, and wrappers that do not follow that cycle lose their icons or stop launching. Opening the app the day after an update is the whole test. A design that references the installed browser rather than copying it needs no rebuild step at all.

Does the sign in persist. Quit the window, restart the Mac, open it again. Landing on a sign in screen means the profile is not being retained, and a window that demands a login every morning has given back everything it was built for.

Do the shortcuts still collide. If the official build is also installed, Option and Space may be contested. Whichever utility loses the argument should have its binding removed rather than left ambiguous.

Which decisions are actually reversible

Setup paralysis comes from treating every choice as permanent. Most of them are not.

Decision	Reversible later	What a change costs
Account	Add another app	Nothing
Browser underneath	Yes	New profile, sign in again
Tab strip visible	Yes	Nothing
Icon	Yes	Nothing
Popup handling	Yes	Nothing
Dock placement	Yes	Nothing

One row carries a cost. Everything else can be changed while using it, which means the correct approach is not to plan carefully but to settle the browser choice, build, and adjust the rest over the first week. Waiting until every preference feels certain simply delays the point at which the tab stops being hunted for.

The account row deserves a note. Adding a second app later costs nothing because nothing gets replaced: the first app keeps its profile and its sign in, and the new one starts clean. That is different from changing the account inside an existing app, which does involve a sign out and usually a round of password manager prompts.

What determines how many apps to build

The instinct is to count services. The better count is identities.

One service used by two accounts needs two windows. Three services used by one account can share a single window with several URLs opened as tabs at launch. Applying both rules at once collapses the number quickly: someone with a personal and a company Google account who uses Gemini, Gmail and Calendar ends up with two windows rather than six.

There is a practical ceiling worth respecting as well. Past roughly eight or ten dedicated windows, the Dock stops being a shortcut and starts being another list to scan, which is the problem the exercise began with. Anything below daily use is better reached through the application switcher or a launcher, and anything below weekly use is fine as a bookmark. Building a window for every service that ever gets opened recreates the tab strip in a different shape.

The second axis is whether something should survive the browser being quit. For anyone who clears every tab several times a day, whatever must stay signed in belongs outside that habit. For anyone who leaves a browser running for weeks, this distinction never surfaces.

The preset list is worth scanning before building anything by hand, since it is already covered under Supported services.

What to change first

Settle the account question before opening any menu, because it is the only one of the four that costs real work to reverse. Then build one window for the account used most, verify it survives a restart, and add the second only when the first has proven itself. Pricing and the size of the free tier are set out on the Kagemusha page.