Export iCal to Google Calendar and keep one place for everything

Two calendars are open on the same Mac. Apple Calendar holds the events that were typed on the phone, the ones that came from an airline confirmation, the family birthdays. Google Calendar holds the work meetings, because that is where the invitations arrive. Neither view is complete, and checking both before agreeing to anything is the small daily tax that a single place would remove.

Moving events from one to the other is a ten-minute job. Deciding which of the two available mechanisms to use is the part that determines whether the problem is solved once or reappears in three weeks, because the two look almost identical on screen and behave nothing alike.

A copy and a feed are not the same operation

Google Calendar offers two routes, and the vocabulary in the interface does not make the difference obvious.

The first is an import. A file is uploaded, the events inside it are written into a calendar of your choosing, and the file is then irrelevant. Those events belong to the Google calendar from that moment on. Editing them in Google works. Editing the original in Apple Calendar changes nothing on the Google side, and re-importing an updated file adds a second copy rather than updating the first.

The second is a subscription. A URL is registered, and Google reads the calendar published at that address on its own schedule. Nothing is copied once and forgotten: the source stays authoritative, and changes made where the file is published reach Google without any further action. The trade is direction. The events arrive as a feed, so the place to change anything is the source, not the Google grid.

Which of those two is correct depends on one question. Is this a migration, where Apple Calendar is being retired and Google becomes the only place events live? Or is it a merge, where both sides carry on and one of them needs to see the other? A migration wants an import. A merge wants a subscription. Most of the frustration in this area comes from performing a migration when the intention was a merge, then wondering why last week's edits never showed up.

Getting the file out of Apple Calendar

The export routes on a Mac are documented and there are two of them, producing different formats that are not interchangeable.

For a single calendar, select its name in the calendar list on the left, then choose File, then Export, then Export. If the calendar list is hidden, View then Show Calendar List brings it back. The result is one .ics file containing that calendar's events, which is exactly what the Google importer reads.

For everything at once, File then Export then Calendar Archive writes an .icbu file. That format is an Apple archive, not an iCalendar file, and the Google importer will not take it. Its purpose is restoring back into Apple Calendar, and Apple's documentation carries a blunt warning about that: importing a calendar archive replaces all of your current calendar information and data. Treat the .icbu as a backup and use the per-calendar .ics files for anything leaving the Mac.

The reverse direction is worth knowing while the files are in hand, because a migration often needs a rehearsal. Apple's guide describes two ways to read an .ics file back in: drag the file into Calendar, or choose File then Import, select the file and click Import, then pick the calendar the events should join. It also notes that importing a calendar file removes the events' previous custom colour, which is a small thing that looks like data loss the first time it happens. Importing a test export into a new empty calendar on the Mac is a cheap way to see exactly what a file contains before it is handed to Google.

There is a caveat about where the events actually are. Apple's guide notes that calendars held in an account such as iCloud or Exchange are stored on that provider's servers rather than on the Mac, and the import and export routes matter most for calendars sitting in the On My Mac section. If the events are in iCloud, a subscription to the iCloud calendar is usually the better mechanism than exporting a snapshot of it.

Importing the file into Google Calendar

The destination side is one screen. Open Google Calendar in a desktop browser, click the settings icon at the top right, then Import & export in the left menu. Choose the file, choose the calendar to receive the events, then click Import.

Three constraints apply, and all three are stated in Google's import documentation.

Importing works on a computer. The phone and tablet apps have no import screen, so a file that lives on a phone has to reach a desktop browser first.

Archives are not unpacked for you. An export that produced a .zip file has to be opened, and each .ics file inside imported on its own, with the destination calendar chosen each time.

And the import is selective about what it carries:

When you import an event, guests and conference data for that event are not imported.

A meeting with six people and a video link therefore arrives as a titled block of time. For a personal calendar of appointments and birthdays that costs nothing. For a work calendar being migrated it is the difference between a record of the past and a working schedule, and it is the strongest argument for keeping the Google side as the place where invitations are issued.

Import, subscribe, or sync: what each one actually gives you

	Import a file	Subscribe to a URL	Two-way sync tool
Later changes at the source appear	No	Yes	Yes
Editable inside Google Calendar	Yes	No, change it at the source	Yes
Needs a published address	No	Yes	Account access on both sides
Guests carried over	No	Depends on the source file	Usually
Runs without anything installed	Yes	Yes	No
Risk of duplicates	Yes, one set per import	No	Depends on the tool

The third column is there because it is a real option, not because it is the answer. A two-way bridge is the only way to edit an event on either side and have both agree, and it is also the only one of the three that hands a third party continuous access to both calendars. For a personal calendar of dentist appointments that is a straightforward trade. For a work calendar it is a decision that belongs to whoever owns the account.

Subscribing to a calendar URL instead

The subscription route sits on the main Google Calendar screen rather than in settings. On the left, next to Other calendars, click the plus icon. Two of the entries there look similar and are not.

Subscribe to calendar takes an email address. It asks the owner of that Google account for access, and Google's help page notes the limit plainly: calendars that are not from Google cannot be subscribed to this way. This route is for colleagues, not for files.

From URL takes the address of a published calendar. This is the one that reads an iCalendar feed, so an iCloud calendar that has been shared as a public calendar, a room booking feed, a sports fixture list or a holiday calendar all arrive through here. Paste the address, click Add calendar, and it appears under Other calendars.

Two practical notes about living with subscriptions. Google does not publish how often it re-reads a subscribed address, and its help pages do not offer a refresh interval or a refresh button, so a subscribed feed is not the place to put something that changes in the next ten minutes. And there is a documented ceiling on volume: subscribing to more than four hundred calendars can cause performance problems when browsing calendars. That number sounds unreachable until a team starts subscribing to one feed per project.

The same mechanism works in the other direction. Apple's documentation describes adding a subscription in Calendar on a Mac through File then New Calendar Subscription, entering the calendar's web address and choosing iCloud as the location so the subscription follows to the iPhone and iPad. If the goal is to read Google events inside Apple Calendar rather than the reverse, that is the route.

The failure modes worth knowing in advance

Duplicates are the most common one, and they come from treating an import as if it were a sync. Importing a file, editing events in Apple Calendar, then importing the file again gives two events for every date. There is no undo for an import, so the repair is manual. Importing into a newly created empty calendar makes the repair one click, because deleting the calendar deletes everything the import created.

The second is the silent expectation of two-way behaviour. A subscribed calendar is read where it is published. An attempt to drag one of its events on the Google grid is not going to hold, and an event that needs editing in Google has to be created in Google.

The third is permissions on shared calendars. When a calendar is shared rather than imported, what the other side can do is set explicitly, and the four documented levels run from seeing free and busy blocks with no detail, through seeing all event details, through making changes to events, up to making changes and managing sharing. A migration that was meant to preserve editing rights can easily end up granting the read-only level, and the symptom looks like a broken sync rather than a permission choice.

Where the Mac side of this sits

Once both sets of events live in Google, the question becomes which window you open to look at them. A native Mac calendar reading the Google account directly removes the browser tab from the loop, and it also removes the reason most people kept Apple Calendar in the first place, which was having something that opens instantly and works offline. The set of things that changes is listed under Features, and the account setup, including connecting more than one Google account so work and personal appear together, is the first section of the Guide.

Subscribed feeds are worth a separate thought. A holiday calendar or a fixture list added by URL is display material: useful to see, never something to edit. Keeping those as overlays rather than importing their contents keeps the calendar you actually edit small, and it means a season schedule that gets revised revises itself.

What to change first

Answer the migration or merge question before touching either interface. If Apple Calendar is being retired, export one .ics per calendar, import each into a fresh empty Google calendar, and accept that guests and meeting links do not come along. If both sides carry on, use From URL in one direction and stop importing files entirely.

Then decide what you open each morning. A desktop calendar such as Caltimate reads the Google account directly on the Mac, which is the point at which having one place for everything stops being a filing exercise and starts saving time.