How I Monitor Mac Health from Within the App Store Sandbox

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.