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 If your notary requests are stuck in the In Progress state, see my reply here. If your notary requests are failing with Team is not yet configured for notarization, see my reply here and also the follow-up here. 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"

Following Quinn's advice in https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022, I have opened a Developer Programs Support case and am posting here with the case number. Case number: 103005753388 Team ID: 6PG3USG4A9 Notarization worked for this team: three submissions were accepted on 21 and 22 October 2026. Since the evening of 22 October every submission is rejected with status code 7000, "Team is not yet configured for notarization". The rejection logs have "issues": null and no ticket. Nothing changed on our side between the accepted and the rejected submissions: same app, same Developer ID Application certificate, same Apple ID with an app-specific password, same xcrun notarytool. The team is otherwise active; our iOS app is live on the App Store. Accepted: 49e6f112-fd07-40ca-b908-6b8126d2d137 (2026-10-21) fcaae8e3-84e3-493b-a747-297f0ab60c79 (2026-10-21) ab12ace8-743b-47fa-955b-e030feabce11 (2026-10-22) Rejected with 7000: 1731bdca-bf9c-417c-a65a-4f38c619897d (2026-10-22) 245112d4-8422-4b1d-bd73-d7718f994378 (2026-10-22) 52c784f3-ca5f-4d42-964d-2308192c5515 (2026-10-23) 2863f755-7bc4-42ea-b117-1eedcc7fcade (2026-10-23) 33996a21-59af-455e-ad22-11ef01f39fa4 (2026-11-03) b498ee7c-a1bf-46b4-bbb2-e8b3d643fe85 (2026-11-03) We distribute a Mac app outside the Mac App Store, and a release is waiting on this. Could someone from Developer Programs please look at the team's notarization status, or tell us what is missing on the account? Thank you.

Account Holder 的姓名是：Zhou Zhou,以及 zhou.zhou@cn.mcd.com 是 Admin。 日志中 issues: statusCode: 7000 statusSummary: Team is not yet configured for notarization. Team ID: CT4HBGAZ7B Team name: M (Nanjing) Digital Technology Co., Ltd. Apple ID used: zhou.zhou@cn.mcd.com 最近一次提交是2026年11月3日。同时是首次公正

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue. All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating. I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago: error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>" ), NSLocalizedDescription=The network connection was lost., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null)

Hello, All of our notarization submissions except one are stuck in "In Progress" with no terminal state. I would appreciate it if someone could confirm whether they are still queued, or whether something on our side is blocking them. Team ID: 7MK3979GD2 Account: individual, newly enrolled; Developer ID Application certificate issued 2026-10-29 Tool: xcrun notarytool submit with an App Store Connect API key (Team Key, Admin role) Auth/upload work fine: notarytool info returns "In Progress"; notarytool log says the log is not yet available. Submissions (all times UTC): created submission id file status 1 2026-10-29T23:59:53Z 10b84260-955d-4ed5-a7ad-aa7484228427 GsGPT.zip In Progress 2 2026-10-30T01:24:44Z 2fa44ce1-345e-467b-8ea9-97362be6f45f GsGPT.app.zip Accepted (~2.5 min) 3 2026-10-30T01:28:09Z 097fee47-6fec-4645-b4af-f8250820dc8f GsGPT-mac-arm64-8.31.0.dmg In Progress 4 2026-10-30T09:21:25Z 9f4ec58b-d116-4e84-b859-9281ec0e5b92 GsGPT.app.zip In Progress 5 2026-10-30T11:05:58Z d0b9cebb-7795-4699-94b7-2c040fd06028 GsGPT.app.zip In Progress Notes: Submission #2 was accepted in about two and a half minutes, and its log reports "status": "Accepted", "issues": null. All submissions come from the same account, the same certificate and the same build job, so I believe the signed content is compliant. I have not resubmitted the same content. Later attempts are different artifacts from the same pipeline (app zip and DMG). App: GsGPT, an Electron-based macOS desktop app (bundle id cc.ekoaku.gsgpt, version 8.31.0, arm64), signed with Developer ID Application with hardened runtime, to be distributed outside the App Store as a notarized, stapled DMG. I understand that first notarizations from a new account may undergo additional screening. The oldest stuck submission has now been waiting over 13 hours, so I would just like to know whether these are still being processed or have been held. Could you please confirm the current state of Team 7MK3979GD2's submissions and let me know if anything on our side needs action? I am happy to provide any logs or additional details. Thank you very much for your time.

Hi Apple team, I have a recently created dev account and submitted two different 20-30 mb .apps for notary through the notary tool. I have read that this should only take minutes at this size of an app but both have been stuck in progress for almost 24+ hours. Below are the UUIDs of the notary submissions. Also I tried re-submitting but these are also stuck in progress. Successfully received submission history. history -------------------------------------------------- createdDate: 2025-09-26T11:46:32.643Z id: 9714758e-e216-496d-80f8-422f77011ebe name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T21:48:46.161Z id: c2a81300-c903-4277-8ef3-70205a690c76 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T18:24:36.205Z id: 42742be1-c7e5-4483-a2c5-95e89086d070 name: <>.zip status: In Progress -------------------------------------------------- createdDate: 2025-09-25T16:35:09.059Z id: a404256e-40c2-4dca-97fc-983e70ea4b7b name: <>.zip status: In Progress

My macOS app notarized in 22-24 seconds on every release for months under my previous Developer ID team. I often shipped several releases a day, even with minor changes. Since moving to a new Developer ID team (FPRW433858) on Oct 25, every submission of the same app is held for hours: 85da38d3-1874-458a-9bb5-e4656c770037 (Oct 25 19:09 UTC): still In Progress when my CI job hit its 6-hour limit; accepted later. e4bf6e71-58dc-4710-abc0-ba0b459b099f (Oct 29 17:02 UTC): Accepted after 1h56m. Log: "issues": null, "Ready for distribution". Useless because GitHub CI crashed on it. 0c21d8be-cd60-45c0-b990-f7ebb616201a (Oct 29 19:02 UTC): In Progress, 1.5+ hours and counting. Same source, same build pipeline, same Sparkle framework, hardened runtime, inside-out signing. The only change is the team. The build is clean, and you have accepted it twice. I've read the "some uploads are held for in-depth analysis" answers. That is not an answer I can work with. A bugfix release now takes hours or fails outright on CI time limits (6h on github), for an app you have already accepted twice under the new Dev ID and countless times under the old Dev ID. I need concrete answers: Is team FPRW433858 flagged for in-depth analysis, and why? When does that end? After how many accepted submissions, or on what date? Is there anything I must do on my side? If so, what exactly? If nothing on my side causes this, please clear the team or escalate it to someone who can. I cannot accept to wait hours/days on app releases that are straightforward otherwise.

Hello Apple Developer Support, All notarization submissions for my macOS application are being rejected with the following error: "Team is not yet configured for notarization." Both DMG and PKG submissions have failed. Recent submission IDs: a65c01f3-2897-42c5-a3a1-39583a771df0 9cfc86e0-00fd-4c7e-ae94-1f9a647eb966 Could you please check whether my Developer Team is properly provisioned for the Apple Notary Service and escalate this to the team responsible for notarization provisioning? This issue is blocking the release of my macOS application.

Our organization team (OMNIX TECH LTD, Team ID 8PKGR2HTA7, enrolled 6 June 2026) has never been able to notarize. Every notarytool submission since 9 June 2026 is rejected with statusCode 7000 "Team is not yet configured for notarization", including a 33 KB test zip containing only /bin/ls (latest: baacf441-da6e-4cbf-8b90-04a9e7bc179c, 16 Oct 2026, minutes after accepting the October 2026 Program License Agreement). Signing with our Developer ID Application certificate works; the notary service never evaluates the upload. An earlier case (102913653946, 30 June 2026) got no resolution. A new case 102998191235 was filed today under Development and Technical / Other Development or Technical Questions. Could someone confirm the team has been enabled for the notary service, or tell us what is missing on our side?

Requesting staff review. Team ID: RMHZ6VXS4C (individual, Account Holder, India). Case ID: 103000814312. What happened My Apple Developer Program membership lapsed. I renewed it on 18 October 2026. developer.apple.com/account → Membership details now shows the renewal: Renewal date October 18, 2027, annual fee US$99. So the renewal is recorded on my account. Even so, App Store Connect still shows "Your Apple Developer Program membership has expired," and the agreement banner that used to be there disappeared without anything to accept. App Store Connect → Business → Agreements lists no agreements at all. Notarization has failed the whole time. Every notarytool call returns: 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. This happens with xcrun notarytool history as well as submit, using an app-specific password and the Team ID above. Last checked 23 October 2026. What I have checked The US$99 renewal was charged on 18 October 2026. I am the Account Holder, and there is no pending agreement to accept anywhere on developer.apple.com/account or in App Store Connect. My Developer ID Application certificate for this team is valid; code signing works, only notarization is refused. I corrected my membership address (city/state) on 23 October in case an identity check was holding the renewal. Impact I distribute a macOS app outside the App Store under Developer ID. Without notarization, new users get Gatekeeper's "Apple could not verify" block, so I am shipping unnotarized builds as a stopgap and my launch is on hold. I emailed Developer Support a week ago (case above) and have had no reply; the contact form offers no phone or callback option for India. Ask Could someone on the Developer Program team check why this team's membership shows as renewed on the account page but expired for App Store Connect and notarization, and push it through, or tell me what is still missing on my side? Happy to provide the receipt and logs.

We ship an Endpoint Security system extension inside a host app. On one managed Mac (macOS 26.6.2, build 25G83, arm64) the extension can't be activated, while the same package works on other Macs with the same macOS build. WHAT WE SHIP AND HOW IT'S NOTARIZED Host app: ElasticEndpoint.app (co.elastic.endpoint), Developer ID signed, notarized, with the ticket stapled (codesign -dvv shows "Notarization Ticket=stapled"). System extension: ElasticEndpoint.app/Contents/Library/SystemExtensions/co.elastic.systemextension.systemextension (co.elastic.systemextension), same Team ID, Developer ID signed. It was part of the same notarization submission as the host app but has no ticket stapled to itself (stapler validate says "does not have a ticket stapled to it"). Delivery: a root-owned service extracts the app into /Applications with tar (so no quarantine attribute) and then runs "ElasticEndpoint --install" as root to request activation. Versions: first reported on 9.0.8, and the same on 9.5.1. 9.1.0 and 9.5.4 have the same layout. Public packages: https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.0.8-darwin-aarch64.tar.gz , with the app in data/elastic-agent-*/components/endpoint-security-resources.zip -> 64_Bit_Elastic_App_macOS.tgz. The 9.5.1 package is at the same URL pattern. SYMPTOMS ON THE AFFECTED MAC syspolicyd: [com.apple.syspolicy:default] Unable to parse ticket. syspolicyd: [com.apple.syspolicy:default] error registering ticket: -1 sysextd: Error checking with notarization daemon: 3 sysextd: bundle code signature is not valid - does not satisfy requirement: -67050 code failed to satisfy specified code requirement(s) sysextd: co.elastic.systemextension: extension failed to validate! uninstalling... "spctl -a -vv -t execute" prints "accepted / source=Developer ID", not "Notarized Developer ID", for our app and for an unrelated vendor's notarized app. Healthy Macs print "Notarized Developer ID". "syspolicy_check distribution" reports a notary error, and "codesign -R="notarized" --check-notarization" fails. RULED OUT The stapled ticket (Contents/CodeResources, 1716 bytes, SHA-256 e8679543f9934bd43b127210c10348f764b78a53360ec515ccbcb4afc0920e28) is byte-identical on the affected Mac, on a healthy Mac, and in the official 9.5.1 package. The network: TLS to api.apple-cloudkit.com and valid.apple.com works, there's no proxy, and the clock is correct (sntp offset 0.03 s). WHAT A HEALTHY MAC DOES (fresh macOS 26.6.2 VM, app without quarantine) Running the app's binary produces: "Extracting ticket from bundle" -> "Registering stapled ticket with system" -> CloudKit fetch -> "Inserting ticket". /var/db/SystemPolicyConfiguration/Tickets gains rows in the "tickets" and "hashes" tables, including the extension's cdhash. sysextd then validates the extension locally ("isNotarized = 1"), so the extension's notarization is established through the host app's ticket. If I truncate CodeResources on the VM, I get the same "Unable to parse ticket" / "-1" lines and then -67050. So on the affected Mac, ticket registration seems to fail even though the ticket file is intact. A third-party write-up describes the same signature on one Mac ("stapler validate" exit 65 for every vendor's app): https://github.com/fsnow/cst/blob/main/docs/implementation/NOTARIZATION_TICKET_ISSUE.md They report that none of these helped: resetting the Tickets database with SIP off, restarting syspolicyd/trustd, a fresh user account, or OS upgrades up to macOS 27.0.1. QUESTIONS What can make syspolicyd fail to parse or register a valid stapled ticket on a single Mac? Is there a supported way to repair ticket registration without erasing the Mac? Is it expected that sysextd validates nested code (the extension) only against the local ticket database, with no online fallback? What should we collect for you: a sysdiagnose, or a Feedback Assistant report? [FB number if filed]

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).

2022-07-24 16:43:30.074 *** Error: Notarization failed for '/var/folders/r1/3j8rdbl95l9csz588j1nc6xc0000gn/T/electron-notarize-gGm3Fr/git-icons.zip'. 2022-07-24 16:43:30.075 *** Error: You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881 You do not have required contracts to perform an operation (-19208) { NSLocalizedDescription = "You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881"; NSLocalizedFailureReason = "You do not have required contracts to perform an operation"; }

Hi — submissions from my account have been stuck "In Progress" for 3+ days, and as of today even a tiny control probe is being held, while an identical probe submitted two days earlier was accepted in under an hour. Notary service status is green. This is blocking our first signed beta release. Team ID: 35L272URMA (individual account, enrolled 2026-10-16) App submissions (all still In Progress): fbed8a42-a43e-436f-bc99-49262ee4189d, 2026-10-16 04:55 UTC 090bd775-a288-435a-a2c6-95253e36b4cf, 2026-10-16 05:22 UTC (current build) 698e88b0-e111-41c0-8a5b-4da74aff6599, 2026-10-16 08:22 UTC ec3bd245-9306-4b56-b799-3d84782fc833, 2026-10-17 05:43 UTC App: "Octopus Beta" - Developer ID-signed, hardened-runtime, darwin-arm64 Electron app (131 MB zip, ~10k nested files, submitted as ditto zip, not DMG). Tooling: electron-builder 26.15.2 / notarytool (Xcode CLT) / macOS 26. Control probes (same account, same credentials, same flow, ~10 KB signed test apps): 5dda20a1-3f03-4757-90bb-52fce39427f3, hello.zip, 2026-10-16 09:54 UTC, Accepted in under 1 hour 7889bf07-f4ba-4aa8-9b77-10b504ce9a18, hello2.zip, 2026-10-18 15:29 UTC, STILL In Progress 17+ hours later The first probe passing quickly while an identical second probe now hangs suggests this is no longer just in-depth analysis of the large app. Either the whole account is now being held, or there is a service-side backlog window. Could you confirm which, and whether anything on our side is contributing? We have stopped resubmitting per the guidance in thread/814841. Happy to provide artifacts. Thank you!

I'm trying to notarize a macOS app under my individual team, WPJCQG3698. I enrolled in the Apple Developer Program in June 2026. Membership is active, all agreements are accepted, and the Developer ID Application certificate is valid. All 12 notarytool submissions since June 20 have failed the same way: statusCode: 7000 statusSummary: Team is not yet configured for notarization issues: null I'm authenticating with an App Store Connect team API key. Authentication and upload succeed every time, then the submission gets rejected in under a minute. As a control I copied /bin/ls, signed the copy with the same certificate, and submitted that. Same error, so it doesn't look app-specific. The latest submission is 03369f51-9929-4ec1-8940-e488cf1d00a7, uploaded 2026-07-10T08:30Z. Developer Programs Support case 102922992178 has been open since June 23 and was escalated to engineering on July 7. I retried today and nothing changed. This has been blocking our macOS release for three weeks now and I'm out of things to check on my side. Have I missed an account-side step, or is this something only Developer Programs Support can fix for the team?

Our team's notarization has been fully blocked since Oct 9 with statusCode 7000 "Team is not yet configured for notarization" (issues: null) on every submission - app, .pkg, and standalone binaries alike. Team ID: 7AVQDHV488 (US organization) Critically, this is a REGRESSION, not a first-time setup problem. The exact same binary that Apple ACCEPTED on Oct 9 returns 7000 when re-submitted, with nothing changed on our side: 9a603fde-f005-4803-ba0e-9f7ce0a61ac4 - ACCEPTED Oct 9 2f27d7eb-2530-46d2-8439-d12664233a3d - the SAME binary, re-submitted Oct 12 -> 7000 eddbcd23-c423-4e7f-a95b-15346e2be440 - our app (.zip), Oct 12 -> 7000 846be3bc-b90b-45fc-afae-1081a23c97b6 - our .pkg, Oct 12 -> 7000 Everything on our side checks out: Membership active (renews Aug 2027) Apple Developer Program License Agreement signed Oct 8, 2026 Signing valid: codesign --verify --deep --strict passes; the .pkg is signed with "Developer ID Installer: NUREV.IO Inc. (7AVQDHV488)" and a trusted timestamp Because Apple returns issues: null, the rejection happens before any binary inspection, which points to an account-configuration issue on Apple's side rather than our code or signing. I filed support case 102991640706 on Oct 9 and have only received the automated acknowledgment (3+ days, no human response). This is blocking our product launch. Could an Apple engineer please look into this, or route it to the team that can re-enable notarization for 7AVQDHV488? Happy to provide any additional submission logs. Thank you.

Hello, My notarization submissions have all stayed "In Progress" and produced no log. The first one has been waiting for almost a week: 07701908-cfc9-416b-93d8-783b50cb25c2, created 2026-09-29T18:11:38Z (the earliest) 11ab0aff-70d2-4cc6-a26f-8169e2f2a749, created 2026-10-04T14:23:28Z 99bfd78f-d4be-488a-aa1a-b6a81931d1c5, created 2026-10-05T15:24:00Z These are the only submissions that have been made. Team ID: YHQLC8PBT3 App: Termstead (com.pavelkhorenyan.Termstead), a macOS SSH client, universal (arm64 + x86_64) Signed with Developer ID Application, with the hardened runtime and a secure timestamp; codesign --verify --deep --strict passes Submitted as a zip with xcrun notarytool submit --wait from my Mac Could you take a look? Thank you, Pavel

Team JHNW3WU9NQ (Individual). Every submission is rejected with statusCode 7000 and issues null, the newest on 2026-10-06 (submission 4ab80a9a-2dae-437e-a3f1-52a33751d3c0). Developer Support case 102939827032 has been open since 2026-08-17; the identity verification Apple requested was accepted; the case has been with engineering since, with no update since 2026-09-15. Agreements are accepted, the Developer ID Application certificate is valid, and the build is signed with the hardened runtime. Several other threads report the same status for 5 days to 5+ weeks. Has anyone had a team configured after a case of this age, and what finally worked? An Apple engineer, please pick this up: the status text itself sends us to Developer Programs Support, who have not resolved it.

Our team (Team ID WQS88HK2V3) began notarizing with a new Developer ID Application certificate on October 2nd. Since then, no submission has completed. Every one sits at "In Progress"; two production app uploads from October 2nd are still there after three days. To rule out our app, I submitted a minimal signed hello-world binary (a main that returns 0, signed with hardened runtime and a timestamp, zipped with ditto). Today's one, 151fa89a-f115-4b8b-9713-d3c733f7b3ad, submitted 2026-10-05 15:32 UTC, was still "In Progress" after 20 minutes with --wait. Earlier hello-world tests took many hours to reach "Accepted"; one from October 3rd (1274bb4c-a0a5-4af6-a991-ac8fc3194656) is still "In Progress". What we've verified: notarytool history authenticates and lists every submission under the team, so credentials and upload are fine. codesign -dv shows TeamIdentifier=WQS88HK2V3 and the Developer ID chain. The Apple Developer Program License Agreement was accepted on 2026-10-02; nothing is pending on the Membership page. System Status shows the Developer ID Notary Service as available. No App Store Connect app record exists, which I understand is expected for Developer ID distribution. Stuck production submissions: 258583f0-2322-4048-a97c-f290c63d849c — 2026-10-02 17:45 UTC a7d7b1b1-286f-47ae-ab51-f20b0634f27e — 2026-10-02 19:41 UTC We have a Developer Support case (102984780721); so far the guidance has been to upload to App Store Connect, which doesn't apply to Developer ID notarization. Is there a known hold on first submissions from a newly provisioned team, and is there anything on our side that would clear it? This is blocking a release to our customers.

Hello, My macOS app notarization submissions have been stuck in the "In Progress" status for several days. There are no errors, logs, or rejection messages available. Could someone please help check if the backend analysis is stuck? Submission IDs: 9480dd02-ca54-4c79-9467-cfaeb046f772 (Submitted Oct 1) b3a11e2e-72b3-490b-a431-4fb1b67af9e9 (Submitted Sep 30) Team ID: S9ANDPPCK5 Thank you!