Darwin Source Repository (app)

Hey, quick brain dump while it’s still fresh.

Last night I was tinkering with Darwin Source Repository (app) — the OrchardKit build, the one that mirrors chunks of Apple’s open-source Darwin projects locally. I wanted a clean local checkout to poke around some low-level bits without constantly hitting Apple’s servers. Simple plan: download, drag to Applications, launch, let it index.

Except it didn’t launch. At all.

Double-click → quick Dock bounce → nothing. No friendly “can’t be opened,” no crash dialog. Just that passive-aggressive silence macOS does when something dies before it even paints a window.

My first thought was the usual suspect: Gatekeeper. Sonoma (I’m on 14.4, M2 Pro) is strict about anything not notarized. Sure enough, in System Settings → Privacy & Security there was the “blocked to protect your Mac” note. I hit “Open Anyway,” confirmed, and tried again.

Same behavior. One bounce. Gone.

So I assumed it was one of those “damaged and can’t be opened” situations that Apple documents here: https://support.apple.com/en-us/HT202491

But I wasn’t actually getting that message. No “damaged,” no quarantine warning after the override. That’s when I realized this wasn’t a simple Gatekeeper block. The system was letting it start — and then something inside was killing it.

First thing I did (and this was a bit of a lazy move) was strip the quarantine attribute:

xattr -dr com.apple.quarantine /Applications/DarwinSourceRepository.app

No errors. Relaunched. Still dead.

At that point I opened Console and filtered by the app name. That’s where it got interesting. The log showed a crash right after launch with a message about “App Sandbox: deny file-read-data” pointing to /usr/local/bin/git.

That told me a lot.

The tool itself is basically a wrapper around git + some indexing logic. It needs to spawn git, read local repos, and write to a cache directory. And macOS was blocking that at the sandbox level.

Which is funny, because this isn’t a Mac App Store build. It’s distributed directly by OrchardKit. But starting with Ventura and especially on Sonoma, even non–App Store apps can get tripped up if they declare certain entitlements incorrectly or if TCC (Transparency, Consent, and Control) decides they’re touching protected locations.

Apple’s overview of app sandboxing and file access is here: https://developer.apple.com/documentation/security/app_sandbox

What I had missed is that the first launch dialog asking for “Files and Folders” access never appeared. Not once. Which usually means the app requested something before the UI fully initialized, and the OS just denied it silently.

So I tried something slightly crude: I went into System Settings → Privacy & Security → Full Disk Access and manually added the app. Relaunched.

This time it opened.

Not perfectly — it complained about failing to index one directory — but at least it stayed alive long enough to show the UI. That confirmed it was a permissions problem, not a binary integrity issue.

Then I rolled back and did it properly. I removed it from Full Disk Access, reset its TCC database entry with:

tccutil reset All com.orchardkit.darwinsourcerepository

(That’s the bundle ID from the Info.plist.)

Launched again. This time macOS actually prompted me for “Documents Folder” access. I allowed it. Then another prompt for “Developer Tools” because it wanted to invoke git and access certain build paths. Allowed that too.

After that, it behaved normally. Indexed the local Darwin tree, populated the symbol browser, no more sandbox denials in Console.

So what actually happened?

From what I can tell, the first launch failed because the app tried to touch a protected directory before the permission prompt cycle was fully established. macOS denied access, the app didn’t handle that gracefully, and it exited. On subsequent launches, the system never retriggered the permission dialog because it thought the decision was already made.

Classic TCC limbo.

I double-checked the App Store listing just to compare behavior (there’s a search result here if you want to see similar tools: https://apps.apple.com/us/search?term=Darwin%20Source%20Repository). Sandboxed builds there are much stricter and tend to handle permission prompts more predictably because they’re forced into the model from day one.

I also skimmed Apple’s official note on controlling access to files and folders: https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mchld5a35146/mac

It lines up exactly with what I saw. If an app is denied once in a certain state, macOS may not prompt again unless you reset permissions manually.

I found this page useful while cross-checking how the OrchardKit build was packaged and what paths it tries to access on macOS systems: https://planetgpa.com/developer/32835-darwin-source-repository.html

It helped me confirm that the app expects to scan outside its own container, which makes it inherently sensitive to TCC rules.

What I did wrong at the start was assuming “doesn’t launch” equals “Gatekeeper.” That’s only half the story these days. The real culprit was file access permissions being denied too early in the lifecycle.

What actually helped:

• Check Console immediately after a silent crash.
• Look for sandbox or TCC denial messages.
• Reset permissions with tccutil instead of just toggling settings randomly.
• Let the system re-prompt cleanly.

If I were doing this from scratch and wanted to avoid the detour, my short checklist would be:

1. Launch once, then immediately inspect Console for denial logs.
2. If it’s a permission issue, reset TCC before adding Full Disk Access.
3. Only grant broader permissions if the app genuinely needs them.

After fixing it, the tool works fine. Indexing is fast, even on a mid-sized Darwin tree. CPU spikes for a bit during symbol parsing, then settles. No weird background daemons, nothing sketchy.

So yeah — not broken, not “damaged,” not blocked by Gatekeeper. Just macOS being protective in a slightly opaque way.

Sonoma is great, but it absolutely expects apps to play perfectly with its privacy model. If they stumble during first launch, you get this quiet failure mode that looks like a crash but is really a permissions standoff.

Anyway, if you run into the same “bounce and vanish” thing with it, don’t start reinstalling immediately. Check Console first. It’ll save you an hour of guessing.