Turning Google Calendar into a standalone app on macOS

Searching for this produces a lot of download buttons that lead somewhere other than a Google Calendar installer, because no such installer exists. Google publishes calendar apps for Android, iPhone and iPad, and on a computer the product is a website. That fact is stated plainly in the help centre rather than buried, and once it is accepted the question changes into a better one: given that the calendar is a website, where should that website live on a Mac, and what does each answer cost.

Google's own answer to this search

The Get started page for Calendar ends its browser section with a single line that settles the matter.

Tip: While you can't download and install Calendar on your computer, you can use it offline. Source: support.google.com

The same page lists the supported browsers as Chrome, Firefox, Safari and Microsoft Edge, and notes that JavaScript and cookies have to be enabled. Google also warns that on an older or unsupported browser some features stop working and the application might not open at all, with the example given being that calendars can be viewed but not updated.

So there are exactly three routes on a Mac. Put the events into Apple Calendar and use a native app that was never made by Google. Use the website in a browser tab. Or use the website in a window of its own. Each of the three loses something specific, and the losses are documented well enough that this can be decided on facts rather than taste.

Route one: Apple Calendar holding the Google account

The setup is short. In Apple Calendar, open the Accounts tab in settings, add an account, choose Google, sign in, and set how often calendars refresh. Everything under My calendars in Google Calendar syncs automatically, along with birthdays. Anything else, including calendars subscribed to or shared by other people, has to be ticked on the Calendar sync page before it appears.

One trap is worth knowing in advance. If the Delegation tool in Apple Calendar was used previously, it has to be switched off for the sync to work, which is a common cause of a setup that looks correct and shows nothing.

What is gained is everything native: alerts through the macOS notification system, a menu bar and Notification Center presence, offline access without configuration, and integration with the rest of the Apple applications. What is lost is documented by Google as three specific things.

Email notifications for events do not work. New Google calendars cannot be created from Apple Calendar. Room Scheduler is not available, which removes room booking for anyone on a Workspace domain where meeting rooms are resources.

For a personal calendar those three rarely matter. For someone booking meeting rooms and creating project calendars several times a month, they are the whole job.

The refresh interval deserves a moment as well. Apple Calendar pulls changes on a schedule set in the Accounts tab, so an event added by a colleague appears after the next refresh rather than instantly. On a calendar where meetings are moved during the day, a long interval turns into a wrong answer at the wrong time, and the setting is easy to forget after the initial setup.

Route two: the website, in a tab or in its own window

The website is the full product. Everything Google ships for Calendar is there, including the features Apple Calendar cannot reach. The question is only where the window sits.

Offline is the detail most people miss. Calendar does work offline, but the support documentation is specific about the conditions: offline access and accessibility tools are not supported in Firefox, Safari and Microsoft Edge, which leaves Chrome. Turning it on is done in Calendar settings under General, followed by a reload and a sync. Once ready, an offline session can show the last four weeks and anything in the future, in day, week or month view.

The offline mode is read mostly, not read write. Google lists what cannot be done while offline: creating or editing events, emailing guests, and reaching tasks. There is one more trap in the same note. Clearing cached images and files in the browser also clears offline support, so it has to be switched back on afterwards.

Chrome can install the site as a web app on its own, through More, then Cast, save, and share, then Install page as app. That produces a windowed version managed at chrome://apps, where a right click also offers Open at login. It is free and takes a minute. Its limit is that it belongs to the Chrome profile it was installed from, so holding a work calendar and a personal calendar at the same time means running two Chrome profiles and keeping track of which window came from which.

The three routes side by side

Apple Calendar Website in a browser tab Website in its own window

Create new Google calendars No Yes Yes

Room Scheduler No Yes Yes

Email notifications for events No Yes Yes

Alerts through macOS Yes Browser notifications only Yes, when the app is set to allow them

Offline access Yes Chrome only Chrome based apps only

Survives quitting the browser Yes No Yes

Two accounts at once Yes, as two accounts Awkward Yes, one window each

Reachable with Command and Tab Yes No Yes

Read down the first column and the pattern is clear. Apple Calendar wins on being native and loses on being a partial copy of Google Calendar. The website wins on completeness and loses on placement. The third column is the website with the placement problem fixed, which is why it exists at all.

Third party calendar clients, and why they are a fourth answer

A number of paid Mac calendar applications connect to a Google account and present it in their own interface. They are a legitimate option and they solve some of the same problems as Apple Calendar, with better views and faster event entry. They also inherit the same boundary.

The boundary is the protocol. Any client that syncs a Google account is reading and writing events through an interface, not running Google Calendar. That is why the same three gaps keep appearing across different clients: creating a new Google calendar, booking a room from a Workspace resource list, and sending an email notification to guests are actions of the Google web application rather than properties of an event. A client that does not implement them cannot borrow them.

The practical reading is that a third party client competes with Apple Calendar, not with the website. Choosing one is a question of which interface suits the way a day is planned. It does not remove the reason the website stays open, and anyone who ends up keeping both should decide which one is allowed to send notifications, because two calendar sources alerting for the same meeting is worse than one.

What usually decides it: notifications and accounts

Two questions settle most cases, and neither is about features.

The first is where alerts should come from. A tab can only produce browser notifications, and only while the browser is running. If the calendar is the thing that stops meetings being missed, it should not depend on whether a browser was quit that morning. Apple Calendar solves this natively. A dedicated window solves it if notifications are enabled for that app, after which the app gets its own row in System Settings under Notifications, and its alert style, sound and banner behaviour can be set without touching every other website.

The second is how many Google accounts are in play. One personal account and one work account is now the normal case rather than the exception. Google Calendar's own account switcher works, but it applies to the whole browser session, so switching to check a work event signs the other windows into the same identity. Two separate windows, each holding one account permanently, removes the switch. This is also the answer for anyone who has ever created an event on the wrong calendar, which is a mistake made at the account level rather than at the calendar level.

Giving the website an application shell

The third route needs a tool, and the mechanism is worth understanding before picking one.

A site to app tool does not bundle a browser engine. It builds a small application bundle that points, through a symlink, at a Chromium browser already installed on the Mac, so updating the browser updates the window. Chrome, Brave, Edge, Opera, Vivaldi, Chromium and Arc can serve as the base. Because the base is Chromium, Calendar's offline mode remains available, which a Safari based shortcut cannot offer.

Three of the settings matter for a calendar specifically. Notifications can be turned on so the site's alerts arrive as macOS system notifications. Dock presence can be left on so the window keeps a fixed position and answers to Command and Tab. And each generated app carries its own profile, so a work calendar window and a personal calendar window never share a session. The full list of switches is in the Guide.

There is also a grouping option worth knowing about, since a calendar is rarely used alone. One window can be built to hold several related services with a sidebar for switching, which suits a set such as mail, calendar and files opened together at the start of the day. Calendar is one of more than three hundred services already described with their URL, name and icon on the Supported services page, so building it takes a couple of clicks rather than a configuration session.

What this route cannot do

Honesty about the limits keeps the decision sound.

A window around a website is not a native calendar. It contributes nothing to Notification Center widgets, it does not appear in the menu bar as an agenda, and it stays outside the Apple ecosystem, so Siri, Reminders and other Apple applications will not see the events. Anything on a Mac that reads from Apple Calendar reads nothing from this route.

That points to a combination rather than a contest. Apple Calendar can hold the Google account for widgets, Siri and system wide awareness, while the website in its own window handles creating calendars, booking rooms, managing guests and everything else Google ships. The two are looking at the same events, so nothing is duplicated except the viewing.

What to change first

Decide which of the three Apple Calendar limitations actually affects the week ahead. If none of them do, Apple Calendar is the least work and the most native answer. If creating calendars, booking rooms or emailing guests appears in a normal week, the website has to stay, and the useful change is to move it out of the tab strip into its own window with Kagemusha, which is free for the first three apps.