Orchard

The Report That Earns Its Place on the Genius Bar Counter

Mon, 08 Jun 2026 09:00:00 -0400

Last week I wrote about why Orchard uses SQLite instead of Core Data — specifically, how an append-only time-series workload is a poor fit for Core Data’s object graph model, and how Point-Free’s SQLiteData library gives me the persistence layer and CloudKit sync I need without fighting the data model. That SQLite database is where every monitoring event lands: every app launch, every memory pressure reading, every disk snapshot.

This week I want to talk about what all that accumulated data is actually for — not the upgrade verdict, which I’ve covered before, but a feature I’m probably most excited about in the whole product: the Orchard Report.

The Problem It Solves

Anyone who has been to an Apple Store to buy a new Mac knows the experience. You’re trying to decide between configurations — 16 GB or 24 GB of RAM, 512 GB or 1 TB of storage — and the person helping you is working from guesswork about your actual usage. You’re working from guesswork too. The result is that people either overbuy out of anxiety or underbuy and regret it six months later.

The question “what Mac should I buy?” almost always reduces to “how do I actually use my current Mac?” And almost nobody has a good answer to that, because nothing has ever shown it to them clearly.

After running Orchard for a few weeks, I do.

What the Report Contains

The Orchard Report is a single-page branded PDF generated from the monitoring data already sitting in SQLite — no new collection required. It’s your Mac at a glance: chip generation, RAM, storage, macOS version, your upgrade verdict if applicable, and a plain-English usage summary. Typical concurrent apps. Memory pressure patterns. Disk usage trend. The things that actually determine whether a base-spec machine will suit you or whether you need to step up.

The report exports via share sheet or a dedicated Export button. It’s designed to be printed and handed over.

The Genius Bar Counter Effect

Here is the part that genuinely excites me as a product decision.

Every printed Orchard Report that appears on a Genius Bar counter is a physical advertisement inside Apple’s own retail ecosystem. An Apple Store employee who glances at a well-designed, useful report and thinks “this is exactly what I wish every customer brought” is now an organic recommendation channel. They will mention it to the next customer who comes in without one.

That channel cannot be bought at any price. It can only be earned through report quality and genuine utility to the people reading it. No amount of App Store keyword optimisation or press coverage replicates it. It requires building something worth recommending, which is fortunately the only kind of thing I’m interested in building.

Why This Ships in V1.0

The Orchard Report could easily become a scope trap — there’s always another data point worth including, another layout refinement worth exploring. I’ve avoided that by constraining it tightly: the report only uses data Orchard is already collecting. No new monitoring, no new schema, no new permissions. It’s a read-only view of the SQLite database, rendered as a PDF.

The rough version gets built in Phase 3, during QA and prep, and beta testers will shape the final content. The question I’ll put to them is simple: if you were buying a new Mac tomorrow, what on this report would you hand to the Apple Store employee? If the answer is obvious, it’s working — if not, the content gets simplified until it is. The polished version ships with the App Store submission.

With macOS 27 (“Golden Gate”) now confirmed Apple Silicon only, millions of Intel users face a forced hardware decision in the next twelve months. The Orchard Report gives them data-backed clarity about that decision — a concrete picture of how they actually use their Mac — instead of guesswork at the point of sale. It felt wrong to defer that to V1.1.

If you’re interested in being part of the beta and shaping what ends up on that single page, here’s where to start.

Next up: building a privacy-first sharing system so a family helper can monitor a Mac — without any data touching a server I control.

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.

Why I Chose SQLite Over Core Data for Orchard

Sat, 06 Jun 2026 09:00:00 -0400

In the previous post, I wrote about the challenge of monitoring Mac health from inside the App Store sandbox — how Orchard collects real signals (memory pressure, disk space, running apps, launch and quit events) using only APIs Apple permits in a fully sandboxed environment. Once I’d established what data Orchard could collect, the next question was obvious: where does it all go?

Every non-trivial Apple app eventually confronts that question, and for most developers, Core Data is the default answer. It’s deeply integrated into Xcode, it has decades of community knowledge behind it, and Apple continues to invest in it. So why did I walk away from it for Orchard?

The short answer: Core Data was designed for object graphs. Orchard needs a time-series log.

The Shape of Orchard’s Data

To understand the choice, you need to understand what Orchard is actually doing underneath. Every 15 to 30 minutes, the app captures a snapshot of your Mac: memory pressure state, free disk space, which apps are running, overall system state. It also logs discrete events — every app launch and quit — in real time via NSWorkspace notifications.

Over a week of normal use, that’s thousands of rows across a handful of tables. None of it is a complex object graph. It’s append-only event data, with occasional reads to compute aggregates. That’s exactly what SQLite was built for.

The schema reflects this directly. Most of it is a handful of flat, append-only tables: an app launch/quit event log (mac_app_events), periodic system snapshots (mac_usage_snapshots), the installed-app inventory (apps), and the recommendation engine’s outputs (compatibility_checks). The high-volume, privacy-sensitive tables — the event log and the snapshots — stay entirely local; a separate, smaller set describes the devices you own and the synthesised summary that syncs. No relationships to navigate, no managed object contexts to reason about.

Why Core Data Wasn’t the Right Fit

Core Data is excellent at what it does — managing the lifecycle of persistent objects, handling relationships, powering list UIs with fetched results controllers. But Orchard’s access patterns are almost entirely analytical. I’m not loading objects to display or edit. I’m asking questions like: What was the average number of concurrent apps running over the last 30 days? How frequently did memory pressure hit critical in the past two weeks?

Writing those queries in Core Data means fighting the abstraction. You end up in NSPredicate territory, wrestling with fetch request configuration, and often pulling more data into memory than you intended. SQLite with direct queries is more natural for this workload — and significantly easier to reason about when something goes wrong.

Schema migrations were also a concern. Core Data migrations can be fragile, particularly as a schema evolves across multiple app versions in the wild. SQLite migrations, handled explicitly, are predictable. I know exactly what’s happening.

The Point-Free SQLite Library

Rather than using raw SQLite calls, I’m building on the Point-Free SQLiteData library, which includes a SyncEngine for iCloud. This is what makes the CloudKit integration tractable without writing a custom sync layer from scratch — and without touching CKRecord, CKShare, or CKOperation directly.

The library lets me define my schema with the @Table macro in Swift and write type-safe queries via StructuredQueries. All CloudKit record mapping, conflict resolution, and share management is handled by the SyncEngine internally.

The privacy architecture falls out of this naturally. Raw event data — every app launch, every memory pressure reading — stays in local SQLite on your Mac and never leaves it. Only synthesised summary data crosses to iCloud — chiefly a device_summary row carrying aggregated health metrics and the current upgrade verdict, alongside basic device-inventory records. The iOS companion app (planned for January 2027) will read from this summary. Your granular event log is never uploaded.

Honesty as an Architectural Constraint

One design decision that shaped the schema more than I expected: the compatibility engine’s three-bucket model.

Every installed app is classified as confirmed compatible (✓), confirmed incompatible (⚠), or unverified (?). The verdict is conservative — only confirmed signals drive Safe, Caution, or Wait — but unknowns are never hidden. They’re surfaced honestly, ranked by how frequently you actually use each app. If you launch Final Cut Pro every day and Orchard can’t confirm it’s compatible with macOS 27, the verdict reasoning says so explicitly: “You use Final Cut Pro daily, but Orchard can’t confirm it’s compatible — check with the developer before upgrading.”

This matters for the schema because compatibility_checks needs to store not just the verdict, but the reasoning — including the count of unverified apps and the specific heavy-use unknowns that were flagged. Honest output requires honest data.

The Practical Outcome

The analysis engine reads from mac_usage_snapshots and mac_app_events to compute the aggregate metrics that feed the recommendation engine. The recommendation engine produces its Safe / Caution / Wait verdict and writes it to compatibility_checks. Everything flows in one direction, the tables have clear owners, and the queries are straightforward SQL.

None of that requires an object graph. It requires good data design and the right tool for the job.

If you’re building something similar — monitoring tools, health apps, anything with an event log at its core — I’d encourage you to start with the same question I did: is this an object graph, or is it a series of facts over time? The answer should drive the choice.

Next up: the Orchard Report — turning all this local data into a single-page PDF you can hand to an Apple Store employee when you’re choosing your next Mac.

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.

How I Monitor Mac Health from Within the App Store Sandbox

Thu, 04 Jun 2026 09:00:00 -0400

If you read the origin story, you know why Orchard exists: I got tired of watching family members make Mac upgrade decisions based on nothing more than “Apple says I should.” After 30 years in the Mac industry — and years running a local user group where “new hardware or not?” was the question that came up every single autumn — I knew the real answer required more context than any generic prompt could provide.

What I didn’t know when I started building Orchard was how much of that context I could actually collect from inside the App Store sandbox.

The Constraint That Focused Everything

The Mac App Store sandbox exists to protect users. It blocks the obvious monitoring approaches: no arbitrary shell commands, no deep process inspection, no background daemon installed via LaunchAgent. Everything that makes a traditional Mac monitoring tool work is off the table.

Early in the design I made a deliberate choice to embrace that constraint rather than fight it. Orchard was always going to live in the App Store — the same distribution model I used with FruitJuice — and that meant every signal had to come from APIs Apple explicitly makes available to sandboxed apps.

The constraint turned out to be a feature. Staying within Apple’s lines meant thinking carefully about which signals actually matter for the question Orchard is trying to answer: should you upgrade, and if so, to what?

The Four Signals That Matter

App launches and quits come from NSWorkspace.notificationCenter. This sandbox-approved API delivers real-time notifications every time an app opens or closes. Orchard uses this to build a continuous picture of which apps you actually run — not which ones are installed. That distinction matters enormously for upgrade advice. An incompatible app you haven’t touched in two years is a very different risk than one you open every morning. That usage history lives in a local SQLite database and never leaves your Mac.

Memory pressure is detected using dispatch_source with DISPATCH_SOURCE_TYPE_MEMORYPRESSURE. This gives system-level pressure events — normal, warning, critical — without needing access to per-process memory figures. It’s event-driven rather than polling, which is efficient, and the aggregate picture it paints — how often is your Mac genuinely under memory stress? — is far more useful for an upgrade decision than a single RAM utilisation snapshot. I pair this with host_statistics64 for memory totals.

Disk space comes from URL.resourceValues(forKeys:) — .volumeAvailableCapacityForImportantUsageKey for free space and .volumeTotalCapacityKey for total, no special entitlements required. I deliberately avoided the older FileManager.attributesOfFileSystem route: it reports the raw POSIX free count, which ignores purgeable space — Time Machine local snapshots, evictable caches — and can disagree with Finder by tens of gigabytes. A verdict that contradicts the number already on your screen is worse than no verdict at all, so Orchard uses the same figure Finder and About This Mac show. I sample this periodically and trend it over time. A Mac running low on disk isn’t just uncomfortable — it’s an upgrade blocker. You need headroom for the installer, and you need to understand whether your storage habits are growing into a problem before you commit to a smaller-capacity machine.

Concurrent running applications at any moment come from NSWorkspace.runningApplications. Combined with the launch/quit event stream, this builds an understanding of how many apps you typically have open at once — which feeds directly into the RAM sufficiency assessment and, eventually, into hardware purchase guidance.

The Compatibility Picture (And Its Honest Limits)

Sandbox APIs tell me a lot about how your Mac behaves. Telling you whether your apps will survive macOS 27 requires a different approach.

Now that macOS 27 (“Golden Gate”) is confirmed Apple Silicon-only, the compatibility problem actually gets simpler than it used to be. For Intel Macs, the verdict is automatic: Wait. No app inventory analysis needed. The hardware is the blocker.

For Apple Silicon Macs, Orchard classifies every installed app into one of three buckets: confirmed compatible, confirmed incompatible, or unverified. The verdict is conservative — only confirmed signals drive Safe, Caution, or Wait. But unverified apps are never silently hidden. If you use an app every day and Orchard can’t confirm it’s ready for macOS 27, you’ll see that explicitly: “You use Final Cut Pro daily, but Orchard can’t confirm it’s compatible — check with the developer before upgrading.”

Hiding the unknowns would be a lie of omission. From my user group days, I saw what happens when someone upgrades confidently and discovers on the other side that a critical app is broken. That’s the exact situation Orchard exists to prevent.

What I Can’t See (And Why That’s Fine)

CPU and GPU temperatures, per-process CPU usage, detailed memory breakdowns by app — the sandbox blocks all of it. I can’t run softwareupdate to check for pending updates or inspect processes that aren’t my own.

In practice, none of those missing signals are necessary for what Orchard does. The question I’m answering isn’t “what is your CPU doing right now?” It’s “is your Mac ready for what’s coming, and does it have the legs for another few years?” Those questions are answerable from everything I can see — and answerable honestly.

What This Builds Toward

Every event Orchard observes goes into local SQLite, processed through the Point-Free SQLiteData library. Periodic snapshots capture system state. The recommendation engine aggregates all of it into a Safe, Caution, or Wait verdict with plain-English reasoning.

That same dataset is what powers the Orchard Report — at launch, a single-page branded PDF of your actual Mac usage, designed to be printed and brought to the Apple Store when you’re making a hardware purchase decision. Knowing whether to buy the base MacBook Air or step up to 16 GB of RAM is a lot easier when you have real data about how you actually use your current Mac.

The sandbox didn’t limit Orchard. It gave it focus.

Next up: why I chose SQLite over Core Data for time-series Mac monitoring — and what that decision unlocked.

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.

Why I'm Building Orchard

Tue, 02 Jun 2026 22:46:49 -0400

Every year, without fail, it starts with a phone call.

“Should I upgrade to the new macOS?” my mom asks. Or my aunt. Or a friend of a friend who somehow ended up in my contacts as the family’s designated Mac person. The question sounds simple. The honest answer rarely is.

I’ve been working in the Apple ecosystem for thirty years. I’ve shipped apps. I understand how upgrades work, what can break, what to watch for. But when someone calls me from across the country asking whether they should upgrade their MacBook, I’m flying blind. I don’t know what apps they depend on. I don’t know their disk space situation. I don’t know whether the one creative tool they use for work has been updated yet. I’m giving advice based on general knowledge, not their actual machine.

Apple, of course, always says upgrade. That’s not cynicism — it’s just how it works. Their job is to move people forward. Nobody at Apple is incentivized to tell your mom to wait three months.

That gap — between “Apple says upgrade” and “what’s actually right for your specific Mac” — is where Orchard lives.

The initial idea was narrow: build something that gives people an honest, personalised upgrade recommendation: Safe, Caution, or Wait. Not based on Apple’s marketing, but on your actual hardware, your actual apps, your actual usage patterns.

But the more I sat with the problem, the more I saw something bigger.

The upgrade decision gets its marketing moment in June, when Apple announces the next macOS at WWDC. That’s when enthusiasts pay attention. But most people don’t make the decision in June. The actual question — should I upgrade? — lands in the Fall, when Apple ships the release and starts nudging everyone with a notification. By that point, if Orchard has been running quietly in the background since summer, it already knows your Mac. It knows which apps you use every day, how your memory and disk have been trending, whether anything in your setup is likely to cause a problem. The upgrade question gets a real answer, not a guess.

That’s where Orchard earns its subscription. Not the upgrade check. The year-round presence.

This year adds another dimension entirely. Apple just confirmed that macOS 27 (“Golden Gate”) drops support for Intel Macs — they just got their last supported release. For a lot of people, the question isn’t “should I upgrade the OS.” It’s “do I need a new Mac altogether.” That’s a harder, more expensive decision, and it deserves better than a shrug.

There’s a second use case I care about just as much, and it comes directly from my own life.

When a family member calls with a Mac problem, I have almost nothing to go on. They describe symptoms in ways that don’t map to what I’d see on screen. I ask them to read me things and they read the wrong things. We both end up frustrated.

Orchard gives me a window into their Mac — memory pressure trends, disk space, what’s running, whether their apps are compatible with the next macOS — all shared privately through iCloud — from another Mac at launch, and from a native iOS app early next year. No screen sharing. No credentials changing hands. No “can you install this remote desktop thing.” Just the information I need to actually help.

For millions of people who informally support family members with Apple devices, this relationship exists already. It’s just painful. Orchard formalises it in a way that respects everyone’s privacy and doesn’t require anyone to give up control of their machine.

I’m building Orchard because the problem is real, the gap is clear, and nobody else is filling it honestly.

If you’re someone who wants a straight answer about your Mac — or someone who wants to be a better helper for the people you care about — Orchard is for you.

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.