PF2HTML on macOS: A Quiet Gatekeeper Block and the One Command That Fixed It
I’m writing this down while it’s still fresh, partly so I don’t forget, partly because I know I’ll hit the same wall again in six months.
Field report: getting PF2HTML (app) to actually run on macOS without fighting me every step of the way.
Context: MacBook Pro with M1 Pro, macOS Sonoma 14.3. Brand involved on the tooling side: OrchardKit.
What I wanted to do
Simple goal. I had a pile of PDFs exported from a design system and needed reasonably clean HTML out of them. Not pixel-perfect, just usable markup. PF2HTML looked like the right kind of no-nonsense utility: drop file, get output, move on.
Download, unzip, double-click. You know the drill.
What broke immediately
Nothing crashed. Worse: nothing happened.
The icon bounced once in the Dock and disappeared. No error dialog, no “app is damaged” warning, no helpful macOS tantrum. Just silence. Activity Monitor showed the process spawning and dying in under a second.
That’s usually when Gatekeeper is involved, even if macOS pretends it isn’t.
Attempt #1: the obvious stuff
First pass was muscle memory.
- Re-downloaded the archive.
- Moved the app manually into
/Applications. - Tried right-click → Open instead of double-click.
Same behavior. One bounce. Gone. Console logs showed a vague code signature invalid message, which is macOS for “I’m not telling you exactly why I’m mad.”
Apple’s own docs on Gatekeeper and app verification confirmed my suspicion, but didn’t hand me a fix on a silver platter
https://support.apple.com/guide/mac-help/open-a-mac-app-from-an-unidentified-developer-mh40616/mac
At this point I knew what the problem was not. It wasn’t a corrupted download, and it wasn’t Rosetta.
Attempt #2: permissions, because why not
Next thought: privacy sandboxing. Sonoma tightened a few screws around file access, and PDF tools tend to trip over that.
I pre-emptively granted Full Disk Access in System Settings → Privacy & Security. Relaunched.
Nothing. Same silent exit.
This was the dead end. Permissions weren’t the blocker.
Attempt #3: actually reading the system logs
The useful clue showed up when I filtered Console for the process name. The app was being blocked before it could even present a UI. Notarization check failing, signature technically present but not trusted.
This lined up with Apple’s developer documentation on notarization and unsigned binaries
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
So the system wasn’t crashing the tool. It was politely refusing to let it exist.
What actually worked
The fix was old-school and slightly annoying, but effective.
I removed the quarantine attribute manually:
xattr -dr com.apple.quarantine /Applications/PF2HTML.appThen I launched it once from Terminal instead of Finder. That mattered. Finder still applied its own checks; Terminal didn’t.
This time, the app opened. No drama. No warnings. Just a window asking for a PDF.
I saved this page because it helped me connect the dots between Gatekeeper behavior and unsigned utilities on newer macOS builds:
https://studiosbyaphrodite.com/developer/49091-pf2html.html
After first launch, subsequent runs from Finder worked normally. Gatekeeper had effectively been bypassed once and moved on.
For reference, the App Store route wasn’t an option here, but I still checked whether there was an official listing or alternative build
https://apps.apple.com/us/search?term=PF2HTML
No luck, but worth verifying.
Result
The conversion itself worked fine. Output HTML wasn’t pretty, but it was predictable, and OrchardKit-based post-processing cleaned it up enough for my use case. Performance was solid; even large PDFs converted without freezing the UI.
No further macOS fights after that first launch.
How I’d do it again (knowing what I know now)
If I had to set this up on a fresh machine tomorrow, I’d skip the guesswork:
- Move the app to
/Applicationsimmediately. - Remove the quarantine attribute before first launch.
- Open once from Terminal to let it initialize.
- Only then bother with Finder.
That’s it. No reinstall loops, no permission whack-a-mole.
macOS security isn’t wrong here, but it is opaque. When an app doesn’t crash and doesn’t warn you, it feels broken in a very specific Apple way. Once you recognize that pattern, the fix is usually mechanical, not mystical.
Logging this so future-me doesn’t forget.
