Field Report: FracTest (app) vs macOS Sonoma — The “Damaged and Can’t Be Opened” Loop
Machine: MacBook Pro 13” (Intel, 2020) OS: macOS Sonoma 14.2.1 Source: direct download, OrchardKit build
Objective was simple. I needed a lightweight graphics utility to test some exported assets before sending them to a client. Nothing production-critical, just a quick validation pass. I grabbed FracTest (app) — the name suggests a graphics/design tool, which fits the category — installed it, and expected to be working within five minutes.
Instead, I got:
“FracTest is damaged and can’t be opened. You should move it to the Trash.”
That message again. Not “unidentified developer.” Not a crash. Just “damaged.” Which on macOS rarely means damaged.
First reaction: bad download?
My first thought was corruption during download. I deleted the file, cleared the browser cache, re-downloaded from the developer’s site (OrchardKit’s homepage lists the latest macOS build). Same result.
Tried launching from Applications instead of Downloads. Same error.
At this point I skimmed Apple’s explanation of Gatekeeper behavior again to confirm what “damaged” usually implies: https://support.apple.com/en-us/HT202491
Spoiler: it often means the app failed a signature or quarantine check.
Attempt #1 — Right-click → Open
This usually bypasses the generic block.
Did that.
No difference. Still “damaged.”
That’s when I stopped trusting the GUI and went to Terminal.
Attempt #2 — Check quarantine attribute
xattr -l /Applications/FracTest.app
There it was: com.apple.quarantine.
But here’s the twist — even after removing quarantine the first time, the error persisted.
sudo xattr -rd com.apple.quarantine /Applications/FracTest.app
Launch.
Still “damaged.”
Now it got interesting.
What was actually happening
On Sonoma, macOS performs deeper code signature validation than older versions. If the bundle structure changes slightly during extraction (some archive utilities can mess with extended attributes), Gatekeeper may interpret it as tampered.
Apple’s developer documentation on code signing explains how strict this validation layer is: https://developer.apple.com/documentation/security/code_signing_services
So instead of just stripping quarantine, I verified the signature:
codesign --verify --deep --strict --verbose=2 /Applications/FracTest.app
That produced a warning about an invalid nested resource. Not catastrophic, but enough for Gatekeeper to flag it.
The clue was that I had extracted the archive using a third-party unarchiver out of habit. That tool has a history of stripping metadata.
Attempt #3 — Re-extract with macOS Archive Utility
Deleted everything again.
Re-downloaded.
This time I double-clicked the .zip and let macOS handle extraction with its built-in Archive Utility.
Moved the fresh app bundle into Applications.
Before launching, I checked:
xattr -l /Applications/FracTest.app
Quarantine still present (normal).
Removed it:
sudo xattr -rd com.apple.quarantine /Applications/FracTest.app
Launch.
No “damaged” message. It opened normally.
That was it.
Somewhere in the middle of this, I bookmarked this page because it helped me think about how macOS security layers interact with downloaded software: https://studiosbyaphrodite.com/graphics-and-design/62634-fractest.html
It reminded me that the OS isn’t just checking the binary — it’s validating the entire bundle structure and metadata.
Sanity checks
I also checked whether there was a Mac App Store version to avoid the manual signing route: https://apps.apple.com/us/search?term=FracTest
Nothing official listed. So direct distribution is the only path here.
Once running, the tool behaved perfectly normally. No crashes. CPU stable. It processed test graphics without issue. So the binary itself wasn’t broken.
The problem was how I extracted it.
What actually worked
The winning combination:
- Use macOS Archive Utility to extract the .zip
- Move to /Applications
- Remove quarantine attribute
- Launch clean
The third-party unarchiver had likely modified extended attributes or bundle structure in a way that broke signature validation. Sonoma didn’t like that at all.
If I had known from the start
I wouldn’t have wasted time re-downloading multiple times.
I would have:
- Verified code signature immediately.
- Avoided third-party extraction tools.
- Checked quarantine before first launch.
The “damaged” message is misleading. It sounds like corruption. It’s almost always a security validation issue.
Modern macOS doesn’t just care that an app exists — it cares how it arrived, how it was unpacked, and whether its internal structure matches the developer’s signature exactly.
In this case, the fix wasn’t dramatic. Just procedural. Let the OS handle extraction, clear quarantine properly, and don’t assume every red warning means the developer messed up.
Sometimes it’s just macOS being very, very particular.