Import an iCal file: bringing events in without duplicates

An .ics file is sitting in the Downloads folder and the only question left is where it should go. That sounds like a two-click job, and often it is. The trouble arrives afterwards, when the same meeting appears twice in the week view, when a carefully colour-coded project calendar lands as a flat grey block, or when the file replaces every calendar on the Mac instead of adding to one.

The format does not change between those outcomes. What changes is which operation gets used, and what the receiving app decides to do with the identifiers inside the file. Sorting those two things out before the import takes a few minutes. Sorting them out afterwards means deleting events one at a time.

What an iCal file actually carries

An .ics file is plain text in the iCalendar format, standardised as RFC 5545. It opens with a BEGIN:VCALENDAR line, holds one VEVENT block per event, and closes with END:VCALENDAR. Inside each event block sit the summary, the start and end times, the location, the description, any recurrence rule, and one field that decides almost everything about duplicates: UID.

The specification is blunt about that field. The UID "MUST be a globally unique identifier", the generator of the file "MUST guarantee that the identifier is unique", and it is described as "the method for correlating scheduling messages with the referenced VEVENT". Every occurrence of a repeating event shares the same UID, and a single occurrence is pointed at with RECURRENCE-ID. So a well-formed file hands the receiving calendar a stable name for every event in it.

There is a second field worth knowing about, because its absence is what makes an exported file safe to open. METHOD marks an iCalendar object as part of a scheduling transaction, such as METHOD:REQUEST for an invitation. RFC 5545 states that if the property is not present, "a scheduling transaction MUST NOT be assumed" and the object is "merely being used to transport a snapshot of some calendar information". A calendar exported from an app has no METHOD line. Importing it will not fire invitations at the people listed on those events.

What the file does not carry is just as important. Google's help page on importing is explicit: "When you import an event, guests and conference data for that event are not imported." Attendee lists, RSVP replies and video meeting links do not survive the trip. Anyone moving a year of meetings expecting the guest history to come along will find the events present and the context gone.

Import or subscribe, and why that choice outranks the steps

Two different operations are both described as "adding a calendar", and they behave nothing alike.

An import copies the events once. They become ordinary events on the destination calendar, editable, movable, and frozen at the moment of the export. A subscription points the app at a URL and lets it refetch on its own schedule. The events stay read-only and stay current.

	Import a file	Subscribe to a URL
Source	A file on disk	A webcal or https address
Updates	Never, until another file is imported	Automatic, on the app's refresh cycle
Editable	Yes	No
Duplicate risk	High, if the file is imported twice with changed identifiers	Low, the feed replaces itself
Good for	A one-way migration, a fixed set of dates	Holidays, fixtures, a colleague's published calendar

The rule that falls out of this is short. If the source will ever change again, subscribe. If the source is being retired and its events need a new home, import. Doing both to the same source is the most common way to end up with two of everything, because the imported copies and the subscribed feed have no reason to recognise each other.

Apple Calendar on a Mac exposes the subscription path directly. Option-Command-S opens the dialog for a new subscribed calendar. On an iPhone the same thing lives under the calendar list, as Add Calendar and then Add Subscription Calendar, where a .ics URL is entered and the resulting calendar is read-only. Apple's guide also notes that an unwanted subscription can be removed with Unsubscribe, or with Unsubscribe and Report Junk, which reports it to Apple as a suspected junk subscription. That option exists because spam calendar invitations were common enough to need a button.

Importing into Apple Calendar on a Mac

Apple documents two ways in, and both are in the Calendar User Guide. The file can be dragged into the Calendar window, or File then Import can be used to select it. Either way, the next dialog asks which calendar the events should join, and that dialog is the most useful moment in the whole operation.

Point it at a new, empty calendar. File then New Calendar takes a few seconds, and naming it something like "Imported" or "From old system" costs nothing. The payoff is that the import becomes reversible. Toggling the calendar's checkbox shows exactly what arrived and what was already there. If the dates are wrong or the file was the wrong export, deleting that one calendar undoes everything. Point the import at the main calendar instead and the only way back is to identify the imported events by hand.

One detail from Apple's own page catches people out: "Importing a calendar file removes the event's previous custom color." Colour in Apple Calendar belongs to the calendar, not to the file, so a colour scheme built in the source app does not travel. If colour is carrying meaning in the original, the meaning has to be rebuilt on the destination side, usually by splitting the import across several calendars.

Export works the same way in reverse. Selecting a calendar and choosing File, Export, Export writes a .ics file, and Apple notes that this is the only format available for a single calendar.

The archive file is a different operation entirely

Alongside .ics, Apple Calendar can write a calendar archive with the extension .icbu, produced by File, Export, Calendar Archive. It looks like a bigger version of the same thing. It is not.

Apple's guide carries a warning in capital letters on this point: "Importing a calendar archive file replaces all of your current calendar information and data." It also removes every calendar's custom colour. An .icbu file is a restore point for the whole app, not an addition to it. Opening one to grab a handful of events will take out everything else that is currently there.

The practical reading is that .icbu belongs to backup and machine migration, and .ics belongs to everything else. Anyone who has been handed an .icbu and only wants part of it is better off restoring it on a spare account or a second Mac, then exporting the one calendar needed as .ics.

Accounts change this picture too. Apple points out that calendars held in an account such as iCloud or Exchange already live on the provider's servers, which "allows you to avoid having to manually back up and restore your calendars". Export and import are mainly a concern for calendars in the On My Mac section, and for moving between services that do not talk to each other.

The same file, three destinations

The file is standard. The handling is not.

Google Calendar takes .ics and .csv through Settings, then Import & Export, then selecting the file. The destination calendar can be chosen, and Google's page notes that "by default, events are imported into your primary calendar", which is the same trap as on the Mac and has the same fix. Two further details are worth knowing before starting. A .zip export has to be unpacked first, because each calendar inside it is a separate .ics that has to be imported individually. And repeating events imported from a .csv file, in Google's words, "might not show up that way" and land as a series of one-time events, because CSV has no field for a recurrence rule.

Outlook is stricter. Microsoft's page on calendar sharing states that in the new Outlook for Windows, "importing events from an .ics file is only supported for Microsoft 365 Exchange accounts". The same page describes what Outlook offers instead: publishing a calendar produces both an HTML link, for viewing in a browser, and an ICS link, for subscribing. That ICS link is the piece worth keeping, because it turns an Outlook calendar into something any other app can subscribe to.

A native Mac calendar sits on top of whichever of those accounts holds the events. The useful question when choosing one is not whether it can open a file, but whether it can subscribe to the feeds that matter and show them alongside everything else. The feature list is where to check that, and the guide covers the order in which accounts and subscriptions should be set up so that the first import lands where it was meant to.

Why duplicates appear, and what UID has to do with it

Duplicates are not random. They happen when the receiving calendar cannot tell that two events are the same event, and there are four reliable ways to arrange that.

The first is importing a file whose UIDs changed between exports. Some systems mint a fresh identifier on every export. Two exports of the same month then look like two unrelated sets of events, and both get created. The defence is to import once into a dedicated calendar and delete that calendar before importing again, rather than trusting the destination to deduplicate.

The second is importing a feed that is also subscribed to. The subscription keeps its own copy and refreshes it; the import made a separate, editable copy. Both are legitimate events as far as the app is concerned.

The third is CSV. There is no identifier column, so every import is a first import.

The fourth is importing the same file into two calendars while experimenting. Nothing is technically duplicated inside either calendar, but the week view shows everything twice. This one is the easiest to fix, by hiding or deleting one of the calendars.

Google's Calendar API describes the mechanism from the other side. Its import method exists "to add a private copy of an existing event to a calendar", and it requires the iCalUID to be supplied, noting that "the iCalUID and the id are not identical" and that recurring occurrences "all share the same iCalUIDs" while having different ids. Deduplication is keyed on that UID. When the UID is stable, repeated imports are safe. When it is not, nothing downstream can save the situation.

What to change first

Create an empty calendar and import into that, every time, before touching anything else. It costs ten seconds and converts an irreversible operation into a reversible one. Then decide, once, whether each source is a migration or a feed, and subscribe to the feeds instead of importing them.

If the events are arriving from several places and the week now needs to hold all of them at once, a calendar that keeps subscriptions, accounts and travel time on one surface is doing more work than the import dialog ever will. Caltimate is built for that side of the job.