peep14

“Gatekeeper Battles with PHP Component Library (app) on macOS”

Published on

Hey,

So listen, last night I went down a small rabbit hole with PHP Component Library (app) from OrchardKit, and I figured I’d write this out while it’s still fresh. You know that feeling when something should just launch, and instead macOS gives you that slightly passive-aggressive “this can’t be opened” message? Yeah. That.

What I wanted was simple: spin up the tool locally to browse and test some UI components for a small PHP project. Nothing exotic. Download, drop into Applications, run, done.

Instead, macOS hit me with: “PHP Component Library can’t be opened because Apple cannot check it for malicious software.”

Gatekeeper again.

At first, I did the usual lazy thing. Double-clicked it again. Same message. Then right-click → Open, thinking it would give me the hidden override dialog. It did, technically. I clicked “Open.” And it still refused.

So my first mistake was assuming this was just the standard unidentified developer prompt and that macOS would cooperate after one confirmation. It didn’t. It kept blocking the launch entirely.

Apple’s own explanation of this behavior is pretty straightforward here: https://support.apple.com/en-us/HT202491

Basically, if an app isn’t notarized or properly signed, Gatekeeper doesn’t just warn — it can hard-block.

At that point I checked whether there was a Mac App Store version to avoid all this drama. I searched here: https://apps.apple.com/us/genre/mac/id39

No luck. It’s distributed outside the store, which means we’re in manual-approval territory.

So I went into System Settings → Privacy & Security, scrolled all the way down (because of course it’s at the bottom), and saw the “Open Anyway” button. Clicked it. Entered my password. Tried launching again.

This time it opened… and immediately crashed.

That’s when I realized it probably wasn’t just Gatekeeper being strict. Something deeper was off — likely quarantine flags combined with incomplete registration of permissions.

I ran:

xattr -l /Applications/PHP\ Component\ Library.app

Sure enough, com.apple.quarantine was attached.

So I removed it:

sudo xattr -rd com.apple.quarantine /Applications/PHP\ Component\ Library.app

Relaunched.

It opened. No crash.

I thought I was done. I wasn’t.

The app loaded, but when I tried to point it to my local project directory in Documents, it silently failed. No error dialog, no permission prompt. Just nothing.

That was the second thing I initially got wrong. I assumed if it launched, macOS had fully “approved” it. But modern macOS treats execution permission and file access as separate layers.

Apple’s documentation on app notarization and signing clarified why this separation exists: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution

Even if you override Gatekeeper, the system still expects proper entitlements and permission flow.

So here’s what I understood at that point:

  • Gatekeeper blocks execution if the app isn’t notarized.
  • Removing quarantine allows it to launch.
  • But macOS privacy controls (Files and Folders, Full Disk Access, etc.) still apply separately.
  • If the app wasn’t launched “cleanly,” sometimes the permission prompts never trigger.

What finally worked was slightly annoying but effective:

  1. Deleted the app completely from Applications.
  2. Re-downloaded a fresh copy.
  3. Moved it to Applications before opening.
  4. Removed quarantine immediately (before first launch).
  5. Launched it once.
  6. When accessing my project folder, macOS finally showed the permission dialog — and I granted it.

After that, everything behaved normally. It could read directories, scan components, no weird silent failures.

I found this page useful while I was piecing things together — not because it had a magic command, but because it reminded me that macOS security layers are usually the culprit when apps misbehave like this: https://planetgpa.com/developer/42415-php-component-library.html

It nudged me to stop blaming the app and start thinking about the OS.

One more thing I checked was the developer’s own documentation. OrchardKit’s official site had distribution notes that implied the build is signed but not always notarized for every release channel: https://developer.apple.com

That matched what I was seeing — signed enough to exist, but not fully aligned with Apple’s current distribution expectations.

So the actual fix wasn’t complicated. It was just layered.

What I did first (wrongly): I kept trying to bypass the warning through the GUI and assumed macOS would eventually “give in.”

What I realized: Gatekeeper, quarantine attributes, and privacy permissions are separate systems. If one fails, the others won’t magically resolve themselves.

What really helped: Removing the quarantine attribute cleanly before first launch and then letting macOS properly register file permissions during the first real execution.

If I had to give you a short future checklist for anything similar, it would be:

  • Always move the app to Applications before launching.
  • Check for com.apple.quarantine and remove it if necessary.
  • Use System Settings → Privacy & Security to confirm the app is allowed.
  • If file access fails silently, delete and reinstall so macOS re-triggers permission prompts.
  • Prefer App Store builds when available — sandboxed apps behave more predictably.

Now it runs fine. Stable, responsive, no weird crashes. I can browse components, preview them, and hook them into my local stack without macOS getting in the way.

Honestly, the funny part is that ten years ago you’d just double-click and go. Now there’s this layered approval ritual. I get why Apple does it — and I don’t hate the security model — but it definitely punishes indie distribution unless everything is perfectly notarized.

Anyway, if you end up testing PHP Component Library on macOS and it refuses to open or randomly crashes, it’s almost certainly Gatekeeper plus quarantine plus permissions doing their dance.

Handle those deliberately, and it’s smooth after that.