Gemini as a Mac app: what it does and where it breaks down

The phrase describes an outcome, not a procedure. Three separate routes lead to something that behaves like a Mac app, and they differ in what they can reach inside macOS, what they demand from the machine, and what happens on the day the browser restarts. Reading a guide for the wrong route is the usual reason this takes an afternoon instead of five minutes. Sorting the three apart first makes the rest short.

Three routes wear the same name

Route one is Google's desktop build. A .dmg from gemini.google/mac goes into the Applications folder, and what lands there is a native application wired into the permission system that macOS reserves for native applications.

Route two is the install function already inside the browser. In Chrome, Install Page as App takes gemini.google.com and gives it a window with no tab strip. What gets created belongs to the browser: same engine, same profile, fewer chrome elements around the page.

Route three is a site to app tool, which builds a real .app bundle that opens exactly one URL using a browser already on the machine. Mechanically it sits close to route two, but the Dock position, the icon, the profile assignment and the lifetime of the window are handled differently.

These are layers rather than rivals. Moving up the stack buys deeper access to macOS and costs stricter conditions. Anyone whose actual complaint is a hotkey wants the top layer. Anyone whose actual complaint is a tab strip forty items wide wants the lower ones. Most searches start from the second problem and land on pages about the first, which is where the confusion begins.

What the official build is for

Google's desktop application handles the things a browser window structurally cannot do.

  • Option and Space opens a mini chat, Option and Shift and Space opens the full chat, from inside any application. Both combinations can be changed in settings.
  • A menu bar icon and a Dock icon both launch it.
  • Pressing both Command keys at once passes the content of the frontmost window in as context.
  • Gemini Spark works on local folders that have been explicitly connected, organising files and summarising them into Docs and Sheets.

Each of those needs an application that can hold permissions of its own. A browser window cannot read another application's screen and cannot claim a system wide hotkey, because those are granted to applications, not to windows. The gap is about the size of the permission container, not about how the icon looks.

The requirements are narrow and published plainly. Windows 10 and later on x64 and ARM64, and on the Mac side Apple silicon MacBooks running macOS Sequoia 15.0 or later. There is no charge.

The Gemini desktop app is available in all languages and countries where the Gemini app is supported. Source: gemini.google

Two of the headline features are staged. Dictation into other applications and Gemini Spark are rolling out in English first, and the page notes that some features are available to users aged 18 and over with a Google AI subscription. For anyone working in another language, those two belong on a waiting list rather than in a decision made today.

What the browser install function produces

Route two changed in 2024, and the change still catches people. Create Shortcut kept its name and lost its job.

Starting in Chrome 128, the Create Shortcut menu item in More > Save and share now creates a bookmark on the user's desktop or homescreen. The previous behavior of this menu item on desktop has moved to the Install Page as App option. Source: developer.chrome.com

On a Mac the current path runs through the three dot menu, then Cast, save and share, then Install Page as App. The result is filed under Chrome Apps inside the Applications folder in the home directory, and it appears in the chrome://apps list. Anything sitting on the desktop with a browser icon is a bookmark instead.

What this route delivers is a window without a tab strip, a Dock icon and a slot in the application switcher. What it keeps is the profile. Cookies, the signed in Google account and the installed extensions all stay shared with the profile that created it. That single property is responsible for roughly half of the problems in the next section.

Where the process actually stalls

Five points account for most of the dead ends.

The machine. Intel Macs are excluded from the official build regardless of memory or purchase date, as is any Apple silicon Mac still on macOS 13 or 14. No separate build exists, so waiting changes nothing here.

The account. When a work or school Google account fails to sign in, the fix lives in the admin console, not on the Mac. An administrator has to have enabled Gemini, and the plan or licence has to include access to the app.

Two accounts at once. Creating two windows through the browser install function does nothing if both belong to the same profile. The second one opens signed in as the first. Separating them requires a second profile, not a second window.

The browser quitting. An installed window can share its lifetime with the browser behind it and close when that browser quits. Anyone who clears forty tabs several times a day meets this constantly.

Browser updates. Chrome ships an update every few weeks. Wrappers that do not follow that update cycle lose their icons or stop launching until they are rebuilt.

The first two cannot be solved on the Mac at all. The last three are questions of where a window lives, and they have answers. Telling them apart is easy: a failure inside Google's own screen is an account and plan question, while a failure in the macOS layer, a window that vanishes or an icon that resets, is a placement question.

There is a sixth point that appears later rather than at setup. Permissions are part of the trade with the official build. Letting it read a full page in a browser, or every file inside a connected folder, requires enabling Accessibility for it under Privacy and Security in System Settings. That is a broad grant, the same category used by automation tools and screen readers, and it is not divided into per feature switches. Nothing about that makes it wrong to give, but it deserves a deliberate decision rather than a reflexive click during setup, particularly on a machine that shows client material during the working day. Running the application without that permission is perfectly workable: the hotkey and the menu bar icon still function, and only the window reading features go quiet.

What a dedicated window tool covers, and what it does not

Route three targets those last three points and nothing else. It does not bundle a copy of Chromium. It builds an app that opens one URL using a browser already installed, which keeps the rendering engine current without any rebuild step.

The resulting window holds a fixed Dock position, appears in Command and Tab, and survives the browser quitting. Each app gets its own browser profile automatically, so two windows built from gemini.google.com hold two separate Google sessions, and extensions can be switched on per app rather than per profile. Seven engines can serve as the base: Chrome, Chrome Canary, Chromium, Brave, Microsoft Edge, Vivaldi and Opera. The list and the build steps are set out in the Guide, and the services already preconfigured are listed under Supported services.

The limits are equally clear. Such a window claims no global hotkey, reads no other application's screen and touches no local folders. Those belong to native applications holding system permissions. This route is not a replacement for the official build. It covers the Macs the official build will never run on, and the case where two identities need to stay open side by side.

What stays identical across all three

It helps to know which parts of the decision do not matter, because a surprising number of them do not.

The conversation is the same in every route. The model answering is chosen by the Google account and its plan, not by the container the page is rendered in. A question typed into the official application and the same question typed into a wrapped window reach the same service and come back with the same quality of answer. Nothing is computed on the Mac, so none of these routes work offline, and none of them reduce the load on the machine in any way worth measuring.

History and memory are also shared. Google states that chat history and memory sync across every device signed in to the same account, which means a conversation started on a phone continues in a desktop window and a conversation started in a wrapped window continues in the official application. Deleting one container deletes nothing but the container.

Image generation, video generation, Deep Research and Canvas behave identically as well, since all of them run inside the page. This is why the comparison table above contains no row for features: the differences sit entirely in the macOS layer, in how the thing is reached, where it lives and which identity it holds. Anyone comparing routes on the basis of what Gemini can do is comparing a constant.

The one genuine content level difference is the screen context feature, and it exists only because reading another application's window requires a permission that pages cannot request.

The three routes side by side

Official desktop build Browser install Dedicated window tool
Machine Apple silicon MacBook Any Mac running the browser Any Mac running the browser
macOS floor 15.0 Sequoia or later Browser support range Browser support range
Cost Free Free Free tier available
Global hotkey Yes No No
Reads front window Yes No No
Dock and switcher slot Dedicated Dedicated Dedicated
Account separation One per app Depends on profile One profile per app
Survives browser quit Unaffected Sometimes closes Unaffected
Extensions Not applicable Shared with profile Per app toggle

The table narrows the decision to one question: is the goal to reach deeper into macOS, or to fix where things sit and which account they hold. Only the top route answers the first. The third route gives the most control over the second. Running both at once causes no conflict, because chat history and memory sync across devices for the same Google account.

What to change first

Open About This Mac and read the chip line and the macOS version, because that decides whether the official build is even an option. If it is, install it and close the old tab. If it is not, or if two Google accounts are in daily use, give gemini.google.com a window of its own with Kagemusha, which covers the first three apps at no cost.

Frequently asked questions

Does turning Gemini into a Mac app cost anything?

Google's desktop build is free in every language and country where the Gemini app is supported, and the browser install function costs nothing either. Dedicated window tools vary: some allow a limited number of apps at no charge, some are one time purchases, and some are monthly subscriptions.

Can an Intel Mac do this?

Not through the official desktop build. It requires an Apple silicon MacBook running macOS Sequoia 15.0 or later, and Google ships no separate Intel version. The browser install function and dedicated window tools both work normally on Intel hardware, so those two routes stay open.

Why does a work Google account fail to sign in?

Usually because of administration rather than anything on the Mac. Work and school accounts need an administrator to have enabled Gemini, and the plan or licence has to include access to the app. Checking Mac settings will not surface the cause.

Is it a problem to run the official app and a dedicated window together?

No. Chat history and memory sync across devices whenever the same Google account is signed in, so either entry point continues the same conversation. A common arrangement is to let the official app hold the account used most, with a second window holding the other one permanently.

Back to all posts