Fixing 'App Is Damaged and Can't Be Opened' on macOS
The app usually isn't damaged — it's Gatekeeper's quarantine flag reacting to how it was downloaded, and there's a legitimate way to override it.
“App is damaged and can’t be opened, you should move it to the Trash” is one of macOS’s most misleading error messages — in the overwhelming majority of cases, the app isn’t damaged at all. This is Gatekeeper and code signing reacting to an unsigned or ad-hoc-signed app that was downloaded through a path that added a quarantine flag.
Step 1: understand what’s actually happening
xattr -l /Applications/SomeApp.app
Look for com.apple.quarantine in the output — this attribute gets added automatically to files downloaded via a browser, and is what triggers Gatekeeper’s stricter scrutiny of the app when you first try to open it.
Step 2: check whether the app is actually properly signed and notarized
codesign -dv --verbose=4 /Applications/SomeApp.app
spctl -a -vv /Applications/SomeApp.app
spctl’s output distinguishes a genuinely corrupted or tampered app (a real problem) from one that’s simply unsigned or from an unidentified developer (not actually damaged, just untrusted by default).
Step 3: for software you trust, remove the quarantine attribute
xattr -d com.apple.quarantine /Applications/SomeApp.app
This is the standard, legitimate way developers and experienced users unblock software they’ve verified is safe but that Apple hasn’t notarized — only do this for software from a source you actually trust, since removing quarantine also removes the safety check it exists to provide.
Step 4: alternatively, allow it through System Settings
System Settings → Privacy & Security → scroll to the blocked-app
notice → "Open Anyway"
This appears only after you’ve already attempted to open the app once and been blocked — a slightly more guided, GUI-based equivalent to Step 3.
Step 5: verify the download wasn’t actually corrupted, if this is a fresh download
shasum -a 256 SomeApp.dmg
Compare against a checksum published by the software’s actual distributor, if one is available — a genuinely corrupted download (as opposed to a merely-unsigned one) is a real possibility worth ruling out, especially if re-downloading the file resolves the issue without needing any of the steps above.
Step 6: re-download from the original source if in doubt
If you’re not confident about a specific download’s integrity or origin, downloading fresh from the software’s official site or the Mac App Store — rather than removing quarantine on a file you’re uncertain about — is the safer path.
Why this message is worded so alarmingly for what’s usually a benign situation
Apple’s phrasing here errs deliberately on the side of caution — telling an average user “this might be unsafe, delete it” is a safer default message than a more nuanced but harder-to-parse explanation of code signing and notarization status. For anyone who understands what’s actually happening and trusts the specific software in question, Steps 3 and 4 are the legitimate, intended way to proceed — not a workaround exploiting a bug.
What notarization actually adds beyond a basic code signature
A code signature alone confirms an app hasn’t been tampered with since a specific developer signed it — it says nothing about whether Apple has ever reviewed that specific build for malware. Notarization is the separate step where a developer submits a signed app to Apple’s automated scanning service, which checks for known malware signatures and other red flags before issuing a notarization ticket; Gatekeeper checks for that ticket (either embedded via “stapling” or fetched live from Apple’s servers) alongside the signature itself when deciding how much friction to present. An app that’s signed but not notarized still shows a Gatekeeper warning, just a less severe one than a genuinely unsigned app — which is why “properly signed” and “fully notarized” are two related but distinct bars a piece of software can clear independently, and why spctl’s output distinguishing them matters for correctly diagnosing which one, if either, a specific flagged app is actually missing.
Why re-downloading sometimes fixes it without touching quarantine at all
Occasionally, what looks like a Gatekeeper block is actually a genuinely corrupted or incomplete download that happens to trip the same warning — re-downloading the file cleanly, rather than working around quarantine on a file that was never intact to begin with, resolves this specific variant without needing to override anything Gatekeeper is protecting at all.
Related:
- Code Signing, Notarization, and Gatekeeper on macOS
- Verifying App Signatures and Notarization with codesign and spctl
Sources: