“The App That Wouldn’t Launch: How macOS Permissions Quietly Killed Find Similar”

I ran into this while setting up **Find Similar (app)** on my Mac, and it turned into one of those very macOS-specific problems that looks trivial on the surface and then quietly eats half an hour of your life. The goal was simple. I wanted a lightweight utility to scan a messy external SSD and spot duplicate or near-duplicate files — photos, PDFs, random exports from old projects. Nothing exotic. I grabbed the build associated with OrchardKit, dropped the app into /Applications on an M1 MacBook Pro running macOS Sonoma 14.3, and double-clicked it. Nothing happened. Well, technically something happened — the icon bounced once in the Dock, then vanished. No crash dialog, no permission prompt, no helpful warning. Just… gone. ### First instinct: Gatekeeper, obviously My first assumption was the usual Gatekeeper routine. macOS loves pretending it’s protecting you while giving you zero context. I checked **System Settings → Privacy & Security**, scrolled down, expecting the classic “blocked from opening” message with an Allow Anyway button. Nothing there. I tried the right-click → Open trick. Same result. One bounce, silence. Activity Monitor didn’t even show a lingering process. At this point it didn’t feel like a hard crash; it felt like the system refusing to launch it at all. Apple’s own docs on this behavior are vague but accurate: if an app isn’t properly notarized or trips a security rule early, it can be killed before it fully spins up. Apple explains the mechanism pretty cleanly on their Gatekeeper overview at support.apple.com. Helpful in theory, less so when you’re staring at an empty Dock. ### Second attempt: reinstall and blame quarantine Next idea: maybe the app bundle picked up a quarantine flag during download. That’s common if the file came from a browser instead of the App Store. I deleted the app, re-downloaded it, and this time moved it manually instead of letting Finder do the “Are you sure?” dance. Still nothing. At this point I cracked open Terminal and checked the extended attributes. Sure enough, the quarantine flag was there. I removed it manually with xattr, launched again… and got the exact same behavior. No error, no warning, just an app that refused to exist. This was the point where I stopped assuming the problem was “the app” and started suspecting macOS permissions more broadly. ### What actually broke: file access, not execution Here’s the non-obvious part. The tool launches into a file scan almost immediately. On Sonoma, if an app tries to enumerate certain directories before the system has granted it file access, macOS can terminate it without ever surfacing a permission dialog. That’s not a crash. It’s the OS pulling the plug. I confirmed this by running the app once more and immediately checking Console logs. The message was short and unhelpful, but it pointed to denied file system access during startup. Apple’s developer documentation on file system privacy (developer.apple.com) mentions this exact edge case — if an app touches protected locations too early, it may never reach the point where macOS asks the user for consent. So the fix wasn’t “force open.” It was making sure the system already trusted the app before launch. ### The fix that finally worked What actually solved it was boring, but reliable. I went to **System Settings → Privacy & Security → Full Disk Access** and manually added the app there. Yes, before it ever launched successfully. Then I did the same under **Files and Folders**, even though the app hadn’t requested anything yet. Launched again. This time it opened instantly. No drama. No warnings. Just a normal window asking me which folder to scan. Once running, everything behaved exactly as expected. Scans completed, similar files grouped sensibly, no weird spikes in CPU usage. The issue wasn’t stability or performance — it was macOS refusing to let the tool touch the disk during its first breath. I ended up bookmarking **this page** because it helped me sanity-check how macOS treats file-management utilities and sandbox rules: [https://philropost.com/file-management/60943-find-similar.html](https://philropost.com/file-management/60943-find-similar.html). Not magic, just useful context while I was narrowing things down. ### What I’d do differently next time If I were setting this up again on a clean machine, I’d skip half the guessing and do this upfront: * Move the app to /Applications manually * Add it to Full Disk Access before first launch * Only then open it for the first time That sequence avoids the silent termination loop entirely. Apple’s own explanation of file and folder permissions on support.apple.com backs this up, even if it doesn’t spell out the failure mode in big letters. If you’re the App Store type, this is also why similar utilities distributed via apps.apple.com tend to “just work” — the sandbox and permission flow is pre-negotiated. Standalone builds have more freedom, but you pay for it with setup friction. ### The takeaway This wasn’t a broken build, and it wasn’t user error in the obvious sense. It was macOS being aggressively cautious and spectacularly uncommunicative. Once the app had explicit permission to do what it was designed to do — scan files — it behaved like a perfectly normal, well-built utility. So if you ever run into an app that doesn’t crash, doesn’t warn, and doesn’t open, don’t just blame Gatekeeper. Sometimes the OS kills it quietly because it tried to look at your files before macOS decided it was allowed to. Annoying? Yes. Fixable? Also yes — once you know where to look.