Building a Privacy-First Sharing System for Family Device Management
In the last post, I wrote about the Orchard Report — a single-page branded PDF of how you actually use your Mac, designed to be useful when you’re standing in the Apple Store trying to make a $1,200 hardware decision. That feature is built for the person who manages their own Mac. But Orchard has a second persona to serve: the IT Helper. The tech-savvy person who manages a family member’s Mac from afar. Getting data to them raised a different set of questions — and the answers shaped one of the more interesting pieces of the architecture.
One of the core promises of Orchard is that your data never leaves Apple’s ecosystem. That’s not marketing copy — it’s a design constraint that shapes every architectural decision, including this one: how do you let a helper monitor a family member’s Mac — from their own Mac — without any of that data ever touching a server I control?
The answer is CloudKit — but the implementation is more considered than that one word suggests.
What actually syncs — and what doesn’t
Orchard never uploads raw event data. The individual app launch and quit events, the granular memory pressure readings, the periodic system snapshots — all of that stays in SQLite on the Mac itself, permanently local. What reaches iCloud is synthesised summary data — chiefly the device_summary row: the current Safe / Caution / Wait verdict, aggregate metrics like average memory pressure frequency and available disk space, and a timestamp — alongside basic device-inventory records. That summary syncs every one to six hours, with an on-demand option when the helper actively opens Orchard. And it’s the same synced data wherever the helper looks: the Mac-to-Mac shared view that ships at launch and the iOS companion that follows both read the identical device_summary surface — the iPhone app is a second reader of the same summary, not a second, richer pipeline.
The helper sees what they need to have a useful support conversation. They don’t see a surveillance feed. There’s a meaningful difference between those two things, and the schema enforces it rather than relying on policy.
The SyncEngine does the heavy lifting
Rather than writing direct CloudKit code — no CKRecord, no CKShare, no CKOperation — Orchard uses Point-Free’s SQLiteData library with its built-in SyncEngine. The SyncEngine handles record mapping, conflict resolution, invitation generation, acceptance flows, and share revocation. Configuring which tables sync is declarative; the plumbing disappears. This is one of those cases where the right library doesn’t just reduce code — it removes an entire category of subtle errors.
When sync fails for any reason, the shared-device view surfaces the last-synced timestamp prominently — on the Mac at launch, and in the iOS companion in the new year — so the helper always knows how fresh the data is. Stale data labelled as stale is a feature. Stale data presented as current is a bug.
The invitation flow is the hardest part
The SyncEngine handles invitation generation and acceptance, but the experience of accepting an invitation still had to be designed carefully — because this is the moment Orchard can’t fully control. The helper sends an invitation, and then a non-technical person, possibly a parent in their seventies, has to successfully accept it on their Mac. That flow had to be designed for the least technical person in the relationship, not the most. Single page. Minimal decisions. No jargon. Getting this wrong means the helper relationship never gets established, and the product’s core value proposition evaporates.
Revoking access is just as important as granting it
A privacy-first architecture has to make it easy to say no, not just yes. Access can be revoked at any time through iCloud settings — no Orchard involvement required, no support ticket, no waiting. This is deliberate. Orchard should never be the gatekeeper of someone else’s data sharing preferences.
Why this matters more now
With macOS 27 (“Golden Gate”) now confirmed Apple Silicon only, millions of Intel users are facing a hardware decision they can no longer defer. The helper relationship becomes most valuable precisely when the stakes are highest — not a free OS update, but a $1,200 to $3,000 hardware purchase. A helper who can see that their parent typically runs three apps at once and uses 90 GB of disk has something concrete to say. That’s the conversation Orchard is built to enable.
The result is a sharing model that feels almost unremarkable to use, which is exactly what good infrastructure should feel like. The helper opens the shared view, sees the Mac’s status, and can have an informed conversation — from anywhere, with no screen sharing, no VNC tunnel, and no compromise on the end user’s privacy.
Next up: the compatibility engine. Two weeks, hard timebox, scope locked at the end. More on that soon.
It launches this fall alongside macOS 27. Follow along at theorchard.app, where you can “Follow the Build” and sign up to be notified about early access this Summer!
Thanks for reading.