A Google Meet desktop app on a Mac: calls out of the tab strip

A call is starting in two minutes and the Meet tab is somewhere in a row of thirty. That is the moment people search for a Google Meet desktop app for Mac, and the results are unhelpful in a particular way: an App Store listing that turns out to be for a phone, Mac App Store entries with the Meet name published by developers nobody has heard of, and a Google help article whose title promises a download. Underneath all of it, Google's answer for a computer is consistent and slightly hidden. Knowing what it is takes five minutes, and acting on it takes five more.

What Google publishes for a computer

Google's own Meet help section sets out a six part setup series. Its second entry is about downloading the Meet app, and its third is specifically about downloading the Meet Progressive Web App on a computer. The existence of two separate articles is the whole answer: the app that downloads is the mobile one, and the computer route is a web application created from the browser.

The requirements article fills in the rest. Meet needs a Google account, and for work or school accounts a Workspace administrator has to have turned Meet on for the organisation. Creating a meeting requires being signed in to a Workspace account, while anyone inside or outside the organisation can join from a link. On the desktop side, Meet is supported on the current version and the two previous major releases of macOS, Windows, ChromeOS, and Ubuntu and other Debian based Linux distributions.

For browsers, the supported list is Chrome, Firefox, Edge and Safari, with the current version of each being the recommendation. That matters more than it looks, because a web application built on Meet inherits the engine it was created from, and the engine decides which Meet features are available.

The support window moves every year

The phrase "the current version and the two previous major releases" deserves a moment, because it is a moving line rather than a fixed one. Every autumn, when a new macOS ships, the oldest version in that set falls out of the supported range. A Mac that was inside it in June can be outside it in October without anything on the machine changing.

Two things follow. A Mac kept deliberately on an older release, which is common where a single piece of professional software demands it, will eventually be running Meet outside the supported range, and the symptoms of that are features quietly failing rather than a clear refusal. And a browser left unupdated has the same effect at the browser level, since the recommendation is the current version of each supported browser. Checking both numbers once a year, rather than after a call goes wrong, is the cheap version of this problem.

There is no Mac installer, and that is not a gap

It is worth being plain about this. A calling product that runs fully in a browser and is supported in four browsers does not need a native Mac client, and the absence of one is a design decision rather than an oversight. The practical problem is not that Meet lacks an app. It is that a browser tab is a bad container for something that has to be found in ten seconds while people are waiting.

The near misses in the search results

Two results waste the most time, and both can be dismissed by reading one line.

The iPhone version of Meet is free, requires iOS 18.0 or later, and stood at version 377.0 in late September 2026. Its listing does not include Mac desktop among its supported devices, which is the flag that permits an iPhone app to be installed on an Apple Silicon Mac. Because developers set that flag, the app does not appear when searching the Mac App Store, and no amount of a newer Mac changes it.

Searching the Mac App Store for Meet instead returns a cluster of applications with names built around the Meet brand, published by independent developers rather than by Google. On any store, the publisher line under the title is the check that matters, not the words in the title. Those applications are wrappers around the same web page, and whether one of them is worth using is a question about that developer's work, not about Google's software. The same job can be done directly, with control over the name, the icon, the engine and the account.

Three ways to get a Meet window

Route	Requirement	Signed in session	Control over icon and name
Safari, Add to Dock	macOS Sonoma 14 or later	Its own, separate from Safari	Set at creation, editable later
Chrome, Install page as app	Any recent Chrome	Shared with the Chrome profile	Managed by Chrome
A site to app tool	Varies by tool	Its own per app	Set freely

Apple documents the Safari route precisely. From macOS Sonoma 14 onward, opening the page and choosing File and then Add to Dock, or using the Share button and then Add to Dock, saves it as a web app into the Applications folder inside the home folder, so no administrator password is involved. It functions independently of Safari and shares no browsing history, cookies, website data or settings with it. Its settings panel carries an Application Name field, an Application URL field with a Set to Current Page button, and an Icon picker that accepts any image, and Apple notes that such an app can be added as a login item so that it opens automatically at login.

Chrome's route is More, then Cast, save, and share, then Install page as app, with an Install button appearing at the right of the address bar on some sites. Installed apps are listed at chrome://apps, where a right click offers Create shortcut and Launch at startup. Chrome also shows an App update available prompt when a site wants to change the app's name or icon, which can be accepted, ignored or used to uninstall. Uninstalling offers to delete the app's data from Chrome as well.

The third route exists because the first two build one window at a time and hand over most of the choices. Supported services lists the kinds of sites that end up handled that way, and the Guide covers the window behaviour once several exist.

The permission that has to be granted again

This is the step that surprises people, and skipping it produces a Meet window with no camera thirty seconds before a call.

macOS grants camera and microphone access per application. Apple's documentation describes the camera list in settings as showing the apps that have asked to use the camera, with a switch for each, and notes that the green light beside the camera glows while the camera is on and goes out when every app that can use it has been closed. A new web application is a new entry in that list, so it has to ask and be allowed on its own.

Google's own instruction covers the site side: on first use, starting a new meeting prompts for access and it has to be allowed, and if access was blocked earlier, the blocked camera indicator at the right of the address area offers an option to always allow the Meet address to use the camera and microphone. Doing both of those once, inside the new window, is the entire setup.

Test it before a real call

The test is not optional and takes a minute. Open the window, start a new meeting from it, confirm the camera preview appears and the microphone level moves, then leave. Do the same for screen sharing if presenting is part of the job, because sharing a screen is a separate permission that macOS also grants per application. A window that has passed those two checks is reliable. One that has not is a gamble taken in front of colleagues.

Why multiple accounts is the real reason to do this

The strongest case for a Meet window is not speed. It is that a browser profile holds one signed in Google session at a time in any comfortable sense, and a great many people have two.

A work Workspace account and a personal account. A contractor with accounts at two clients. An organisation where Meet is enabled by an administrator on one account and not on the other. In a single browser, running two means account switching, which is the step that goes wrong when a meeting link arrives for the account that is not currently in front.

Because Apple's saved web applications share no cookies or website data with Safari, two of them built on Meet hold two separate signed in sessions, each with its own name and icon. A window named for the client, or for work against personal, removes the switching entirely: the link is opened from the right window and the right identity is already there. An app installed from Chrome behaves differently, since it belongs to the Chrome profile that created it and shares that profile's session, which is fine for one account and does not solve two.

One caveat belongs here. A meeting link arriving by mail or chat opens in whatever browser macOS is set to use, not in the window, because that is an operating system routing rule. The habit that makes this work is opening the window first and pasting the meeting code into it, or keeping the default browser signed in to the account used most.

What the engine choice decides

Because a web application inherits the engine it was created from, the engine is a feature decision rather than a preference.

Google's documentation for background and visual effects lists the browser versions required on a Mac: Chrome M114 and up, Firefox 110 and up, Edge based on Chromium 114 and up, and Safari 16.4 and up. It also states that graphics acceleration has to be turned on. Separately, the effects article notes that some device based processing is available for Windows, ChromeOS and Linux machines meeting certain requirements, which is a reminder that not every Meet feature reaches every platform at the same time.

Hardware sets the floor underneath all of that. Google gives a minimum of a dual core processor and 2GB of memory for joining meetings and presenting non video content, and a minimum recommendation of a modern processor such as a 10th generation Intel i3, i5 or i7 from Ice Lake onward, or an AMD 3000 series Ryzen 5 or 7. Meet adjusts the experience to the performance of the device, so a machine near the floor loses features quietly rather than failing loudly. Checking what each option costs on the pricing page is worth doing only after the window itself is proven to work.

What to change first

Build one Meet window per Google account, name it for the account rather than for the product, and grant camera, microphone and screen sharing permission inside each window before the next real call. If two accounts are in play, choose the route that keeps their sessions separate, which is what a tool such as Kagemusha is for.