Understanding Mac App Notarization and Code Signing (2026)

Every time you download and open an application on your Mac, a complex security verification process happens in the background. This process involves code signing, notarization, and Gatekeeper checks—Apple's multi-layered approach to protecting macOS users from malicious software. Understanding these mechanisms empowers you to make informed decisions about which apps to trust and install. This comprehensive guide demystifies app notarization and code signing, showing you how to verify app authenticity before installation.

The Evolution of macOS App Security

Apple's approach to app security has evolved significantly over the years, responding to increasingly sophisticated threats.

Pre-2012: The Wild West Era

Before OS X Mountain Lion (10.8), macOS had minimal app verification:

Any application could run without restriction
No developer identity verification
No systematic malware checking
Users relied entirely on their own judgment

This freedom came with significant risk, as malware could easily masquerade as legitimate software.

2012: Introduction of Gatekeeper

OS X Mountain Lion introduced Gatekeeper, which checked developer signatures:

Apps from the Mac App Store were automatically trusted
Apps from "identified developers" required signed certificates
Users could choose to allow apps from "anywhere" (with a warning)

This was a significant step forward but had limitations—signatures proved an app came from a specific developer but not that it was safe.

2019: The Notarization Requirement

macOS Catalina (10.15) added the notarization requirement:

All distributed software must be submitted to Apple for automated malware scanning
Apple issues a "notarization ticket" for approved software
Gatekeeper checks for this ticket before allowing apps to run
Dramatically reduced malware distribution on macOS

2020-Present: Strengthening Protections

Recent macOS versions have continued to enhance security:

Stricter notarization requirements
Enhanced malware detection capabilities
Tighter control over system access and permissions
Regular security updates to detection algorithms

By 2026, these layered protections make macOS one of the most secure desktop platforms available.

Code Signing Explained

Code signing is the foundation of macOS app security, providing cryptographic proof of an app's origin and integrity.

What is Code Signing?

Code signing is a process where developers use cryptographic signatures to:

Prove Identity: Confirms the app comes from a specific developer or organization registered with Apple.

Ensure Integrity: Verifies the app hasn't been modified or corrupted since the developer signed it.

Enable Trust Chains: Creates a verifiable chain of trust from Apple's root certificate authority to the specific app.

Prevent Tampering: Any modification to the app after signing invalidates the signature, alerting users to potential compromise.

Think of code signing like a wax seal on an important letter—it proves who sent it and that it hasn't been opened or altered in transit.

How Code Signing Works

The technical process involves several steps:

Developer Obtains Certificate
- Developer enrolls in Apple Developer Program ($99/year as of 2026)
- Apple verifies the developer's identity
- Apple issues a unique Developer ID certificate
- Certificate contains developer's identity and cryptographic keys
Developer Signs the App
- Developer uses the codesign tool with their certificate
- Creates a digital signature of all code and resources
- Embeds signature within the app bundle
- Includes information about the developer and signing date
User Downloads and Opens App
- macOS verifies the signature using Apple's root certificate
- Confirms the app hasn't been modified since signing
- Checks if certificate is valid and not revoked
- Allows or blocks the app based on Gatekeeper settings

Components of a Code Signature

A code signature includes several key elements:

Developer Identity: The name and identifier of the signing entity, verified by Apple.

Timestamp: When the signature was created, allowing verification even after certificate expiration.

Designated Requirement: Specifies what entities are allowed to sign the app, preventing unauthorized signatures.

Entitlements: Special capabilities the app requests (like accessing contacts, calendar, or network).

Resource Rules: Which files within the app bundle are included in the signature.

Hash Values: Cryptographic hashes of all signed components, detecting any modifications.

Checking an App's Code Signature

You can verify any app's signature using the Terminal:

Basic Signature Verification:

codesign -v /Applications/Safari.app

If valid, you'll see no output. If invalid:

/Applications/Safari.app: code signature invalid

Detailed Signature Information:

codesign -dv /Applications/Safari.app

Output includes:

Executable=/Applications/Safari.app/Contents/MacOS/Safari
Identifier=com.apple.Safari
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=12345 flags=0x0(none) hashes=456+7 location=embedded
Signature size=4321
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Timestamp=Jan 15, 2026 at 10:30:00 AM
Info.plist entries=42
TeamIdentifier=ABCDE12345
Sealed Resources version=2 rules=13 files=456
Internal requirements count=1 size=123

Verify with Requirements:

codesign -dv --requirements - /Applications/Safari.app

Shows the designated requirements that must be met for the signature to be valid.

Deep Verification (checks all nested code):

codesign -vvv --deep /Applications/ComplexApp.app

Useful for apps with plugins, frameworks, or helper tools.

App Notarization Explained

While code signing proves who made an app, notarization adds Apple's verification that the app is safe.

What is Notarization?

Notarization is an automated process where:

Developer Submits App to Apple
- After signing, developer uploads app to Apple's notarization service
- Submission includes the signed application bundle
Apple's Automated Security Scan
- Checks for known malware signatures
- Analyzes behavior patterns associated with malicious software
- Verifies code signing is correct and complete
- Checks for common security issues
Apple Issues Notarization Ticket
- If the app passes all checks, Apple creates a "ticket"
- Ticket is associated with the app's unique signature
- Developer "staples" the ticket to the app (embeds it)
- Alternatively, Gatekeeper can check online for the ticket
User Downloads App
- Gatekeeper checks for notarization ticket (locally or online)
- If found and valid, app opens with minimal warning
- If not found, more restrictive warnings appear

Notarization vs. App Review

It's important to distinguish notarization from the Mac App Store review process:

Notarization (for apps distributed outside the App Store):

Automated malware scanning only
No human review of functionality or quality
No check for App Store guidelines compliance
Focuses solely on security
Typically completes in minutes to hours

App Review (for Mac App Store apps):

Human reviewers examine the app
Checks for guideline violations
Reviews functionality, content, and business model
Ensures app works as advertised
May take days to weeks

Key Point: Notarization does NOT mean Apple endorses the app or guarantees it works correctly. It only means automated scans found no malware.

What Notarization Checks For

Apple's notarization process examines several security aspects:

Known Malware Signatures: Compares against database of identified malicious code patterns.

Suspicious Behavior Patterns: Analyzes for behavior common in malware:

Unexpected network connections
Attempts to escalate privileges
Accessing sensitive data without clear need
Code obfuscation techniques

Code Signing Validity: Ensures:

Valid Developer ID signature
All components properly signed
No modifications after signing
Hardened runtime enabled (required since 2020)

Hardened Runtime Compliance: Verifies the app uses security features:

Code injection prevention
Library validation
Debugging protection
DRM capabilities if needed

Entitlement Appropriateness: Checks if requested capabilities are properly declared and justified.

Hardened Runtime Requirement

Since 2020, notarized apps must use the "hardened runtime," which enables several security protections:

Prevents Code Injection: Other processes can't inject code into the app, preventing a common malware technique.

Library Validation: Ensures only Apple-signed or developer-signed libraries can be loaded, preventing DLL hijacking attacks.

Disable Debugging: Prevents debugging tools from attaching (unless explicitly allowed), blocking runtime analysis by attackers.

Disable DYLD Environment Variables: Prevents malicious environment variable manipulation.

Resource Access Declarations: Apps must explicitly declare needs for camera, microphone, location, etc.

Hardened runtime significantly raises the bar for attackers trying to exploit or manipulate applications.

Checking Notarization Status

You can verify if an app is notarized using Terminal:

Check Notarization:

spctl -a -vv /Applications/AppName.app

Possible Outputs:

Notarized App:

/Applications/AppName.app: accepted
source=Notarized Developer ID
origin=Developer Name (TEAM123456)

Signed but Not Notarized:

/Applications/AppName.app: accepted
source=Developer ID
origin=Developer Name (TEAM123456)

(Note: "Developer ID" without "Notarized")

Unsigned App:

/Applications/AppName.app: rejected
source=no usable signature

Check for Stapled Notarization Ticket:

stapler validate /Applications/AppName.app

Output:

Processing: /Applications/AppName.app
The validate action worked!

Or if not stapled:

Processing: /Applications/AppName.app
The validate action failed! Error 65.

Note: An app can be notarized without a stapled ticket—Gatekeeper will check online in that case.

View Notarization Details:

codesign -dv --verbose=4 /Applications/AppName.app 2>&1 | grep -A 5 Notarization

Gatekeeper: The Enforcement Mechanism

Code signing and notarization would be meaningless without enforcement. That's where Gatekeeper comes in.

How Gatekeeper Works

When you download and try to open an app, Gatekeeper:

Checks Quarantine Attribute
- Downloaded files are tagged with com.apple.quarantine
- Triggers Gatekeeper verification on first launch
- Local apps created on your Mac aren't quarantined
Verifies Code Signature
- Confirms signature is valid
- Checks certificate hasn't been revoked
- Verifies chain of trust to Apple's root certificate
Checks Notarization
- Looks for stapled notarization ticket
- If not stapled, performs online lookup (requires internet)
- Caches result for future launches
Evaluates Against Security Policy
- Applies your Gatekeeper settings (App Store, Identified Developers, etc.)
- Determines whether to allow, warn, or block
Presents User Interface
- Allows app if all checks pass and policy permits
- Shows warning if notarization is missing but signature is valid
- Blocks if signature is invalid or app is known malware

Gatekeeper Security Levels

macOS offers different security levels in System Settings:

App Store Only (Most Secure):

Only apps from the Mac App Store can run
All apps are sandboxed and reviewed
Limits functionality but maximizes security

App Store and Identified Developers (Recommended):

Apps from App Store or signed with Developer ID
Notarization required (on macOS 10.15+)
Balanced security and flexibility
Default setting on modern macOS

Anywhere (Least Secure, Hidden):

Allows unsigned apps without warning
Not available in System Settings GUI
Can be enabled via Terminal (not recommended)
Removes critical security protection

Current Default: "App Store and identified developers" with notarization requirement.

Gatekeeper Bypass Methods

As covered in our "How to Open Apps from Unidentified Developers" guide, Gatekeeper can be bypassed for specific apps:

Right-Click > Open: Presents a dialog with an "Open" button, allowing you to explicitly permit the app.

System Settings Override: After Gatekeeper blocks an app, you can allow it in Security & Privacy settings.

Removing Quarantine: Using xattr -d com.apple.quarantine, advanced users can remove the trigger for Gatekeeper checks.

Important: These methods should only be used for apps you fully trust from verified sources.

Verifying App Authenticity Before Installation

Before installing any app, especially from outside the Mac App Store, verify its authenticity.

Step 1: Verify the Download Source

Official Website Only:

Download from the developer's official website
Verify the URL is correct (watch for typos: "goog1e.com" vs "google.com")
Look for HTTPS connection (padlock in browser)
Avoid third-party download sites, torrents, or file-sharing services

Check Developer Identity:

Research the developer or company
Look for established web presence
Check reviews and community reputation
Verify company registration if critical software

Beware Impersonation:

Attackers create fake websites mimicking legitimate ones
Double-check domain names carefully
Bookmark official sites for frequently used software

Step 2: Verify File Integrity with Checksums

Many developers provide cryptographic checksums to verify downloads haven't been tampered with.

What are Checksums?

A checksum (typically SHA-256) is a unique fingerprint of a file. Even tiny changes completely alter the checksum.

Finding Official Checksums:

Look on the download page
Check release notes or documentation
GitHub releases often include checksums
Some developers provide separate checksum files

Calculating SHA-256 Checksum:

# For a .dmg file
shasum -a 256 ~/Downloads/AppName.dmg

# For a .zip file
shasum -a 256 ~/Downloads/AppName.zip

# For a .pkg file
shasum -a 256 ~/Downloads/AppName.pkg

Example Output:

abc123def456789... ~/Downloads/AppName.dmg

Verification:

Compare your calculated checksum with the developer's published checksum
They must match exactly (case-insensitive)
If different, the file may be corrupted or tampered with—don't install

Automated Verification (if developer provides checksum file):

# Download checksum file (example)
curl -O https://developer.com/AppName.dmg.sha256

# Verify automatically
shasum -a 256 -c AppName.dmg.sha256

Output will show:

AppName.dmg: OK

Step 3: Check Code Signature Before Installing

Before mounting a DMG or running an installer, verify the signature:

For .app Files:

codesign -dv --verbose=4 ~/Downloads/AppName.app

Look for:

Valid authority chain ending in "Apple Root CA"
Timestamp showing when signed
TeamIdentifier (developer's Apple ID)

For .dmg Files:

codesign -dv --verbose=4 ~/Downloads/AppName.dmg

For .pkg Installers:

pkgutil --check-signature ~/Downloads/AppName.pkg

Example output:

Package "AppName.pkg":
   Status: signed by a developer certificate issued by Apple
   Certificate Chain:
    1. Developer ID Installer: Company Name (ABC123XYZ)
       SHA1 fingerprint: 12 34 56 78 9A BC ...
    2. Developer ID Certification Authority
       SHA1 fingerprint: 9A BC DE ...
    3. Apple Root CA
       SHA1 fingerprint: DE F1 23 ...

Red Flags:

No signature
Invalid signature
Certificate revoked
Unknown certificate authority (not Apple)

Step 4: Verify Notarization

After confirming the signature, check notarization:

spctl -a -vv ~/Downloads/AppName.app

Ideal Output:

accepted
source=Notarized Developer ID

Warning Signs:

source=Developer ID

(Signed but not notarized—proceed with caution)

rejected

(No valid signature—do not install)

Step 5: Research the Developer

Before installing, research the developer's reputation:

Developer Website:

Professional appearance
Contact information
Clear documentation
Privacy policy and terms of service

Online Presence:

Active GitHub repository (for open-source apps)
Social media presence
Community forums or support channels
Verifiable history

Community Feedback:

Reviews on independent sites
Discussion on Reddit, Hacker News, Mac forums
Warnings or red flags from other users
Length of time app has been available

Open Source Verification (if applicable):

Public source code repository
Commit history and contributors
Issue tracker with active development
Transparency about build process

Step 6: Check App Permissions and Entitlements

Before launching a new app, understand what it can access:

View Entitlements:

codesign -d --entitlements - /Applications/AppName.app

Output shows requested capabilities in XML format:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.network.client</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
</dict>
</plist>

Common Entitlements:

com.apple.security.network.client: Can make outbound network connections
com.apple.security.network.server: Can accept incoming connections
com.apple.security.files.user-selected.read-write: Can access files you explicitly choose
com.apple.security.files.downloads.read-write: Can access Downloads folder
com.apple.security.device.camera: Can access camera
com.apple.security.device.microphone: Can access microphone
com.apple.security.personal-information.location: Can access location

Red Flags:

Simple calculator requesting camera access
Text editor requesting network server capabilities
Utility requesting full disk access without clear need

Note: Entitlements declare what an app can do, not what it will do. The app still needs to request runtime permissions for sensitive access.

Understanding Security Warnings and Dialogs

macOS presents different warnings based on an app's verification status.

"App Downloaded from the Internet"

What It Means: The app is signed and notarized. This is a normal informational message.

Dialog Text:

"AppName" is an app downloaded from the Internet. Are you sure you want to open it?

Buttons: "Cancel" and "Open"

Action: Click "Open" if you trust the source. This is Apple's way of making you consciously confirm first-run for internet downloads.

Recommendation: Safe to proceed if you downloaded from a trusted source.

"Cannot Be Opened Because Developer Cannot Be Verified"

What It Means: The app is signed but not notarized.

Dialog Text:

macOS cannot verify that this app is free from malware.

Buttons: "Cancel" and "Move to Trash"

No "Open" Button: You can't open directly from this dialog.

Action: Use right-click > Open to get a dialog with an "Open" option, or use System Settings method.

Recommendation: Only proceed if you have verified the developer and source independently. Check signature manually.

"Cannot Be Opened Because It Is from an Unidentified Developer"

What It Means: The app is not signed with a Developer ID certificate.

Dialog Text:

"AppName" can't be opened because it is from an unidentified developer.

Buttons: "OK"

Action: Use right-click > Open or System Settings override methods.

Recommendation: High risk. Only proceed if:

Open-source with verified code
Internal corporate tool from trusted IT department
Self-created application
Legacy software you've used safely for years

"Damaged and Can't Be Opened"

What It Means: The app's code signature is invalid, corrupted, or the app has conflicting extended attributes.

Possible Causes:

File was corrupted during download
App was modified after signing
Extended attributes conflict
Malware (signature was deliberately broken)

Action:

Re-download from official source
Verify checksum
Try removing quarantine attribute: xattr -c /path/to/app
If still failing, do not use—likely corrupted or tampered with

Recommendation: Treat with high suspicion. Re-download and verify integrity.

"Malware Detected" or "Will Damage Your Computer"

What It Means: Gatekeeper or XProtect has identified the app as known malware.

Dialog Text:

"AppName" will damage your computer. You should move it to the Trash.

Buttons: "Move to Trash" and "Cancel"

Action: Move to trash immediately. Do not attempt to bypass this warning.

Recommendation: Never override this warning. The app contains known malicious code. Delete it and run a malware scan.

For Developers: Signing and Notarizing Your Apps

If you're a macOS developer, proper signing and notarization are essential for distributing your software.

Prerequisites

Apple Developer Account:

Enroll at developer.apple.com
Cost: $99/year (individual or organization)
Provides Developer ID certificate for signing

Xcode and Command Line Tools:

# Install Xcode Command Line Tools
xcode-select --install

App-Specific Password (for notarization):

Generate at appleid.apple.com
Use for authenticating notarization requests
Not your regular Apple ID password

Step 1: Code Signing Your App

Enable Hardened Runtime:

In Xcode:

Select your target
Go to Signing & Capabilities tab
Check "Hardened Runtime"
Add necessary entitlements

Via command line:

codesign --sign "Developer ID Application: Your Name (TEAMID)" \
         --options runtime \
         --entitlements entitlements.plist \
         --timestamp \
         --deep \
         YourApp.app

Sign All Components:

Sign frameworks and libraries first
Then sign helper tools and apps
Finally sign the main application
Use --deep flag to sign nested code automatically

Verify Signing:

codesign -vvv --deep --strict YourApp.app

Should output:

YourApp.app: valid on disk
YourApp.app: satisfies its Designated Requirement

Step 2: Creating a Distributable Archive

Create a .dmg, .zip, or .pkg:

For .zip:

ditto -c -k --keepParent YourApp.app YourApp.zip

For .dmg (requires additional tools):

hdiutil create -volname "YourApp" -srcfolder YourApp.app -ov -format UDZO YourApp.dmg

For .pkg (installer):

productbuild --component YourApp.app /Applications \
             --sign "Developer ID Installer: Your Name (TEAMID)" \
             YourApp.pkg

Step 3: Notarizing the App

Store Credentials (one-time setup):

xcrun notarytool store-credentials "AC_PASSWORD" \
                --apple-id "your-email@example.com" \
                --team-id "TEAMID" \
                --password "app-specific-password"

Submit for Notarization:

xcrun notarytool submit YourApp.zip \
                --keychain-profile "AC_PASSWORD" \
                --wait

The --wait flag makes the command wait for notarization to complete (usually minutes to an hour).

Check Notarization Status:

xcrun notarytool info <submission-id> --keychain-profile "AC_PASSWORD"

If Notarization Fails:

# Get detailed log
xcrun notarytool log <submission-id> --keychain-profile "AC_PASSWORD"

Review the log for specific issues:

Missing or incorrect entitlements
Hardened runtime not enabled
Invalid code signature
Detected security issues

Step 4: Stapling the Notarization Ticket

After successful notarization, attach the ticket to your app:

xcrun stapler staple YourApp.app

Or for a .dmg:

xcrun stapler staple YourApp.dmg

Verify Stapling:

xcrun stapler validate YourApp.app

Output:

Processing: YourApp.app
The validate action worked!

Why Staple?

Users can open your app offline without internet connection
Faster verification (no online lookup needed)
Better user experience

Step 5: Distributing Your App

Upload to Your Website:

Provide HTTPS download link
Include SHA-256 checksum
Mention the app is notarized in description

GitHub Releases:

Attach signed and notarized binary to release
Include checksum in release notes
Tag the release with version number

Update Mechanism:

Consider using Sparkle framework for automatic updates
Sign update feeds with EdDSA keys
Ensure updates are also notarized

Troubleshooting Notarization Issues

Common problems developers encounter:

"The binary is not signed with a valid Developer ID certificate"

Cause: App isn't signed or uses wrong certificate type.

Solution:

Ensure you're using "Developer ID Application" certificate, not "Mac Development" or "Apple Distribution"
Re-sign with correct certificate
Verify certificate is valid and not expired

"The signature does not include a secure timestamp"

Cause: Signature lacks timestamp, required for notarization.

Solution:

codesign --timestamp --sign "Developer ID Application: Your Name" YourApp.app

Always include --timestamp flag when signing.

"The executable does not have the hardened runtime enabled"

Cause: Hardened runtime not enabled during signing.

Solution:

codesign --options runtime --sign "Developer ID Application: Your Name" YourApp.app

Use --options runtime flag.

"The binary uses an SDK older than the 10.9 SDK"

Cause: App was built with very old Xcode/SDK.

Solution:

Rebuild with modern Xcode (Xcode 10+)
Update project to use current SDK
May require code updates for deprecated APIs

"The binary requests the com.apple.security.get-task-allow entitlement"

Cause: Debug entitlement left in release build.

Solution:

Remove get-task-allow entitlement from release builds
Only use this entitlement during development
Create separate entitlements files for debug/release

Best Practices for App Security

Whether you're a user or developer, follow these practices:

For Users

Download from Trusted Sources: Official websites, Mac App Store, or reputable platforms like GitHub releases.
Verify Signatures: Use codesign and spctl to check apps before running.
Check Checksums: When provided, always verify SHA-256 hashes.
Stay Updated: Keep macOS updated for latest Gatekeeper protections.
Respect Warnings: Don't casually bypass security warnings—they exist for a reason.
Research Developers: Look for established reputation, transparency, and community trust.
Monitor Permissions: Pay attention to what apps request access to.

For Developers

Always Sign Your Apps: Even internal tools benefit from code signing.
Notarize Everything: Don't make users jump through hoops to run your software.
Enable Hardened Runtime: Use modern security features Apple provides.
Minimize Entitlements: Only request capabilities your app actually needs.
Provide Checksums: Help users verify downloads haven't been tampered with.
Transparent Communication: Document your app's capabilities and data handling.
Keep Certificates Current: Monitor expiration dates and renew before they lapse.
Test on Clean System: Verify your app launches correctly for new users with strict Gatekeeper settings.

The Future of macOS App Security

Apple continues to evolve its security model. Trends to watch:

Stricter Notarization Requirements: Apple periodically tightens what passes automated scans, requiring developers to adopt newer security practices.

Enhanced Malware Detection: Machine learning and heuristic analysis improve detection of novel threats.

Reduced Trust in Unsigned Software: Future macOS versions may make it harder or impossible to run unsigned apps.

Supply Chain Security: Greater focus on verifying the entire development and distribution pipeline.

Privacy Nutrition Labels: Following iOS, clearer upfront disclosure of data collection practices.

Account-Based Trust: Potential for user-specific trust decisions synced across devices via iCloud.

Conclusion

App notarization and code signing represent Apple's balanced approach to macOS security—maintaining an open platform while protecting users from threats. Understanding these mechanisms empowers you to make informed decisions about which software to trust and install.

Key Takeaways:

Code signing proves identity and integrity: It confirms who made an app and that it hasn't been tampered with.
Notarization adds safety verification: Apple's automated scans provide an additional layer of protection against known malware.
Gatekeeper enforces these protections: It checks signatures and notarization before allowing apps to run.
Verification is your responsibility: Use codesign, spctl, and checksums to verify apps before installation.
Trust but verify: Even notarized apps deserve scrutiny—check the developer, permissions, and source.
For developers, signing and notarization are essential: They build user trust and ensure smooth installation.

By understanding the technical details behind macOS's security architecture, you can navigate the ecosystem confidently, distinguishing between legitimate software and potential threats. Whether you're downloading your next productivity app or distributing software to users, these verification processes are your allies in maintaining a secure Mac environment.

The extra moment it takes to verify an app's signature and notarization status is a small investment that can prevent significant security incidents. Make it a habit, and your Mac will remain both functional and secure throughout 2026 and beyond.