Monday, July 13, 2015 [Tweets] [Favorites]

Contacts Framework Identifiers

Greg Pierce:

I’ve experimented with the the Contacts Framework a bit. One thing that caught my attention was that the documentation specifically calls out that identifier properties for contact, group and other objects vended by the framework can be persisted between app launches.

[…]

It appears the identifiers given are unique to the device, but not the app, and are changed if a contact is ever removed and restored to the device via any sort of sync process.

[…]

Long story short, it would not be practical for Drafts to have an action that linked directly to a contact, because it would not be possible to sync that action across devices and still have it point to the same contact.

That’s a shame. With the old Mac Address Book framework, there was a uniqueId (kABUIDProperty) property, a string that I think was the same across devices. (Unfortunately, contrary to the documentation, iCloud syncing could cause this permanent identifier to change.)

iOS instead had a typedef int32_t ABRecordID that also changed with syncs:

Every record in the Address Book database has a unique record identifier. This identifier always refers to the same record, unless that record is deleted or the data is reset. Record identifiers can be safely passed between threads. They are not guaranteed to remain the same across devices.

The recommended way to keep a long-term reference to a particular record is to store the first and last name, or a hash of the first and last name, in addition to the identifier. When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record.

In the new Contacts framework, the identifier is a string (like the old Mac API) that is only unique on a given device (like the old iOS API).

I assume that this was done for privacy reasons—though the benefit is not entirely clear to me—but it makes for more coding work to get an inferior user experience, with some features like Pierce suggests not really possible.

Update (2016-03-18): Greg Pierce:

Let’s talk about ContactsUI. Deprecate its predecessor and fix 0 bugs in it since iOS 9b1.

2 Comments

I wonder how much other, non- iCloud, sync services come into play here. I remember dealing with Exchange-synced contacts in the early days was a bastard because they lacked certain attributes that synced-from-a-Mac contacts would have.

...though, I don't think I've looked at what at the Mac-side implementation since before Apple really embraced support for third party contact services...

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment