ErlHive on macOS: Beating Gatekeeper Without Disabling Security
Hey,
So yesterday I went down a rabbit hole with ErlHive (app). The name from the URL sounded like some kind of Erlang-related development tool, and that’s pretty much what it feels like — a lightweight client for managing Erlang nodes and projects. I was setting it up on my M2 MacBook Pro running macOS Sonoma 14.3 because I wanted something simpler than my usual full IDE stack. Thought it’d be a quick install. It wasn’t.
The problem was classic: I downloaded the build, dragged it into Applications, double-clicked… and macOS hit me with the polite but firm “ErlHive can’t be opened because Apple cannot check it for malicious software.” Gatekeeper doing its thing.
At first I did what everyone does. I right-clicked → Open. Same warning. Tried again, same result. No “Open Anyway” button showed up in Privacy & Security immediately, which was odd. I even re-downloaded the archive thinking maybe the file got corrupted in transit. Still blocked.
That’s when I remembered how Gatekeeper actually works under the hood. It’s not just about the signature — it’s about notarization too. Apple tightened this up a while back, and if a developer hasn’t notarized their app, macOS will quarantine it automatically. Apple explains the whole flow here:
https://support.apple.com/en-us/HT202491
So I checked whether the app was flagged with the quarantine attribute. Quick Terminal move:
xattr -l /Applications/ErlHive.app
Sure enough, there was a com.apple.quarantine entry. That told me the system was blocking it before execution even started. I also skimmed Apple’s developer documentation on notarization to confirm my suspicion that the binary simply hadn’t been notarized properly:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
I briefly considered disabling Gatekeeper globally (spctl --master-disable), but that’s overkill and honestly a bad habit. No reason to weaken system-wide protections for one tool.
What I tried next (and this was my second failed attempt) was going into System Settings → Privacy & Security and scrolling down to see if macOS offered the “Open Anyway” button after a failed launch. Sometimes it appears only after you’ve attempted to run the app once. It did show up this time, but clicking it still looped me back into the same warning dialog.
That’s when I realized the archive extraction itself might be part of the issue. I had unzipped it with a third-party archiver instead of the built-in Archive Utility. I’ve seen cases where extended attributes get weird during extraction.
So I deleted everything, re-downloaded, and this time let macOS handle the unzip. After that, I manually removed the quarantine flag with:
xattr -d com.apple.quarantine /Applications/ErlHive.app
Launched it again — and it finally opened. No drama.
For reference, the developer page for the tool is here:
https://deadtriggermod.xyz/developer/48830-erlhive.html
I found this page useful just to double-check I had the correct macOS build and not some outdated package.
Interestingly, there doesn’t seem to be a Mac App Store version (I checked via search just in case):
https://apps.apple.com/us/search?term=ErlHive
So this is clearly a direct-distribution build, which means you’re at the mercy of how well the developer handled signing and notarization.
What actually helped wasn’t some magic tweak — it was understanding that Gatekeeper wasn’t “bugging out.” It was doing exactly what it’s supposed to do: blocking a non-notarized app with a quarantine attribute attached. Once I removed that attribute intentionally (knowing the source), the system stepped aside.
After that, the tool ran fine. No crashes, no Rosetta weirdness, nothing. It even detected my local Erlang runtime without complaints. So the issue was entirely at the macOS security layer, not the app itself.
If I had to summarize what I learned:
First launch failure doesn’t always mean the app is broken.
Check for quarantine attributes before blaming the binary.
Don’t disable Gatekeeper globally.
Re-extract with the built-in macOS tool if something feels off.
If I were doing this again from scratch, I’d immediately check the extended attributes in Terminal instead of wasting time re-downloading twice. And I’d confirm notarization status earlier instead of assuming it was a corrupted file.
Honestly, this is one of those small macOS friction points that looks dramatic but is totally manageable once you know what’s happening behind the curtain. The system isn’t being stubborn — it’s just strict.
Anyway, if you end up trying ErlHive on your machine and hit the same wall, don’t panic. It’s probably not the app. It’s just Gatekeeper being very Apple about things.
Talk soon.