Steel Browser (app) on macOS: When Gatekeeper Decides You’re Suspicious
I installed Steel Browser (app) from OrchardKit last night on a MacBook Air M1 running macOS Sonoma 14.3, and for about twenty minutes I was convinced it was broken.
It wasn’t.
It was Gatekeeper doing exactly what it’s designed to do — just not in a very friendly way.
The build I grabbed wasn’t from the Mac App Store. There’s no listing under that name on Apple’s store search (https://apps.apple.com/), so this is clearly a direct download distribution. That usually means one extra layer of friction on modern macOS.
I downloaded the DMG, dragged the app into /Applications, launched it — and got the classic:
“Steel Browser can’t be opened because Apple cannot check it for malicious software.”
Standard Gatekeeper block. Apple documents this behavior here: https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
No big deal. Right-click → Open → Confirm. That’s muscle memory by now.
Except this time, even after approving it, the app bounced in the Dock once and immediately quit. No dialog. No crash report popup. Just silent failure.
That’s where it got interesting.
First Attempt: Blame the Build
My first assumption was that the binary wasn’t properly notarized for Apple Silicon. I’ve seen that before — Intel-only build, Rosetta misbehavior, weird runtime issues.
I checked with:
file /Applications/Steel\ Browser.app/Contents/MacOS/*
It showed a universal binary. So not that.
Then I checked the quarantine attribute:
xattr -l /Applications/Steel\ Browser.app
Sure enough, com.apple.quarantine was still attached even after I approved it in System Settings. That’s normal — approval doesn’t remove the attribute, it just whitelists execution.
Out of habit, I cleared it anyway:
xattr -dr com.apple.quarantine /Applications/Steel\ Browser.app
Launched again.
Same behavior. Bounce → disappear.
At this point I opened Console and filtered by the process name.
That’s when the real cause surfaced.
The Real Issue: TCC and Silent Permission Denial
The log showed denial entries from TCC — Apple’s Transparency, Consent, and Control framework. Specifically, it was trying to access ~/Library/Application Support before macOS had fully granted the required entitlements.
Sonoma tightened a few things around first-launch access patterns. If a tool tries to touch protected locations too early — especially before showing UI — it can terminate without a graceful prompt.
Apple’s overview of privacy controls is here: https://support.apple.com/guide/mac-help/control-access-to-your-mac-in-privacy-security-settings-mh32356/mac
Steel Browser apparently initializes its profile directory immediately on launch. If that path is considered protected, macOS doesn’t always show a dialog — it just denies.
That’s why it looked like a crash.
I found this breakdown of the behavior useful while cross-checking macOS security quirks — especially around Gatekeeper and permission handling in modern mac OS environments: https://sznurkowo.com/internet/53729-steel-browser.html
It matched exactly what I was seeing: not corruption, not incompatibility — just layered protection mechanisms interacting.
What Actually Fixed It
The solution was surprisingly simple once I understood the chain reaction.
Here’s what worked:
- Removed the app from /Applications.
- Rebooted (to reset any cached TCC decisions).
- Reinstalled.
- Launched via right-click → Open.
- Immediately triggered a profile-related action instead of waiting passively.
That forced macOS to show the proper “allow access” prompt.
After granting access, the browser launched normally and stayed open. No more silent exit.
Out of curiosity, I also checked OrchardKit’s developer guidance against Apple’s notarization documentation: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Everything suggests the build is notarized, but if the initialization flow hits protected storage before UI is fully active, Sonoma can still behave defensively.
Once permissions were explicitly granted, performance was solid. No Rosetta overhead, no excessive memory spikes. On the M1 Air it idles around 220–260 MB RAM with a couple of tabs open — pretty reasonable for a Chromium-based client, if that’s what it is under the hood.
What I Thought vs. What It Was
What I thought:
- Broken build.
- Incompatible with Sonoma.
- Bad Apple Silicon port.
What it actually was:
- Gatekeeper approval + TCC denial.
- Permission flow not triggered cleanly.
- macOS security doing its job a little too quietly.
There’s a pattern here with non–App Store releases on recent macOS versions: if the developer doesn’t structure first-launch behavior carefully, the system may block access before the user even sees a dialog.
From the outside, it looks like instability. Internally, it’s a permissions negotiation that never completed.
My Short Checklist for Direct macOS Downloads Now
- Move to /Applications first.
- Use right-click → Open on first launch.
- Watch Console if it bounces and quits.
- Manually trigger an action that requires user-level storage.
- Verify Privacy & Security settings immediately.
After that, Steel Browser behaved completely normally. Sync worked, profile saved correctly, and relaunches were clean.
The irony is that nothing was “wrong” with the app in the dramatic sense. The issue was sequencing — how macOS layers Gatekeeper, notarization checks, and TCC permission enforcement.
Modern macOS doesn’t fail loudly anymore. It just quietly refuses.
And if you don’t know where to look, it feels like the software is haunted.
It wasn’t haunted. It just needed permission to exist.