I have an application that I have been signing, notarizing and distributing to beta testers for a year with no issues, note: I have never got stapling to work I always get a error 65 in the process. But up until yesterday that hasn't been an issue and online verification has always worked. Yesterday morning around 9am online gatekeeper verification has been failing with: APP not opened, apple cannot verify app is free of malware. etc this keeps happening, with every build I try. redownloading previously successful builds show the same behavior I know I can allow in privacy and security, but heading towards launch I dont want to have to tell users to do that. has there been a change in how gatekeeper works or issues with the service? any help with this or getting stapling working would be very appreciated!

My notary service has been stuck for more than 5 hours. Is it taking long time because the notary service is down or because i am a new user

I believe that this is related to the post https://developer.apple.com/forums/thread/790880. I essentially have the same problem that they did. I submit my Distribution PKG for notarization but the notarization fails and when I attempt to install the PKG user the UI I get a "External component packages (3) trustLevel=0 (trust evaluation failed; treating as invalid due to higher trust level for parent product archive)" However if I install using "sudo installer -verboseR -pkg ConcealDistribution.pkg -target /" everything works as expected. The difference between me and the other post is that when I expand my PKG using pkgutil --expand I do not have a Resources folder within my top level distribution. Instead my structure looks like ConcealDistribution ├── Distribution ├── ConcealConnect.pkg ├── ConcealBrowse.pkg └── ConcealUpdate.pkg The specific notary service errors I receive are as follows { "logFormatVersion": 1, "jobId": "7e30e3fd-1739-497c-a02e-64fbe357221d", "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "archiveFilename": "ConcealDistribution.pkg", "uploadDate": "2025-10-08T19:41:33.491Z", "sha256": "40aacfacf25c6da0be8fe31ae9c145a25ddf9ed1f38be714687c74d95b26619d", "ticketContents": null, "issues": [ { "severity": "error", "code": null, "path": "ConcealDistribution.pkg", "message": "Package ConcealDistribution.pkg has no signed executables or bundles. No tickets can be generated.", "docUrl": null, "architecture": null }, { "severity": "warning", "code": null, "path": "ConcealDistribution.pkg", "message": "The contents of the package at ConcealDistribution.pkg could not be extracted.", "docUrl": null, "architecture": null } ] } For what its worth all the inner PKGs have their executables signed, the PKGs are signed themselves and they are all notarized and stapled without issue. Then I am attempting to sign and notarize the outer PKG and that is where the problems pop up. Additionally I'm not sure when this stopped working as I expected but just a few months ago I was able to do this exact same process and install with the UI and have it work.

I am facing an issue while trying to staple a notarization ticket to my signed macOS installer package. Details of my setup: The .pkg file is signed using my Developer ID Installer certificate. The app inside the package is signed using my Developer ID Application certificate. Notarization via xcrun notarytool completes successfully with status: Accepted. However, the stapler command fails with the following error: xcrun stapler staple -v /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg Processing: /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg Could not validate ticket for /Users/mac-test/Desktop/IPMPlus_Arm_Installer_signed.pkg The staple and validate action failed! Error 65. I verified that all other Apple notarization-related servers (api.apple-cloudkit.com, gs.apple.com, ocsp.apple.com, ocsp2.apple.com, crl.apple.com, developer.apple.com) are reachable. However, the domain cdn-apple-cloudkit.apple.com cannot be resolved from any network, including mobile or public Wi-Fi. Both dig and nslookup return “No answer” even when using external DNS servers like 8.8.8.8 or 1.1.1.1. It appears that cdn-apple-cloudkit.apple.com might be required during the stapler validation process, but the DNS for this domain is not resolving. Could you please confirm whether this CDN endpoint is required for stapling, and if there is currently an outage or configuration issue with cdn-apple-cloudkit.apple.com?

Hi everyone, My app notarization has been stuck in the “In Progress” state for the past 4 days. Here are the details: createdDate: 2025-10-12T07:56:46.228Z id: 8f8c9a33-1c72-489e-a189-74c797a12fbc name: DevScribe.zip status: In Progress I checked the Apple System Status page and noticed that the Developer Notarization service has been showing an outage since October 8th. Could this ongoing outage be the reason my notarization is stuck? Is anyone else experiencing the same issue? Any guidance or workaround would be greatly appreciated.

Hi everyone, I’ve just subscribed and configured my Apple Developer account. I tried to notarize the first binary I need to distribute via Homebrew, but I’m experiencing an issue where the process has been stuck in “In Progress” status for more than 21 hours, without completing or returning any errors. Here’s the relevant history: createdDate: 2025-10-15T21:53:41.343Z status: In Progress

Hello, I am new to the apple developer program. I, and my team, are working on porting some medical software that we have written from Windows to MacOS. We obviously want to notarize our app to make it easy for professionals and colleagues to use. The software is entirely written in python and includes ffmpeg for one of the features to export the medical data to video and compiled to a single file with pyinstaller, like so: pyinstaller app_name.py --noconfirm --onefile --add-data "ffmpeg:ffmpeg" chmod +x dist/app_name* We are currently adding the signing and notarization of the app to our github workflow. The workflow build a successful app with the correct structure and is able to be run if we allow it past the MacOS firewall. We are signing the app like so: run: | BINARY_PATH="dist/app_name" IDENTITY=$(security find-identity -p codesigning -v | grep -E 'Developer ID Application|Mac Developer' | head -n1 | awk -F\" '{print $2}') echo "Using identity: $IDENTITY" security unlock-keychain -p "" build.keychain codesign --verbose=4 --force --options runtime --timestamp --entitlements .github/mac_build_tools/entitlements.plist --sign "$IDENTITY" "$BINARY_PATH" codesign --verify --verbose=4 "$BINARY_PATH" We then also move the binary around into an app structure and sign that as well like so echo "Moving contents to SedPlot.app" mkdir -p dist/app_name.app/Contents/MacOS mv "$BINARY_PATH" dist/app_name.app/Contents/MacOS cp .github/mac_build_tools/Info.plist dist/app_name.app/Contents echo -n "APPL????" > dist/app_name.app/Contents/PkgInfo echo "Signing App" codesign --verbose=4 --force --options runtime --timestamp --entitlements .github/mac_build_tools/entitlements.plist --sign "$IDENTITY" dist/app_name.app codesign --verify --verbose=4 dist/app_name.app codesign --display --entitlements :- dist/app_name.app If I upload the artifact and check its properties, everything looks good. It has the correct ID associated with it and shows as valid when I use codesign --verify on it. I start having issues when I move onto notarization, like so: cd dist echo "Zipping and checking the zip" ditto -c -k --keepParent app_name.app app_name.zip zipinfo -1 app_name.zip | head echo "$AC_API_KEY" > AuthKey.p8 SUBMISSION_ID=$(xcrun notarytool submit app_name.zip \ --key AuthKey.p8 \ --key-id "$AC_KEY_ID" \ --issuer "$AC_ISSUER_ID" \ --team-id "TEAM_ID" \ --output-format json | jq -r '.id') echo "Submitted notarization with ID: $SUBMISSION_ID" All of the print statements for errors look good at this point, and the submission ID shows up in my history when I query it. However, all 7 attempts that I have made to notarize this app hang for indefinite amounts of time. We are hoping to submit our tool for publication soon, and it would be helpful to know if there is an issue causing the hang on our end or if this is an issue with new developers. I have been reading around the forums and see some notes about this taking about a week until the system start to "learn" about our development team and our attempts to notarize. I also know that there is limited amounts that can be said about the backend of the notarizations step. What would be helpful is a few things: I would like feedback about if there is a fundamental flaw in our approach for signing and notarizing our application, so that we can identify it. I would appreciate some guidelines about how long to expect this notarization step to take until we can get notarization to finish within 10s of minutes, as we have a hard-coded 30 min wait time for the completion of the notarization in our workflow right now. It would be helpful to know how to check our logs, as requesting the logs for any of our attempts results in being told that the logs are not available yet. In case someone from apple is interested in this and wants to check, the most-recent submission ID (the one that I believe should be most-likely correct and valid) is 9ef24966-42a5-47db-a7e0-c6baf0310ac4 Thank you in advance!

I am trying to package a Filemaker 18 Runtime app. A week ago, I managed to get 90% of the way towards doing as much, using MS Copilot as a guide. Unfortunately, due to my confusion over the landing stage files, I decided to start the process from scratch. This time, I fell at the first stage: Code Signing my .app Bundle. The Terminal command: codesign --deep --force --verify --verbose \ --sign "Developer ID Application: ME (V********)" \ "/Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app" Returned the error: /Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app: bundle format unrecognized, invalid, or unsuitable In subcomponent: /Users/Me/Documents/Apps/MyApp/Runtime/MyApp/My App.app/Contents/Frameworks/FMWrapper.framework No matter how many separate elements within the bundle I sign, I encounter the same error message. A few days ago, the identical command worked first time. I would be obliged for any help you can provide. Thanks.

Hello, We are experiencing an issue with the notarization queue and would appreciate your assistance. A few days ago, we helped another team submit their app for notarization. However, that submission has been stuck in the “In Progress” state for about three days now. Unfortunately, this also seems to have caused our own team’s notarization requests to get stuck as well. We ran the following command to review the submission history: xcrun notarytool history --apple-id "xxx" --team-id "xxx" --password "xxx" Successfully received submission history. Partial results: id: 0bafa66f-4f47-4327-811f-a05481be5d0b status: In Progress id: 2d00b75a-a17a-44fc-afa1-71e0e39ec2cd status: In Progress It appears that one of these belongs to another team’s app we helped submit, and the other is our own submission. Both have remained In Progress for several days, and we are now unable to proceed with any new notarization requests. Could you please help us clear or reset the stuck notarization queue so we can continue our submissions? Thank you very much for your help!

Hello Quinn and Apple Developer Support, We are encountering an issue where our notarization queue appears to be stuck, and we would greatly appreciate your help. A few days ago, we assisted another team by submitting their app for notarization using our own Apple Developer account, because their own notarization attempts were getting stuck. However, the submission we made for them under our account has now been stuck in the “In Progress” state for about 5 days. Later, their own submission (using their account) was rejected after 2–3 days, but our submission for them (under our account) has never completed. Since then, all our subsequent notarization requests have also remained “In Progress”, which strongly suggests that the stuck submission is blocking our entire notarization queue. Here are the details from our submission history: xcrun notarytool history --apple-id "xxx" --team-id "xxx" --password "xxx" Partial results: id: 0bafa66f-4f47-4327-811f-a05481be5d0b status: In Progress id: 2d00b75a-a17a-44fc-afa1-71e0e39ec2cd status: In Progress The first ID is our own app’s submission. The second ID belongs to the submission we made for the other team. Both have been stuck in “In Progress” for several days, which seems abnormal. Could you please help us clear or reset the notarization queue for our account so that we can continue submitting our own apps? Thank you very much for your time and assistance! Best regards, gongcj

Hi everyone, I’m trying to notarize a macOS app for direct distribution in Xcode. The upload finished, but the notarization has been stuck on “In Progress” for hours. I’m not getting any emails or errors, and the status log in Organizer only shows the same “In Progress” message without any extra details. I tried reopening Organizer and creating a new archive, but it always ends up in the same state. Is this normal, or is there something I should check on my side? Any help would be appreciated. Thanks!

Unable to notarize Electron-based application. All notarization attempts fail with "The signature of the binary is invalid" for main executable and Electron Framework, despite passing local codesign verification. ENVIRONMENT: macOS: 24.6.0 (Sequoia) Hardware: Apple M4 Max (arm64) electron-builder: 26.0.12 Electron: 36.9.5 (also tested 37.10.2, 38.2.0) Certificate: Developer ID Application: AS LIVE MEDIA SP Z O O Team ID: 2KJ532SU3G Certificate validity: Oct 7 2025 - Oct 8 2030 PROBLEM: Every notarization submission fails with identical error for two binaries: Contents/MacOS/PresentClic Desktop Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework Error message: "The signature of the binary is invalid." Architectures affected: Both x86_64 and arm64 CRITICAL CONTRADICTION: ✅ Local verification PASSES: $ codesign --verify --deep --strict "PresentClic Desktop.app" Result: valid on disk, satisfies Designated Requirement ❌ Apple notarization service FAILS: Error: "The signature of the binary is invalid" LATEST SUBMISSION ID: 11e1a452-4ea7-4562-ac8e-5e76c39eeb6c Local verification output shows all components validated: Electron Framework: validated ✅ All helper apps: validated ✅ All frameworks: validated ✅ Main executable: valid on disk ✅ Authority chain: Developer ID Application → Developer ID CA → Apple Root CA ✅ Timestamp: Present ✅ Runtime Version: 15.4.0 ✅ CONFIGURATION: Entitlements (build/entitlements.mac.plist): com.apple.security.cs.allow-jit: true com.apple.security.cs.allow-unsigned-executable-memory: true com.apple.security.cs.disable-library-validation: true com.apple.security.cs.allow-dyld-environment-variables: true com.apple.security.automation.apple-events: true Standard device/network/file entitlements Build configuration: hardenedRuntime: true gatekeeperAssess: false (tested both true and false) entitlements and entitlementsInherit: properly configured TROUBLESHOOTING STEPS ATTEMPTED (ALL FAILED): ✅ Updated electron-builder from 24.13.3 to 26.0.12 ✅ Downgraded Electron 38 → 37 → 36 ✅ Tested x86_64 and arm64 separately ✅ Regenerated certificate via Xcode (new cert generated 23/11/2025) ✅ Configured App Store Connect API for notarization ✅ Tested multiple entitlements combinations ✅ Manual component-by-component re-signing ✅ Removed all metadata files (._ files) ✅ Tested both ZIP and DMG formats ✅ Automatic electron-builder notarization ✅ Manual notarization via xcrun notarytool ✅ Custom afterSign hooks for re-signing ✅ gatekeeperAssess true and false ✅ Clean builds (removed dist/ directory) ALL attempts result in identical failure. Local codesign verification ALWAYS passes. QUESTIONS: Why does local codesign --verify pass but Apple notarization service fails? Is there a known issue with Electron Framework notarization on macOS Sequoia + Apple Silicon? 3. Are there undocumented requirements for Electron apps that could cause this? 4. Could this be a bug in the notarization service for this specific configuration? ADDITIONAL CONTEXT: Multiple notarization attempts over 24+ hours Different certificates, configurations, architectures - all fail identically No similar reports found in forums or GitHub issues Application functions correctly when Gatekeeper is bypassed This is blocking production distribution to macOS users This appears to be either: A bug in Apple notarization service for Electron apps An incompatibility between electron-builder 26 + Electron 36/37 + macOS Sequoia + Apple Silicon The fact that local verification passes but notarization fails suggests the issue is with the notarization service validation logic, not the actual code signatures. REQUEST: Need guidance on resolving this issue. Standard documentation and troubleshooting steps have not resolved the problem. Thank you for any assistance. Staszek Pliszko

Error 7000 "Team is not yet configured for notarization" - Cannot notarize any apps I'm trying to notarize macOS apps for Developer ID distribution and consistently getting error 7000 on every submission. Error Details: { "status": "Rejected", "statusSummary": "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 } What I've tried: Completed enrollment verification Created new App Store Connect API key with Admin access Created fresh App-Specific Password Submitted via both API key and App-Specific Password authentication All submissions are accepted and uploaded successfully, but after processing they're rejected with error 7000 Technical Details: Active Developer ID Application certificate Hardened runtime enabled Apps are properly code-signed (codesign -vvv passes) Behavior: Over 15 submissions since December 2nd - ALL rejected with the same error 7000. The submissions upload successfully and show "In Progress" for extended periods (sometimes hours) before eventually being rejected. Questions: Has anyone encountered error 7000 and resolved it? What was the fix? Are there any account settings or agreements required specifically for notarization that aren't obvious in the developer portal? Should I contact Apple Developer Support directly, or is there a self-service solution? Any guidance would be greatly appreciated.

Dear support team, is it possible to rename a notarized ZIP package and not to loose the notarized status? One of our ZIP package contains resources and binaries which are code signed. The archive itself is accepted after submitting and uploading during the notarization process (online notarization). Unfortunately, the ZIP cannot be stapled (offline verification). So, is the filename part of the notarized ZIP package or can a ZIP package be renamed? Best regards, Stefan

i encountered an error when i distributing my app on xcode 26.0.1. Below is error log. { "logFormatVersion": 1, "jobId": "ed2b622b-61f6-4c8a-90b7-7c3cdfbafc7a", "status": "Rejected", "statusSummary": "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, "archiveFilename": "mychm.zip", "uploadDate": "2025-12-10T01:50:34.198Z", "sha256": "b61e224154823c8e06c3db904d67a78969f1564c7602f1fa77335fdd12a8d22b", "ticketContents": null, "issues": null }

I'm currently observing a problem similar to this thread https://developer.apple.com/forums/thread/737334 The difference is that this is happening after updating a system extension. Basically same error, sysextd complains it can not check that the system extension is notarized: macOS Error 3 + Error code=-67050. I think macOS (Sequoia 15.3.2 or 15.7.2 if it matters) is wrong in this case for the following reasons: when using spctl assess -t install, the system extension is reported to be correctly notarized. when restarting the Mac, the updated system extension is correctly checked and staged. if I run spctl assess before sysextd tries to check the system extension, it works. I'm currently thinking of 2 reasons why the check does not work: sysextd is somehow trying to work with a cached assessment that has become invalid after the system extension was updated. macOS needs way more time between the update of the files and the request to update the staged extension. I tried adding a 5-second delay. This does not seem to work or at least reliably. I tried just touching the system extension, no positive result. Unfortunately, in macOS Sequoia, it is not possible anymore to reset-default using spctl and see if it solves the issue, at least the next time the update is performed. [Q] Is there some magic operation that would help macOS correctly check the notarization of an updated system extension?

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.

Notarization step fails: New AppID and password created: xcrun notarytool submit “.dmg” --apple-id “” --team-id “” --password “” --verbose --wait Error: HTTP status code: 401. Your Apple ID has been locked. Visit iForgot to reset your account (https://iforgot.apple.com), then generate a new app-specific password. Ensure that all authentication arguments are correct. I have reset app password many times, not result. Codesigning completes normally: Mac OS 11.5.2 Xcode 13.2.1

This has been going on for at least a couple of hours for us: notarizing doesn't complete. Our last job ran for over 90 minutes before CircleCI timed it out. We're using xcrun notarytool submit with the --wait option; it contined to say "Current status: In Progress" for, as I said, 90 minutes or so. (Normally it takes about 70 seconds.) https://developer.apple.com/system-status/ says everything is normal. This does not seem to be the case for us. 😄

Hi everyone, Native Instruments is encountering a critical issue with the notarization process. The xcrun notary submit command appears to be stuck and is not completing, preventing us from notarizing our apps. Specifically, the command hangs indefinitely. This issue started today. We've already tried the following troubleshooting steps: Cancelling and re-running the command Checking my internet connection Checking the Apple System Status page Cleaning the build folder using a different machine This is a major blocker for our company, as it's preventing from from us from testing and releasing some of our products. It seems to be a similar issue as reported in https://developer.apple.com/forums/thread/772542?page=2. Has anyone else experienced xcrun notary submit getting stuck like this? Any insights or suggestions would be greatly appreciated. I'm particularly interested in knowing if there are any known issues with the notarization service currently. Details about my setup: Xcode Version: 16.1 macOS Version: 14.7.1 App Type: macOS app Thanks in advance for your help!