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"

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.

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

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. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress: 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 returns "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 plus ~180 PyInstaller backend binaries) are signed inside-out These packages are essentially identical in size and structure to our previous release 2.1.7, which notarized within minutes. In fact 2.1.8 is about 1 MB smaller than 2.1.7 (arm64 dmg 214.2 MB vs 215.3 MB; x64 dmg 223.3 MB vs 224.5 MB), so this is not a large or unusual upload. 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, while the packages verify cleanly and match a previously-accepted release, looks like an account-level backend issue rather than 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.

Can someone at Apple please help move this case forward? Team F587Y8G7S4 (Individual membership, active since 3 July 2026) has never been able to notarize. Every submission, including an empty test zip, is rejected before scanning with: statusCode 7000 — "Team is not yet configured for notarization" issues: null, ticketContents: null Latest test: submission 08e5b2a7-db7d-4a3c-b760-fbe97266ad0a, 7 September 2026, 18:10 UTC. First occurrence: submission f2331ba3-65e0-4513-aa46-da98ecc6d742, 3 July 2026. Signing: Developer ID Application (G2), hardened runtime, uploads succeed. Membership and all agreements are active. Developer Programs Support case 102932780546 has been open since 4 July. It was escalated on 25 July, then "escalated to our engineering team" on 18 August and again on 2 September. No internal ticket number, no timeline, and no engineer has contacted me. I have supplied every detail requested (repro steps, timestamps, screenshots). Please: Escalate case 102932780546 to the team responsible for Notary Service provisioning. Confirm Team F587Y8G7S4's notarization provisioning is being reviewed or reset. Provide the internal ticket number and the current next step. This is blocking a commercial macOS release. If you need anything else, tell me exactly what to provide.

Hello Apple Developer Support, I am requesting maximum escalation for this case. My paid Apple Developer Program account has been unusable for Developer ID notarization for more than two weeks. This blocks macOS distribution entirely, despite the fact that the membership is active and all visible account requirements appear to be completed. Team ID: GRP4HM9M63 Apple Developer Program: Active Account status already checked: Apple Developer Program membership is active Apple Developer Program License Agreement is accepted Apple Developer Agreement is accepted Free Apps Agreement is active W-8BEN tax form is active Developer ID Application certificate exists and is active The applications are signed with Developer ID Application Hardened Runtime is enabled Local codesign verification passes Despite this, notarization is still unavailable for this Team. This is not an issue with a specific app, archive, DMG, ZIP, signing configuration, or binary validation. Multiple different apps and archives are rejected with the same account-level error before binary validation. Recent failed submissions: Cassini.zip Submission ID: a429460d-cdf9-47cc-9731-90bac71286af Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Lunoura.zip Submission ID: 3aa46853-b3c7-4076-a08d-f9e4db9bea64 Status: Rejected Status code: 7000 Status summary: “Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions.” Issues: null Earlier submissions for Cassini.dmg and Cassini.zip were also rejected with the same statusCode 7000. Since multiple unrelated archives are affected and all logs contain issues: null, this clearly appears to be a Developer Team/account configuration issue on Apple’s side, not an application validation issue. Please escalate this case to the appropriate Developer Program / notarization backend team and urgently check the notarization configuration for Team ID GRP4HM9M63. Please explicitly confirm: Whether Team ID GRP4HM9M63 is currently enabled for Developer ID notarization. Whether there is any hidden account, KYC, legal, compliance, tax, or backend configuration issue blocking notarization. Whether Paid Applications Agreement or bank account setup is required for Developer ID notarization, even though we are not distributing paid apps. What exact action is required from our side. When this paid Developer Program account will become usable for Developer ID notarization. This issue has already blocked us for more than two weeks. We are paying for Apple Developer Program membership, but cannot use a critical Developer ID distribution feature.

Can someone at Apple please help move this case forward? My team has been unable to notarize any macOS app since January 30, 2026. Latest test: Team ID: FDH6MWPL9X Submission ID: f0cd3704-36d5-450a-8035-26dc6e69a739 Support case: 20000107489402 Error 7000: "Team is not yet configured for notarization." issues: null ticketContents: null This team successfully notarized on January 27. Credentials work and all agreements are active. Apple rejects each submission before scanning the app. The support case has been open since February. I was told an internal ticket was created, but I have not received its number, a status update, or a timeline. Please: Escalate case 20000107489402 to the team responsible for Notary Service provisioning. Confirm that Team FDH6MWPL9X's notarization provisioning is being reviewed or reset. Provide the internal ticket number and the current next step. If you need more information, please tell me exactly what to provide.

Hi everyone, For the past three days I've been unable to notarize my app — every attempt fails with an HTTP 500 error from Apple's notarization service. What's unusual is that the error occurs not only during submission, but also when simply validating credentials via store-credentials. Example: $ xcrun notarytool store-credentials "notarytool-password" \ --apple-id <id> --team-id <team> --password <app-specific-password> Validating your credentials... Error: HTTP status code: 500. Internal Server Error Request ID: K6NYCMIFNM66OI2WRG3ORZEDUE.0.0 Please try again at a later time. Since the failure happens at credential validation — before any package is even uploaded — I'm fairly confident this is a server-side issue, not something wrong with my setup or the binary. I've tried across different network connections, same result. Has anyone else been hitting this? Is there a known outage or incident on Apple's notarization infrastructure? Any way to escalate or get a status update beyond checking developer.apple.com/system-status/? Thanks

Hello, Our team has been completely blocked for over 13 days trying to notarize our macOS desktop application for external distribution via Developer ID. Every single submission to the notary service fails immediately with statusCode: 7000 and issues: null. The exact error returned by xcrun notarytool is: "Team is not yet configured for notarization. Please contact Developer Programs Support..." We have already confirmed this is an account-level backend restriction rather than a code-signing or binary packaging issue. To prove this, we submitted signed raw system binaries (copies of /bin/cat and /bin/echo with no app content) and they were rejected with the identical Team 7000 error code. Our Free Apps Agreement is active, and our tax/compliance forms are completely up to date. We opened a high-priority ticket with Developer Support (Case #20000128878099), but the initial front-line response was a generic boilerplate macro telling us to complete iOS App Notarization metadata fields and accept the EU Alternative Marketplace Addendum. None of this applies to a standard macOS application distributed outside the Mac App Store. Team Details: • Team ID: QDH4N9GF75 (Metafix Fintech LLC) • Platform: macOS • Tooling: xcrun notarytool Recent Submission Request IDs (All rejected identically with issues: null): • 360351f5-72b5-4f60-949b-531bf3c0e514 • dfaae647-250d-463d-b0e9-8f8f0738bd95 • e8950d1b-5bdc-41f5-8379-da6ba3311941 Could a Developer Relations engineer or community manager please flag this case internally? Our team profile requires a manual configuration adjustment or provision reset on Apple's backend to enable the Developer ID Notary capability for our Team ID. Thank you, Jobson

Every notarytool submission from my team is rejected before analysis: statusCode 7000 — "Team is not yet configured for notarization. Please contact Developer Programs Support…" Latest submission ID: 15c77a26-4ebc-4e01-b9c6-c5871ab2aeec (Aug 26). The package itself is fine — Developer ID Application certificate, hardened runtime, secure timestamp, issues: null in the log. Context: the same team (32NT5Y39TG) successfully notarized this application in May 2021. The membership lapsed later and was renewed in November 2025; all agreements are accepted. It looks like the notarization entitlement was not restored on the team when the membership was reactivated. I have done what the message says: Developer Programs Support case 20000145991521 has been open since Aug 24 (first report Aug 19). It was "escalated to engineering" on Aug 24 after I supplied system info and storefront, and there has been no update since. Meanwhile a finished release is on hold. Two questions: Is there anything on the developer's side that can cause 7000 after a membership renewal, or is it purely a server-side flag? Is there any way to get this case moving? A week for a flag toggle is hard to explain to users. Thanks.

Hi, I'm reporting three notarization submissions that have all been stuck in the "In Progress" state today. I'm posting mainly to ask whether my team has been pulled into in-depth analysis, since as far as I know there is currently no way to determine that from the client side. Team ID: SE3B3RM5Y4 === Stuck submissions (all still "In Progress" as of 2026-08-17 12:15Z) === 99722c12-dc10-4098-88be-84b7b58ff1f4 created 2026-08-17T07:51:19Z a41cf8fe-8883-4073-a043-5143323407da created 2026-08-17T09:45:11Z 35746a17-d332-4398-a353-cd7b1d8520ac created 2026-08-17T11:34:55Z notarytool info returns status "In Progress" with no message field for all three. No errors, no rejections - they simply have not moved. === Immediately prior submission, same pipeline, succeeded === a9138c72-41ee-4b42-adcf-78851eb3e5c7 created 2026-08-12T10:58:00Z Accepted That submission was Accepted in roughly 25 minutes. Every submission before it (2026-08-09 x2, 08-06, 07-26, 07-21, 07-15, 07-09) was also Accepted within a similar window. Today's three are the first that have not completed. === Why I believe this is team-scoped rather than a bad package === The three submissions are not retries of one another: 99722c12 and a41cf8fe are the same app version (1.3.1). 35746a17 is a different build of a different app version (1.3.2), produced from a newer source tree, with different content and a different zip. It was submitted almost 4 hours after the first one and was stuck immediately as well. So a fresh, independently produced package entered the same stuck state right away. That seems more consistent with a team-level hold than with a problem in any individual package. I understand from previous threads that once a team enters in-depth analysis, it affects all notarizations for that team until the state clears, which appears to match what I'm seeing. === What changed between the last successful submission and today === I want to disclose this in case it is relevant to the analysis: Package size grew from ~635 MB to ~751 MB (+116 MB, +18%) for the signed .zip. This is one of the larger single-release size increases in this app's history. A bundled third-party command-line helper was updated to a much newer release. It ships its own separately Developer ID-signed Mach-O executable, so while the file path and its signing identity are unchanged from previous releases, the actual binary content is almost certainly different from what was notarized on 2026-08-12. The app's own main executable is rebuilt every release, so its content always differs between releases. That has never caused a delay before. No new kinds of executables, dylibs, or runtimes were added to the bundle. I verified this by diffing the packaging scripts and the bundle tree: there are no newly introduced binary types, and no new entitlements. The Hardened Runtime entitlements are byte-for-byte identical to the 2026-08-12 build. === What I've already checked === Signing identity is a valid, unexpired Developer ID Application certificate. codesign -vvv --deep --strict passes on the app before submission. Hardened Runtime is enabled; entitlements unchanged from the accepted build. The Developer ID Notary Service shows as operational on the system status page. I am nowhere near the documented submission rate limits (3 submissions today). App-specific password and credentials are valid - notarytool history authenticates and returns results normally. === Environment === macOS host: Apple silicon Xcode command line tools, xcrun notarytool submit --wait Electron-based application, packaged with electron-builder Signed zip: ~751 MB === My questions === Is there any way to confirm from my side whether these submissions have been routed into in-depth analysis? I understand this is a known and frequently requested feature, but I want to make sure I'm not missing an existing diagnostic. Given that these are only a few hours old, I understand this is well below the threshold at which it makes sense to investigate individual submissions. I'm happy to wait. I'd just like to confirm whether waiting is in fact the correct action here, or whether there's anything in the changes described above that I should address on my end before resubmitting. Is submitting an additional build while earlier submissions are still pending harmful in any way? I've read that it's acceptable, but I want to confirm I'm not making the queue situation worse for my own team. I will update this thread when the state resolves, including how long it took, so there's a data point on the record. Thanks very much for your time.

Hello, I am distributing a macOS application outside the Mac App Store and using xcrun notarytool to submit my .zip payload. However, my submission has been permanently stuck in the "In Progress" state for several days without completing, failing, or generating a log. Standard Apple Developer Support advised me to post here, as they do not have visibility into the Notary Service backend queue. From reading other threads on the forum, I suspect this might be a first-time submission hang or a backend account-provisioning issue. Could an engineer please take a look at the queue and help unstick this submission? Here are the exact details: Team ID: 5LY7WW2QDP Submission ID: 154a0dbd-4e6e-4475-b03f-da19cdc983bd Filename: Enso.zip Tool Used: xcrun notarytool When querying the status using xcrun notarytool info, it continues to return status: In Progress and xcrun notarytool log confirms no log is available yet. Any assistance in clearing this queue so I can proceed with notarization would be greatly appreciated. Thank you!