Spider MPlan on macOS: When Gatekeeper Refuses to Play Nice
I was trying to set up Spider MPlan for a pretty boring reason: planning out a migration of client assets between two Macs (one Intel iMac still on macOS Ventura 13.6, one M2 MacBook Air on Sonoma 14.3). The tool looked lightweight, focused on file structure mapping and batch moves. Exactly what I needed.
Download, drag to Applications, double-click. Standard routine.
Except it didn’t open.
Instead: “Spider MPlan can’t be opened because Apple cannot check it for malicious software.” Classic Gatekeeper line. The icon bounced once in the Dock and stopped. No crash report, no helpful dialog beyond that.
So this became a small field test in modern macOS security.
Attempt #1: The Obvious Right-Click Trick
First reflex: right-click → Open.
That usually bypasses the initial quarantine block. Sometimes that’s all it takes. macOS throws a second dialog with an Open button and you’re good.
Not this time.
It showed the same warning and refused to proceed. That told me the app wasn’t notarized properly or was signed in a way that Sonoma didn’t like.
Apple’s own breakdown of Gatekeeper behavior is here:
https://support.apple.com/en-us/HT202491
Nothing unusual in the setup. It was downloaded via Safari, so quarantine attributes were definitely attached.
Attempt #2: System Settings → Privacy & Security
Next stop: System Settings → Privacy & Security → scroll down to the bottom. Sometimes macOS shows a “Spider MPlan was blocked” notice with an Allow Anyway button.
It did.
Clicked “Allow Anyway.” Tried launching again.
Still blocked.
At this point, I checked the extended attributes manually:
xattr -l /Applications/Spider\ MPlan.app
There it was: com.apple.quarantine.
I removed it:
xattr -dr com.apple.quarantine /Applications/Spider\ MPlan.app
Launched again.
New error. Progress.
Now it complained that the app was “damaged and should be moved to the Trash.” That’s usually either a corrupted download or a signing mismatch between architectures.
What Was Actually Wrong
This is where the hardware difference mattered.
The version I grabbed was clearly built for Intel only. On the M2 machine, macOS was trying to run it through Rosetta 2. Rosetta itself was installed, but the signature check was still failing after quarantine removal.
Apple’s developer documentation on notarization and signing explains why Sonoma is stricter than older macOS versions:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
So I tried installing Rosetta manually just to rule it out:
softwareupdate --install-rosetta
It was already there. No change.
At this point I went back to the source page I had bookmarked for macOS utilities and builds — this one:
https://rvfcb.com/file-management/54393-spider-mplan.html
Turns out there were separate builds listed for Apple Silicon and Intel. I had grabbed the wrong one the first time. Easy mistake.
Downloaded the Apple Silicon build directly from the developer’s distribution page (they host it themselves via OrchardKit branding). For reference, their main site is:
https://orchardkit.io
Fresh download. Drag to Applications.
Double-click.
This time the Gatekeeper prompt appeared once. I allowed it via Privacy & Security. And that was it. The tool launched normally.
The Secondary Glitch: File Access Permissions
It didn’t end there.
When I tried scanning my external SSD, Spider MPlan just showed an empty directory tree. No error. Just nothing.
This wasn’t a bug in the tool. It was macOS.
Under Sonoma, apps need explicit Full Disk Access or at least Files and Folders permissions for external drives. Since this wasn’t from the Mac App Store, it didn’t auto-prompt correctly.
Manual fix:
System Settings → Privacy & Security → Full Disk Access → Add the app.
After relaunch, it immediately indexed the drive structure correctly.
For context, Apple explains these privacy controls here:
https://support.apple.com/guide/mac-help/control-access-to-files-and-folders-on-mac-mh32356/mac
If I Did This Again
Here’s what I would’ve done from the start:
- Confirm architecture (Intel vs Apple Silicon) before downloading.
- Install Rosetta only if truly needed.
- Expect to grant Full Disk Access for any file management utility.
- Avoid manually stripping quarantine unless I’m certain the build is clean and from the official source.
I also checked whether it was available through the Mac App Store to bypass all this, but it isn’t listed there (you can verify via Apple’s search interface at https://apps.apple.com).
Once running, the tool behaved exactly as expected. Lightweight, no weird background services, and it handled large directory previews without beachballing. On the Intel iMac, performance was slower but stable.
The real friction wasn’t the software itself. It was macOS doing its job — aggressively.
And honestly, that’s fine. I’d rather deal with two extra permission clicks than clean up a compromised machine.
Still, grabbing the correct build would have saved me twenty minutes and a mild amount of terminal sarcasm.
Top comments (0)