How to change the default calendar app on a Mac

A new calendar app is installed and running. An .ics attachment arrives, gets double clicked, and Apple Calendar opens anyway. That is usually the moment this search starts, and it is also the moment people notice that macOS does not keep this control where it keeps the others. System Settings has a default web browser. It has no default calendar.

The switch does exist. It sits inside the app being replaced, which is why it is easy to miss for months.

The setting lives inside Apple Calendar

Open Calendar. From the menu bar choose Calendar, then Settings, then click the General tab. In that pane there is a pop-up menu named Default calendar app. It lists every installed application that has told macOS it can handle calendar files. Choose the one that should take over and close the window. There is no confirmation dialog, no restart, and no visible change until the next calendar file or subscription link is opened.

Apple states the scope of the setting in a single sentence: "Choose which calendar app to use when you open calendar (.ics) files or when you click weblinks to subscribe to calendars." That sentence is worth reading twice, because it is narrower than most people assume. The full description of the pane is in the Calendar general settings page of Apple's own guide.

Two consequences follow from that wording. First, the setting is a file and link handler, not a system wide preference for anything else. Second, Apple Calendar has to stay installed, because the only place to reach the control is inside it. It cannot be deleted from a standard macOS install in any case.

If the Settings window looks unfamiliar, note that older versions of macOS called this window Preferences rather than Settings. The pane and the pop-up menu are in the same place under both names.

Two settings with confusingly similar names

The same General pane contains a second pop-up menu named Default Calendar. It looks like a duplicate. It is not.

Setting	What it decides	Where it applies
Default calendar app	Which application opens .ics files and webcal subscription links	Across the Mac, for those file types and links
Default Calendar	Which calendar list a newly created event lands in	Inside Apple Calendar only

Picking the wrong one is the most common reason a change appears to do nothing. Someone who wanted their invitations to open in a different app changes the destination calendar for new events instead, sees no difference in behaviour, and concludes the setting is broken. The one that routes files and links to another application is Default calendar app, the one with the word app in it.

The second menu still matters after a switch, because a third party calendar that reads the macOS calendar database will write new events into whichever list that database treats as the default. Setting it to a working calendar rather than an old shared one prevents a class of quiet sync failures later.

What actually changes, and what does not

Switching the handler is a smaller change than it feels like. The table below separates what gets routed to the new app from what stays with the system.

Action	After the switch
Double clicking an .ics file	Opens in the new app
Clicking a webcal subscription link	Offers to subscribe in the new app
Accepting an invitation from a Mail message	Depends on the account type and on whether the app reads the system calendar store
Siri requests such as add a meeting at three	Handled by the system calendar store, not by the chosen app
The Calendar icon in the Dock	Still launches Apple Calendar until it gets replaced manually
The date and time in the menu bar	Still opens Notification Center
Calendar widgets already placed	Keep showing whichever app supplied them
Alerts and notification sounds	Come from whichever app holds the events and has notification permission

The Mail behaviour deserves a note. Invitations for accounts configured in System Settings under Internet Accounts flow into the shared macOS calendar database, and any app that reads that database sees them without extra work. An app that talks to Google's servers directly and keeps its own copy of the data is a separate store, so an invitation handled by the system may not appear there instantly. Neither approach is wrong. They fail in different ways, and knowing which one is in use explains most cases of an event appearing in one calendar window but not another.

When the app you want is missing from the list

The pop-up menu only shows applications that registered themselves with macOS as capable of opening calendar data. If a newly installed app is absent, work through these in order.

Launch it once from the Applications folder

Registration happens on first launch. An app that has only been dragged from a disk image, or that has been quarantined after download, may not have run to completion yet. Open it once, grant the calendar access prompt if one appears, quit it, then reopen Calendar settings.

Check that only one copy exists

A copy still sitting in Downloads alongside the one in Applications produces duplicate entries or an entry that points at the wrong path. Delete the extra copy, empty the Trash, and check again.

Rebuild the handler database

macOS caches these registrations in Launch Services. When the cache goes stale after upgrades or repeated reinstalls, the list stops matching what is installed. Running lsregister -kill -r -domain local -domain system -domain user from the LaunchServices support directory rebuilds it. Log out and back in afterwards. This is a maintenance step, not a fix to reach for first.

Route the file type by hand instead

The Finder route works independently of the Calendar setting. Select any .ics file, choose File then Get Info, expand Open with, choose the app, then click Change All. Every .ics file on the Mac now opens there. Subscription links clicked in a browser still follow the Calendar setting, so both need attention if both matter.

Subscription links behave differently from files

The Apple sentence quoted above covers two things, and they fail independently. A file arrives as an attachment or a download and gets opened once. A subscription link points at a calendar hosted somewhere else, and the app that accepts it keeps checking that address for changes. School terms, sports fixtures, national holidays, and shared team calendars are usually distributed this way.

Those links come in two forms. Some use the webcal scheme, which browsers hand straight to whichever app holds the calendar registration. Others are ordinary https addresses that serve an .ics file, which the browser downloads first, at which point the file handler decides what happens next. Changing the setting in Calendar covers both, but a browser that has already been told to always open .ics downloads with a particular app will keep doing so. That override lives in the browser's own downloads settings, not in macOS.

Subscriptions also carry a refresh interval, and the interval belongs to the app that holds the subscription rather than to the calendar being published. Apple Calendar offers a choice between checking every few minutes, hourly, daily, weekly, or only when asked, set per subscribed calendar in its info panel. Third party apps expose their own equivalents, and some do not expose the setting at all. A holiday calendar checked once a week is fine. A shared team calendar checked once a week is a source of missed changes.

One more thing gets lost in a switch: subscriptions do not move by themselves. They live in whichever app accepted them, so a new default handler starts with none of them. Before switching, open the old app and note the address of each subscribed calendar, since the original link is often long gone from the email that carried it.

A five minute test after switching

Assume nothing until it has been checked. The following sequence exercises each path that tends to break, and it takes about five minutes.

Send a calendar invitation to the address in question from another account and open it on the Mac. Export any existing event as an .ics file by dragging it out of a calendar window to the desktop, then double click that file. Click a public calendar subscription link, such as a sports fixture list, and cancel out of the subscription prompt once the correct app has appeared. Create an event in the new app and confirm it shows up in Apple Calendar, then create one in Apple Calendar and confirm the reverse. Finally, set an alert five minutes ahead and wait for it, because notification permission is granted per app and a fresh install usually has none.

Reverting is as cheap as switching. The pop-up menu still lists Calendar, so putting it back takes the same few seconds, and nothing that was created in the meantime is lost, because events live in the accounts rather than in the handler. That makes a trial period low risk. Set the new app as the handler for a fortnight, and if the .ics files stop landing where expected, or a subscription silently stops updating, switch back and keep the app installed for everything else. Nothing about the setting requires committing to one calendar for everything.

If the round trip in step four fails in one direction only, the two apps are reading different stores. That is a sync configuration question rather than a default handler question, and the setting under discussion here will not solve it.

Whether the handler is the thing worth changing

Routing .ics files elsewhere is a small win. It is worth doing, and it takes under a minute. It also rarely addresses what pushed someone to install a second calendar in the first place.

The reasons people replace a Mac calendar cluster around three jobs. Getting an event in fast, without breaking away from whatever else is open. Seeing what is next without hunting for a window. Judging whether two commitments actually fit, once travel between them is counted. A file handler setting touches none of those. Different apps solve them to very different degrees, and a comparison of how other Mac calendars handle each one is a faster way to decide than switching handlers and hoping the feel changes.

If the friction is in getting events in, the specific thing to look at is how the app parses typed or spoken input, covered in entering events. If the friction is that back to back meetings keep colliding, look at how the app handles travel time between them, since a calendar that treats a journey as a real block of time changes what a full day looks like.

What to change first

Change the handler now, because it costs a minute: Calendar, Settings, General, Default calendar app. Then run the five minute test rather than assuming it worked, since the second pop-up menu in that pane catches nearly everyone at least once. If the calendar still feels wrong afterwards, the problem was never the handler, and a calendar built around fast entry and honest travel time, such as Caltimate, is the more useful thing to evaluate next.