I’ve never actually written about the compatibility engine directly, even though it’s the part of Orchard that decides whether your apps survive an upgrade. It’s been built for a while — Info.plist inspection, a curated rules database, a Safe / Caution / Wait verdict per app. What I want to write about instead is what happened over the last couple of weeks, because it turned into the most important realization of the project so far, and it wasn’t a coding problem at all.
Why the rules can’t just live in the app
Apple’s Info.plist tells you an app’s minimum supported OS version — the floor. It tells you nothing about the ceiling: whether that app will actually run on next year’s macOS. That has to come from somewhere else, because nobody publishes it in a machine-readable way. So Orchard ships a curated database of per-app, per-version rules, keyed on the one field that matters most: the highest OS version an app is known to run on. And because “known to run on” changes constantly as vendors update their apps, that database can’t be frozen into the app binary at build time — it has to be a live feed Orchard can refresh without waiting on an App Store review.
So that’s what I built: a CSV file I edit by hand, a validator that turns it into JSON, a publish script that pushes it to theorchard.app/v1, and a client in the app that fetches it, caches it locally, and falls back to a bundled seed if it can’t reach the server or the cache goes stale. Straightforward, in theory. I got it fully live this week — real 200 responses, real conditional 304s when nothing’s changed, a working fallback chain. And then I sat down to actually fill it in, and that’s where the real story starts.
The validator kept catching me being wrong
Before I even got to the content problem, building the safety rails around this thing surfaced a string of bugs that were each individually small and collectively unsettling, because every one of them would have shipped a confident, wrong answer to someone.
A ceiling written as a bare major version — “26,” say — turns out to mean only 26.0, not the whole 26.x line, because the comparison is precise to however many components you give it. Write it that way and everyone running 26.1 or later gets told their app is at risk, on the OS they’re already using. That’s not a curation mistake, that’s a validator-shaped hole, so it’s now a hard build error.
Real installed version strings are messier than I’d assumed — Zoom reports something like 6.2.10 (43047), Spotify appends a long build suffix. My band-matching logic wanted a clean dotted number, so those apps would have silently matched nothing and reported as unverified regardless of what I’d curated for them. And the CSV itself has a boring but real gotcha: Numbers and Excel both save with Windows-style line endings, and a naive line-by-line parser reads the entire file as a single row when it hits those. All fixed, none of them dramatic on their own — but a pattern was forming.
The one that actually stopped me
Here’s the bug that mattered most. One of my six seed entries — Photoshop — had a note attached: “Verified on macOS 27 beta 3.” The date on that note was four days before the first macOS 27 beta was released. The claim wasn’t dishonest. It was written sincerely, about a beta that, at the time it was written, did not exist yet. Nothing in the system caught that a review can predate the thing it claims to have reviewed — until I added a check for exactly that: if you’re asserting an app is fine on an upcoming release, the review date has to fall after that release became something you could actually test against. It’s a narrow rule, and it only catches the reviews you forgot to update, not the ones you rubber-stamped without really checking. But it’s a real category of error a curated database can quietly contain, and I’d already contained it, on day one, in my own sample data.
Then the actual problem showed up
Once the validator was solid, I sat down to do the real work: curate 50 to 100 real apps against macOS 27. I have a working list — 97 apps, pulled from a real inventory of what’s actually installed on a real Mac. And I could not honestly fill in a single row, because until today, nobody had published macOS 27 compatibility information for any of these apps. Not Apple. Not Adobe, whose own compatibility pages were unreachable. Not the usual aggregator sites, which still only covered last year’s OS. macOS 27 shipped today, September 14 — the beta cycle vendors test against is only now giving way to the real thing. The data I need is only just starting to exist, for anyone to curate from.
I tried a shortcut first: pull the App Store’s top-charts feed and curate the popular apps. It works technically — real bundle IDs, real version numbers. But when I checked it against apps actually installed on a real working Mac, only 7 of the 98 charted apps matched. The chart is dominated by consumer utilities and free games; real workflows run Adobe Creative Cloud, SketchUp, Transmit, Backblaze — none of which show up there. And there’s a deeper irony: App Store apps are sandboxed, notarized, and auto-updated, and Apple pulls the ones that stop working. They’re the apps least likely to break on an upgrade in the first place. The chart pointed me at exactly the wrong set of apps to worry about.
So the feed is live, and it publishes nothing
Rather than guess, or quietly ship a “not verified” that looks the same as “checked and it’s fine,” I added a way to explicitly park a row — mark it as not yet reviewed, keep it in the working sheet, but exclude it from what actually publishes. Every one of the 97 apps is parked right now. The live feed genuinely returns zero curated rules. That’s not a bug and it’s not a backlog slipping — it’s the honest state of the data. It would have been easy to write something plausible-sounding into 97 cells and ship it, and nobody using the app would have known the difference between a real answer and a good guess. That’s precisely the shortcut Orchard exists to refuse. A verdict that says “not verified” is more honest than one that quietly made something up, even when — especially when — making something up is the easier engineering path.
What actually breaks this open is beta testers’ real Mac inventories, arriving over the next few weeks, plus real vendor statements that can finally exist now that macOS 27 is out. That’s a far better source than any chart: real apps, on real Macs, weighted by what people actually run rather than what’s popular in a free-app storefront. Curation starts for real now that data exists — not before.
Next up: what beta testers’ real Macs are turning up, and how that’s reshaping which apps get curated first.
Follow along at theorchard.app, where you can “Follow the Build” and sign up to be notified when early access opens.
Thanks for reading.