“Schborg on macOS: When ‘Damaged’ Really Means ‘Blocked’”

Hey,

So, listen — last night I went down a rabbit hole with Schborg (app) from OrchardKit. I just needed it for a small internal workflow thing, nothing dramatic. Quick install, launch, grant permissions if needed, move on. That was the plan.

Instead, macOS hit me with the classic:
“Schborg is damaged and can’t be opened. You should move it to the Trash.”

Which is always mildly insulting. Like, no it’s not.

I’m on a MacBook Pro (M1 Max) running macOS Sonoma 14.4. And Sonoma has been… opinionated about security lately. So at first I assumed it was just Gatekeeper doing its thing. Apple’s official doc on opening apps from unidentified developers covers the usual right-click → Open trick:
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac

I tried that. Same message. “Damaged.” No override button. No “Open Anyway” in Privacy & Security either.

First mistake: I re-downloaded the installer. Twice. Different browser, just in case the file got corrupted. Still the same error.

That’s when I realized it probably wasn’t corruption. It was quarantine.

Sonoma is stricter about extended attributes, especially when an app isn’t notarized exactly the way Apple expects. And sometimes instead of saying “unidentified developer,” it jumps straight to “damaged.” Which is misleading but technically accurate from its point of view.

So I checked the quarantine flag in Terminal:

xattr -l /Applications/Schborg.app

Sure enough, com.apple.quarantine was there.

At that point I remembered Apple’s broader notes on notarization and runtime protection from the developer side:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

If the app isn’t notarized correctly for your OS version, Gatekeeper can get dramatic.

So I removed the quarantine attribute:

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

Launched it again.

This time it opened. For about two seconds.

Then it crashed.

Different problem now. Progress, technically.

Console.app showed a permission denial related to Documents access. That was the real issue hiding behind the “damaged” message. The app tries to create a working directory inside ~/Documents on first launch, and Sonoma blocked it before the permission prompt even appeared.

So now I went to:

System Settings → Privacy & Security → Files and Folders

Schborg wasn’t listed yet. That happens when an app fails before triggering the system prompt.

What finally worked was manually adding it to Full Disk Access (temporarily). After that, I relaunched it, and this time macOS properly displayed the permission request dialog. I granted access to Documents only, then removed Full Disk Access afterward.

And then everything behaved normally.

I actually found this page useful while piecing it together — mostly because it confirmed I wasn’t imagining the Sonoma quirks around app permissions and launch behavior:
https://rvfcb.com/office-and-productivity/36442-schborg.html

It wasn’t some catastrophic bug. It was just macOS being strict in a slightly opaque way.

I also checked whether there was an official App Store build to avoid this whole dance. Searched here:
https://apps.apple.com/

No listing for it. So manual install it is.

For completeness, I browsed OrchardKit’s main site to see if there was any mention of ARM-native or notarization updates:
https://orchardkit.com/

Nothing explicit about Sonoma compatibility, but the build itself runs fine once permissions are sorted.

What I did wrong at the beginning was assuming the error message was literal. “Damaged” made me think corrupted download. In reality, it was a security layer refusing to execute code that hadn’t passed all of its checks in the expected way.

Once I understood that, the fix was straightforward:

1. Move the app to /Applications (don’t run from Downloads).
2. Remove quarantine flag via xattr.
3. Temporarily grant Full Disk Access if permission prompts fail to appear.
4. Relaunch and let macOS properly register file access permissions.
5. Remove excess privileges afterward.

After that, it’s stable. No random crashes. CPU usage is normal. Memory footprint reasonable. It actually runs smoothly on Apple Silicon under native arm64 — I checked via Activity Monitor.

If I had to do it again, I’d skip the re-download step and go straight to checking quarantine attributes. Sonoma is predictable once you accept that it prioritizes system integrity over clarity of error messages.

Anyway, just sharing in case you run into the same thing. It’s not broken software. It’s just modern macOS doing modern macOS things.

Next time I see “damaged,” I’m going straight to Terminal instead of panicking.

— End of small adventure.