General:
DevForums topic: Code Signing > Notarization
DevForums tag: Notarization
WWDC 2018 Session 702 Your Apps and the Future of macOS Security
WWDC 2019 Session 703 All About Notarization
WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps
WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API
Notarizing macOS Software Before Distribution documentation
Customizing the Notarization Workflow documentation
Resolving Common Notarization Issues documentation
Notary REST API documentation
TN3147 Migrating to the latest notarization tool technote
Fetching the Notary Log DevForums post
Q&A with the Mac notary service team Developer > News post
Apple notary service update Developer > News post
Notarisation and the macOS 10.9 SDK DevForums post
Testing a Notarised Product DevForums post
Notarisation Fundamentals DevForums post
The Pros and Cons of Stapling DevForums post
Resolving Error 65 When Stapling DevForums post
Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
Notarization
RSS for tagNotarization is the process of scanning Developer ID-signed software for malicious components before distribution outside of the Mac App Store.
Posts under Notarization tag
124 Posts
Sort by:
Post
Replies
Boosts
Views
Activity
Dear Apple Developer Technical Support,
I am encountering an issue with notarizing and stapling both PKG and DMG installers for our Electron-based macOS application COSGrid. Despite receiving successful notarization submission responses via notarytool, the stapling process fails with Error 65.
Environment:
App Name: COSGrid
Bundle Identifier: com.cosgrid.pkg.COSGrid
Developer ID Team ID: YB8S2XZ98K
macOS Version: macOS [15.1]
Xcode Version: [16.0 (16A242d)]
Workflow Summary:
For PKG:
Build via yarn build (Vite + Electron Builder)
Package with pkgbuild
Sign using productsign
Submit for notarization:
xcrun notarytool submit COSGridMZA-2.1.10-arm64.pkg --apple-id "..." --team-id YB8S2XZ98K --password "..." --wait
Conducting pre-submission checks for COSGridMZA-2.1.10-arm64.pkg and initiating connection to the Apple notary service...
Submission ID received
id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a
Upload progress: 100.00% (235 MB of 235 MB)
Successfully uploaded file
id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a
path: /Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGridMZA-2.1.10-arm64.pkg
Waiting for processing to complete.
Current status: Accepted.....................
Processing complete
id: a8ff8e09-1ab4-49ed-9f6b-4afb9f09e53a
status: Accepted
Receive notarization success
Stapling fails:
xcrun stapler staple COSGridMZA-2.1.10-arm64.pkg
Could not validate ticket...
The staple and validate action failed! Error 65.
For DMG:
Sign via codesign
Submit to notarization — success
Attempt to staple:
xcrun stapler staple -v COSGrid-2.1.10-arm64.dmg
Could not validate ticket...
The staple and validate action failed! Error 65.
Additional Verification:
I verified the DMG’s code signature integrity:
Command:
codesign --verify --verbose=4 COSGrid-2.1.10-arm64.dmg
Output:
COSGrid-2.1.10-arm64.dmg: valid on disk
COSGrid-2.1.10-arm64.dmg: satisfies its Designated Requirement
Command:
codesign -dvv COSGrid-2.1.10-arm64.dmg
Output:
Executable=/Users/murugavel/Documents/MZA/mza/release/2.1.10/COSGrid-2.1.10-arm64.dmg
Identifier=COSGrid-2.1.10-arm64
Format=disk image
CodeDirectory v=20200 size=308 flags=0x0(none) hashes=1+6 location=embedded
Signature size=9013
Authority=Developer ID Application: COSGrid Systems Private Limited (YB8S2XZ98K)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=1 Jul 2025 at 11:34:05 AM
Info.plist=not bound
TeamIdentifier=YB8S2XZ98K
Sealed Resources=none
Internal requirements count=1 size=180
**Verified Signature for .pkg **
pkgutil --check-signature COSGridMZA-2.1.10-arm64.pkg
Package "COSGridMZA-2.1.10-arm64.pkg":
Status: signed by a developer certificate issued by Apple for distribution
Signed with a trusted timestamp on: 2025-06-30 13:57:19 +0000
Certificate Chain:
1. Developer ID Installer: COSGrid Systems Private Limited (teamID)
Expires: 2027-02-01 22:12:15 +0000
2. Developer ID Certification Authority
Expires: 2027-02-01 22:12:15 +0000
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
Diagnostic Logs Attached:
Stapler verbose logs for both PKG and DMG
codesign verification output for both PKG and DMG
Notarytool submission logs
Ticket JSON response from Apple API
API request/response headers
Effective electron-builder.yaml config
Key Observations:
codesign verification passes successfully for both artifacts
Notarization submission reports success via notarytool
Stapler fails with Error 65 for both PKG and DMG
Ticket JSON fetched from CloudKit API appears valid
No provisioning profile used (Developer ID distribution only)
Request:
Could you please help investigate:
Why is the stapler unable to validate or attach the ticket even though notarization completes successfully?
Are there any known issues, entitlements, or workflow adjustments recommended in this case?
Is any special handling required for Electron apps’ PKG/DMG packages or Hardened Runtime configurations during stapling?
I can provide the signed DMG/PKG and full notarization logs upon request.
Thank you very much for your assistance — looking forward to your guidance.
Best regards,
Murugavel
COSGrid Systems Private Limited
It's been over 24h and it's still in progress. Is there a timeout for a failed notarization? or do we just wait for days.. weeks.. moths?
Successfully received submission info
createdDate: 2025-06-25T09:52:03.153Z
id: 2ae713a5-c2e3-432f-84ee-e5d3d4aed621
name: slideshow-city-1.1.0-arm64.dmg
status: In Progress
Yesterday there were reported outages on the Developer ID Notary Service, but it was reported pretty late and we were able to notice the outages in real time. It says resolved now, however an error still persists:
Error: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. Ensure your team has signed the necessary legal agreements and that they are not expired.
Is there an ongoing outage at this moment that is not being reported again?
Our pipelines have been working flawlessly for months without intervention nor changes until the most recent outages
I've been successfully notarizing my apps for a year or so now, with intermittent releases every so often, usually succeeding with notarization in a couple of minutes.
These apps are all written in Python, but I worked through all the jank required to get them to notarize cleanly a while ago and have no issues since.
Today I submitted a couple of builds which have been stuck for hours. They're just "in progress", so no logs I can look at, no emails or anything on my developer account page.
How can I begin to debug this?
Successfully received submission info
createdDate: 2025-06-24T18:43:37.140Z
id: 8d1a1ca9-f0ad-426f-a714-89aaf9e01a07
name: pinpal-2025.6.25.for-notarizing.app.zip
status: In Progress
I should note that in addition to the comment added within 10 minutes of creation of this issue, within the last day, we also have:
https://developer.apple.com/forums/thread/789389
https://developer.apple.com/forums/thread/789599
https://developer.apple.com/forums/thread/789995
So it seems pretty likely something is going on on the backend.
Starting a few hours ago (roughly 2:45PM Eastern time) we began experiencing elevated latency with the Developer ID Notary Service. There is nothing listed on the developer system status page about degraded performance or a service outage.
Operations that usually take ~15 minutes, are stacking up for hours.
The oldest pending entry we have was created at 2:45PM Eastern:
createdDate: 2025-06-24T18:45:22.539Z
id: 5209a4d2-eae4-4714-aa8e-6961677ff2e
We currently have 27 pending builds in the notary service since we are required to notarize internal builds to ensure we satisfy our requirements so this is creating an issue for us.
I have multiple submissions for an app notarization. The goal is to distribute the DMG on my website rather than the app store (which I also have a submission in review for). These are the notarization logs:
--------------------------------------------------
createdDate: 2025-06-23T20:26:46.597Z
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
name: Mira-Assist-Fresh.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:53:11.825Z
id: 4bccdfb6-6663-41d3-89bc-c0a15fbdd4b8
name: Mira Assist.zip
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T17:45:10.342Z
id: fedca538-7619-4a7f-bcc8-3199d6e4b1a6
name: Mira-Assist-1.0.0-Hardened.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:51:04.289Z
id: 19a866b9-e664-4641-b137-6ac852c14ac9
name: Mira Assist-1.0.0.dmg
status: In Progress
--------------------------------------------------
createdDate: 2025-06-23T02:44:25.372Z
id: 455209e5-91dd-4324-aac0-d582f88efc95
name: Mira Assist-1.0.0.dmg
status: In Progress
The earliest of which occured more than 18 hours ago.
This is my first time submitting an app for notarization. I also have a developer account that was created ~1-2 days ago.
From what I've read online, notarization usually occurs in less than 10 minutes.
When querying for the logs, it juts says that the submission ID is invalid or the logs aren't available yet.
Submission log is not yet available or submissionId does not exist
id: 75972c58-bc83-44a9-b3af-4aff1b1839c3
I've tried to notarize my app recently and got the error:{
"logFormatVersion": 1,
"jobId": "...",
"status": "Rejected",
"statusSummary": "Team is not yet configured for notarization",
"statusCode": 7000,
"archiveFilename": "myapp.dmg",
"uploadDate": "2019-06-20T06:24:53Z",
"sha256": "...",
"ticketContents": null,
"issues": null
}I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.
Hello,
I'm working on an app at work and we finally got to signing and notarizing the app. The app is successfully notarized and stapled, I packaged it in a .dmg using hdiutil and went ahead and notarized and stapled that as well.
Now I tried to move this app to another machine through various methods. But every time I download it from another machine, open and extract the contents of the dmg and attempt to open the app, I get the "Apple could not verify my app is free of malware that may harm your Mac or compromise your privacy.
When I check the extended attributes there's always the com.apple.quarantine attribute which from what I know, is the reason that this popup appears
I've tried uploading it to google drive, sending through slack, onedrive, even tried our AWS servers and last but not least, I tried our Azure servers (which is what we use for distribution of the windows version of our app). I tried uploading to Azure through CloudBerry (MSP360 now), and azure-cli defining the content-type as "application/octet-stream", the content-disposition as "attachment; filename=myApp.dmg", and content-cache-control as "no-transform". None of these worked
The only times where a download actually worked with no problems was when I downloaded through the terminal using curl, which obviously not a great solution especially that we're distributing to users who aren't exactly "tech savy"
I want the installation experience to be as smooth as other apps outside the App Store (i.e Discord, Slack, Firefox, Chrome etc....) but I've been stuck on this for more than a week with no luck.
Any help is greatly appreciated, and if you want me to clarify something further I'd be happy to do so
I have attempted all upgrades:
updated xcode to 16.4
downloaded and installed Command Line Tools for Xcode 16.4
I have no issues with the installs, however when I run:
> xcrun notarytool --version
1.0.0 (38)
I need to be running v2.x
How can I resolve this issue.
Hi Developers,
I'm encountering persistent validation errors in Xcode 16.3 (16E140) on macOS 15.4.1 (24E263) with M1 when archiving and distributing a macOS app (Developer ID signing + notarization).
App Structure:
A native Swift/Obj-C wrapper app that launches a nested .app inside its Resources.
The nested app is built with PyInstaller and includes:
A Python core
Custom C++ binaries
Many bundled .so libraries (e.g., from OpenCV, PyQt/PySide)
Issues During Validation:
App Sandbox Not Enabled
Error: App Sandbox missing for NestedApp.app/Contents/MacOS/NestedExecutable.
Question: For Developer ID (not App Store), is sandboxing strictly required for nested PyInstaller apps? If the wrapper is sandboxed, must the nested app be as well? Given the PyInstaller app's nature (requiring broad system access), how should entitlements be managed?
Upload Symbols Failed
Errors for missing .dSYM files for:
The nested app’s executable
Custom C++ binaries
.so files (OpenCV, PyQt, etc.)
These are either third-party or built without DWARF data, making .dSYM generation impractical post-build.
Question: Are these symbol errors critical for Developer ID notarization (not App Store)? Can notarization succeed despite them? Is lack of symbol upload a known limitation with PyInstaller apps? Any best practices?
Dear Apple support,
Since the last couple of days, we have some (very) long running notarization requests. Similar requests were done normally under 1 minute.
This behavior is unexpected to us, and we did not see it before.
The issue occurs for a small CLI tool submitted as a ZIP archive.
Checking the documentation, I come across the section about "Avoid long notarization response times and size limits" (https://developer.apple.com/documentation/security/customizing-the-notarization-workflow#Avoid-long-notarization-response-times-and-size-limits).
One fact is mentioned “Limit notarizations to 75 per day.”
What is behavior if that limitation is reached?
Is that limitation per Apple ID or per team ID?
Are there some known issues about Notarization Service?
Best regards,
Stefan
Dear Apple Support,
for better understanding to use the Notary Service, I would like to ask when and what have to be notarized.
I am absolutely aware of using the Notary Service and which packages can be submitted and how to get the status.
Scenario:
We have one library which is developed by a specific team and other teams develop and deliver to customer MacOS apps which packages this library for the shipment.
So, the library will be produced internally and will be shipped in different products.
The library will be code signed before we make available internally.
When should we notarize (and staple) this library?
Directly after the code is signed or when it will be packaged in each product when it will be delivered to customer?
Best regards,
Stefan
Product: macOS,
Notarization Tool: notarytool,
Stapler Tool: xcrun stapler,
Application: master-billing.app,
DMG: master-billing.dmg
I'm attempting to notarize and staple a macOS .dmg file containing a signed .app. Notarization completes successfully, but the stapling step fails with Error 65. All tools are up-to-date and I'm following the official Apple process.
#!/bin/bash
set -e
APP="dist/mac-arm64/master-billing.app"
DMG="dist/mac-arm64/master-billing.dmg"
IDENTITY="Developer ID Application: NAME (TEAM ID)"
PROFILE="notarysiva"
VOLUME_NAME="MasterBilling"
Sign binaries and frameworks
find "$APP" -type f ( -name ".dylib" -or -name ".so" -or -name "*.node" -or -perm -u+x )
-exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ;
find "$APP" -type d ( -name ".app" -or -name ".framework" )
-exec codesign --force --options runtime --timestamp --sign "$IDENTITY" {} ;
codesign --deep --force --options runtime --timestamp
--sign "$IDENTITY" "$APP"
Create DMG
hdiutil create -volname "$VOLUME_NAME" -srcfolder "$APP" -ov -format UDZO "$DMG"
Sign DMG
codesign --sign "$IDENTITY" --timestamp "$DMG"
Verify DMG signature
codesign --verify --verbose=2 "$DMG"
Submit for notarization
xcrun notarytool submit "$DMG" --keychain-profile "$PROFILE" --wait
Staple ticket
xcrun stapler staple -v "$DMG"
Signing all binaries, dylibs, and frameworks...
.
.
✅ App signing complete.
💽 Creating DMG...
......................................................................................
created: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg
🔏 Signing the DMG...
✅ Verifying DMG signature...
dist/mac-arm64/master-billing.dmg: valid on disk
dist/mac-arm64/master-billing.dmg: satisfies its Designated Requirement
📤 Submitting DMG for notarization...
Conducting pre-submission checks for master-billing.dmg and initiating connection to the Apple notary service...
Submission ID received
id: 32927c3c-7459-42b4-a90c
Upload progress: 100.00% (123 MB of 123 MB)
Successfully uploaded file
id: 32927c3c-7459-42b4-a90c
path: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg
Waiting for processing to complete.
Current status: Accepted............
Processing complete
id: 32927c3c-7459-42b4-a90c
status: Accepted
📌 Stapling notarization ticket to DMG...
Processing: /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg
.
.
.
Downloaded ticket has been stored at file:///var/folders/1l/ht34h5y11mv3rhv8dlxy_g4c0000gp/T/5bb9e667-dfe1-4390-8354-56ced7f48fa0.ticket.
Could not validate ticket for /Users/one/Documents/MASTER/bill-master/dist/mac-arm64/master-billing.dmg
The staple and validate action failed! Error 65.
Hi all,
I’m trying to notarize a Flutter macOS app built in CI (GitHub Actions). The app builds and signs fine locally—codesign --verify --deep --strict and spctl --assess both pass. However, Apple’s notarization service consistently rejects the app with errors like:
The binary is not signed with a valid Developer ID certificate: file_picker.framework
The binary is not signed with a valid Developer ID certificate: file_saver.framework
The binary is not signed with a valid Developer ID certificate: url_launcher_macos.framework
What I’ve tried:
Explicitly re-signing all frameworks with my Developer ID Application certificate and --timestamp
Removing existing signatures before re-signing
Ensuring correct entitlements and bundle identifier
Matching the app bundle name and identifier in all places
Using both codesign --deep and manual signing of each binary
Local validation always passes, but notarization fails in CI
Certificate:
I am using a “Developer ID Application” certificate (not a “Mac Developer” or “Apple Development” certificate). The output of codesign -dvv for the problematic frameworks shows:
Authority=Developer ID Application: [My Name/Team] ([Team ID])
So I believe I am not making the common mistake of using the wrong certificate type.
CI Environment:
GitHub Actions, macos-latest runner
Flutter 3.27.2, stable channel
All secrets (cert, Apple ID, app-specific password, team ID) are set up
Questions:
Has anyone encountered this with Flutter plugins or CI builds?
Are there known issues with signing Flutter plugin frameworks for notarization?
Is there a way to get more detailed feedback from Apple’s notarization service?
Any advice or pointers would be greatly appreciated. I’m happy to provide logs, scripts, or a minimal project if needed.
Thanks!
Is it theoretically possible to:
Build an app with Mac Catalyst without the App Sandbox entitlement and
Distribute it outside the Mac App Store (w/ notarization)?
Thank you!
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
App Store
Mac Catalyst
Notarization
App Sandbox
I haven't been able to notarize my macOS app for the past two days. Now, I believe this is an issue with the notarization process because I've tried notarizing the default app that's provided whenever you open a new Swift application, but that completely failed as well.
And I've been waiting for the past two days and it's been stuck on in progress. This is the second time this has happened to me in the past two months and oftentimes I have to wait more than a day or two for the notarization to occur. I just, I don't understand why it's deadlocked like this.
I've done nothing. I haven't changed my certificates. I haven't done any different configurations within my Mac. The last time that this happened, the issue went away after two days, but my biggest concern right now is that if this happens whenever we need to urgently push updates, we can't.
I have absolutely no idea what to do and I'm just extremely frustrated because this is happening right before our launch day. I've been stuck on notarizing again for the past two days and I've seen no progress, I've seen no responses from support emails and the ones that do aren't even applicable to my current scenario.
Hi,
Out app is approved on app store, however we want to distribute outside apps tore as well. But notarization always fails with error:
Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.",
"statusCode": 7000,
Any help to address this issue is highly appreciated.
hey, trying to notarize my mac app rn. maybe servers are down. earlier today super fast but now slow and i need to ship.
anyone having similar issue?
I am trying to notarize a simple app I made, but keep getting stuck on "In Progress".
The app is a MacOS app, and I'm using XCode. I've tried all the steps listed in the links below:
https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution
https://developer.apple.com/documentation/security/resolving-common-notarization-issues
I've had the same issue with another app, which got rejected after multiple hours. Never got to resolve this.
I use the 'notarytool' to notarize applications and .pkg installers for Developer ID distribution. When using the notary tool with a fresh Apple Developer account, the notarization process remains stuck in the 'In progress' state. However, if I try the same app with an older developer account (one that has notarized at least one app in the past), the notarization works.
All agreements are accepted in developer portal and Appstore Connect.