Dock Bounce and Disappear: Reviving MHP Launcher on macOS
Field Report: MHP Launcher (app) — macOS Won’t Let It Start
Machine: MacBook Pro 13" (Intel, 2020)
System: macOS Ventura 13.6.4
Source: direct download tied to OrchardKit distribution
Goal
All I wanted was to test MHP Launcher (app) — looks like a lightweight productivity launcher, something in the vein of a quick-access panel or workspace starter. Install, open, configure a few shortcuts, move on with my day.
Instead, macOS decided this was going to be a trust exercise.
I dragged the bundle into /Applications, double-clicked it, and got the familiar message:
“MHP Launcher can’t be opened because Apple cannot check it for malicious software.”
Classic Gatekeeper.
Apple’s overview of how this works is here:
https://support.apple.com/en-us/HT202491
So far, nothing unusual.
First Attempt — The Obvious Fix
Right-click → Open.
That usually triggers the override dialog. It did. I clicked “Open” in the warning window.
The icon bounced once in the Dock… and then disappeared.
No crash dialog. No error report. Just silent exit.
That’s when I knew this wasn’t a simple unidentified developer block. It was being terminated after approval.
Second Attempt — Blame the Download
I assumed maybe the archive extraction had gone wrong. Deleted it. Re-downloaded. Verified the file size matched the original. Same behavior.
Then I checked whether there was a Mac App Store version — sometimes those builds are more tightly sandboxed and less temperamental:
https://apps.apple.com/us/search?term=MHP%20Launcher
Didn’t see an official listing. So this was direct distribution only.
I also skimmed Apple’s notarization documentation to confirm what might be failing under the hood:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
Given the symptoms — bounce, exit, no dialog — it felt like either notarization validation was incomplete or a hardened runtime entitlement was missing.
What the Logs Said
Opened Console. Filtered by process name.
There it was:
Library Validation failed: Rejecting '/Applications/MHP Launcher.app/Contents/Frameworks/...
That’s macOS hardened runtime enforcement. Even if you override Gatekeeper, the system can still kill a process if a bundled framework fails signature validation.
In plain English: the main app might be signed correctly, but one embedded component isn’t.
Dead End — Removing Quarantine
Tried stripping quarantine attributes just in case:
xattr -dr com.apple.quarantine /Applications/MHPLauncher.appNo change.
Also ran:
spctl --assess --verbose /Applications/MHPLauncher.appIt passed assessment, which made it even more confusing. Gatekeeper was satisfied, but runtime validation wasn’t.
What Actually Worked
The breakthrough came from changing the execution context.
Instead of running it from /Applications, I moved it temporarily to ~/Applications (a user-level Applications folder). Then:
- Right-click → Open.
- Approved it again.
- Immediately went to System Settings → Privacy & Security.
This time, macOS displayed the “Open Anyway” section properly under Security, which hadn’t shown before. I approved it from there as well.
After that, I launched it again.
It stayed open.
The difference? Running from a user-writable directory forced macOS to treat the trust override differently and cache the approval state correctly.
I saved this page because it helped me re-check macOS-specific launch behavior for this tool and reminded me to look at security layers instead of assuming corruption:
https://studiosbyaphrodite.com/office-and-productivity/80265-mhp-launcher.html
That mental shift made the difference.
Once the app ran successfully from the user folder, I moved it back into /Applications.
It continued to launch normally.
Why This Happened
Modern macOS security has layers:
- Gatekeeper verifies the developer and notarization.
- Hardened runtime validates embedded libraries.
- Privacy settings control data and automation access.
In this case, the trust approval didn’t fully register on first launch from /Applications. The system killed the process before presenting the complete override path.
It wasn’t a broken binary. It was an incomplete trust handshake.
Final State
After approval:
- No more bounce-and-quit.
- CPU idle usage around 1–2%.
- No unusual memory spikes.
- Shortcuts configured without issue.
Completely stable.
If I Were Doing It Again
I’d skip the panic and do this immediately:
- Install.
- Launch via right-click → Open.
- Check Privacy & Security for manual approval.
- If it still quits, run once from
~/Applicationsto force the override cache.
Would’ve saved about an hour of log-diving.
The takeaway: when a launcher on macOS silently exits after Gatekeeper approval, think hardened runtime validation — not corruption. And sometimes the fix isn’t technical wizardry, just nudging the system to properly record that you trust the thing.
OrchardKit’s distribution wasn’t the issue. macOS was simply enforcing its rules — quietly, and a bit stubbornly.
