A Grok desktop app on a Mac: one window for your chats

Anyone looking for a Grok desktop app on a Mac has usually already tried the obvious things. The Mac App Store has nothing from xAI. The site offers no installer. Searching turns up a handful of community projects on GitHub with names that look official and release notes that are not. At that point the question changes from where is the download to what is actually available, and whether the missing installer is the real problem.

The short version: Grok is a web product with phone apps, and xAI says so plainly. The longer version is that most of what makes a chat assistant unpleasant in a browser tab is fixable in about a minute, and the fix has nothing to do with waiting for a native client.

What xAI ships today

The product page for Grok states the supported platforms in one line: available on Web, iOS and Android. The download menu on xAI's own site lists two destinations, iOS and Android, with separate entries for Grok on X and Grok Bot. The plan comparison table on the pricing page carries a feature row reading Web, iOS, Android apps, and it is checked across every tier from Free to Enterprise. Three separate places on the site say the same thing, which is as close to an official answer as a missing product gets.

The App Store listing matches. Grok AI is published by X Corp., requires iOS 17 or later, and names iPhone, iPad and Apple Vision with visionOS 1.0 or later in its compatibility list. There is no macOS line. That absence matters more than it looks, because it also closes the side door: an iPad app can run on an Apple Silicon Mac only when the developer leaves that option on, and this one does not. A Mac App Store search for a Grok client from xAI or X Corp. returns nothing from either.

So on a Mac there are exactly two official surfaces. The web app at grok.com, and Grok inside X for anyone who uses it that way. Both are websites. Everything that presents itself as a desktop application is something else, and it is worth knowing what.

What unofficial desktop builds actually are

The community projects that show up in a search fall into two groups, and the distinction is useful before downloading anything.

The first group wraps the website. The application window contains grok.com, loaded by a bundled browser engine, with a native title bar around it. Nothing about the model, the rate limits or the account changes, because the thing doing the work is still the same web app on xAI's servers. These are wrappers, and a wrapper is a reasonable thing to want. It is just not a native client.

The second group talks to the API with a key the user supplies, which is a genuinely different product. Billing runs through the xAI platform rather than a Grok subscription, conversation history lives in that application rather than in the account, and features tied to the consumer product may be absent. That is the right tool for scripting and the wrong tool for someone who simply wants their existing subscription in a window.

For either group, three questions decide whether it is worth installing. Who publishes it, and is the build signed and notarised so macOS will open it without a bypass. Where do the credentials go, since a wrapper handles a live signed in session and an API client handles a key. And what happens when the site changes, because a wrapper with an abandoned repository breaks quietly the next time the login flow is updated.

None of that is an argument against community software. It is the reason many people end up preferring a general purpose tool that turns a website into a standalone Mac app: the same result, with one piece of software to trust instead of one per site.

The identity problem nobody mentions

Here is the part that makes Grok different from a bookmark, and it is the most common reason a wrapper gets searched for in the first place.

Session identity is browser identity. Grok in a browser is signed in as whichever account that browser holds, and Grok inside X is signed in as whichever X account is current. One browser keeps one default session per site. Anyone running a personal account and a work account, or an agency account alongside a client's, has already met the result: the wrong history in the sidebar, a subscription that appears to have vanished because the session belongs to the free account, or a link from a chat message opening under the identity that was current rather than the one intended.

There is a second version of the same problem, caused by the product having more than one front door. The download menu on xAI's site lists Grok on X and Grok Bot as separate entries alongside the phone apps, and in a browser those live at different addresses from grok.com while sharing the browser's cookies. Someone who reads posts in one place and asks questions in another is asking one browser to hold two related sessions that keep interfering with each other.

The usual workaround is a second browser profile, and it works. What it costs is a whole second browser window with its own tab strip and its own unrelated tabs, so switching identity means switching windows and then finding the tab again. It also means the two windows look identical in Command and Tab, because as far as macOS is concerned they are the same application.

An app with its own isolated session inverts that. One app, one permanently signed in account, chosen by which icon gets clicked. Two accounts become two icons with two names. Nothing is switched, and nothing opens under the wrong identity because the wrong identity has no session in that window.

What a browser tab costs a conversation

The individual costs are small. They repeat several times a day, which is the point.

The tab drifts. A chat opened in the morning ends up narrowed to a favicon in the middle of a tab strip, next to two other AI sites that look similar at that size. Reaching it is a scan rather than a gesture.

Command and W sits next to Command and Q. The conversation itself survives, because history is stored on the account rather than in the page, and that is worth saying plainly. What does not survive is the answer currently streaming, the position in a long thread, the file that was half attached, and whatever was typed into the composer but not yet sent.

Voice mode belongs to the browser. Microphone access is granted to the browser as a whole, so it is on for every site the browser opens, and the permission entry in System Settings names the browser rather than the assistant. A standalone app asks for the microphone as itself and appears under its own name in Privacy and Security, which is a cleaner arrangement for anyone who uses voice regularly.

Long tasks are the case where this bites hardest. Image and video generation, and the multi agent answers where several agents work in parallel, are the requests most likely to be left running while something else gets done. In a tab, that means leaving a tab alone and remembering which one it was, with an accidental reload or a closed window as the ordinary risk of a busy tab strip.

Notifications and Focus have the same shape. A rule aimed at the browser silences work mail and the assistant together, or silences neither. While they are one application, macOS has no way to treat them differently. The same goes for window behaviour: a full screen chat is a full screen browser window, competing with everything else that browser is doing, including a background tab that decides to start playing something.

Giving it a window of its own

macOS has two routes built in, and a third for the cases the first two do not cover.

In Safari, open grok.com, use the share control in the toolbar and choose Add to Dock. Apple's Safari guide describes what comes out: an icon in the Dock and in Spotlight, a simplified toolbar with no tab strip or address bar, and an app that can post its own notifications. The current Safari session carries over, which is convenient with one account and unhelpful with two.

In Chrome, the same idea lives in the three dot menu under Cast, save and share, as Install page as app. Google's help page covers managing and removing installed web apps. An app made this way belongs to the profile that created it, so the account question is settled by which profile did the installing.

The third route is a tool that turns a website into a standalone Mac app, wrapping a chosen engine rather than relying on whichever browser is built in. People choose it for two reasons: a separate session per app, so several accounts can each have a permanently signed in window, and control over what the window contains. The Features page covers which parts of a window can be switched on or off per app, and the Supported services list shows which sites already have presets.

	Browser tab	Safari Add to Dock	App with its own session
Finding it again	Scan the tab strip	Dock icon, Command and Tab	Dock icon, Command and Tab
Account used	The browser's current one	The browser's current one	Whichever is signed in per app
Microphone permission	Granted to the browser	Granted to the app	Granted to the app
Extensions inside the window	Yes	No	Depends on the engine
Focus and notifications	Whole browser	This app	This app

The second row is usually the deciding one. A single account makes the built in route entirely sufficient. Two or more accounts is the case where per app sessions are the only arrangement that stops the same question being asked every day.

What a window will not change

The limits are set by the subscription, not by the frame around the page.

Rate limits and model access are plan properties. xAI lists a Free tier at $0 per month with what it calls generous limits, SuperGrok at $30 per month for higher rate limits and frontier model access, and SuperGrok Plus at $100 per month for significantly higher usage, 1080p video creation and priority access at peak times. A Dock icon does not move any of those lines.

Offline use does not appear. The window needs the network, and without it the app fails exactly as a tab would. Nothing runs on the Mac itself, because nothing about a wrapper makes a hosted model local.

Speed is unchanged too. Responses stream at whatever rate the service produces them, and a native title bar has no effect on that. What changes is the part that was actually irritating: the assistant has an address, a stray keystroke stops costing an in flight answer, the microphone belongs to one app, and a Focus schedule can treat a chat window and a browser full of work as two separate things.

What to change first

Make one app for the account that gets used most, and give the second account its own app on the same day rather than waiting until the sessions collide. If per app sessions and extension support inside the window are what matter, that is the case for a tool such as Kagemusha over the built in Safari route, which is otherwise the fastest thing to try.