General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums 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 forums 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 forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums 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"

Hello, we have a product package which is structured like this: / Installer.pkg / Distribution / Main Component.pkg / Scripts / preinstall / postinstall / helper [ Mach-O executable ] / Payload / Application Bundle.app / Another Component.pkg ... The helper is our custom CLI helper tool which we build and sign and plan to use it in pre/post install scripts. I'd like to ask if we need to independently notarize and staple the helper executable or just the top level pkg notarization is sufficient in this case? We already independently notarize and staple the Application Bundle.app so it has ticket attached. But that's because of customers who often rip-open the package and pick only the bundle. We don't plan to have helper executable used outside of installation process. Thank you, o/

Hello, I'm experiencing a persistent issue where all my notarization submissions remain stuck in "In Progress" indefinitely. This has been happening for the past several days, affecting multiple submissions. Environment: macOS 26.2 (Build 25C56) Using xcrun notarytool submit for submissions Team ID: M3FN25UQK2 Timeline of the issue: Starting from January 2nd, 2026, my submissions began getting stuck in "In Progress" As of January 6th, I have 6+ submissions that have been "In Progress" for 24-72+ hours Prior to this, notarization was working normally (I have multiple "Accepted" submissions from January 1st) What I've tried: Verified my Developer ID Application certificate is valid and properly installed Checked Apple Developer System Status page (shows "Operational") Verified code signatures using codesign -vvv --deep --strict Contacted Apple Developer Support (no response yet) Checked my Apple Developer account for any pending agreements or warnings (none found) Is there any known issue affecting notarization processing, or could my Team ID be rate-limited/flagged? Any guidance on how to resolve this would be greatly appreciated. Thank you!

Hi everyone, Has anyone seen notarization behave like this? We have one specific app (let’s call it App A) with a Network Extension system extension. Whenever we submit App A for notarization: • Its submission stays “In Progress” indefinitely • The provisioning profile for its system extension becomes Invalid on its own • All our other apps suddenly fail notarization • And the whole team immediately gets: StatusCode 7000 – “Team is not yet configured for notarization.” Apple Support restored notarization once(Case 102738171569), and we confirmed other apps notarize fine — until we submit App A again, which instantly triggers the same team-wide block. This cycle has repeated twice. We verified: • Hardened runtime • Proper system extension signing • No private API usage • No get-task-allow • No ATS violations What’s confusing is that this doesn’t look like a normal notarization rejection. Normal failures don’t invalidate provisioning profiles or disable notarization for the entire team. It feels more like an automated security heuristic or misclassification. My questions: 1. Can a single app or system extension trigger an automated team-wide notarization disable? 2. Can an entitlement or NE configuration issue cause StatusCode 7000 instead of a standard rejection? 3. If this could be a false positive, is there a specific team at Apple who can manually review/clear it? Any insight would be greatly appreciated.

Notarization Rejects Valid Developer ID Certificates - Apple Infrastructure Issue? Environment macOS: 15.6.1 Xcode: 26.0.1 Architecture: arm64 (Apple Silicon) Team ID: W---------- Certificate Status: Valid until 2030 (verified on developer.apple.com) Problem Apple's notarization service consistently rejected properly signed packages with error: "The binary is not signed with a valid Developer ID certificate." Despite: ✅ Valid certificates on developer.apple.com ✅ Local signing succeeds (codesign --verify passes) ✅ Proper certificate/key pairing verified ✅ Package structure correct Failed Submission IDs September 2025: adeeed3d-4732-49c6-a33c-724da43f9a4a 5a910f51-dc6d-4a5e-a1c7-b07f32376079 3930147e-daf6-4849-8b0a-26774fd92c3c b7fc8e4e-e03c-44e1-a68e-98b0db38aa39 d7dee4a1-68e8-44b5-85e9-05654425e044 da6fa563-ba21-4f9e-b677-80769bd23340 What I've Tried Re-downloaded fresh certificates from Apple Developer Portal Verified certificate chain locally Tested with multiple different builds Confirmed Team ID matches across all configurations Verified no unsigned nested components Waited 3 months for potential propagation delays Verified all agreements are current and accepted Re-tested with minimal test package - same error persists Local Verification # Certificates present and valid security find-identity -v -p codesigning | grep "Developer ID" 1) XXXXXXXXXX "Developer ID Application: <<REDACTED>> (W----------)" 2) XXXXXXXXXX "Developer ID Installer: <<REDACTED>> (W----------)" # Signing succeeds codesign --verify --deep --strict --verbose=2 [app] → Success Question This appears similar to thread #784184. After 3 months and ensuring all agreements are signed, the issue persists with identical error. The certificates work for local signing but Apple's notarization service rejects them. Could this be: Backend infrastructure issue with Team ID W----------? Certificate not properly registered in Apple's notarization database? Known issue requiring Apple Support intervention? Has anyone else experienced valid Developer ID certificates being rejected specifically by the notarization service while working locally?

I've submitted my app four times, each time waiting a few hours for something to happen, then reducing the file size of my *.dmg and trying again. The first two seemed to have completed after 36 hours, but I no longer have that specific signed binary (and its a much smaller binary now anyway). The latest two are still "In Progress" and its almost been 48 hours. I know my process isn't wrong, and my app isn't somehow incorrectly built or being denied because two were accepted. The outage page shows green for the notary tool (https://developer.apple.com/system-status/) so I'm not sure what the hold up is.

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

I am trying to notarize a VS-Code Fork Electron based app for non-App store distribution. Its just same for more than 24hrs, it just says processing. Looking for someone who could help me. Thanks

Hello Apple Developer Team I am an independent iOS developer creating highly specialized applications for a very small private audience of fewer than ten users These applications are tightly coupled with custom hardware that I design and manufacture myself for example automotive air suspension control systems Due to the extremely narrow scope and non commercial nature of these apps maintaining a full Apple Developer Program membership is economically impractical The applications are not distributed publicly are not monetized and are used only by a small group of people who share the same technical hobby All application code is written entirely by me There are no copyright violations no private API usage no hidden functionality no tracking and no malicious behavior The apps do not compromise iOS security do not harm users and do not discredit Apple or the iOS platform The software only functions when paired with proprietary hardware under my control At present the only viable way to install these apps is by using free developer certificates with a seven day expiration period This creates a significant usability burden Users must constantly re sign and reinstall the apps Non technical users frequently make mistakes during this process which leads to frustration and discourages experimentation learning and hardware innovation I would like to propose that Apple consider a limited and tightly controlled homebrew style distribution option where non App Store applications could be installed only after Apple review and approval similar in spirit to TestFlight or app notarization This could include strict limitations such as a very small number of allowed users no monetization no public discovery and clear labeling as private experimental or hardware coupled software Apple would retain full control over approval enforcement and revocation at all times Such a mechanism would preserve the security and trust model of iOS while supporting independent engineers hardware developers and advanced hobbyists It would reduce incentives for unofficial sideloading and encourage innovation at a grassroots level without weakening platform safety I deeply respect Apple’s focus on security quality and user trust This proposal is not about bypassing the App Store but about enabling a controlled reviewed and extremely limited path for legitimate non commercial hardware specific applications I hope this message can receive timely consideration and that if such an approach aligns with Apple’s platform goals it could be explored for inclusion in upcoming iOS versions where feasible Thank you for your time and for supporting the developer community Best regards Anzor Tekuev Independent iOS Developer

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.

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 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 facing an issue with my macOS app after code signing and notarization. The app is signed with my Developer ID and notarized using xcrun notarytool. Everything works fine on the machine where the signing was done — Gatekeeper accepts it, no warning appears, and codesign/spctl checks pass. However, when running the same .app on other Macs, users receive a Gatekeeper warning saying the app is "malicious software and cannot be opened". The signature is valid and the notarization log shows status: Accepted. What I've tried: Verified signature with codesign --verify --deep --strict --verbose=2 Checked notarization status via xcrun notarytool log Assessed Gatekeeper trust with spctl --assess --type execute Everything passes successfully on the development machine. Why would the app be treated as malicious on other systems even after notarization? I'm happy to share logs and technical details if needed.

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

App Notarization got stuck, showing In-Progress from last 24 hrs. This is really frustrating. Can anyone plz update on this?

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.

Hey everyone, I’m trying to notarize a macOS app for direct distribution through Xcode, and the notarization step has been stuck on “In Progress” for hours now. The upload completed fine, but since then I haven’t gotten any feedback at all: no email, no notification. Organizer just shows: Status: In Progress I’ve tried closing/reopening Organizer, and even re-archiving the app, but it always sits in the same state. Is this just a delay on Apple’s side, or is there something I might have misconfigured? Any tips on how to get more insight into what’s going on? Thanks!

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!

Is the Notary service unavailable again? The system-status page shows it as being green but I am back to receiving the same error as previously which fixed itself once the notary service went green again and I am unable to notarize and staple my Distribution PKG.

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.

During the release of our macOS App, we encountered the following issue: We need to support dynamic code loading of WebAssembly (wasm) inside our App, mainly by loading WebAssembly (wasm) binary modules. We discovered a problem: a wasm file is neither an executable nor a bundle, so it cannot be code-signed. Since our App needs to pass notarization, we have not set the com.apple.security.cs.allow-unsigned-executable-memory entitlement. Without setting com.apple.security.cs.allow-unsigned-executable-memory, loading a wasm module results in an “unsigned code” error that causes the process to crash. Could you please advise on what we should do to avoid this problem? Is it possible to apply for a special entitlement to allow com.apple.security.cs.allow-unsigned-executable-memory?