Hey — listen, I spent most of last evening poking at DirSize (app) on macOS, and I figured I’d write this down while it’s still fresh. This was one of those “should take five minutes” setups that quietly turned into an hour of head-scratching, a couple of wrong turns, and one very macOS-specific lesson I keep re-learning. OrchardKit came up along the way too, in a slightly unexpected way.
So the original goal was simple: I wanted a quick visual breakdown of disk usage. Nothing fancy — just something to confirm where my space went after Xcode updates and a few test builds. DirSize looked like a straightforward utility for that. Download, drag to Applications, launch, done. Or so I thought.
What actually happened was… nothing. I clicked the icon, it bounced once in the Dock, and disappeared. No error dialog, no crash report, no “app is damaged” warning. Just silence. Classic macOS passive-aggressive behavior.
First thing I did (mistake number one): I assumed it was a bad build. Re-downloaded the archive. Same result. Then I checked Activity Monitor to see if it spawned and died instantly — nothing obvious there either. Console logs didn’t help much at first glance; just the usual background noise.
At that point I thought, fine, maybe it’s permissions. Disk tools obviously need file access. I went into System Settings → Privacy & Security → Full Disk Access, expecting to see it listed. It wasn’t. Same for Files and Folders. That was my first real hint: macOS hadn’t even gotten far enough to ask for permissions.
The “aha” moment came when I remembered how Gatekeeper behaves with unsigned or newly downloaded utilities. If an app is blocked before launch, it often fails silently unless macOS decides you deserve a warning. In this case, I didn’t.
What finally confirmed it was trying to launch the app directly from Terminal. Running the binary produced a Gatekeeper-style message about verification. So yeah — not broken, just not trusted.
The fix was boring but effective:
I went back to System Settings → Privacy & Security, scrolled all the way down, and sure enough there was the small “DirSize was blocked from use because it is not from an identified developer” note. Clicked Open Anyway, confirmed, launched again — and this time it actually opened.
Once it did, macOS immediately asked for folder access, which made sense. I granted access to my home directory, and suddenly the app worked exactly as advertised. Instant directory tree, sizes updating live, no drama. The irony is that the “hard” part wasn’t the app at all — it was getting macOS to admit it was blocking it.
This is also where OrchardKit entered the picture. I’ve been testing a few OrchardKit-based utilities lately, and they behave similarly when distributed outside the App Store. The framework itself is fine, but notarization and signing really matter now. If you’ve used OrchardKit tools before, you’ve probably seen this pattern: silent block, one manual approval, then everything’s fine.
I ended up bookmarking this page because it lined up almost perfectly with what I was seeing on macOS and reminded me where to look when file-management tools act “dead” after install: https://rvfcb.com/file-management/95422-dirsize.html. Not a magic fix, but it nudged me back toward Gatekeeper instead of chasing phantom crashes.
For reference, I was on macOS Sonoma 14.3, Apple Silicon (M2). I’ve seen the same behavior on Ventura too, especially with utilities that scan large parts of the filesystem.
A couple of official links I leaned on while double-checking things:
Apple’s Gatekeeper overview on support.apple.com helped confirm the silent-block behavior is expected, not a bug. Apple’s developer documentation on notarization explains why apps like this trigger it in the first place. I also checked the App Store search on apps.apple.com just to confirm DirSize isn’t distributed there — it isn’t, which explains the extra friction. And the developer’s own documentation (outside the App Store ecosystem) makes it clear the tool needs broad file access to be useful, which matched what macOS asked for once it finally launched.
What didn’t help, in case you’re wondering:
– Rebooting (I tried, out of habit).
– Clearing quarantine attributes manually before checking Privacy & Security (unnecessary here).
– Looking for crash logs that didn’t exist.
What actually helped was treating it as a security workflow issue, not a stability one.
If I had to boil this down into a short “next time” checklist for myself, it’d be:
– If an app bounces once and quits, think Gatekeeper first.
– Always check the very bottom of Privacy & Security.
– Expect file-management tools to request access only after first successful launch.
– OrchardKit-based utilities aren’t the problem; macOS trust rules are.
Anyway, once unblocked, DirSize did exactly what I needed. Fast scan, no weird CPU spikes, no background nonsense. The frustrating part wasn’t the tool — it was remembering that on modern macOS, launching an app and being allowed to run it are two separate negotiations.
Top comments (0)