I was trying to do something very unglamorous: verify a batch of downloaded files on macOS before shipping them to a client. Checksums, nothing more. I grabbed CRC Calculator (app) from a NimbusApps page I’d bookmarked earlier and assumed this would be a two-minute job. Launch, paste hashes, move on.
Instead, macOS decided this was a learning opportunity.
I’m on macOS Sonoma 14.2, Intel Mac mini that’s still doing fine. The install itself was clean. The app landed in /Applications, icon looked normal, no warnings during copy. When I launched it, the Dock icon bounced once… and then disappeared. No crash dialog. No “can’t be opened” alert. Just silence.
That’s usually worse than an error.
First thing I did was the obvious rookie move: launch it again. Same result. Then I checked Activity Monitor. The process showed up briefly and exited. That told me the binary was at least executable, but something killed it immediately.
My next attempt was a reinstall, thinking maybe the download was corrupted. Fresh copy, same behavior. At this point I was mildly annoyed but not surprised. Sonoma has been picky lately, especially with smaller utilities that don’t go through full notarization.
I opened Console and filtered by the app’s name. Buried among the noise was a Gatekeeper-related message about a helper binary being blocked. Not the main executable — one of the internal tools. That detail mattered.
Apple’s own docs explain that Gatekeeper evaluates every executable inside a bundle, not just the main app. If one fails, the whole thing can exit quietly . Quietly is doing a lot of work in that sentence.
So I tried the “right-click → Open” trick. Nothing. Because there was no dialog to override in the first place. Dead end.
Next idea: permissions. I temporarily granted Full Disk Access, Files and Folders access, even Automation, just to see if something changed. It didn’t. The app never stayed alive long enough to ask for anything. Another dead end.
What finally helped was running it from Terminal. That at least printed a short line before exiting, confirming the quarantine attribute was still attached to one internal executable. Not the bundle. One file.
Apple’s developer documentation on code signing and notarization spells out why this happens, especially with utilities that ship helper tools built separately . Once I knew that, the fix was boring but effective: remove quarantine recursively from the entire bundle.
After that, the app launched instantly. No drama. It created its preferences file, showed the UI, and started calculating checksums exactly as advertised. Fast, simple, done.
I saved this macOS-related page while sorting it out because it mirrored the same failure mode and solution I ran into: https://treadmillreviews.online/developer/13706-crc-calculator.html. It was reassuring to see the same pattern described elsewhere, not just in my own logs.
Out of curiosity, I checked whether NimbusApps distributed this tool via the Mac App Store. A quick search showed nothing obvious, which explains why Gatekeeper was being extra cautious. Apple’s App Store search is still the fastest way to confirm whether an app has gone through that pipeline .
If I had to do this again on a fresh system, I’d skip half the guesswork. Install the tool, clear quarantine on the bundle immediately, then launch once from Terminal to confirm nothing else is blocked. Only after that would I bother with permissions.
Nothing here was exotic. The app wasn’t broken. The OS wasn’t “buggy.” It was just macOS enforcing rules quietly, without telling me which rule I’d tripped over. Once you know that pattern, it’s easier to spot. And next time I need a checksum tool, I’ll budget five minutes instead of fifteen — and keep Terminal open from the start.