Mac
“App Is Damaged” on Mac: Safe Checks Before Opening
Fix a damaged-app warning safely: identify the exact macOS alert, re-download a verified build, check its signature and know when Open Anyway is appropriate.
Start here: Record the exact warning before changing anything
Read the complete dialog. Separate “damaged” or “modified” from “developer cannot be verified” / “cannot be checked for malicious software”, and from “will damage your computer” / malware warnings. Record the app name, download URL and macOS version.
Do not force open software macOS identifies as harmful, or disable Mac security protections.
Problem summary
Start by reading the exact warning. For a damaged or modified app, re-download a supported build from the verified publisher before considering any exception. Malware and revoked-authorisation warnings must stay blocked. An unsigned-app warning has a different, limited Open Anyway path.
Read the complete dialog. Separate “damaged” or “modified” from “developer cannot be verified” / “cannot be checked for malicious software”, and from “will damage your computer” / malware warnings. Record the app name, download URL and macOS version.
spctl --assess --type execute --verbose=4 "/Applications/App Name.app"
You have the exact message and know which security branch applies.
Do not force open software macOS identifies as harmful, or disable Mac security protections.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Record the exact warning before changing anything
Check: Read the complete dialog. Separate “damaged” or “modified” from “developer cannot be verified” / “cannot be checked for malicious software”, and from “will damage your computer” / malware warnings. Record the app name, download URL and macOS version.
Expected result: You have the exact message and know which security branch applies.
If not: If macOS identifies malware or revoked authorisation, leave the app blocked and contact its developer through a separately verified channel.
Safe stop: Do not force open software macOS identifies as harmful, or disable Mac security protections.
Re-download a damaged app from its verified publisher
Check: For a damaged/modified app, keep it closed. Obtain a fresh installer from the publisher’s official site or the App Store. If the publisher provides a checksum, compare it. Replace only the application, keeping your documents and settings backed up.
Expected result: The newly downloaded, compatible build opens without a security override.
If not: If a fresh copy is also blocked, the source being official does not prove this build is safe or intact. Ask the publisher for a corrected, signed/notarised build.
Safe stop: Do not remove quarantine as a routine damaged-app repair.
Inspect integrity without changing security settings
Check: For a developer or support investigation, run the read-only assessment and verification commands below against the actual application path. Keep the exact output.
Expected result: Gatekeeper assessment and signature verification produce evidence you can share with the publisher.
If not: A rejection or signature verification error needs publisher investigation. An unsigned app also fails verification; this alone does not prove malware. Successful checks are not a guarantee of safety.
Use Open Anyway only for the eligible unsigned-app branch
Check: For a recognised app with a developer-not-verified or cannot-be-checked warning, try opening once, then inspect the "Supported security screen" command below. Consider Open Anyway only when macOS offers it and you have independently assessed the publisher and need for this app.
Expected result: The offered exception applies to this app, with the risk clearly understood.
If not: If no exception is offered, do not treat that as permission to bypass the warning. Use a supported build or contact the publisher.
Safe stop: A damaged/modified or malware warning is not interchangeable with an unsigned-app warning.
Prove the application works and preserve the result
Check: Open the clean supported build, check its version and perform one harmless operation with a copy of a document. If the warning persists, send the publisher the exact warning, macOS version, source URL and assessment output without private files.
Expected result: The app opens and the test operation succeeds with system security still enabled.
If not: Check the publisher’s macOS and Intel/Apple Silicon requirements. Use a compatible release, or leave the app closed while support investigates.
Did this solve your problem?
Your answer helps us improve this page.
No account or personal details. We store the page, answer, optional reason and day with a 90-day retention period. A random reference in this browser prevents repeat votes. Feedback privacy
Decision tree
If: The warning says the app is damaged or modified
Then: Bundle integrity may be wrong; an unsigned-app exception is not the default repair
Action: Re-download a supported build from the verified publisher; assess the fresh copy and escalate a repeated warning.
If: macOS says the software will damage your computer or authorisation was revoked
Then: This is a security stop, not a routine installation obstacle
Action: Leave the app blocked and contact the verified publisher; do not force it open.
If: The developer cannot be verified or the app cannot be checked, and macOS offers Open Anyway
Then: This is an eligible unsigned/unnotarised-app risk decision
Action: Assess the publisher and need independently before using the offered per-app exception; retain system-wide protection.
If: A fresh official copy fails signature verification or assessment
Then: The publisher must explain the build/policy failure; verification failure alone does not prove malware
Action: Send the exact read-only assessment output to support and use a supported corrected release.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| The warning says the app is damaged or modified | Exact dialog, publisher URL, app/macOS versions and signature-verification output | Bundle integrity may be wrong; an unsigned-app exception is not the default repair | Re-download a supported build from the verified publisher; assess the fresh copy and escalate a repeated warning. |
| macOS says the software will damage your computer or authorisation was revoked | Exact malware/revocation warning and how the application arrived | This is a security stop, not a routine installation obstacle | Leave the app blocked and contact the verified publisher; do not force it open. |
| The developer cannot be verified or the app cannot be checked, and macOS offers Open Anyway | Exact warning, fresh download source and offered Privacy & Security exception | This is an eligible unsigned/unnotarised-app risk decision | Assess the publisher and need independently before using the offered per-app exception; retain system-wide protection. |
| A fresh official copy fails signature verification or assessment | codesign verification and spctl assessment output for the actual fresh app path | The publisher must explain the build/policy failure; verification failure alone does not prove malware | Send the exact read-only assessment output to support and use a supported corrected release. |
Commands and settings paths
Gatekeeper assessment
spctl --assess --type execute --verbose=4 "/Applications/App Name.app"Where: Terminal; replace App Name with the actual app
Expected: An assessment verdict and signing/source information
Failure means: Rejected can mean signing/notarisation or policy failure; retain the exact output
Safe next step: Ask the publisher to interpret a rejection; do not bypass it.
Signature verification
codesign --verify --deep --strict --verbose=2 "/Applications/App Name.app"Where: Terminal; read-only verification
Expected: Verification completes without a signature error for a valid signed bundle
Failure means: Unsigned or changed components can fail this check
Safe next step: Compare a fresh official build and contact the publisher; a pass is not proof of safety.
Supported security screen
System Settings → Privacy & Security → SecurityWhere: macOS Settings after one blocked open attempt
Expected: An eligible unsigned app may have Open Anyway
Failure means: Missing exception is not evidence that quarantine can safely be removed
Safe next step: Keep damaged or malware-flagged software closed.
Hardware and platform boundary
Change only when
- Use a publisher-supported application release when the current build cannot pass its security checks.
Evidence that matters
- Exact warning, supported macOS version, signing evidence and a fresh verified download.
Evidence that does not matter
- A successful application start without checking the actual data or result.
Avoid
- Do not disable Gatekeeper, use an unlocker, or remove quarantine to force damaged/malware-flagged software open.
Related problems
Last reviewed
2026-09-27 · Reviewed by HomeTechOps. Reviewed 2026-09-27 against Apple’s current warning categories. Removed blanket quarantine-removal advice and the claim that an official download is safe to override. No hands-on test of every warning on every macOS version is claimed.
Sources/assumptions
- Source-reviewed against Apple’s security guidance; signature checks provide evidence, not a guarantee that software is safe.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.
Get the deal & firmware alerts
Home Stack Field Notes: NAS deals, firmware changes worth acting on, restore-test reminders, and new decision guides — plus the capacity & backup sizing cheatsheets from our calculators. Unsubscribe anytime.
Subscribe on beehiiv