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"

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.

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.

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]

Hi, This is our first-ever Developer ID notarization submission for our macOS application, Recto. The submission was created on: 2026-10-17T12:55:05.164Z Submission ID: d6f971e4-755c-494e-8f80-b2fa9e48b85e File: Recto.zip The submission has remained: status: In Progress for more than 3 days. Running: xcrun notarytool info d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns the submission successfully and shows In Progress. However, running: xcrun notarytool log d6f971e4-755c-494e-8f80-b2fa9e48b85e \ --keychain-profile "recto-notary" returns: Submission log is not yet available or submissionId does not exist Since notarytool info successfully finds the submission, the submission ID appears to be valid. This is our first notarization under this Developer ID account. Is this delay expected for a first notarization / in-depth analysis, or does the submission appear to be stuck? Should we continue waiting, or is there any action required from our side? Thanks.

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!

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

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 first notarization request with a new Developer ID account has been "In Progress" since October 2, 2026, with no result and no log. Submission ID: 204f7ef7-01ae-4d0e-a0c3-a4678edf93e6 Created: 2026-10-02T13:06:27Z File: settle-notarize-ELdioM.zip (macOS menu bar app, bundle ID com.settlewifi.Settle, version X.X) Team ID: XXXXXXXXXX Submitted with notarytool from my Mac; the upload completed and the request appears in notarytool history, still "In Progress" (checked on October 5) I understand that first submissions may be held for in-depth analysis, so I have not resubmitted the same build. Could someone check whether this request is still being processed or needs an action on my side? Thank you.

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!

Hello, My first notarization request with a new Developer ID account has been "In Progress" since September 29, 2026, with no result and no log. Submission ID: e5e4658b-eb0e-4d80-a3b2-524f96b9f598 Created: 2026-09-29T16:16:42Z File: Resovia.zip (macOS app, bundle ID fr.auxentis.ressources, version 1.0.1, universal) Team ID: HSVNXVL4X2 Submitted with notarytool from a GitHub Actions macOS runner; the upload completed and the request appears in notarytool history, still "In Progress" (checked on October 2 at 08:56 UTC) I have read that first submissions may be held for in-depth analysis, so I have not resubmitted the same build. Could someone check whether this request is still being processed or needs an action on my side? Thank you.

Hi Apple Developer Support, The ARM64 build of our macOS app, has remained In Progress for over five days. The x64 build of the same release, submitted shortly afterward, has been accepted. Pending ARM64 submission: Submission ID: f2aa218e-680c-4497-a977-17b7f3d85ae1 Submitted: September 23, 2026, at 12:57:14 UTC Archive: signed-arm64.zip Status: In Progress Accepted x64 submission: Submission ID: bbae43b0-3846-46d0-a160-3b3af3aede9b Submitted: September 23, 2026, at 12:59:28 UTC Archive: signed-x64.zip Status: Accepted I checked both submissions again on today using xcrun notarytool info. For the ARM64 submission, notarytool log returns: Submission log is not yet available or submissionId does not exist However, notarytool info successfully finds that submission and still reports In Progress. Could someone please check whether this submission is still undergoing additional analysis, or whether there is an issue requiring action on our side? If another support channel is more appropriate after this length of time, please let us know. This is blocking our Apple Silicon release. We would appreciate any guidance.

Following up with a full diagnostic summary since my last post, in case it helps narrow this down. Certificates: Developer ID Installer and Developer ID Application (Team ID 6VCLSHAN7R), both freshly created Aug 19, 2026. Both show as valid/trusted in Keychain Access and match the developer portal (expiration 2031/08/20). What I've verified/tried, all pointing to the same conclusion: Local signature is valid. pkgutil --check-signature shows a full chain (Developer ID Installer → Developer ID Certification Authority → Apple Root CA) with a trusted timestamp. codesign -dvv on the embedded binaries (VST3, AU component, standalone app) all show Authority=Developer ID Application: ..., hardened runtime enabled, valid secure timestamp. No account/cert issues found. No duplicate certificates (security find-identity -v -p basic returns exactly 2 valid identities). No pending Program License Agreement. developer.apple.com/system-status shows Notary Service operational. Signed with productsign directly, not just via the packaging GUI (Packages/Whitebox) — same result. Isolated from product content: a minimal pkgbuild test package (single text file, signed only with productsign, no relation to my actual product) fails with the exact same error. Waited 3+ days in case of certificate propagation delay — no change. Tried both authentication methods — Apple ID + app-specific password, and a Team-scoped App Store Connect API key — both fail identically. Every single attempt returns: "message": "The binary is not signed with a valid Developer ID certificate." Latest Submission IDs (all Invalid, same error): 5b495af5-1a31-41cd-b8a3-d1e33ab2a12a (product pkg, API key auth) 91eee4f0-778a-4edb-9515-eabfc6711f3f (minimal test pkg, Apple ID auth) At this point I've ruled out everything on my end I can think of — package contents, signing tool, authentication method, certificate freshness/propagation, account status. This looks like something wrong with how these specific certificates are provisioned on Apple's side for notarization. Could someone from DTS take a look at the account/certificates directly? Happy to provide any further diagnostics needed. Thanks for your patience.

Hi all I'm stuck on a notarization failure that doesn't match any cause I can find or fix locally — looking for either a known explanation or a pointer to the right support channel. Setup: macOS 15.7.2 (24G325) Certificate: "Developer ID Installer" Issued: 16 Aug 2026, expires 17 Aug 2031 Confirmed on developer.apple.com as Active (not revoked) — matches the certificate installed locally by serial/expiry Signing a component .pkg containing a notarized-requirements-compliant plugin bundle (hardened runtime, secure timestamp, universal x86_64/arm64, signed with a valid "Developer ID Application" cert from the same team) What I've verified locally, all pass cleanly: pkgutil --check-signature on the .pkg: full valid chain, Developer ID Installer -> Developer ID Certification Authority -> Apple Root CA, with a trusted timestamp spctl -a -vvv -t install on the .pkg: recognizes it as "Developer ID" origin, correctly reports "Unnotarized Developer ID" (i.e. Gatekeeper trusts the signature itself, just knows it isn't notarized yet) codesign -dv --verbose=4 on the inner plugin bundle (both architecture slices checked individually): valid Developer ID Application signature, hardened runtime flag set, trusted timestamp present What I've tried, no change in any case: Originally built/signed via the third-party "Packages" app — failed notarization Re-signed the same .pkg independently with Apple's own productsign directly (bypassing Packages entirely, to rule out a third-party tool bug) — productsign's own console output explicitly confirmed it added both the "Developer ID Certification Authority" and "Apple Root CA" certificates to the signature — still failed notarization, identical error Found and accepted a pending Program License Agreement banner on developer.apple.com that I hadn't noticed before — resubmitted after accepting — still failed, identical error Rebuilt the plugin bundle from source fresh, repackaged, resubmitted — still failed, identical error Every attempt gets the same result from xcrun notarytool log <id>: "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "issues" "severity": "error", "path": "<the .pkg filename itself>", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": null Note "path" is the top-level .pkg itself and "architecture" is null — so this is flagging the Installer signature on the package, not the inner bundle's Application signature. Some submission IDs for reference, in case anyone from Apple can look at the notary service's own logs directly: 9a5364bf-7b0e-4cf8-a68c-0508bc081855 caa2a263-d4af-443b-89dd-1c26d93a7bee f15fcf6d-99c3-4810-8c42-926e4328a042 Has anyone seen this combination before — a certificate that verifies as fully valid by every local tool (pkgutil, spctl, codesign) and shows as Active on the portal, but is rejected by the live notary service specifically? Is there some other account-level state (beyond agreements, which I've now accepted) that can cause this? Trying to figure out whether this needs a Technical Support Incident or if it's a known/documented gotcha I'm missing. Thanks for any pointers.

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.

Notarization submissions stuck In Progress then disappear, x64 only Team ID CJLCWP5NP3, app Write (com.connerkennedy.write), Xcode Command Line Tools notarytool 1.1.3 (42), macOS 26.6.2 build 25G83. Every x64 (Intel) notarization submission for this app gets stuck at status In Progress and never resolves. After roughly 11 to 12 hours, the submission disappears entirely: notarytool info with that submission id starts returning "Submission does not exist or does not belong to your team," and the submission no longer appears in notarytool history at all, not as Accepted, Invalid, or Rejected, just gone. This has happened identically on three consecutive x64 submissions. The submission ids and creation times, in UTC, are: b532a8a4-1dab-4eab-b37c-81b53b3573bb, created 2026-09-20 20:25:48 3a1ea67f-f88d-43e6-9ef5-62a6de1aa5d2, created 2026-09-20 21:22:16 8bc19842-e93a-4ea7-b3cc-3c1aeb20b423, created 2026-09-21 11:28:53 All three followed the same pattern: stuck in progress, then vanished roughly 11 to 12 hours later. In sharp contrast, every arm64 (Apple Silicon) submission from the same team, same day, same build pipeline, succeeded normally, typically within a few minutes. Five separate arm64 submissions across September 8 through September 20 all came back Accepted with no issues. This is the first time this team has ever submitted an x64 build for notarization. Every prior successful submission was arm64. That is the only meaningful difference we can find between the submissions that succeed and the ones that get stuck. Before concluding this is server side, we ruled out several things on our end. It is not a local network or VPN issue, since we reproduced it with a VPN active, after fully disconnecting the VPN, and after a full machine reboot. It is not local resource pressure, since we reproduced it with over 18 GB of free RAM after a reboot, the same conditions under which arm64 succeeds instantly. It is not the specific file, since we reproduced it with a completely fresh rebuild of the app and also when submitting a dmg instead of a zip. It is not our build tooling, since we bypassed electron-builder's built in notarize step entirely and submitted directly with xcrun notarytool submit and info, with the same result. And it is not a one off blip, since it reproduced three times in a row over about 36 hours, always the same stuck then vanished pattern, with arm64 unaffected the whole time. We would appreciate help understanding why x64 submissions under this team are getting stuck and then disappearing after 11 to 12 hours, while arm64 submissions from the same team notarize normally. Either an explanation of what is happening so future x64 submissions process normally, or confirmation that this is a first time x64 review hold that needs manual clearing on Apple's side, would be very helpful. Happy to provide the actual zip we submitted, full notarytool logs, or anything else that would help investigate

Title: Notarization submissions stuck "In Progress" for 4 days (new Team ID) Every notarization submission from my team has been stuck "In Progress" since 11 September 2026. The first one went through; everything submitted after it has never reached a verdict. Team ID: T36RPB6Z2G Tool: xcrun notarytool (Xcode command line tools), app-specific password App: a Tauri desktop app, Developer ID distribution outside the Mac App Store Submissions (UTC): 2026-09-11 11:17:19 76bd3fd2-657c-4c3c-9c6b-6e7bc789fb4e In Progress (~92 h) 2026-09-11 11:18:30 1becd424-2ede-4044-b432-7f3afc646270 Accepted (minutes) 2026-09-11 14:39:38 3058ba57-d546-4e82-a781-02a1494eef71 In Progress 2026-09-12 07:24:20 b9568de2-6504-4d83-adc6-40e44f08ba44 In Progress 2026-09-12 09:29:07 572cff54-0e90-4e0d-9908-4ad82759dc9a In Progress (control test) What I have ruled out: Credentials and signing are fine — 1becd424 was accepted within minutes with the same certificate, the same password and the same tooling. It is not my app: as a control I signed a 14 KB Mach-O (a copy of /bin/echo) with the same Developer ID Application identity, hardened runtime and a secure timestamp, submitted it on its own, and it has been "In Progress" for ~70 hours as well. xcrun notarytool log <id> returns "Submission log is not yet available" for all four, so processing appears to have never started. codesign --verify --deep --strict passes on the app bundle; the certificate chains to the Developer ID G2 intermediate and shows as valid in Keychain. The Developer System Status page reports the Notary Service as operational. This looks like the documented behaviour where an upload is held for in-depth analysis and every later submission queues behind it — but four days with no movement, including on a 14 KB binary, seems beyond the usual delay. I have deliberately stopped submitting so as not to lengthen the queue. Could someone from Apple check whether 76bd3fd2 is being held, and release it? This is blocking the first signed release of the app.

One of our notarization submissions has been In Progress since Sep 11 and hasn't moved. Submission ID: 5069b140-08dd-4113-bd13-6bc632b4200d Created: 2026-09-11T19:58:35Z Team ID: 9R8Q4GQCR8 notarytool info still shows In Progress, and notarytool log says the log isn't available yet. Our pipeline had five submissions Accepted on Sep 10 with the same certificates. We moved from an Individual to an Organization account on Sep 9, in case that matters. I haven't resubmitted the same binary. Could you check whether this one is held for deeper analysis, and whether it's holding up new submissions from our team?

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. xcrun notarytool info no longer shows any meaningful state for them. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress (~2.5h): CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict → "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers + ~180 PyInstaller backend binaries) signed inside-out. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck looks like an account-level backend issue, not a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.