Gemini as a Mac app not working: what to check, in order

Putting Gemini into the Dock on a Mac breaks in a short list of places. The download will not open. The icon appears but the window stays blank. Sign in refuses. The keyboard shortcut does nothing. The app cannot see the screen. Almost every report fits one of those five.

The difficulty is that identical symptoms come from different layers. One is hardware, one is account permission, one is a collision with another running app, one is a macOS privacy setting. Changing settings out of order produces a fix that cannot be explained and will not be repeatable next time. Working down the layers in a fixed sequence is faster than it looks.

Symptom to first place to look

Symptom	Where to look first
The downloaded app will not open	Chip type and macOS version
Icon appears, window stays blank	Network, and the first thirty seconds
Sign in never completes	Which kind of Google account is in use
A work account is refused	Generative AI setting in the admin console
The summon shortcut does nothing	Another resident app holding the same keys
The app cannot see the screen	Privacy and Security permissions
Every launch asks for login again	How the container stores site data

The rows are ordered by how much local control exists over them. The top rows are decided by hardware and administrators. The bottom rows are settings that can be changed in under a minute.

Layer one: the hardware conditions

When the downloaded file opens but the application never runs, this is almost always the layer.

The official Gemini desktop app requires Apple Silicon and macOS Sequoia (15.0) or later, along with 8 GB of RAM and about 200 MB of free disk space. Check the Apple menu, then About This Mac. If the chip line says Intel, no setting will change the outcome, and the time is better spent choosing a browser based route instead.

Where the file came from belongs to the same layer. The supported path is to download from gemini.google/mac, open the .dmg, and drag the icon into the Applications folder. Files pulled from unofficial mirrors that appear high in search results fail in ways that look like system problems but are not, because the thing being launched was never the app in question.

If macOS is simply too old, the choice is to update or to switch routes. On a managed machine where updates are withheld by policy, that decision does not belong to the person at the keyboard, and recognising this early avoids an afternoon of troubleshooting something unfixable.

Layer two: the account and the administrator

If the app launches but sign in never completes, the problem has moved from the machine to the account.

Two kinds of account are supported: a personal Google account under the user's own control, or a work or school account where an administrator has enabled Gemini. That second clause is where corporate machines stop. In Google Workspace, availability is governed by generative AI settings in the admin console, and when those are off the result is identical in every container.

The test takes thirty seconds. Open the Gemini page in a browser on the same Mac, signed in as the same account. If the browser stops at the same point, the container is irrelevant and the answer lies with whoever administers the domain. If the browser works and only the app fails, the problem is local and the next layer applies.

One more thing hides here for people signed into several Google accounts at once: the app may have picked a different account than expected. Signing out and back in, then reading the account name carefully, resolves a surprising share of reports.

A window that opens and stays blank

An icon in the Dock and an empty window behind it is a networking symptom, not an application one, and it is worth separating from the layers above because the fix is nowhere near the app.

Start with connectivity itself. Nothing here works offline. Open a browser on the same Mac and load any unrelated site. A failure there means the thing to repair is the connection, and Gemini is a bystander.

Next comes the shape of the network. Corporate and campus networks frequently route traffic through inspection systems or restrict which destinations can be reached, and the result can be a site that loads in a browser while an application's own requests do not complete. Switching to a phone hotspot and repeating the exact same launch settles it in about a minute. If content appears on the hotspot, the cause sits in the network, and no amount of reinstalling will move it.

The last possibility in this layer is impatience. The first load after signing in can take noticeably longer than later ones. Waiting a full thirty seconds before declaring failure avoids a rebuild that was never needed.

Layer three: a shortcut collision

The app runs, the keys do nothing. This layer has essentially one cause.

The official app binds a global shortcut by default:

You can also use the keyboard shortcut Option + Space to bring up the Gemini chat window after the app is installed. Source: support.google.com

That combination is popular real estate on macOS. Raycast uses option plus space as its default launcher key. Alfred users often move to it specifically to avoid colliding with Spotlight. Siri offers a hold option plus space variant among its keyboard options. Input method switchers sometimes claim it too.

When two applications want the same combination, the one that registered first wins, and which one that is depends on launch order. This is why the symptom is so often described as working yesterday and not today, which sends people looking for a fault that does not exist.

There are two fixes and both are quick: change the key in the other resident app, or change it in the Gemini app settings, which allows the binding to be customised. Pick based on which one gets pressed more often during a normal day. One related point prevents wasted effort: a web app created by Safari or Chrome has no global summon key at all, so nothing is broken when pressing keys does nothing there.

Layer four: permissions and language limits

When the app runs but cannot work with what is on screen, the layer is macOS privacy.

macOS requires explicit user consent before an application can capture other windows. The prompt appears the first time the feature is used, and declining it leaves the capability silently inert rather than showing an error later. Open System Settings, then Privacy and Security, and confirm the app appears and is enabled under screen recording. A restart of the app is required after granting it.

Some features are limited by language rather than permission. Speaking to a window to dictate and edit across apps is documented as English only. Testing it in another language and getting no response is expected behaviour, not a fault.

Voice input that produces nothing usually traces to the microphone permission in the same settings panel, or to macOS routing input to a different device. External interfaces and USB microphones are the common culprits, and the sound input setting resolves it faster than reinstalling anything.

Layer five: problems specific to wrapped pages

Containers built by Safari, by Chrome, or by a site to app tool produce their own symptoms, distinct from the official app.

Being asked to log in at every launch means the container is not retaining cookies, or is clearing them on quit. Containers are deliberately separate from the browser, so an existing browser session does not carry over. Sign in once, quit, reopen, and see whether it persisted. That single test separates a settings problem from a tooling limitation.

Links opening in an external browser is usually not a fault. Navigating to a different domain hands off to the default browser by design in most containers. Whether that can be kept inside the window depends on the tool, and it is a configuration question rather than a bug report.

Stale content calls for quitting and reopening first. If the view is still old, open the same URL in a browser and compare. Fresh in the browser and stale in the app points at the container. Stale in both points at the service, which saves the effort of rebuilding anything. The features page is a useful reference for which of these behaviours are configurable.

Notifications that never arrive

Missing badge counts belong to this same family, and the cause is that notification permission is granted per container rather than per service.

A grant made in the browser does not transfer to an app in the Dock. The container has to ask again, and a decline at that moment produces permanent silence with no error. If permission was granted and nothing still appears, check that the app is listed in System Settings under notifications, and check whether a Focus mode is filtering it out.

Rebuilding a container resets this too. Notifications that stop immediately after recreating an app have not broken; they are waiting to be allowed again.

Change one thing at a time

Troubleshooting by changing several settings at once produces a working system that nobody can explain, which guarantees a repeat performance next month.

Two rules are enough. Change one setting per test, because altering a shortcut and a permission together makes the result uninterpretable. And write down what was changed, including the original value, so the machine can be put back.

A third habit saves more time than either: confirm which route is actually in use before troubleshooting it. A surprising number of sessions go wrong because someone reinstalls the official app repeatedly on a machine that cannot run it, or hunts for a missing shortcut setting inside a Safari web app that never had one. The symptom list at the top of this page is sorted by layer for that reason. Reading the row and then confirming the route turns a vague fault into a specific question, and specific questions usually answer themselves.

Before rebuilding a container, be clear about what is actually at risk. Deleting a container removes its stored sign in state. Conversation history lives with the Google account and stays where it is. Knowing that the data is not tied to the icon makes the rebuild a cheap move rather than a risky one.

What to check first

Run the browser test before anything else: open the same page, on the same Mac, as the same account. Reproducing the fault in a browser means the container is not involved and the answer is upstream in the service or the account, so rebuilding the app would waste the afternoon. Working in the browser but not in the app means rebuilding is the fastest fix, and a Kagemusha style rebuild of a single site takes about a minute.