'<App> Is Damaged and Can't Be Opened' on Mac? Here's the Fix

You unzip a downloaded app, double-click it, and Gatekeeper hits you with a dialog you’ve probably seen before: ” is damaged and can’t be opened. You should move it to the Trash.” Except the file isn’t damaged. You downloaded it from the developer’s site three minutes ago. The Trash is the wrong answer.

This message is one of the most misleading in macOS. The app is fine ninety percent of the time. The wording is a side effect of how Gatekeeper handles certain code-signing edge cases.

What “damaged” actually means here

When you download a file via Safari, Chrome, Firefox, or most email clients, macOS adds an extended attribute called com.apple.quarantine to the file. That attribute marks the file as “from outside” so Gatekeeper can scrutinize it on first launch.

If the app’s code signature doesn’t match what Gatekeeper expects when it checks against the quarantine, you get the “damaged” dialog. The actual binary is fine. The signature check just failed.

Three common reasons:

1. The app is signed but not notarized — common with open-source apps.
2. The signature was made by a developer certificate that’s expired or been revoked.
3. The app extracted from a zip and the metadata wrapper got corrupted in transit.

The exact wording of the dialog:

” is damaged and can’t be opened. You should move it to the Trash.”

Don’t move it to the Trash unless you’re genuinely unsure of the source.

The five-second fix

For trusted apps from known sources, run this in Terminal:

xattr -d com.apple.quarantine /Applications/AppName.app

Replace AppName.app with the actual app’s filename. That removes the quarantine flag and lets the app launch.

If the app is in ~/Downloads or somewhere else, point at the actual location:

xattr -d com.apple.quarantine ~/Downloads/AppName.app

If you get No such xattr: com.apple.quarantine, the flag wasn’t there to begin with — your “damaged” message was caused by something else. Skip to the next section.

When xattr doesn’t fix it

If the quarantine flag wasn’t the problem, the signature itself is broken or missing. Causes ranked by likelihood:

1. Incomplete download. The download stopped halfway and the app bundle is missing files. Re-download.
2. Corrupted unzip. Some old archives extracted with non-default tools mangle the bundle. Re-extract with macOS’s built-in Archive Utility (right-click → Open With → Archive Utility).
3. Modified app bundle. Did you Show Package Contents and edit anything? That breaks the signature. Re-download a fresh copy.
4. Code signature actually invalid. The developer shipped a broken build. Check their support page or download a different version.
5. App was downloaded years ago and the certificate has expired. Particularly common for older builds of niche utilities.

Verify the signature manually:

codesign -dv --verbose=4 /Applications/AppName.app

If it reports code object is not signed at all, the binary genuinely isn’t signed. Use spctl --assess --verbose /Applications/AppName.app to check Gatekeeper’s view — it’ll explain the rejection.

Skip the manual huntSweep clears the cruft that triggers most of these errors — caches, logs, leftover daemons. Download Sweep free →

Specific scenarios you’ll run into

App downloaded from GitHub releases

Many open-source projects ship signed but not notarized binaries. The “damaged” error is especially common with these. Re-download, then xattr -d com.apple.quarantine and you’re set. If the project is reputable and you trust the source, this is safe.

App restored from Time Machine or another Mac

Time Machine sometimes preserves the quarantine attribute, leading to “damaged” errors after restore. Run xattr -dr com.apple.quarantine /Applications to clear it for everything in Applications at once.

App from an old DMG you saved years ago

Certificates expire after ~5 years. An app signed in 2018 by a developer who hasn’t re-signed it may now show “damaged.” Look for an updated version from the developer.

App that worked yesterday and is suddenly “damaged”

Almost always the result of a macOS update tightening Gatekeeper checks. Re-download a current version of the app — older builds often need re-signing for newer macOS versions.

App from email attachment

Some email clients aggressively flag attachments. The quarantine flag plus an unusual code path can trigger the error. Save the attachment, run xattr, then launch.

When you should leave the app in Trash

The trust factor matters. Don’t bypass Gatekeeper for:

• Apps from random links in unsolicited emails or chat messages.
• “Cracked” or pirated apps. They’re routinely repackaged with malware and the “damaged” warning is appropriate.
• Apps from sites that look like the official one but have a slightly different domain.
• App downloads triggered by a website you weren’t expecting.

The Gatekeeper warning protects you from a real attack class. If you have any doubt about the source, take the warning at face value.

Don’t reinstall macOS yetSweep clears the buildup that’s actually causing the issue. Free for macOS →

A safer process for unsigned apps

Some apps you genuinely need are unsigned and unlikely to ever be notarized — older utilities, hobbyist projects, internal tools at a workplace. The right pattern:

1. Verify the source: official website, project repo, or coworker.
2. Check a hash if the developer publishes one (shasum -a 256 AppName.app/Contents/MacOS/AppName).
3. Run xattr -d com.apple.quarantine after download.
4. Right-click → Open the first time, click Open in the Gatekeeper dialog.

This combination accepts the developer’s lack of notarization without giving up Gatekeeper’s protections for other apps.

Mass-clear quarantine on a folder

If you have a folder full of old apps after a migration:

sudo xattr -rd com.apple.quarantine /Applications

The recursive flag means it applies to nested files too. Use this carefully — you’re disabling Gatekeeper checks for everything in the path. Don’t do this on ~/Downloads if you regularly download files from various sources.

When the developer is gone

Some perfectly good apps are abandoned — the developer stopped shipping updates years ago, but the app still works. If the certificate has expired and there’s no updated version:

• The xattr workaround still works as long as you can get past the first dialog.
• Once macOS deprecates the framework the app uses, no workaround helps. That’s when you need to find an alternative.

When the answer is “find a different app”

Some “damaged” failures are unfixable:

• The app is 32-bit on Catalina or newer. macOS won’t run it under any circumstances.
• The app uses a now-removed framework (QuickTime 7, kernel extensions in newer macOS).
• The developer’s certificate was revoked by Apple for a reason that wasn’t a false positive.

A short search usually turns up modern equivalents. Don’t burn hours forcing an abandoned app to run when a current alternative exists.

Prevent the error from coming back

• Download from the developer’s official site or the Mac App Store, not aggregator sites.
• Use Safari for downloads when possible. It cooperates best with macOS’s quarantine system.
• Keep apps updated.
• If you build software yourself, sign and notarize it. The first time is annoying; afterward it’s automatic.

The “damaged and can’t be opened” message is one of macOS’s worst-worded errors. It scares people into deleting perfectly fine apps. Now you know to read it as “Gatekeeper rejected the signature check” and you have a one-line fix for the common cases.