In my previous post, I wrote about how Apple’s Contacts app treats your relationships like a filing cabinet — a flat list of static cards with no context, no history, and no awareness of how people actually matter to you. That’s a product problem. But it’s also a technical one.

Underneath the Contacts app sits a framework called CNContact, introduced at WWDC 2015 as a replacement for the widely despised AddressBook.framework. AddressBook was a C-based API with no Objective-C layer, opaque types like ABRecordRef, and virtually no error handling. When Apple announced its deprecation, the WWDC audience cheered — one of the loudest reactions in the conference’s history.

CNContact was a genuine improvement. Type-safe. Thread-safe immutable objects. A keysToFetch system that lets you load only the properties you need. It’s a well-engineered API for an outdated model. Because while the engineering got better, the underlying concept of what a contact is didn’t change at all. A person is still a card with fields on it. Name, phone number, email, address.

It’s 2026 and that model is broken.

What CNContact Actually Is

CNContact is an immutable object representing a single contact record. You access the database through CNContactStore, and when you fetch contacts, you specify which properties you want via keysToFetch — conceptually similar to a SQL SELECT where you name your columns.

A contact has string properties for names (givenName, familyName, middleName), and multi-value properties for phone numbers, email addresses, and postal addresses. Those multi-value fields use CNLabeledValue — an immutable tuple pairing a label (like “home” or “work”) with a value (like the phone number itself). Modification goes through CNMutableContact, a mutable subclass. A CNContactType enum distinguishes between people and organizations, though the distinction is thin — the same flat field structure applies to both.

The engineering is competent. The problem is what the engineering models.

A Contact Is Not a Business Card

CNContact knows a person’s name, phone numbers, email addresses, physical addresses, birthday, organization, and social profiles. That’s what you’d find on a business card, plus a birthday.

It doesn’t know when you last spoke to this person, how you met them, who introduced you, or what your relationship actually is. It can’t tell you whether someone is important to you right now or someone you haven’t spoken to in three years. It doesn’t understand any connection between this person and your other contacts. There’s no concept of interaction history, relationship strength, or the social graph between the people in your life.

CNContact models a person as a record. It does not model a relationship. In 2026, the relationship is the valuable part. The phone number is the least interesting thing about someone in your network — what you can’t easily recover is context.

The model doesn’t even work well for its most basic use case. There’s a single organizationName field — one company per contact. People consult, freelance, change jobs, hold board seats. CNContact can’t represent any of that. It’s not a model of a person or a business. It’s a model of one person at one company at one point in time.

Apple does expose a contactRelations field — you can label someone as a spouse, parent, or assistant. But it’s a string label, not a link. It doesn’t point to another CNContact. You can’t traverse your network. You can’t ask “show me everyone connected to Sarah.” The relationships, like everything else in this framework, are flat text on a card.

The notes field is singular — one freeform text blob per contact. If you want to track conversations over time, or keep structured notes about multiple interactions, you’re appending to a wall of unstructured text. No timestamps, no separation, no history.

There is no concept of archiving. A contact exists or it’s deleted. There’s no “inactive” state, no way to move someone to the back of the drawer without losing them entirely.

The Identifier Problem

Every CNContact has an identifier property — a string that should uniquely identify the contact. The natural instinct is to use this as a foreign key, linking your app’s data to a specific person.

That instinct will hurt you.

The identifier is local to the device. The same human being on your iPhone and your iPad will have different identifiers. The identifier isn’t stable across backup and restore cycles. Developers on Apple’s own forums have reported that the same contact accessed through different code paths on the same device returns different identifiers — share a contact from Contacts.app and you get one with an :ABPerson suffix, select it via CNContactPickerViewController and you get a different one without it.

Apple can correlate contacts across devices because they control iCloud and the sync engine beneath the framework. Third-party developers cannot. The workaround is rolling your own matching logic — normalized phone numbers, email addresses, name combinations — essentially rebuilding deduplication from scratch.

If you want to build anything that tracks a contact over time — notes, interaction history, relationship metadata — you can’t reliably key it to a CNContact. The identifier that’s supposed to be your anchor is quicksand.

The Frozen Schema

So the identifier is unreliable. Could you at least store your additional data on the contact itself?

No.

CNContact has a fixed set of properties. No custom fields, no metadata dictionary, no extension points. The schema is what Apple decided a contact needed in 2015, and it hasn’t meaningfully expanded since. “Last contacted,” “relationship strength,” “met at WWDC 2024” — anything not on Apple’s predetermined list requires your own data store.

That data store needs a key to link back to the contact, which brings you directly back to the identifier problem. You’re building on a foundation that shifts under your feet.

Even the simplest CRM systems offer custom fields, tags, activity timelines, and relationship types. CNContact isn’t missing features — it’s missing the concept that a contact might mean something different to different people and different apps.

Your Data Lives on Apple’s Terms

I’ll save the full portability deep-dive for a future post, but the short version: getting your contacts out of Apple’s ecosystem is harder than it should be.

The only native export format is vCard. No CSV, no JSON, no bulk API. On iOS, you can share one contact at a time. Export is all-or-nothing per contact — you can’t select which fields to include. Import vCards back in and you’ll likely create duplicates, because the “unified contact” system that deduplicates on-device doesn’t survive a round trip.

Your contacts flow into Apple’s ecosystem with minimal friction. Getting them out requires workarounds and third-party tools. This asymmetry is not accidental.

Built for a World That Doesn’t Exist Anymore

The keysToFetch system is well-designed. The immutable/mutable pattern is sound. CNLabeledValue is a good abstraction for multi-value properties. Apple’s engineers built a competent framework.

They built it to digitize the Rolodex, and they succeeded. CNContact is an excellent digital Rolodex card.

The problem is that we don’t live in a Rolodex world. Our relationships are contextual, dynamic, and cross-platform. A contact isn’t a card with a name and number — it’s a node in a network, with history, context, and meaning that changes over time. CNContact doesn’t model any of that. Its closed schema means you can’t teach it to.

It’s a 2015 solution to a 1985 problem, and it’s the foundation that every app on Apple’s platforms is expected to build on when it wants to work with the people in your life.

What’s Next

I’ve spent enough time studying this framework to understand that patching it isn’t the answer.

The problems compound. There’s no stable identifier, so you can’t reliably extend a contact with your own data. There’s no extensible schema, so you can’t store that data on the contact itself. And there’s no universal key to map against — some contacts are unique by phone number, some by email, some by name and company, some by something else entirely. Every contact is a special case.

You could try to build a mapping layer on top of CNContact. Normalize phone numbers, deduplicate emails, fuzzy-match names. But you’d be building an increasingly fragile bridge between your data and a foundation that was never designed to support it. At some point, the cost of maintaining that bridge exceeds the cost of building something new.

The model needs to change. Not the UI on top of it, not the permissions around it, not the visual design — the model itself. What a contact is. How identity works. How relationships are represented. How your data moves between devices and platforms.

I’m working on that. More soon.

When I was a kid, my dad carried a Filofax everywhere. A thick leather binder stuffed with business cards, meticulously organized. It was his most important professional tool — his grail. He could flip to any section and find exactly who he needed, with notes scribbled in the margins about when they’d last spoken and what they’d discussed.

I sometimes wonder if he had a better handle on his network than any of us do now with our phones.

Everyone has a contacts app. Almost no one thinks about it. It’s done roughly the same thing since phones went digital: show you a list of names with phone numbers and email addresses. Apple’s Contacts app is the one I know best, and with macOS 26 and iOS 26, they finally gave it a visual redesign. They somehow made it worse. But the real problem isn’t the redesign. The real problem is the model underneath — and it hasn’t changed in decades.

What Your Contacts App Actually Does

Apple Contacts is a card viewer. You scroll a list, tap a name, and see fields. It stores names, phone numbers, email addresses, physical addresses, birthdays, a photo, and a single notes field. That’s roughly what you’d find on a business card, plus a birthday.

Here’s what it doesn’t do. It can’t tell you when you last talked to someone. It doesn’t show you how the people in your life are connected to each other. It can’t help you organize contacts in meaningful ways — groups exist but are barely functional, and after more than a decade you still can’t create a group on iPhone without workarounds. It doesn’t track any history or context about a relationship. It doesn’t handle the basic reality that people change jobs, move, and get new numbers. There’s no way to archive a contact — you either keep it or delete it, with nothing in between.

It treats every contact the same. Your spouse and someone whose card you scanned at a conference three years ago sit in the same flat list, given equal weight.

The Redesign Made Things Worse

With macOS 26 (Tahoe) and iOS 26, Apple applied their new Liquid Glass design language to Contacts. The result has been rough.

On macOS, users are reporting that the app crashes when adding new contacts, closing mid-entry without saving. The new photo and background blocks take up enormous screen real estate and flicker when scrolled. Basic operations are broken — copying a contact’s name pastes it as oversized, centered text in Mail, and you can’t copy a company name or job title at all. Users with large contact databases are hitting white screens. Dragging contacts to groups randomly fails.

On iOS 26, you can’t delete contacts from search results — you have to manually scroll through the full list. The redesigned Phone app makes it harder to actually call someone from your contacts. Everything requires more taps than before.

The consistent theme: more visual chrome, less functionality. The redesign is cosmetic surgery on an app that needed a rethinking.

The Things That Were Always Missing

The Tahoe redesign exposed problems, but the app was stagnant long before it.

There’s no interaction history. Contacts has no idea when you last emailed, called, or texted someone — even though your phone has all of that data. There’s no concept of “important” versus “stale” contacts, no way to surface people you’re losing touch with or flag people you need to follow up with.

There’s one company field per contact. In the real world, people consult, change jobs, and hold multiple roles. Contacts doesn’t accommodate that. When someone’s information changes, the old data is simply overwritten — there’s no history, no record of where they used to work or what their old number was.

The notes field is singular. One freeform text blob per contact. If you want to track multiple interactions or keep notes over time, you’re appending to a wall of text with no structure.

You can’t archive. A contact is either active or deleted. There’s no “I don’t need this right now but I don’t want to lose it” state — something my dad’s Filofax handled effortlessly by just moving a card to a different section.

Group management on iOS still doesn’t exist in any real way. Smart groups, tags, filters — none of it. The merge and deduplication tools are unreliable. Sharing is limited to one contact at a time, in vCard format only, with no ability to choose which fields to include.

A Card Viewer, Not a Relationship Tool

The fundamental issue is how the app thinks about what a contact is. To Apple Contacts, a contact is a record — a static card with data fields on it.

But your contacts aren’t records. They’re relationships.

Some people matter more than others at different times in your life. The context of how you know someone, what you’ve discussed, who connected you — that’s the valuable information. The phone number is the least interesting thing about someone in your network.

Apple does allow you to add relationships to a contact — mother, spouse, assistant. But it’s just a text label. It’s not a real link to another contact in your database. You can’t traverse your network. You can’t ask “show me everyone I know through Sarah” or “who do I know at this company.”

This flatness shows up across Apple’s entire product line. In Photos, you can tag a person’s face — but it’s not connected to their contact card. Everything about people in Apple’s ecosystem feels siloed and disconnected, like each app reinvented the concept of “a person” from scratch.

A contacts app should understand relationships, not just store records. It should have opinions about your network — who you’re close to, who you’re drifting from, who you should reconnect with. Instead, what we have is a filing cabinet.

Competitors Exist, But They’re Built on the Same Foundation

There are alternatives. Apps like Cardhop offer better search, natural language input, smart groups, and interaction tracking. Users are actively leaving Apple’s broken Tahoe experience for these tools, and for good reason — they’re genuinely better at the basics.

But they’re all built on top of the same underlying contact model. They can make the card viewer faster, smarter, and prettier. They can add features on top. But they can’t change the fact that the foundation treats a contact as a flat record with a fixed set of fields. They’re still building better Rolodexes.

The demand for something fundamentally better is real and growing.

Why I Care

I’ve been thinking about how we manage relationships since studying social networks in college in 2005. Twenty years later, the default tool for managing your most important connections is still a digital address book. My dad’s Filofax had sections, annotations, and a system that reflected how he actually thought about people. Our phones, with all their power, offer less.

A contact isn’t a name and a number. It’s a relationship — with history, context, and meaning that changes over time. The model underneath Apple Contacts, and every major contacts platform, doesn’t reflect that.

In the next post, I’m going to dig into why — at a technical level — the foundation is broken. And after that, what I think we should build instead.

This Instagram DogsOfNpt is about these beautiful doggos and their adventures around Newport, RI. Expect the photography quality to grow as I learn skills or wane as I begin to get overwhelmed with other aspects of life.