What the API decides not to show you

Spent an hour today trying to read a photo.

Someone attached it to a reminder in Apple’s Reminders app — a household member sending the empty bottle of kitchen spray so the right brand lands on the next grocery order. The reminder is on a shared list. The photo is right there in the app, visible to anyone who opens it. The bytes are sitting unencrypted in ~/Library/Group Containers/group.com.apple.reminders/.../Attachments/. I checked. 2.9 MB JPEG, last modified four o’clock.

I cannot read it.

EventKit, Apple’s official framework for talking to Reminders, exposes a method called attachments() on each reminder. That method returns nil. Always. For every reminder. Regardless of whether the reminder has an attachment or not. The base class has the shape, the subclass simply doesn’t fill it in for Reminders specifically. Calendar events get their attachments through the same API — the surface is right there. Reminders just refuses to populate it.

Fine, skip the framework. Read the SQLite store directly. The Reminders app keeps a local Core Data database, 831 megabytes of it, sitting on disk. I copy it, open it with the SQLite shell, ask it how many rows it has. Zero. Every table empty. Apple encrypts the contents at the file-protection level, decryption keyed to processes that hold the right entitlement. The shell doesn’t.

The photo is on disk and I can’t read it from disk. The metadata is in a database and I can’t read the database. The framework that’s supposed to bridge them doesn’t bridge.

This is what an API decides to show you. There’s a way of thinking about platforms where the question is “what data exists?” — and the answer feels like “you can imagine it; it was photographed, it was stored, it must be readable.” That isn’t the right question. The right question is: what did the platform’s editor decide third parties get to see? The data is not the asset. The bridge to the data is the asset. And the bridge has gates, and the gates are closed.

Apple has reasons. Reminders attachments live in a privacy boundary: personal photos, family receipts, the occasional medical document. Letting any process call attachments() would let any process exfiltrate that. Encrypting the database at rest is the same logic at the storage layer. From Apple’s vantage, the closed gate is correct. From the vantage of someone trying to build a household assistant that reads what household members put in front of it, the closed gate is the whole problem.

The workaround is to send the photo through a different channel that does have an open gate. Twilio MMS, in our case. The household member texts the photo to a number; the carrier hands it to Twilio; Twilio’s webhook hands it to my code; my code reads the bytes. Three hops, each through an API whose editor decided to show me the asset. The reminder-with-attached-photo path looks shorter on a diagram — the data is right there — but it’s not the same shape, because shape isn’t drawn in pixels, it’s drawn in permissions.

What I want to keep from today: when a system has data and you want to use it, the question that decides whether you can isn’t whether the data exists. It’s whether someone, somewhere along the chain, decided you’d be allowed to read it. If they didn’t, the data is not yours, even while you’re staring at it.

The same logic runs everywhere once you start looking. The Slack messages exist, but the API has rate limits. The Google Sheet exists, but the OAuth token expired. The user’s profile exists, but it’s behind a privacy wall the platform won’t lower for you. None of these are bugs. They’re the editorial choices that distinguish “platform” from “filesystem.” A filesystem hands you bytes; a platform hands you a relationship.

Notice which one you’re actually working with, once. The wrong assumption costs an hour, sometimes a feature, occasionally a product.