In the last post, I wrote about the design of Orchard’s sharing system — how a helper can monitor a family member’s Mac through iCloud, with nothing ever touching a server I control. Design is one thing. Proving it survives contact with two real people, two real Apple IDs, and a real iCloud account is another. That’s what the last few weeks have actually been about.
Why I didn’t trust my own mocks
It’s easy to build a sync system that works perfectly in a single account, on a single machine, in a debugger. The bugs that matter hide in the gap between two accounts — the moment one person’s data has to become visible, correctly and only as intended, on someone else’s device. So I set up a real two-account rig: my wife’s Apple ID in a second local macOS user account, standing in for the second Mac, sharing and accepting for real through the system’s own iCloud plumbing. No mocks, no simulators, no assuming.
What held up
A lot did, and I want to give that its due before getting to what didn’t. The Safe / Caution / Wait verdict arrived on the helper’s side intact, every time. Turning the app-list sharing toggle on and off correctly grew and shrank what the helper could see, live. Revoking access — from Orchard’s own button and from the system’s own sharing panel, two genuinely different code paths — cleaned up fully on both sides both times I tried it. Pulling the network mid-sync failed loudly but safely, and recovered the moment the connection came back. And when I signed the helper account out of iCloud entirely, Orchard kept the local data instead of wiping it — which took a deliberate override of the sync library’s default behavior. Monitoring is offline-first by design; a sign-out shouldn’t erase weeks of your own Mac’s history.
What broke — and why I’m glad it did now
Real testing found real bugs, the kind that never show up in a single-account demo. The “Shared” badge was flipping on the instant the invitation was sent, before the helper had actually joined anything — which is backwards; showing “Shared” when nobody’s looking yet is worse than showing nothing. A shared Mac’s display name was falling back to a raw hardware model string instead of the name you’d actually recognize from Finder or AirDrop. And one network failure leaked a raw error code onto the screen — the kind of message that means nothing to anyone who isn’t debugging CloudKit for a living. All three are fixed. None of them were things I’d have caught without a second real account watching.
The one thing still open
Here’s the honest part. Tapping an invitation link is supposed to just open Orchard and prompt you to accept the share — one tap, no jargon, built for the least technical person in the relationship, exactly like I described last time. In testing, that hand-off didn’t reliably fire. I built a way to force it open directly so it didn’t block everything else, but that’s a workaround for testing, not a fix. This is exactly the flow a real monitored family member will depend on, so it’s getting dedicated attention before beta rather than being re-tried a few times and assumed fine.
What this unlocks
With the required stages of real two-account testing now passed, the Mac-to-Mac shared view isn’t a design document anymore — it’s one Mac genuinely showing another Mac’s status through iCloud, with no server of mine in between. It’s also the exact same data pipe the iOS companion will read from in January. Proving it now, on the simpler of the two platforms, means the iOS work inherits a sync layer that’s already been through real bugs instead of just real diagrams.
Next up: how the Orchard Report grew from an idea into something real enough to hand someone at the Apple Store.
Follow along at theorchard.app, where you can “Follow the Build” and sign up to be notified when early access opens.
Thanks for reading.