Google Agenda on a Mac, outside the browser

Searching for Google Agenda for Mac produces a lot of download buttons and none of them belong to Google. That is not a gap in the search results. Google does not publish a desktop calendar application for macOS, and the pages that appear to offer one are either third party clients, browser extensions, or download portals wrapping the web address in an installer.

Google is direct about where the product runs. Its own Calendar product page lists access through the web, the Android and iOS mobile apps, and Wear OS or Apple Watch devices, with calendars syncing automatically across all of them. Desktop is the web, and that is the whole list. Google Agenda is simply the name Google Calendar carries in French, Dutch and Portuguese, so the search term and the product are the same thing.

What remains is a genuine question with three real answers. The calendar is needed as a window on the Dock rather than as a tab lost among fifteen others, and there is more than one way to arrange that.

Route one: bring the calendar into Apple Calendar

Every Mac ships with Calendar, and it accepts a Google account directly. Open Calendar, choose Calendar then Add Account from the menu bar, select the account provider, click Continue, and follow the sign-in prompts in the window that opens.

What this produces is a genuine native application. It launches without a browser, appears in Command-Tab, sends notifications through macOS, and shows calendar data without a network connection because the events are stored on the Mac. It also merges the Google account with anything else already there, so an iCloud calendar and a work calendar appear in one grid. For anyone who juggles calendars from more than one provider, that merge is the strongest argument available.

The trade-off is about behaviour rather than data. Apple Calendar reads and writes events, and it does that reliably. Anything that belongs to Google's own interface rather than to the calendar data itself is still administered in the web interface. Sharing settings, booking pages, working hours, and the more specific configuration options all live there, which means the browser is still opened occasionally even after the switch.

There is also a habit cost that is easy to underestimate. Keyboard shortcuts differ, the week view is laid out differently, and creating an event with a video conference link is a different sequence. None of that is difficult, but it is a week of small friction, which is a real price for someone whose only complaint was that the calendar was hard to find.

Route two: keep Google Agenda, give it a window

The alternative changes nothing about the calendar and everything about where it lives. The interface stays identical, every shortcut keeps working, and the setup takes under a minute.

macOS has this built in from Sonoma 14 onward. Open the calendar in Safari, then choose File followed by Add to Dock from the menu bar, or use the Share button in the toolbar and choose Add to Dock. Name it and click Add. Apple's documentation describes the result precisely: the web app is saved to the Applications folder of the home folder, it shares no browsing history, cookies, website data, or settings with Safari, and for sites that send notifications the Dock icon can show an unread count. Settings for the app, including the name and the icon, are reached by opening it and choosing Settings from the menu bar.

Chrome offers the same idea through a different path: the More menu, then Cast, save, and share, then Install page as app. The window behaves similarly, although the icon is taken from the site rather than chosen.

A dedicated site to app tool covers the cases the two built-in options leave open. It builds the calendar as a standalone application regardless of which macOS release is installed above version 12, keeps cookies and login sessions separate per app so two accounts can be signed in at once, allows the engine underneath to be selected, and repairs the app when the underlying browser updates. The Features page sets out what that involves in practice.

Setting the window up so it behaves like an app

A calendar window created in a minute will behave like an app only after four small adjustments, and all four are easier to make during setup than to discover later.

Give it a name that reads at a glance. The default is usually the page title, which can be long and can begin with the account address, so two calendars end up with names that differ only at the end. In a Safari web app the name is changed by opening the app and choosing Settings from the menu bar. Short and distinct beats accurate.

Change the icon. A web app starts with the site's favicon, which was drawn to be legible at 16 or 32 pixels in a tab strip and looks thin or pixelated once it is sitting at Dock size. The same Settings panel allows a different image to be chosen. Tools built for this purpose usually supply a library of icons drawn at application scale instead, which avoids the problem rather than working around it.

Turn notifications on inside the new app. Notification permission is granted per origin and per cookie store, so the permission that was granted in the browser does not travel with it. The calendar's own notification setting has to be switched on inside the new window, and the macOS prompt accepted when it appears. Missing this step is the single most common reason a new calendar app appears to have stopped reminding anyone of anything.

Decide whether it should open at login. A calendar that is consulted throughout the day is a reasonable candidate for the Login Items list in System Settings, so that it is already running rather than waiting to be launched.

One behaviour cannot be adjusted, and it is worth expecting. A calendar invitation link clicked in a mail message will open in the default browser, not in the new calendar app, because macOS routes web links to the browser. The event still opens correctly, it simply opens in the wrong place. Most people adapt by treating the app as the place they go to look and the browser as the place links land.

Offline is the deciding factor

If the choice between the two routes still feels arbitrary, offline behaviour usually settles it, because the difference is large and the details are documented.

Google Calendar has an offline mode and it is specific about its requirements. It works in a Chrome browser. It is switched on through Settings, then Offline, then Reload now, after which the calendar syncs and the indicator moves through Syncing and Ready for offline. Once active, it allows viewing the calendar and events from the last 4 weeks or any time in the future.

What it does not allow is the important part. Events cannot be created or edited while offline. The offline mode is read only. Additionally, clearing the browser's cached images and files removes the offline data, and the feature has to be enabled again.

Apple Calendar has none of those limits, because the events are on the Mac. Everything can be read, created and edited with no connection, and the changes sync when one returns.

This maps onto the routes cleanly. Someone who works on trains, planes, or anywhere with unreliable connectivity, and who needs to add events rather than only read them, should use Apple Calendar. Someone whose Mac is essentially always online, and who values Google Calendar's own interface, loses very little by keeping the web version and putting it in a window. The read only offline mode is then a reasonable safety net rather than a daily tool, and it is worth turning on either way.

Work and personal at the same time

Anyone with a personal calendar and a work calendar hits the same constraint. A browser holds one signed-in Google session per profile, so two accounts means switching between them or running a second browser profile.

Apple Calendar handles this the way a mail client does, by adding both accounts and displaying one merged grid with colour coded calendars. For people who want to see all commitments in a single view, this is the reason to choose it and nothing else comes close.

The window based route handles it by making two apps rather than one. Because each Safari web app has its own cookie store, two of them pointed at the calendar can hold two different accounts signed in simultaneously, and the same applies to a site to app tool with profile isolation. The result is two Dock icons and two windows, with no switching at all.

Which is better depends on what the two calendars are for. A merged view is better for avoiding double bookings. Two separate windows are better when the boundary between work and personal is supposed to be visible, and when the work calendar should not be on screen at seven in the evening.

Matching the route to the actual complaint

Three complaints hide behind the same search, and each has a different answer.

If the complaint is that the calendar is buried in a browser tab and hard to reach, the answer is a window, not a new application. Safari's Add to Dock solves it in under a minute at no cost, and nothing has to be relearned.

If the complaint is that the calendar is unusable without a connection, or that everything should live in one merged view, the answer is Apple Calendar. The week of adjustment is worth it for those two properties, and neither one is available any other way.

If the complaint is that two accounts keep colliding, the answer depends on whether one view or two is wanted. One merged view means Apple Calendar. Two visibly separate windows means two web apps with isolated sessions.

The mistake worth avoiding is installing a native client to solve a window management problem. It works, in the sense that the calendar ends up on the Dock, and it arrives with a set of behaviour changes that were never requested. The reverse mistake is also common: putting the web calendar in a window and then discovering on a flight that events cannot be created. Naming the complaint first makes both easy to avoid.

What to change first

Open the calendar in Safari and choose File then Add to Dock, which costs a minute and nothing else, and use it for a week. If that week exposes a real need to create events without a connection, add the same Google account to Apple Calendar as well and keep both, since they show the same data and nothing is lost by having two ways in. If instead the gap turns out to be a second account needing its own permanent window, Kagemusha runs on macOS 12 and later with a free tier covering up to three apps, and the Supported services list shows which sites already have a preset waiting.