I have been waiting well over 24 hours for my notarization to occur, and nothing - no "we might take a while if it is your first app" or any mention of that in the docs. So why is it taking this long? What's the hold up??? If this is part of the process, Apple should officially document it, so developers aren't left resubmitting and wondering. This is not a good first experience with the developer program. Successfully received submission history. history -------------------------------------------------- createdDate: 2026-01-07T05:22:34.038Z name: URSAMajorSpaceStationSST206_v1.0.0.zip status: In Progress -------------------------------------------------- createdDate: 2026-01-06T01:55:05.144Z name: URSAMajorSpaceStationSST206_v1.0.0.zip status: In Progress -------------------------------------------------- createdDate: 2026-01-05T20:55:50.624Z name: test.zip status: Invalid -------------------------------------------------- createdDate: 2026-01-05T20:32:52.944Z name: URSAMajorSpaceStationSST206.vst3.zip status: In Progress -------------------------------------------------- createdDate: 2026-01-05T19:37:15.426Z name: URSAMajorSpaceStationSST206.component.zip status: In Progress -------------------------------------------------- createdDate: 2026-01-05T18:37:43.101Z name: URSAMajorSpaceStationSST206.component.zip status: In Progress

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.

I am submitting .dmg notarization requests from Sequoia 15.7.3 using xcrun submit. My developer certificate was created in the last two weeks and is valid. I have had some successful notarizations already so I know that my configuration is correct. However, for the last 48 hours all of my submissions are stuck at 'in progress'. Is there an issue with the notarization service on Apple's side?

In an AppleScript applet, compiling and exporting in Script Editor replaces a custom icon with the default. To retain a custom icon, it is necessary, after exporting, to use Finder's "Get info..." to copy the icon from another file and paste into the icon for the applet. The custom icon is stored in the "Icon?" file, located in the root of the applet bundle. The applet can then be signed and notarized. With macOS Tahoe, that procedure no longer works. That is because the notarization process now wipes the "Icon?" file. The file remains in place but has zero size. Thus Finder shows the default applet icon. Does anyone know of a way to provide a custom icon for a signed and notarized AppleScript applet ?

We package a nightly build of our application for distribution. About 1 month ago, this package has started showing the "Apple could not verify 'Application' is free of malware" message. This only happens to our development branch package. We run the same pipeline with the same signature for our stable branch and the stable package does not show this message. $ codesign -dv --verbose=4 KiCad.app Executable=/Applications/KiCad/KiCad/KiCad.app/Contents/MacOS/kicad Identifier=org.kicad.kicad Format=app bundle with Mach-O universal (x86_64 arm64) CodeDirectory v=20500 size=51931 flags=0x10000(runtime) hashes=1612+7 location=embedded VersionPlatform=1 VersionMin=722432 VersionSDK=983552 Hash type=sha256 size=32 CandidateCDHash sha256=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d CandidateCDHashFull sha256=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d03cbe70641719fd1ced3395b Hash choices=sha256 CMSDigest=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d03cbe70641719fd1ced3395b CMSDigestType=2 Executable Segment base=0 Executable Segment limit=3915776 Executable Segment flags=0x1 Page size=4096 CDHash=4f15435c1d3cc056a83432b78a2f6acae8fb0e6d Signature size=9002 Authority=Developer ID Application: KiCad Services Corporation (9FQDHNY6U2) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Dec 19, 2025 at 5:21:05 AM Info.plist entries=17 TeamIdentifier=9FQDHNY6U2 Runtime Version=15.2.0 Sealed Resources version=2 rules=13 files=37238 Internal requirements count=1 size=176 codesign --verify --verbose=4 KiCad.app <snipped all libs validated> KiCad.app: valid on disk KiCad.app: satisfies its Designated Requirement % spctl --assess --verbose=4 KiCad.app KiCad.app: accepted source=Notarized Developer ID We distribute this via dmg. The notarization ticket is stapled to the dmg and the dmg opens without warning. Any help would be 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

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

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 }

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've been trying to have an app I've built notarized by Apple. The processing hangs there for hours just waiting. I even tried with a tiny 1KB test file, it has been stuck for 25+ minutes, and I have 7 real submissions stuck for 24+ hours. Any Apple representative can help please? I need to publish and release my app asap.

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.

Hi, This is my first time notarizing an app with Developer ID. I have submitted multiple notarization requests, and all of them have been stuck in "In Progress" status. The oldest one was submitted over 24 hours ago. Is this normal for first-time submissions? How long should I wait before contacting support? Thanks!

Today, I used xcrun notarytool submit to upload my packaged Electron app for macOS—once as a .zip file and once as a .dmg—for Apple notarization. However, both submissions have been stuck at "Current status: In Progress" for several hours now. I’ve also checked the status using xcrun notarytool info, and it keeps returning status: In Progress. Could someone please help me understand what might be going wrong? This is quite urgent—if a technical support engineer or anyone from the team could take a look, I’d be glad to provide the UUIDs of my notarization requests.

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

Can someone please explain why Mac app packaging is so farcically convoluted? Windows app packaging can be picked up in an hour or so. But I've spent longer trying to fathom how to package the Mac version than I did building the app. And it's not done with me yet. Every single line of code requires a deep dive into a new, unrelated skillset. So, it’s sidebar after sidebar. Kafka’s ‘The Trial’ comes to mind. Why does it have to be like this?

Hi, I'm currently at 19 hours waiting for notarization. My dev account is new and this is the first time I'm submitting anything to be notarized. I've gathered from my research that this is normal (unfortunately). I figure the only thing I can do is wait, but is there any way for me to know if I'm waiting for a human to manually review it? I was going to file a support request, but I saw that they won't be responding to any support requests until after their Thanksgiving break, and I assume nobody is manually reviewing notary submissions for the next week+. I attached the submission below, thanks! createdDate: 2025-11-21T21:17:10.082Z id: c9746d42-1dc7-4641-aec1-62c6cedff1a2 name: ***********.zip status: In Progress