Guide · Updated August 22, 2026

Mac app signing, Apple notarization and Gatekeeper explained

Q: Why does macOS say a freshly downloaded app is damaged?

Almost always because of the com.apple.quarantine attribute macOS attaches to downloaded files, combined with a signature Gatekeeper cannot evaluate. The file itself is usually intact. Removing the quarantine attribute with the xattr command, or downloading again from the original source, resolves it.

A direct Mac download can still be signed by a registered developer and checked by Apple's notarization service. This guide shows the normal trusted path, how to verify a release yourself, and what to do only when an older unsigned build triggers a Gatekeeper warning.

Contact support Get the apps

What macOS is actually telling you

Both warnings come from Gatekeeper, the part of macOS that checks software the first time you launch it. Gatekeeper is not a virus scanner in the traditional sense. It is closer to an identity check at a door: it asks whether the app carries a cryptographic signature it can trace to a registered Apple Developer account, and whether Apple has a record of having scanned that exact build.

If the answer is no, macOS refuses the first launch and shows a message. Crucially, the message reports a lack of information, not a detection. "Apple cannot check it for malicious software" means exactly that: nothing was checked, so nothing was found either way. If macOS had actually identified known malware, the wording would be different and far more direct, and the file would be blocked outright rather than deferred to a confirmation step.

Gatekeeper, quarantine, and notarisation

Three separate mechanisms interact here, and untangling them makes the fixes obvious.

Code signing attaches a cryptographic signature to an app so macOS can tell whether the file has been altered since the developer built it. Signatures come in tiers. A Developer ID signature ties the app to a paid Apple Developer account. An ad-hoc signature proves the bundle is internally consistent but is not tied to any registered identity.

Notarisation is a separate Apple service: the developer uploads each build, Apple runs an automated malware scan, and if it passes, Apple issues a ticket that macOS can check at launch. It requires Apple Developer Program membership and a build process that submits every release. Many independent developers, hobbyist tool authors, and open-source projects skip it. That is why some legitimate Mac software still triggers these warnings.

It is worth being precise about what notarisation does and does not prove. It confirms that an automated scan found no known malware in that build and that the build is tied to an accountable developer account Apple can revoke. It is not a code review, not a privacy audit, and not a guarantee that the software behaves well. Notarised apps have shipped adware and aggressive data collection. The absence of notarisation is a missing signal, not a warning sign; the presence of it is a weak positive signal, not a clean bill of health.

The quarantine attribute is the trigger. When Safari, Chrome, Mail, or Messages saves a file, macOS tags it with an extended attribute called com.apple.quarantine. That flag is what makes Gatekeeper run its check on first launch. Files you build yourself or copy from a USB drive usually have no flag, which is why the same app can open silently in one situation and be blocked in another.

Fix: "cannot be opened because Apple cannot check it for malicious software"

This is the standard unidentified-developer case, and macOS has a built-in override. You do not need Terminal.

Move the app into your Applications folder first, then double-click it.
When the warning appears, click Done or Cancel. Do not click "Move to Trash."
Open System Settings → Privacy & Security, and scroll to the Security section near the bottom.
You will see a line naming the app that was just blocked, with an Open Anyway button next to it. Click it and confirm with Touch ID or your password.
The app opens. Every launch after that is normal, with no prompts.

The entry only appears in Privacy & Security after a blocked launch attempt, so if you do not see it, try opening the app once more. On older macOS versions the equivalent shortcut is to right-click (or Control-click) the app and choose Open from the context menu, which offers a confirmation dialog instead of a dead end.

Fix: "the app is damaged and can't be opened"

This wording alarms people, and it is usually inaccurate. In most cases the file is intact and the message is macOS's fallback when a quarantined app carries a signature Gatekeeper cannot evaluate, most often because the download was ad-hoc signed or because the archive was unpacked in a way that disturbed the bundle. Genuinely corrupt downloads happen too, so if you are unsure, download the file again from the original source before anything else.

If a fresh download behaves the same way, clear the quarantine flag. Open Terminal (Applications → Utilities), paste the line below, and press Return:

xattr -dr com.apple.quarantine "/Applications/YourApp.app"

Read that command before you run it. xattr manages extended attributes, the small pieces of metadata macOS attaches to files alongside their contents. -d means delete one named attribute, -r applies it through everything inside the app bundle, and com.apple.quarantine is the specific flag being deleted. Replace YourApp.app with the real name and keep the quotation marks, which matter for names containing spaces. The command touches nothing but that one app's metadata. It does not disable Gatekeeper system-wide, does not change any security setting, and does not grant the app extra privileges.

What it does do is remove the prompt that would otherwise have asked you to confirm. That is the whole point of the check, so only run it on software you have already decided to trust.

How to judge whether unsigned software is safe

Since macOS is handing the decision to you, it helps to have a method rather than a feeling.

Provenance beats everything. Did you land on the download from the developer's own site, over HTTPS, or from a link in a forum post, an ad, or a search result for "free download"? Impostor sites for popular Mac apps are the single most common way people get burned. Type the domain yourself rather than following a link.
Look for a trail. A developer with a real site, a changelog, a support address that replies, a public repository or an app that has been discussed by name for years is a very different proposition from an anonymous binary posted last week.
Match the permissions to the purpose. macOS asks separately for Full Disk Access, Screen Recording, Accessibility, camera, and microphone. A text editor requesting Screen Recording deserves an explanation. You can review and revoke everything later in System Settings → Privacy & Security.
Inspect the signature. In Terminal, run codesign -dv --verbose=4 "/Applications/YourApp.app". The output names the signing authority. A Developer ID line identifies a registered developer; Signature=adhoc tells you the bundle is self-signed with no registered identity behind it. Either way, spctl -a -vv "/Applications/YourApp.app" shows you exactly what Gatekeeper thinks.
Scan the download. Upload the .dmg to VirusTotal, which runs it past dozens of engines. Treat one or two hits on an unsigned app as likely false positives and a cluster of them as a reason to stop. Where the developer publishes a SHA-256 checksum, compare it against shasum -a 256 file.dmg to confirm you received the file they shipped.
Watch the network. An app that claims to work offline should not be chattering to servers. Little Snitch, LuLu, or macOS's own firewall will tell you.

Where IndepApps stands now

Signing and notarization are being introduced release by release. Gravity 1.0 Direct edition is signed with a Developer ID, notarized by Apple, and distributed with a stapled notarization ticket. Gatekeeper accepts that exact build through the normal install flow. Its product page publishes the version, system requirements, file size and SHA-256 checksum.

Other catalog builds remain legacy releases until they pass the same signing, subscription-removal, notarization and Gatekeeper checks. The site does not apply an Apple-notarized badge to an app merely because another edition exists in the Mac App Store. The badge describes the exact website download offered for purchase.

Verification is release-specific and reproducible: compare the checksum, inspect the signature with codesign -dv, and ask Gatekeeper with spctl -a -vv. There is a named developer and a support address behind every build. Read more about who builds them, or ask anything through support.

Frequently asked questions

Does the "cannot be opened because Apple cannot check it for malicious software" message mean the app has a virus?

No. It means the app has not been through Apple's notarisation service, so macOS has no record of a scan result for it. The message describes an absence of information, not a detection. Malware has never been found in the file; Apple simply has not looked at it.

Why does macOS say a freshly downloaded app is damaged?

Almost always because of the com.apple.quarantine attribute macOS attaches to downloaded files, combined with a signature Gatekeeper cannot evaluate. The file itself is usually intact. Removing the quarantine attribute with the xattr command, or downloading again from the original source, resolves it.

Is it safe to run `xattr -dr com.apple.quarantine` on an app?

The command only deletes a metadata flag on that one app; it changes nothing else on your Mac and leaves Gatekeeper active for everything else. The real question is whether you trust that specific app, because you are removing the prompt that would otherwise ask you. Never run it on something you downloaded from a source you cannot identify.

Are IndepApps apps notarised by Apple?

Notarization is being introduced release by release. Gravity 1.0 Direct edition is Developer ID signed, Apple notarized and distributed with a stapled ticket. A product page only shows the Apple-notarized badge after that exact website build passes verification; legacy builds are identified separately and may require Open Anyway.