Google Chat as a Mac app: the official route and its catch

Search for a Google Chat desktop app and the results contradict each other within the first screen. Google's own download page says a desktop app exists for macOS. A Chrome Web Store listing appears alongside it, suggesting an extension is the answer. A forum thread says there is nothing. A GitHub project offers an unofficial client.

All of those are describing real things, and the confusion comes from the word app being stretched across four different mechanisms. The short version is that Google does publish a standalone Chat app for macOS, it is not an extension, and it carries a requirement that decides whether it is right for a given machine.

What Google publishes, and what it is called

Google's Chat download page offers the desktop app for macOS and Windows, alongside the mobile apps on Android and iOS. The Help Centre article describing it is direct about what the thing actually is:

For a simple way to use Google Chat, install the Google Chat standalone app in your Chrome Browser. This provides a streamlined Chat experience and is a Progressive Web Application (PWA) that you can open from your desktop. Source: support.google.com

So it is a web application installed through Chrome, not a separate program downloaded as a disk image. That explains why there is no installer to find: the install happens inside the browser.

The same page settles the extension question in one line, stating plainly that there is no Google Chat Chrome extension and directing people to install the app instead. Anything in the Chrome Web Store carrying a similar name is a third-party product rather than Google's.

Installing it takes a minute. Sign in at chat.google.com, then either click the install icon at the right of the Chrome address bar, or open the three dot menu and choose Install Google Chat. Once installed, the app appears on macOS in the Applications folder under the name Chat, and it can also be reached by entering chrome://apps in the address bar.

One quirk is worth knowing before wondering why the install option is missing. Google notes that if a Chrome shortcut to chat.google.com was created previously, the app installs automatically and the manual install option no longer appears.

The catch: Chrome has to be running

The system requirements section of that article contains the sentence that decides this for most people:

Chrome doesn't need to be your default browser, but it does need to be open to use the Chat standalone app. Source: support.google.com

That is a meaningful constraint on a Mac where Chrome is not the daily browser. The Chat window looks independent, sits in the Dock, and appears in Cmd+Tab, but it is running on a Chrome process underneath. Quitting Chrome to free memory, or simply never launching it, takes the chat app with it.

The article also lists Google Chrome 73 or later as the floor, which no current Mac will trip over, and a requirement that the machine allows Chrome extensions and apps to be installed at all. That last one is the reason the install silently fails on some work machines, and Google's guidance in that case is to contact the Workspace administrator rather than to look for a workaround.

Two conveniences come with the route. Launch at startup can be switched on by entering chrome://apps, right-clicking the Chat app and selecting Launch at startup. Removing the app uses the same menu, choosing Uninstall instead.

What the app asks for

Chat's web app manifest, the file that tells a browser how an installed version should behave, is worth a look because it explains why this particular Google service installs more cleanly than its siblings.

Chat declares a display mode of standalone, meaning a plain window with no browser furniture. It sets a launch handler that focuses an existing window rather than opening a second one, which is why clicking a Chat link does not scatter duplicate windows across the desktop. And it extends its scope to cover the chat area inside Gmail, so the same app can handle addresses under Gmail's chat path.

Compare that with the rest of the Google suite and the inconsistency becomes clear. Gmail and Google Calendar both declare a display mode of browser, which is a request not to be given a separate window at all. Installing three Google services through the same Chrome command therefore produces three different results, and Chat is the one that behaves the way people expect.

The routes, side by side

Route Independent of Chrome Own sign-in store Requirement
Official standalone app No, Chrome must be open Tied to the Chrome profile Chrome 73 or later
Chat inside Gmail No Shared with the browser None
Safari, Add to Dock Yes Separate macOS Sonoma 14 or later
Unofficial desktop client Yes Separate Trust in the project
Site to app tool Yes Separate per app A one-time setup

The second column is what people are usually buying without realising it. A window whose sign-in is tied to a Chrome profile inherits everything that happens to that profile, including being signed out when browsing data is cleared, and it can only hold one account at a time.

The route that needs no install at all

Chat also runs inside Gmail, and Google documents it as a supported way to use the service rather than as a fallback. For anyone who already keeps Gmail open permanently, this removes the question entirely: the conversations appear in a panel of the mail window, and there is nothing to install, nothing to keep open, and no second account to manage.

The cost is that mail and chat share one window. A message that needs answering now competes for the same screen as an inbox, and closing the mail window closes the chat with it. People who searched for a desktop app usually did so precisely because they wanted those two things apart, which is why this route tends to be mentioned and then dismissed.

It is worth knowing that the standalone app covers both addresses. Chat's manifest extends the app's scope to include the chat area under Gmail's domain, so a link pointing into Gmail's chat panel can open in the standalone window rather than launching a browser. The effect in daily use is that chat links behave consistently no matter where they came from.

When chat fails to load in any of these places, Google's troubleshooting page for Chat errors lists the checks in order: confirm the network is up, reload chat.google.com, confirm the browser is a supported one, and then uninstall browser extensions, since some extensions and apps block Chat from loading. The last item on the list is blocked domains and site permissions, which is the usual culprit on a machine where a content blocker or a workplace policy is filtering requests. Running Chat in a window with its own data store removes most of that list from consideration, because no extension is loaded in it.

Safari's Add to Dock, for a window that needs nothing else

On macOS Sonoma 14 or later, Safari can make a standalone window from any page without Chrome being involved at all. The command is File then Add to Dock, or the Share button then Add to Dock. The result is saved to the Applications folder inside the home folder.

Apple's description of what separates it from the browser is the part that matters for a chat service:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

The first launch therefore asks for a Google sign-in. After that, the session belongs to the app and nothing done in a browser disturbs it.

Notifications follow a rule that catches almost everyone on first setup. Apple is explicit that the notification permission must be answered inside the web app rather than in Safari, and only then does the app appear by name in Notifications settings. Once that is done, the unread count appears as a red badge on the Dock icon, which for a chat service is most of the point.

The app's settings panel, opened by clicking its name in the menu bar, allows the name and icon to be changed, the navigation controls to be switched off, and the site's stored data to be cleared from a Privacy tab. That last control is the fix for a session that has stopped loading, and it affects nothing else on the machine.

Two accounts at once

A personal account and a work account both signed in is where every single-profile route runs out. The official standalone app holds whichever account its Chrome profile holds. Chat inside Gmail follows the browser. A Safari web app holds one session.

Google's own answer within the browser is multiple sign-in, which switches between accounts in one window rather than running two windows side by side. That works, and for people who check the second account occasionally it is enough.

For two windows open at once, each needs its own data store. In practice that means either a second Chrome profile, which brings a second full browser along with it, or one built application per account. A site to app tool takes the second approach: each application keeps its own store, signs in once, and stays signed in regardless of what happens in any browser. The supported services list shows which sites already have presets, and the guide covers how the built windows handle notifications.

The unofficial desktop clients

Independent projects have wrapped Google Chat for years, and one of them appears high in the search results for this query. Its GitHub repository is marked as archived, which is a state the maintainer sets to indicate the project is no longer being worked on, and the README carries an announcement dated November 2022.

That is stated as a fact rather than a criticism. Wrapping somebody else's web service is ongoing work, because the service keeps changing, and volunteers reasonably stop. The practical point for a reader is that an archived project should be evaluated as it stands today rather than on the strength of its search ranking, since nothing further is coming.

The broader question applies to any unofficial client: it runs third-party code with access to a signed-in Google session. On a personal machine with public source code that may be an easy decision. On a machine governed by someone else's policy it usually is not.

What to change first

If Chrome is already open all day, install the official standalone app from chat.google.com and stop there, because it is Google's own route and it takes a minute. If Chrome is not part of the daily setup, or a second account needs its own window, build chat.google.com into a standalone application instead, using Safari's Add to Dock on macOS Sonoma 14 or later, or Kagemusha when the Mac is older or more than one account is in play.

Frequently asked questions

Is there an official Google Chat app for Mac?

Yes. Google offers a standalone Chat app for macOS, but it is a progressive web app installed through Chrome rather than a separate download. Once installed it appears in the Applications folder under the name Chat.

Does Chrome need to stay open for the Chat app to work?

Yes. Google states that Chrome does not have to be the default browser but does need to be open for the standalone app to run. Quitting Chrome closes the Chat window with it, which is the main reason people look for an alternative.

Is there a Google Chat extension for Chrome?

No. Google's Help Centre states directly that no Google Chat Chrome extension exists and points to the standalone app instead. Listings in the Chrome Web Store with similar names are built by third parties.

Why does Google Chat install as a proper window when Gmail does not?

Because each site tells the browser what it wants. Chat's web app manifest declares a standalone display mode, while Gmail and Google Calendar declare a browser display mode, which is a request not to be given a separate window at all.

Can two Google Chat accounts run in separate windows on one Mac?

Not through the official app or a single browser profile, since each holds one signed-in session. Two simultaneous windows need two separate data stores, which means a second Chrome profile or one built application per account.

What happens to the app when Google changes the Chat interface?

Nothing needs to be done, because every one of these routes loads the live site rather than a stored copy. Interface changes appear in the window as soon as they appear on the web, and no update to the app is involved.

Back to all posts