Listen, yesterday I was messing around with CRFTagger (app) and ended up debugging something that looked like a broken build but turned out to be a classic macOS Gatekeeper situation. I’m writing this down because the way it fails is misleading, and if you see the same thing you’ll probably assume the app is corrupted.
So here’s what happened.
I downloaded CRFTagger, moved it into Applications like a civilized person, double-clicked it — and macOS immediately threw the “CRFTagger is damaged and can’t be opened. You should move it to the Trash.” message.
Which is always slightly dramatic.
My first reaction was, okay, bad download. Happens. I deleted it, downloaded it again, verified the file size matched. Same message.
What I did first (and why it didn’t work)
After the second failure, I tried the usual right-click → Open trick. Sometimes that bypasses the basic Gatekeeper block and gives you the “Open Anyway” confirmation dialog.
Nope. Same “damaged” warning.
At that point I assumed the archive was actually corrupted. So I tried downloading via a different browser. Same result.
Then I thought maybe it was some weird extended attribute flag, so I checked with:
Sure enough, there was the com.apple.quarantine attribute attached.
I removed it:
Tried launching again.
Still blocked.
That’s when I realized this wasn’t about corruption at all.
What I understood after digging
The “damaged” message on macOS doesn’t literally mean the binary is broken. In many cases, it’s Gatekeeper refusing to run an app that isn’t properly notarized or whose code signature macOS doesn’t trust.
Apple explains how Gatekeeper works here:
https://support.apple.com/en-us/102445
And the developer-side explanation of notarization is here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
CRFTagger isn’t distributed via the Mac App Store. It’s more of a niche utility, so it likely wasn’t notarized according to Apple’s latest requirements. On newer macOS versions, that matters more than it used to.
So the system wasn’t saying “this app is broken.” It was saying “I don’t trust this.”
What actually helped
The fix wasn’t complicated, just hidden.
I tried launching the app once more so macOS would register the block event. Then I immediately went to:
System Settings → Privacy & Security.
Scrolled down past the main security section. There it was: a note saying CRFTagger was blocked because Apple couldn’t verify it.
There was an “Open Anyway” button.
Clicked it. Confirmed in the follow-up dialog.
And that was it. The app launched normally.
After that first approval, macOS stopped complaining. No more “damaged” message. No crashes. It just ran.
While I was comparing notes and making sure this wasn’t some unique issue on my machine, I found this page useful — the resource I used:
https://bandcinstallersgroup.com/developer/60504-crftagger.html
It helped confirm that the behavior was consistent with Gatekeeper blocking rather than a corrupted build.
Why removing quarantine alone didn’t fix it
This part surprised me slightly.
In older macOS versions, removing com.apple.quarantine was often enough. But on newer systems, Gatekeeper validation goes beyond just that attribute. If the app fails notarization checks or signature validation, macOS can still block execution.
So manually stripping quarantine doesn’t always override the trust evaluation anymore.
If CRFTagger were distributed via the App Store pipeline, this wouldn’t happen because Apple would have already validated it. For comparison, the general App Store entry point is here:
https://apps.apple.com/
Apps coming from there don’t trigger the same warnings because the notarization and signing chain is verified upstream.
One more thing I checked
Just to rule out architecture issues, I confirmed the binary wasn’t 32-bit (modern macOS doesn’t support 32-bit apps at all). That wasn’t the problem. The system log clearly referenced policy restrictions, not binary incompatibility.
Also worth noting: if you move the app after approving it, macOS may re-evaluate it. So it’s best to keep it in Applications once you’ve allowed it.
What I’ll do differently next time
Next time I see “is damaged and can’t be opened,” I won’t immediately assume corruption. I’ll interpret it as “Gatekeeper doesn’t trust this yet.”
Re-downloading rarely fixes that.
Quick checklist for future me
- Try launching once to trigger the block.
- Go straight to System Settings → Privacy & Security.
- Look for the blocked app notice and click “Open Anyway.”
- Only mess with
xattrif the Privacy option doesn’t appear. - Avoid disabling Gatekeeper system-wide unless absolutely necessary.
Disabling Gatekeeper with spctl --master-disable works, but it’s overkill and lowers system protection globally. Approving a single app is cleaner.
After all that, CRFTagger worked exactly as expected. No weird behavior, no instability. The OS was just being strict about trust.
It’s funny how macOS security messages often sound catastrophic. “Damaged” sounds like something exploded internally. In reality, it just means “Apple hasn’t vouched for this.”
Anyway, if CRFTagger ever refuses to open on your machine with that dramatic wording, don’t panic. It’s probably not broken. It just needs that one quiet approval in Privacy & Security, and then it behaves like a normal app.