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 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!

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.

Hello , We have discovered a potentially suspicious software signed with your Apple Developer Program Developer ID certificate. Public distribution of such applications could negatively impact users and is not a permitted use of the Apple Developer Program. Effective immediately, access to your Apple Developer Program membership has been disabled and certificates have been revoked. This is to ensure your assets are kept secure and protect users from the software that may qualify as malware or contain malicious, suspicious, or harmful code or components while you investigate the issue. To provide further details and request that your membership access be reinstated, contact us within 30 days. If you do not contact us within 30 days to resolve the matter, your Apple Developer Program membership will be terminated at that time and any apps distributed through your account will be removed from the App Store. Sincerely, Apple

Hey guys, I am seeking advice or visibility from a DTS engineer regarding a permanent backend account block. Our corporate Apple Developer account is active and in good standing, but every macOS Developer ID notarization request fails after a 24-hour timeout with the following error: "notarization not enabled for this account" (StatusCode 7000) We have had a formal support ticket open for exactly 31 days (opened on August 27th). Every update from standard support states that it is "reviewing with engineering," but no progress has been made, and our US commercial distribution is completely blocked. DTS or Forum Monitors: Since this is an account provisioning/database issue on Apple's servers rather than a technical binary signing issue, could someone please advise on how to escalate this to the team responsible for Notary Service team provisioning? And it's always the same guy "Junghun" Answering with the same generic wait answer. A friend asked me to open a forum ticket and tag Quinn 'The Eskimo!'. I am happy to securely share our Team ID or Request UUID if an Apple employee can reach out. Thank you.

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

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.

My Apple Developer Program team cannot complete Developer ID notarization. Team ID: 8786B65DT4 Both submissions initially uploaded successfully and returned “In Progress,” but later disappeared completely. notarytool info returns: “Submission does not exist or does not belong to your team.” And: xcrun notarytool history --keychain-profile BELLE_EPOQUE_NOTARY returns: “No submission history.” Affected submissions: 9d235d80-01d1-4db7-81ed-112fc8bc97d2 Submitted 2026-08-16T15:28:42.805Z bd49caa9-0f30-4f72-80e4-f1e72ee6f6c9 Submitted 2026-08-22T17:32:43.457Z The app is a universal Unity macOS app distributed outside the Mac App Store via Steam. It is signed with a valid Developer ID Application certificate, Hardened Runtime, and secure timestamp. ZIP integrity and all nested Mach-O signatures pass local verification. Can Apple DTS / the notary service team investigate why submissions for this team disappear rather than reaching Accepted or Invalid?