Spotting non-notarized apps: risks and removal guide

You downloaded an app, double-clicked it, and macOS refused to open it - either because it is “from an unidentified developer” or because “Apple could not verify” it is free of malware. That warning does not tell you whether the app is dangerous. It tells you the app has no notarization ticket from Apple, which is a different thing, and this guide explains how to tell the two apart.

Below you will find how to read each version of the warning, how to check an app’s signature and notarization status yourself, how to decide whether to trust it, and how to remove it completely if you don’t. Every command, path, and screenshot here comes from a real test session on a MacBook Pro (Apple M1, 8 GB RAM) running macOS Tahoe 26.4.1.

Where to start

This guide covers three different situations. Pick the one that matches yours instead of reading straight through.

What “non-notarized” actually means

Two separate mechanisms are involved, and most confusion comes from treating them as one. Code signing is the developer’s act of signing the app with a certificate -either an Apple-issued Developer ID certificate or a self-made ad-hoc signature. It answers the question “who built this and has it been modified since?”

xcrun stapler staple

com.apple.quarantine

The requirement became mandatory in macOS 10.14.5 (Mojave, May 2019): every new Developer ID app has to be notarized, or Gatekeeper blocks it by default. macOS Catalina 10.15 extended the rule to kernel extensions and app updates.

How to spot a non-notarized app

There are two ways to find out. The passive one is to read the dialog macOS shows you. The active one is to check the app yourself, before or after that dialog appears, which is the only way to know the status of an app that is already installed and no longer triggering warnings.

Reading the warning dialog

The exact wording changed across macOS releases, so the string you see also tells you roughly which check failed.

1. “‘X’ can’t be opened because Apple cannot check it for malicious software.” Seen up to macOS Sonoma 14. The app is signed, but it has no notarization ticket.
2. “‘X’ is from an unidentified developer.” Also pre-Sequoia. The app carries an ad-hoc or self-signed certificate, or no signature at all.
3. “Apple could not verify ‘X’ is free of malware that may harm your Mac or compromise your privacy.” This is the current wording in macOS Sequoia 15 and Tahoe 26, with the app’s name in the title above it followed by Not Opened. Some builds add a second line: “This software needs to be updated. Contact the developer for more information.” Note what is missing either way - there is no Open Anyway button in the dialog anymore, only Move to Trash and Done, and Move to Trash is the highlighted default.
4. “‘X’ is damaged and can’t be opened. You should move it to the Trash.” This one is misleading. In most cases, the file is intact, and the signature check failed - commonly after the app was copied over a network share or unpacked by an archiver that stripped its extended attributes. Redownloading often fixes it by accident, which is why the myth persists. Verify before you delete.

Verify it yourself in Terminal

Four commands cover everything you need. Open Terminal (in Applications → Utilities) and substitute your own app name.

Start with the overall Gatekeeper verdict:

spctl -a -vv /Applications/AppName.app

accepted

source=Notarized Developer ID

rejected

Next, look at the signature itself:

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

Authority=

TeamIdentifier=

code object is not signed at all

Notarization Ticket=stapled

spctl

codesign

For the notarization status on its own, macOS 12 Monterey and later accept a direct test:

codesign --test-requirement="=notarized" -v /Applications/AppName.app

And to check whether the ticket is attached to the bundle rather than fetched online:

xcrun stapler validate /Applications/AppName.app

This distinction matters offline. If a developer notarized the app but never stapled the ticket, macOS has to query Apple on first launch, so on a Mac with no network connection, a legitimately notarized app gets blocked.

One more command tells you whether Gatekeeper will even bother:

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

If nothing comes back, the app has no quarantine flag, which is typical for apps copied by hand from a network volume or a disk image, and Gatekeeper will not check it at launch at all. That is worth knowing: an unchecked app is not a verified app.

Check the status without Terminal

If the command line is not your thing, two GUI options show the same information. Apparency, a free utility from Mothers Ruin Software, displays signature, notarization, and entitlement details for any bundle you drop on it.

App Cleaner & Uninstaller by Nektony also reports both states in each app’s card, which is handy for checking everything you already have installed rather than one bundle at a time. Select an app in the Applications tab and read the two fields at the top: Developer and App verification.

Those two fields separate the cases this article is about. An app can be Signed but not verified by Apple - the developer is identified, but the build never went through notarization, which describes a great many legitimate tools.

The real risks - and the limits of notarization

Here is the part most guides skip. The notary service scans for known malware signatures. It does not run the app, it does not analyze behavior, and it does not audit the code. A brand-new piece of malware with no matching signature can pass.

That is not hypothetical. Security vendor Intego documented more than 40 malware samples in August 2020 that Apple’s notary service had approved. Dozens of adware installers sailed through the automated scan. Researcher Patrick Wardle later demonstrated a full Gatekeeper bypass (CVE-2021-30657) that was already being exploited in the wild before Apple patched it. You can only imagine the scale of this problem today with the rise of AI.

So the honest framing is this: notarization lowers your risk and gives Apple a revocation switch if a developer’s certificate turns out to be abused. It is a filter, not a guarantee. And in the other direction, plenty of non-notarized apps are perfectly safe, and the absence of a ticket often just means the developer never paid the $99 a year for the Apple Developer Program.

The genuine danger sits in what you do next. Apple’s own support documentation warns that overriding the Gatekeeper warning is the single most common way Macs get infected. Adware installers rely on exactly that: the user is mid-download, wants the thing to work, and clicks through. If the app then installs a launch agent, it survives reboots and reopens things you did not ask for.

Should you open it? A quick trust decision

Since the warning itself carries no verdict, the decision comes down to where the app came from.

There are ordinary reasons for an app to have no notarization ticket:

• Older or abandoned apps built before the 10.14.5 requirement, still working, still unmaintained
• Open-source utilities distributed straight from the developer without a paid Developer Program membership
• Internal corporate tools never meant for public distribution
• Anything you compiled yourself from source in Xcode or via

  make

  Copy

  , which is always ad-hoc signed

Weigh those against the source. An app downloaded from the developer’s own site, with a public repository and a real commit history, and ideally a published SHA checksum you can compare against your download, is a very different proposition from the same-named app pulled off a download aggregator or a search ad. If you cannot name the developer, treat the app as untrusted and remove it.

How to remove a non-notarized app safely

If you have decided against the app, dragging it to the Trash is not enough. Apps scatter support files, preferences, caches, and sometimes launch agents across your Library folder, and adware in particular relies on those leftovers to reinstall itself.

Manual removal: Trash plus leftover files

Quit the app first, then open your Applications folder in Finder, Control-click the app, and choose Move to Trash.

~/Library

com.developer.appname

• ~/Library/Application Support/<AppName>

  Copy

  or

  <bundle id>

  Copy

• ~/Library/Preferences/<bundle id>.plist

  Copy

• ~/Library/LaunchAgents/<bundle id>.plist

  Copy

  - user-level autostart items

• /Library/LaunchDaemons/<bundle id>.plist

  Copy

  - system-level helpers, needs an administrator password

• ~/Library/Caches/<bundle id>

  Copy

• ~/Library/Containers/<bundle id>

  Copy

  - sandboxed apps only

• ~/Library/Logs/<AppName>

  Copy

~/Library/Containers

Stubborn apps that won’t delete

If macOS refuses to move the app or the Trash won’t empty, something is still holding it.

Check Activity Monitor first for a running process or helper carrying the app’s name, and quit it there. If the app registered a background daemon, find it:

launchctl list | grep 

And then unload it:

sudo launchctl bootout system/

Older apps that installed a kernel extension need their permission revoked before the files will go. On Apple Silicon under Sequoia 15 and Tahoe 26, that lives in System Settings → General → Login Items & Extensions, in the Extensions block. Switch it to By App to see which app owns each extension and what type it is. Before Sequoia this panel sat in Privacy & Security → Security instead, and legacy kext-based apps on Intel Macs may additionally require a reboot into Recovery Mode.

/System

Automated removal with App Cleaner & Uninstaller

Doing the sweep by hand works, but it depends on you knowing every path. App Cleaner & Uninstaller by Nektony matches related files by bundle identifier and developer name rather than by folder name, which catches leftovers that a name-based search in Application Support misses.

1. Open App Cleaner & Uninstaller and go to the Applications tab. Every installed app is listed with its signature and notarization status.
2. Grant Full Disk Access when macOS asks on first launch, in System Settings → Privacy & Security → Full Disk Access. Without it, the scan cannot read

   ~/Library

   Copy

   and system folders, and part of the leftovers stay invisible.
3. Click the app you want to check. A warning triangle next to its name in the list marks anything questionable, and the card spells out why - an app that is both Unsigned and Not verified by Apple is the weakest case of all, since nothing identifies who built it.
4. To see the app’s related files, toggle the Expert Mode in the upper part of the screen and tick the app’s checkbox. The scan pulls in its files automatically, grouped as Executables, Application Support, Caches, Containers, and so on, with the full path under each entry and a running total of selected items.
5. Review that list and untick anything you want to keep, such as license files or your own documents.
6. Click Remove. A confirmation window lists every item once more before anything moves, so this is your last chance to check the paths.
7. Empty the Trash to finish.

Anything protected by SIP, or registered as a system LaunchDaemon or kernel extension, still needs the manual handling described above. The app shows those files rather than pretending they are gone, which is the honest behavior but worth knowing before you assume the job is complete.

Prefer to keep it? Open it safely

If you know the developer and want the app anyway, there is a supported way to allow it - one app at a time.

On macOS Sequoia 15 and Tahoe 26, the sequence is: double-click the app and let it be blocked, then open System Settings → Privacy & Security, scroll to the Security block, click Open Anyway next to the message about the blocked app, and authorize with Touch ID or your password. The button appears only after that first blocked launch attempt, which catches a lot of people out.

On macOS 10.14 through Sonoma 14, the older route still works: Control-click the app icon, choose Open, and confirm in the dialog. This adds the app to Gatekeeper’s allow-list by hash -for that build only.

Advanced users can strip the quarantine flag directly instead:

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

After that, Gatekeeper stops checking this app on launch. It works the same on Intel and Apple Silicon, and it lowers your protection for this one file - which is the point, and the limit.

sudo spctl --master-disable

The bottom line

A Gatekeeper warning is a statement about paperwork, not about danger. The app has no valid notarization ticket, and that is all macOS is telling you - the risk assessment is yours to make, based on where the app came from.

spctl -a -vv

codesign -dv --verbose=4