Fix OSStatus -67030: AMFI Code Signature Error on macOS

What OSStatus -67030 Actually Means

You double-click an app and it either bounces once and dies, or you get "Library not loaded" with a reference to something like @rpath/libFoo.dylib. If you check Console.app, you'll see AMFI in the log saying code signature validation failed and spitting out OSStatus error -67030. AMFI is Apple's Mobile File Integrity subsystem. It's the gatekeeper's gatekeeper. When it rejects a binary, the process gets killed before it ever runs a line of your code.

The -67030 specifically means the code signature doesn't match what AMFI expects. Either the signature is invalid, the binary got modified after signing, or the signature references something that isn't there anymore. The "Library not loaded" message is usually a symptom of the same thing — the dylib it's trying to load fails its own signature check, so dyld bails out and reports the load failure instead of the signature failure.

I had a client last month whose entire Adobe workflow broke after an IT guy ran a "cleanup script" that stripped extended attributes from /Applications. Every Adobe binary failed -67030 on launch. Took ten minutes to fix once I knew where to look.

Cause 1: Quarantine or Extended Attributes Broke the Signature

This is the number one cause and it's almost always fixable in under a minute. When you download an app from the internet, macOS slaps a com.apple.quarantine attribute on it. Normally the app handles that fine. But if the file got touched by something that rewrote the xattr, or if you copied files with cp instead of ditto (which preserves xattrs properly), the signature can end up mismatched against the resource fork metadata AMFI uses.

First, find out what attributes are on the app:

xattr -l /Applications/YourApp.app

If you see com.apple.quarantine or anything odd, nuke it recursively:

xattr -cr /Applications/YourApp.app

That -cr clears all extended attributes recursively. Then try launching again. If the app wasn't actually modified — just flagged — this fixes it on the spot.

Word of caution: if the app really did get tampered with, stripping xattrs won't help and you're about to see the same error. Move to cause two.

Cause 2: The Binary Got Modified After Signing (Or Was Never Signed)

Some apps — especially stuff built by small devs, tools bundled with Python or Node, or anything you compiled yourself — ship with a broken or missing signature. macOS on Apple Silicon requires every executable to be signed, even ad-hoc. Intel Macs are more forgiving but AMFI will still kill things if the signature is present-but-wrong.

Check the signature:

codesign -vvv --deep --strict /Applications/YourApp.app

If you get code object is not signed at all or invalid signature, you've found the problem. The fix is to ad-hoc sign it yourself. That's enough for AMFI to let it run locally, even though it won't pass Gatekeeper's notarization check:

codesign --force --deep --sign - /Applications/YourApp.app

For a bundle with embedded frameworks or helper tools, you might need to sign inside-out. Sign the frameworks first, then the main app:

find /Applications/YourApp.app/Contents/Frameworks -name "*.dylib" -exec codesign --force --sign - {} \;
find /Applications/YourApp.app/Contents/Frameworks -name "*.framework" -exec codesign --force --deep --sign - {} \;
codesign --force --deep --sign - /Applications/YourApp.app

This is the fix I use for Homebrew-built binaries that get flagged, custom internal tools, and anything the dev signed with a certificate that's since expired. Ad-hoc signing with - works when the original cert is dead.

If codesign complains that a bundle format is unrecognized, the app is probably damaged rather than just unsigned. Re-download it from the vendor before signing.

Cause 3: A Dependency Dylib Moved or Lost Its Signature

The "Library not loaded" variant is nastier. The main binary is fine, but it links against a dylib at a path that either doesn't exist or points to a file whose signature is broken. This shows up constantly with Wine, CrossOver, some Python apps, and anything using @rpath.

Find out what it's actually trying to load:

otool -L /Applications/YourApp.app/Contents/MacOS/YourApp

You'll see lines like @rpath/libSomething.dylib (compatibility version 1.0.0, current version 1.0.0). Track down where that resolves:

otool -l /Applications/YourApp.app/Contents/MacOS/YourApp | grep -A2 LC_RPATH

If the dylib is missing, restore it from a backup or reinstall the app. If it's there but unsigned, sign it and re-run the main app:

codesign --force --sign - /path/to/libSomething.dylib

Don't be tempted to disable AMFI globally with nvram boot-args="amfi_get_out_of_my_way=1". On modern macOS (Ventura and later) that's blocked by SIP unless you've disabled SIP too, and disabling SIP on a work machine is how you turn a five-minute problem into a two-day audit. I've seen people go down that rabbit hole and end up reinstalling macOS. Skip it. Fix the signature.

When the app is genuinely corrupted

If codesign -vvv reports the binary has been modified and the modification isn't yours, treat it as suspect. Re-download from the vendor. Don't trust a random copy of an app from a shared drive or an old backup. Malware sometimes ships as a legit-looking app with a broken signature because the attacker patched the binary post-signing.

Quick Reference

Nine times out of ten, -67030 is a one-liner fix. Start with xattr, then codesign, then trace the library. If all three fail and the app came from a trusted vendor, delete it and reinstall. Something upstream is wrong and you're not going to win that fight at 6pm on a Friday.