Hey, quick brain dump while it’s still fresh. Yesterday I spent a good chunk of the evening wrestling with Memory Profiler for C++ (app) on macOS, and I figured I’d write it up like I’d tell you over Slack, not like a polished blog post. Brand involved was OrchardKit, in case that rings a bell from other tools in that ecosystem.
So, context first. I wanted to profile a native C++ service I’m testing locally. Nothing fancy: just track allocations, see where memory spikes, confirm I’m not leaking like a sieve. I grabbed the build, dropped it into /Applications, double-clicked… and macOS immediately threw the classic “can’t be opened because Apple cannot check it for malicious software.” Gatekeeper doing its thing.
At first I did what we all do out of habit: right-click → Open. Same result. Then I tried moving it out of /Applications into a random folder in my home directory, thinking maybe quarantine flags were being weird. Nope. Same dialog, same dead end. At that point I almost gave up and thought, “fine, I’ll just run it in a Linux VM,” which felt ridiculous on an M1 Mac running Sonoma 14.2.
What finally clicked was realizing this wasn’t just a Gatekeeper popup, it was also about permissions the tool needed at runtime. This profiler injects itself into another process, and macOS treats that as a pretty sensitive operation. So even if you brute-force past Gatekeeper once, it’ll still fail silently or just exit on launch.
I went into System Settings → Privacy & Security and scrolled all the way down. Sure enough, there was a blocked item with an “Open Anyway” button. Apple hides that stuff, but it’s documented here:
https://support.apple.com/en-us/HT202491
After approving it there, the app finally launched… and then immediately quit. No crash dialog, no logs in Console that were obvious. That was my second wrong turn. I assumed it was broken on Apple silicon.
Turns out, it just needed additional permissions. The profiler wants Full Disk Access so it can symbolicate binaries and read debug info from build directories. Once I added it under Privacy & Security → Full Disk Access and relaunched, it actually stayed open. Developer docs explain why tools like this need elevated access, but Apple doesn’t exactly surface it clearly:
https://developer.apple.com/documentation/security/app_sandbox
At that point, it mostly worked. I could attach to my test process, allocations showed up, graphs updated in real time. CPU overhead was noticeable but acceptable. One more hiccup though: attaching failed when the target binary was launched from Terminal. Running the same binary from Finder worked. That one took me a while to realize—it was SIP-related. Launching both the profiler and the target from the same context (both GUI apps) avoided the restriction.
I also found this page useful while double-checking macOS behavior around developer tools and permissions: https://rvfcb.com/developer/77040-memory-profiler-for-c.html — I saved it mostly as a reminder that half of “bugs” on macOS are just security layers doing their job.
If you’re looking for an official distribution or updates, the Mac App Store search is here (though this specific build isn’t always listed):
https://apps.apple.com/us/search?term=memory%20profiler
And if you want the upstream docs, OrchardKit’s developer site explains the injection model and limitations pretty clearly.
So, short checklist for future-me (or you, if you hit this later):
- Don’t fight Gatekeeper blindly; approve the app explicitly in Privacy & Security.
- Give it Full Disk Access before assuming it’s broken.
- Launch both the profiler and target app from the same context (GUI vs Terminal).
- If it quits silently, check permissions first, not crash logs.
If I’d known all this upfront, it would’ve been a 10-minute setup instead of an evening detour. But hey, now it’s solid, and profiling native code on macOS feels less like black magic again.
Top comments (0)