GoTo Webinar on a Mac: joining the session without a tab

Ten minutes before a session starts, the confirmation email gets opened, the join link gets clicked, and the browser asks a question nobody wants to answer under time pressure: join in this browser, or download the app. Both work. They do not work identically, and on a Mac the difference includes which browser is acceptable, which is the detail most likely to turn a two minute join into a ten minute scramble. This covers what each route actually supports on macOS, and what to do if the session is a recurring part of the week rather than a one off.

The two roles, and why they need different answers

Attendees and hosts face different constraints, and advice written for one is misleading for the other.

An attendee needs nothing but a link. The support documentation is explicit that signing in or creating an account is not required to attend. The join flow starts from the confirmation email or the completed registration page, and from there the choice of route appears.

A host has a license, a dashboard, scheduling, and a practice mode to rehearse in. The host also has more browser restrictions than the attendee does, which is the reverse of what most people expect.

The system requirements page separates the two. For attendees, the supported operating systems are Windows 10 or newer, macOS 12 or newer, Linux and Chrome OS. For organizers and panelists the list is shorter: Windows 10 or newer and macOS 12 or newer, with no Linux and no Chrome OS. Both roles can use the desktop app or the mobile app, with the mobile app supported for live sessions but not for simulive ones.

The browser route, and the Safari problem

The join screen on a computer presents two options. The first is described in the documentation as Join in this browser, and it is marked as the recommended one. The instruction attached to it names the browsers to use: the latest three versions of Chrome or Edge.

That phrasing is worth reading twice, because Safari is not in it.

The broader system requirements page explains why. Attendees may use Chrome, Edge, Firefox or Safari, with an asterisk on two of them. The asterisk states that Firefox and Safari are supported only for webcast and simulive sessions. For organizers and panelists the browser list is Chrome, Edge and Safari, with a separate note that scheduling alone, as opposed to joining or hosting, can be done from a wider set of browsers.

The practical consequence on a Mac is that Safari is a partial answer. For a broadcast style webcast, or a session the host pre recorded and is running as simulive, Safari is supported. For an ordinary interactive session, the documented path is a Chromium based browser or the desktop app. Anyone whose habit is to keep everything in Safari will eventually meet a session that does not open there, and it will happen at the start of the session rather than in advance.

The desktop app route

The second option on the join screen is to download the app. This runs through a small helper, and the documentation names it precisely: the download opens the desktop app via the GoTo Opener, with an instruction to select Open GoToOpener.app in the dialog macOS shows. That dialog is the step people miss, because it looks like an operating system warning rather than part of the join flow.

The Download Center confirms the platform spread plainly. The GoTo desktop app is available for both Mac and Windows, the mobile app for both iOS and Android, and no account is required to join a meeting or a webinar as an attendee.

The documented device requirements for the app are modest: at least 2GB of memory for the app itself, with 4GB or more recommended, and a computer connection of 1 Mbps or better. The same page adds a caution that is easy to skip and worth keeping: those figures are for the GoTo app alone, and they sit on top of whatever else is running at the same time. A recommendation of 16GB of total system memory appears there for that reason.

One behaviour to expect as an attendee, regardless of route: the documentation states that attendees enter on mute and cannot unmute themselves unless the organizer changes their role. Audio is selected from the audio menu once the broadcast begins.

Choosing between them

	Browser route	Desktop app route
Install needed	None	Yes, via GoTo Opener
macOS floor	macOS 12 or newer	macOS 12 or newer
Browsers	Chrome or Edge, latest three versions	Not applicable
Safari	Webcast and simulive only	Not applicable
Account	Not needed to attend	Not needed to attend
Where it lives	A tab among many	The Applications folder

The browser route wins on speed of first join and loses on where it ends up living. The app route wins on being a real application and costs an install plus a dialog.

For a session that happens once, that trade is easy and the browser wins. For a weekly training, a recurring town hall, or a webinar series someone attends as part of their job, neither answer is satisfying. The app is an application but it is one more installed thing to keep updated, and the browser route puts a scheduled commitment into a container that gets closed by accident.

The third route: a window without an install

There is a middle option that the documentation does not discuss because it is not a feature of the service. A web page can be given its own macOS window, its own Dock icon and its own session, without installing that vendor's software.

Apple's WebKit team documented the built in version of this when Safari 17.0 shipped with macOS Sonoma. The procedure is File then Add to Dock, with the name and icon adjustable at creation, and the result behaves like a Mac application: it works with Stage Manager, Mission Control and Command plus Tab, and it opens from the Dock, Launchpad or Spotlight.

Google documents the same idea in Chrome. From the More menu, choose Cast, save, and share, then Install page as app, or use the Install button that appears at the right of the address bar on some sites. The installed app belongs to the Chrome profile that created it, so an existing session carries over.

For this particular service the difference between those two matters more than usual. A window built through Safari runs on WebKit, which puts it in the same category the documentation limits to webcast and simulive sessions. A window built through Chrome, or through a site to app tool that runs a Chromium based engine, satisfies the Chrome or Edge requirement that the join screen names. When choosing a route here, the engine underneath the window is not a technical footnote. It decides whether interactive sessions open at all.

That is also the reason to look at what a wrapper tool exposes. A tool that lets each app pick its browser engine can put the session window on Chrome or Edge while leaving other windows on whatever suits them, and the Features page of one such tool lists engine choice alongside the other per app settings.

Settings that make a recurring session window worth having

Point it at the right page

A window built on the service's front page is a window that still needs navigation. Built on the dashboard, or on a specific registration or join page, it opens on the thing being used. For a host, the dashboard is the right target. For a regular attendee of a recurring series, the join page or the confirmation link is.

Keep the session separate

A window with its own cookie store keeps its sign in independent of general browsing. For a host who runs sessions on behalf of two organizations, that separation is what makes two windows possible at all, rather than a single window that has to be signed out and back in.

Leave popups partly open

Authentication dialogs are popups, and so are some of the panels the session interface opens. A blanket block breaks sign in. The more considered wrapper tools offer a middle setting that allows authentication windows and blocks the rest, which is the correct choice here.

Name it after the series, not the product

Three windows all carrying the same product name are three identical entries in the application switcher, and picking the right one becomes guesswork at the worst moment. A window named after the series it opens, the department that runs it, or the account it signs in as, is identifiable at a glance and searchable from Spotlight by that name. Both built in routes allow the name to be set when the window is created, and site to app tools generally allow it to be changed later along with the icon. The same reasoning applies to icons: a distinct icon in the Dock is faster to hit than a correct name read in a hurry.

Check audio permissions before the day

A window created by any of these routes is a new container as far as macOS privacy settings are concerned, and microphone and camera access are granted per application. Granting them during a rehearsal is calm. Granting them while ninety people wait is not. Practice mode exists for this.

If you are the one hosting

Plan limits shape the day more than any client side setting, and they are published. In US dollars, the entry plan is listed at $69 per month, or $59 per month billed annually, and includes one organizer seat and up to 500 participants. The middle plan is $129 per month, or $103 per month billed annually, and raises the ceiling to 1,000 participants while adding cloud recordings, branded webinars, breakout rooms and AI summaries. The top plan is quoted by the sales team rather than listed, and covers up to 3,000 participants, paid events and certified training, with a meeting license included. A free trial is offered with no commitment and no credit card.

Two of those limits interact with the window question. Custom organizer seats mean more than one person hosting, which means more than one signed in session on more than one Mac, and a per app profile is how a shared machine handles that without repeated sign outs. Cloud recordings mean the session artifacts live on the web dashboard afterwards, which is a second page worth its own window if pulling recordings is a weekly task. The Guide for setting up windows of this kind covers the mechanics once the decision is made.

What to change first

If the session happens once, join in Chrome or Edge from the link and forget the rest. If it happens every week, build one window on the page actually used, put it on a Chromium engine so interactive sessions are covered, and grant the microphone and camera in a rehearsal rather than on the day. Kagemusha is one way to make that window without installing another vendor's client.