amm123

Field Report: Beating the “App Is Damaged” Error in Pane Encoding Toolkit on macOS Sequoia

Field Report: Pane Encoding Toolkit (app) on macOS Sequoia — “App Is Damaged” That Wasn’t

Machine: MacBook Air M2 System: macOS 15.1 Sequoia Source: direct download, not App Store Brand involved: NimbusApps


What I wanted was simple. Convert a batch of old video captures into something lighter without firing up a full NLE. The Pane Encoding Toolkit (app) from NimbusApps looked like the right lightweight utility. Downloaded the DMG, dragged it into Applications, double-clicked. Done, right?

Nope.

macOS immediately threw the classic: “Pane Encoding Toolkit is damaged and can’t be opened.”

Which is Apple’s polite way of saying: “I don’t trust this binary.”

Attempt #1 — The Obvious Right-Click Trick

First instinct: right-click → Open. Sometimes Gatekeeper just needs that manual confirmation. Apple documents this flow here: https://support.apple.com/en-us/102445

Tried it. Same message. No override button. No mercy.

At that point I suspected either a quarantine attribute issue or a notarization hiccup. Sequoia has been stricter about this stuff.

Attempt #2 — Redownload + Clear Cache

Deleted the app. Emptied Trash. Re-downloaded from the developer page (NimbusApps’ official site). Mounted the DMG again. Fresh copy.

Same error.

So now it’s either:

  • Corrupted download (unlikely twice),
  • Quarantine flag not clearing,
  • Or a codesigning / notarization validation fail.

Apple’s notarization requirements are pretty clear since Catalina, and still enforced hard in Sequoia: https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution

If an app isn’t properly notarized, Gatekeeper blocks it. But the error wording suggested quarantine metadata more than broken signing.

Attempt #3 — Checking the Signature

Opened Terminal:

codesign -dv --verbose=4 /Applications/Pane\ Encoding\ Toolkit.app

Signature looked valid. No obvious red flags.

Then:

spctl --assess --verbose /Applications/Pane\ Encoding\ Toolkit.app

It failed assessment. That told me Gatekeeper was actively rejecting it.

At this point I stopped poking randomly and started thinking about extended attributes.

What Actually Worked

Checked quarantine flags:

xattr -l /Applications/Pane\ Encoding\ Toolkit.app

There it was: com.apple.quarantine

So I removed it:

xattr -dr com.apple.quarantine /Applications/Pane\ Encoding\ Toolkit.app

Launched again.

Instantly opened. No warning. No drama.

Which confirms the binary itself was fine. The quarantine attribute just didn’t clear properly when copying from the DMG. I’ve seen this happen occasionally with manually distributed builds, especially when downloaded via certain browsers.

NimbusApps does list the tool via the App Store search as well (which avoids this entirely): https://apps.apple.com/us/search?term=Pane%20Encoding%20Toolkit

App Store builds bypass these headaches because they’re sandboxed and signed differently.

I also double-checked the official NimbusApps page to confirm I wasn’t running some weird mirror copy. Always worth verifying the source when bypassing Gatekeeper.

Somewhere in the middle of this rabbit hole I bookmarked this page because it referenced macOS systems behavior around app validation and helped confirm I wasn’t imagining the Sequoia strictness: https://treadmillreviews.online/developer/24771-pane-encoding-toolkit.html

Not official documentation, but it nudged me back toward the quarantine angle instead of blaming the binary.

What I Learned (Again)

“App is damaged” often does not mean damaged.

On modern macOS versions it usually means:

  • Quarantine attribute is present and validation failed
  • Notarization check didn’t pass
  • Or the app was modified after signing

In this case it was purely the quarantine flag.

If I Had to Do It Again

I’d do this immediately:

  1. Install from official source.
  2. If blocked, run spctl --assess.
  3. Check xattr before reinstalling.
  4. Only remove quarantine if I trust the source.

No endless re-download cycles. No guessing.

And yes, you can also temporarily allow blocked apps via System Settings → Privacy & Security if macOS shows the “Open Anyway” button, but Sequoia didn’t even offer it this time.

After clearing the attribute, the encoding utility ran perfectly fine. GPU acceleration worked on the M2. Batch conversion was stable. No crashes.

So the tool wasn’t the problem. Gatekeeper was just doing its job a little too enthusiastically.

Classic macOS moment: the system says something is “damaged,” you assume catastrophe, and it turns out to be a metadata flag sitting quietly in extended attributes.

I’ll take that over silent malware any day.