Using Google Meet as a real Mac app

The search for a Google Meet desktop app usually starts the same way. A calendar reminder fires, the meeting link opens a new tab somewhere in a row of thirty, and the first forty seconds of the call are spent hunting for the window that has the camera in it. The obvious fix is an application: something in the Dock, something Cmd+Tab can reach, something that is not a tab.

There is a route to that on a Mac, and Google documents it. It is not a download in the sense most people mean. Knowing which of the available windows Google actually supports, and which of them survives a week of real meetings, decides whether the result is a genuine improvement or a second place to be signed out of.

What Google ships for a Mac, and what it does not

Google's own setup sequence for Meet lists two installable things. One is the Meet mobile app for Android and iOS. The other is the Google Meet Progressive Web App, and the help page for it is explicit about the platform: "This is for your computer only and must run on Google Chrome version 73 and up." The same page lists the operating systems the PWA is supported on: Windows, macOS, Chrome OS and Linux.

There is no separate native macOS build in that list. The computer answer is the PWA, and Google describes it in plain terms: "The PWA and Google Meet have the same features. They automatically update when your Google Chrome browser updates."

That last sentence is the important one and it is easy to read past. The PWA is not an independent application that happens to show Meet. It is a Chrome window with the browser furniture removed, running on the Chrome that is installed on the Mac, updating when that Chrome updates. Chrome does not have to be the default browser to install it, but Chrome has to be open at the time, and Chrome has to stay installed afterward.

For browsers generally, Meet's requirements page names Chrome, Mozilla Firefox, Microsoft Edge and Apple Safari, and says Meet supports the current version and the two previous major releases of macOS. Safari is on the supported list, which matters for the second route below.

Meet has no native Mac application, and the official desktop answer is a browser window with the browser hidden. Everything that follows is a question of which browser is doing the hiding.

Four ways to give Meet its own window

The routes differ in engine, in what data the window can see, and in what has to stay installed for the window to keep working.

Route	Engine	Signed in separately from the browser	Needs another app installed	Cost
Tab in Chrome or Safari	That browser	No	The browser	Free
Google Meet PWA	Chrome	No, shares the Chrome profile it was installed from	Chrome	Free
Safari Add to Dock	WebKit	Yes, no cookies shared with Safari	Nothing beyond macOS	Free
Site to app tool	Depends on the tool	Depends on the tool	The tool, to build it	Paid

The PWA is installed from meet.google.com by clicking Install in the address bar, after which Google says the Meet app appears in the app dock. Removing it is done the same way Chrome removes any installed web app, from the menu inside the app window, with an option to delete the site's data from Chrome at the same time.

Safari's route is a macOS feature rather than a Meet feature. Apple's documentation puts the starting line at macOS Sonoma 14: open the page in Safari, then choose File > Add to Dock, or use the Share button and choose Add to Dock. The resulting app lands in the Applications folder inside the home folder.

What the Safari window can be adjusted to do

A Safari web app is not a locked screenshot of the page. Apple documents a Settings panel reachable from the app's own name in the menu bar, holding the application name, the URL the app opens, the icon, whether the toolbar shows navigation controls, and whether the title bar takes its colour from the site. A Privacy tab clears that app's cookies and caches without touching Safari, and an Extensions tab turns individual Safari extensions on or off for this app alone.

For a Meet window that last control is more useful than it sounds. Extensions that rewrite pages or block scripts are a common cause of a camera preview that never appears, and being able to leave them enabled in Safari while switching them off for the meeting window is a cleaner answer than disabling them everywhere.

The two free routes are not variations on one idea. They differ on the single point that causes the most trouble later, which is whose signed in session the window is using.

The account question decides which route fits

Apple is direct about what a Safari web app shares with Safari, which is nothing: "It shares no browsing history, cookies, website data, or settings with Safari." For a Meet window this cuts both ways.

The cost is a fresh sign in. The Google account already signed in to Safari is not signed in to the new app, so the first launch is a login, and the six month expiry of that login is a separate event from the one in the browser. For anyone who signs in with a security key or a second factor tied to a device, that is one more thing to do once.

The benefit is that the window has its own account, permanently. Someone with a personal Google account and a Workspace account can build two Meet web apps and keep one signed in to each, without the account picker at the top right of meet.google.com and without wondering which identity is about to join a client call. The isolation Apple describes is the mechanism that makes that possible.

The Chrome PWA behaves the other way. It belongs to the Chrome profile it was installed from, which is why Chrome offers to delete the site's data from Chrome when the app is uninstalled. Anyone already using separate Chrome profiles for work and personal accounts can install the PWA from each profile and get the same separation. Anyone running a single Chrome profile with two Google accounts inside it gets a window that inherits exactly the ambiguity they were trying to escape.

Camera, microphone and screen sharing get asked again

This is the part that surprises people during the first meeting held from the new window, and it is not a bug in anything.

macOS grants hardware access per application. Apple's own instructions for camera access describe a list in System Settings under Privacy and Security where access is turned on or off for each app individually, and the list only contains apps that have asked. A new Meet app is a new entry in that list. The permission granted to Chrome or to Safari months ago does not carry over, and Safari's website permissions live somewhere else again, under Safari > Settings > Websites > Camera.

In practice this means the first call from a newly built Meet window will produce permission prompts for the camera and the microphone, and screen sharing will need its own approval before a presentation will work. The sensible move is to build the window, join a test meeting alone, and grant all three before the call that matters. Doing it during the first real meeting costs the opening two minutes and sometimes a restart of the app.

Notifications follow the same per app logic and are worth setting deliberately. Apple notes that a web app's Dock icon can show the number of unread notifications, and that the permission has to be answered inside the web app rather than in the browser for that to work. The web app then appears in System Settings under Notifications by its own name rather than by a URL, which is what makes per app rules possible: a Meet window that is allowed to interrupt, and a different web app that is not.

The link that still opens in the wrong place

Building the window solves the "where is the meeting" problem only if the meeting link lands in it. Most links do not.

A Meet link clicked in Google Calendar, in an email client, or in a Slack message goes to the Mac's default browser, because that is what a link does. Google documents the handoff that follows: from the browser, on the meeting green room page, the browser bar shows Open app, which passes the meeting to the installed PWA. That works, and it is also an extra click on every single meeting, which is the friction the original search was trying to remove.

There are two ways around it. The first is to start meetings from the app instead of from the link, which works when the pattern is a recurring standup at a fixed URL and does not work for meetings scheduled by other people. The second is to change what opens links, which is where the routes separate again. The built in options do not offer a rule for this. A site to app tool is usually where the setting lives, because deciding whether a click inside the window stays in the window or leaves for the default browser is a choice the builder makes rather than a choice the browser makes.

Worth being honest about the scale of this one. It is a click, not a failure. It matters to someone in six meetings a day and not at all to someone in two.

Which route survives a working week

For a single Google account, on Chrome, with no strong feeling about which browser runs video calls, the PWA is the shortest path and it is the one Google supports. It installs in two clicks and it will not drift out of date, because it updates with the browser.

For two accounts, or for anyone who would rather not have a video call depending on whether Chrome is installed and current, the Safari route trades a one time sign in for a window that stands on its own. It requires macOS Sonoma 14 or later, and it uses WebKit, which Meet supports.

For anyone building more than one of these, the arithmetic changes. Each hand built window is a separate set of steps: open the page, name it, pick an icon, sign in, grant camera, grant microphone, grant screen recording, decide about notifications. That is fine once. Across a Meet window, a calendar window, a mail window and a task board, the case for building them from presets rather than one at a time starts to make itself, and that is the job a site to app tool exists to do.

What to change first

Build one Meet window today, join an empty meeting from it, and grant the camera, microphone and screen recording permissions before they are needed live. Use the Chrome PWA if there is one Google account, and Safari's Add to Dock if there are two. If the window holds up and the next three sites on the list deserve the same treatment, Kagemusha builds them from presets instead of by hand.