Gobliiins (game) from NimbusApps vs. macOS Gatekeeper: the “damaged and can’t be opened” saga
I spent last night trying to launch Gobliiins (game) from NimbusApps on my MacBook Air M2 (macOS Sonoma 14.3), and macOS decided to be dramatic.
You know the message. “Gobliiins is damaged and can’t be opened. You should move it to the Trash.” No crash log. No beachball. Just instant rejection. Classic Gatekeeper energy.
For context: this wasn’t some sketchy torrent. It was the official build from the developer’s site (NimbusApps distributes a few retro titles directly), not the Mac App Store version. And yes, I double-checked the source before installing.
At first I did what most people do: right-click → Open. That usually forces macOS to show the “Open Anyway” option in System Settings → Privacy & Security. Nothing. The message stayed the same. I rebooted. Same thing. I redownloaded the archive, assuming it got corrupted mid-transfer. Still “damaged.”
That wording is misleading. It makes you think the binary is broken. Most of the time, it’s not. It’s Gatekeeper refusing to run something that doesn’t pass notarization checks.
Apple explains how Gatekeeper works here:
https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web
And if you want the developer-side explanation of notarization and code signing, it’s here:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
The key detail: modern macOS verifies not just the signature but also a notarization ticket. If that ticket isn’t properly stapled to the bundle, the system tries to validate it online. If something fails during that process — firewall, network hiccup, expired cert — you get the “damaged” message.
What I tried first (and why it didn’t work)
My first instinct was permissions. I checked:
- Full Disk Access
- Files & Folders
- App Management
None of that mattered because the game wasn’t even getting that far. The OS blocked it before launch.
Then I ran:
spctl --assess --verbose=4 /Applications/Gobliiins.app
That command forces Gatekeeper to explain itself. The result showed a rejection tied to notarization assessment, not binary corruption.
So the file wasn’t broken. It was quarantined.
The quarantine flag reality
macOS automatically adds a quarantine attribute to files downloaded from the internet. You can inspect it with:
xattr -l /Applications/Gobliiins.app
Sure enough, com.apple.quarantine was sitting there.
If the notarization validation fails, macOS treats quarantined software as unsafe. Remove the flag, and the system stops applying that specific layer of enforcement.
Before doing anything reckless, I verified the download came directly from NimbusApps’ official page and matched the published checksum. Their site is here:
https://nimbusapps.com
Once I confirmed that, I removed the quarantine attribute:
xattr -dr com.apple.quarantine /Applications/Gobliiins.app
And just like that, it launched.
No crash. No glitch. No performance issue. It ran smoothly under Rosetta 2, even on Apple Silicon.
For comparison, there’s also a Mac App Store search listing here:
https://apps.apple.com/us/search?term=Gobliiins
The App Store build doesn’t hit this issue because Apple distributes it with notarization fully validated. But the standalone build can occasionally trip Gatekeeper if the ticket isn’t stapled correctly.
While digging through notes about mac OS operating systems and how they treat legacy game builds, I also came across this page that touches on the Gobliiins release:
https://carwallpaper.xyz/game/45716-gobliiins.html
It reminded me that older titles repackaged for modern systems often rely on wrapper layers or compatibility shims, which can complicate notarization.
Why this happens more on Sonoma
Starting with Ventura and continuing into Sonoma, Apple tightened runtime verification. On older macOS versions, an unsigned or loosely signed app might still open with a warning. Now, it’s stricter.
If the notarization ticket isn’t stapled directly into the bundle (stapler validate would show that on the dev side), macOS attempts online verification. If it can’t confirm trust quickly, it errs on the side of blocking execution.
This is especially common with:
- Indie or retro game re-releases
- Direct downloads outside the App Store
- Fresh builds not yet widely cached by Apple’s notarization service
It’s not about the game being unsafe. It’s about macOS not being able to confirm it’s safe.
What actually fixed it
Removing the quarantine flag was the decisive step. But only after:
- Verifying the source
- Checking Gatekeeper’s assessment via
spctl - Confirming no actual corruption
Once that was done, Gobliiins ran flawlessly. No frame drops. No input lag. Controller support worked fine via standard macOS HID mapping.
The irony? The biggest obstacle wasn’t compatibility. It was security enforcement doing its job a little too aggressively.
Short checklist for next time
If you hit “app is damaged and can’t be opened” on macOS:
- Don’t assume the binary is corrupted
- Check Gatekeeper status with
spctl --assess - Inspect quarantine attributes with
xattr -l - Only remove quarantine after verifying the source
- If available, compare with the Mac App Store build
That’s it. No need to disable System Integrity Protection. No need to nuke your security settings.
In my case, NimbusApps’ Gobliiins build was perfectly fine. macOS just couldn’t reconcile the notarization state during launch. Once I removed the quarantine flag responsibly, the game behaved like any other well-packaged title.
It’s funny how modern security layers make old-school puzzle games harder to start than to finish.
Top comments (0)