Can the browser engine be changed after the app is built?

Not as a setting. Switching effectively means creating the app again, which is why the decision belongs at the start. The three questions that settle it are whether 1080p sending is needed, whether camera framing is needed, and whether browser extensions have to work inside the call window.

Should a specific meeting room be used as the app's address?

Better not. Meeting URLs change each time, so a room specific app stops being useful once that meeting series ends. The Meet home page is the durable choice because it always offers the code field and the new meeting button, and invites can be pasted in directly.

The camera works but screen sharing does nothing. What was missed?

The macOS Screen Recording permission for that specific app. Open System Settings, then Privacy and Security, then Screen Recording, and enable the app there. It is granted per application, so the underlying browser being authorised does not cover it, and the app may need restarting afterwards.

What should be tested before relying on the app for a real meeting?

Start a meeting alone and check four things in one pass: microphone pickup, camera image, sharing a single window, and applying a background effect. If all four pass, nothing is left to discover during a real call. The whole check takes a few minutes.

Google Meet as a Mac app: the setup order that holds up

Building the app is not the hard part. Paste a URL, pick a name, and the window exists in under a minute. The reason so many of these end up unused, or fail in front of other people, is that several choices made during that minute cannot be undone afterwards, and several permissions do not live where people expect. What follows is ordered by when a decision has to be made, not by which button gets clicked. Answer them from the top and the first real meeting will not be the first time the thing runs.

Step zero: check that this Mac is inside the supported window

Doing this last is expensive, so it goes first. Meet supports the current version of macOS and the two previous major releases. A Mac sitting four or more releases back is outside that range, and no amount of window building changes it.

Browsers have a boundary too. The named options are Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari, each in its current version. If the browser that will act as the foundation is several versions behind, update it before building rather than after. Updating the foundation later changes how the finished app behaves, which makes any troubleshooting harder to attribute.

One more condition applies to work accounts. In a Google Workspace organisation, an administrator has to have Meet turned on. Testing with a personal account, finding that everything works, and then switching to the work account is a common way to discover this at the worst moment. Confirm Meet opens in the account that will actually be used.

The engine comes first, because it cannot be revised

Whether the window runs on a WebKit engine or a Chromium engine is not a preference setting. Changing it means building the app again from scratch, and it determines which Meet features are available inside.

Three questions settle it.

Does 1080p sending matter? Firefox and Safari do not support it. The account edition also gates it: Business Plus, Business Standard, Education Plus, the Enterprise editions, Google One with 2TB or more, Google Workspace Individual, and Teaching and Learning Upgrade.

Does camera framing matter? The automatic recentring feature lists Chrome M91 and up, or Chromium based Edge 91 and up, on Windows, Mac, and Linux, with WebGL and graphics acceleration enabled.

Do browser extensions need to work inside the call window? Transcription helpers and recording aids added as extensions belong to a browser profile, and a WebKit based window has no equivalent.

Backgrounds and visual effects are the exception that stops this from being a one sided choice. On a Mac they require Chrome M114 and up, Firefox 110 and up, Edge 114 and up, or Safari 16.4 and up. Safari qualifies, so effects alone are not a reason to pick an engine.

Decision	Revisable after building?
Browser engine	No, rebuild required
Account the window signs into	Only by clearing storage and signing in again
Front door address	Usually yes, in app settings
Name and icon	Yes, but system permission lists keep the old entry
Camera, microphone, screen permissions	Yes, at any time
Login item and notifications	Yes, at any time

Everything in the top two rows is worth ten minutes of thought. Everything below can be changed on a Tuesday afternoon.

The account, the address, and the name

Three choices cluster together because they are all made in the creation dialog.

The account determines whether the window opens straight into a meeting or into a switcher. Using both a work and a personal Google account usually justifies two windows with separate storage, so that neither signs the other out. The cost is that every permission below has to be granted twice. Using one window means picking whichever account carries more meetings and leaving the other in a browser tab.

The address is where a lot of these go wrong. Meeting URLs change every time, so pinning one specific room produces an app that expires the day after that meeting does. The Meet home page is the stable front door: it carries the field for pasting a meeting code and the button for starting a new call, so an invite link can be pasted straight in without touching a browser. That path works even when link routing has not been configured.

The name matters more than it looks, because it propagates. It appears in the operating system's notification list and in the Screen Recording list under Privacy and Security. Renaming later can leave a stale entry behind in those lists. Putting the service name first and the distinguishing word second also helps, since the application switcher is usually navigated by first letter, and two apps both starting with "Work" defeat that.

Finally, sign in immediately after building. A window with its own storage always starts signed out, and doing the two factor step while a meeting waits is avoidable. Hardware security keys deserve a specific check here. A physical key that works in the browser may need to be tapped again for the new container, and some setups prompt differently inside an app window than inside a tab. Finding that out during setup is a minor detail. Finding it out sixty seconds before a call is not.

There is a fourth item in this cluster that is easy to skip: decide whether the window remembers its size and position. A call window that opens small on a large display forces a resize at the start of every meeting, and that friction is what eventually sends people back to the browser tab they were trying to leave.

Camera and microphone are granted in the window that will use them

This is the step that most often fails, and the reason is structural rather than careless. Site permissions are recorded against an origin combined with a storage container. A new window with its own storage is a container with no history, so an approval given in the browser last year means nothing there.

Before you start using Meet, you need to allow access to your computer's camera and microphone. Source: support.google.com

Perform that inside the new app window. Open the Meet home page there, start a new meeting, and answer the prompt. If access was blocked at some earlier point, the blocked camera indicator near the address area offers the option to always allow meet.google.com to use the camera and microphone.

Editing browser settings will not fix a silent app window. It is a different container, and the settings screen being edited governs a different one.

Screen sharing is approved separately, by macOS

Camera and microphone clearing does not carry screen sharing with it. Presenting falls under Screen Recording in macOS, listed in System Settings under Privacy and Security, and it is granted per application.

Per application is the trap. A browser can be fully authorised while an app built on top of that browser appears under its own name with nothing enabled. Granting it sometimes requires quitting and reopening the app before macOS honours it.

The test costs two minutes. Start a meeting alone and share a single window. If that works, it works in front of other people. On a managed Mac the Screen Recording list can be controlled by policy and cannot be enabled locally, so anyone who presents regularly should raise it with an administrator before building rather than after failing.

Link routing decides whether any of this gets used

Meetings begin in a calendar entry, not in the Dock. Which program opens that invite therefore decides whether the new window ever sees traffic.

Some tools accept URL patterns and send matching addresses into a chosen app while returning everything else to the default browser. Approaches that only draw a window carry no rules, so invites keep opening in the default browser and the app sits idle unless it is opened by hand.

Neither outcome is wrong. What causes frustration is not knowing which one applies before building. Without routing, the working pattern is to open the app from the Dock and paste the meeting code into the home page, which is exactly why the home page was chosen as the front door two sections ago.

What can safely wait

Two settings belong at the end, once the call path is proven.

A login item makes sense only at a certain volume. A call page is not an all day tool the way a task tracker is. Three or more meetings a day justifies having it already running. A handful per week does not, and leaving it out keeps startup lighter.

Notifications follow the same container logic as the camera. Granting them inside the window is what registers the app in the operating system's notification list under its own name, which is also where a Dock badge can be enabled. For Meet specifically this matters less than it might, since meeting alerts usually come from the calendar. It earns its keep when in call chat messages are easy to miss behind another window.

If the app was already built in the wrong order

Most people arrive at this list after building something that half works, not before. The recovery path depends on which row of the table above is the problem, and it is worth diagnosing rather than rebuilding by reflex.

If video and audio work but a Meet feature is missing, the engine is the cause and a rebuild is the only fix. Before doing that, confirm the feature is actually engine gated rather than account gated. A missing 1080p option, for instance, can come from the edition rather than the window, in which case rebuilding on a different engine changes nothing.

If the window opens on the wrong Google account, clearing the app's storage and signing in again is usually enough, and no rebuild is needed. The same applies to an app that opens on a dead meeting room: the entry address is normally editable in the app's own settings.

If the name is wrong, change it, but then check the Screen Recording and notification lists. A stale entry under the old name can sit there granted while the renamed app sits there denied, which produces a failure that looks random. Removing the old entry and granting the new one clears it.

If nothing is wrong except that the app never gets used, the problem is link routing rather than the app. Either configure the routing rules if the tool supports them, or change the habit: open from the Dock and paste the meeting code. The second option costs nothing and works everywhere.

The one situation that genuinely calls for starting over is an app built on an engine that cannot do something the work requires. Everything else in the list is a setting.

What to change first

Lock the engine and the account before anything else, since those are the only two that force a rebuild. Then grant camera, microphone, and Screen Recording inside a solo test call rather than a real one. The macOS version floor and the licence model are the other two constraints that cannot be fixed later, and both are listed at Kagemusha alongside what a built window can carry in Features and how to edit or remove one in the Guide.