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"

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!

Hello, I'm trying to notarize my Electron macOS application using a valid Developer ID Application certificate. Environment: Apple Developer Program: Active Developer ID Application certificate: Successfully created App size: ~130 MB (ZIP) Using notarytool (via electron-builder / GitHub Actions) The submission was uploaded successfully, and I received a Submission ID. Submission ID: 8a2bd38d-08da-46c0-afdf-f37b63ae4e82 However, the notarization has remained in: Status: In Progress for more than 3 hours. Running both: xcrun notarytool info and xcrun notarytool history continues to report: Status: In Progress No notarization log is available yet. Is it normal for a notarization submission to remain "In Progress" for several hours? And if its pulled to deeper checks, is there a way of knowing that is so, and its not just stuck. Knowing it could be crucial so I am not wasting my time on a stuck progress loop. Any insight would be greatly appreciated. Thank you.

I’m attempting to notarize my first macOS application for direct distribution outside the Mac App Store. I now have several submissions stuck indefinitely in In Progress, with no logs and no way to cancel them. The application is an Electron app containing: Standard Electron and Chromium components Native components written in Rust A Swift helper application used for voice dictation Submission chronology 1. First GitHub Actions submission — Invalid My first submission was produced and uploaded by my GitHub Actions CI pipeline. Apple processed it quickly and returned Invalid: 489bd350-8be3-407e-ad0e-799c6d8aa3ec — Invalid I investigated and discovered that some nested native components had not been signed correctly. That rejection was completely reasonable. 2. Second GitHub Actions submission — stuck In Progress I temporarily removed the affected optional Python-based local feature and ran the GitHub Actions pipeline again. This second GitHub submission was the first one to become stuck: f8fe6edd-c150-4427-9a26-77ac0ab27b8d — In Progress Created: 2026-08-05T04:21:23Z The GitHub job produced no output for approximately 20 minutes, so I believed it had stalled and cancelled the runner to avoid continuing macOS runner costs. The Apple submission remained In Progress after the GitHub job was cancelled. Because this CI invocation used JSON output, multipart-upload progress was suppressed. Apple created a submission record, but I cannot retrospectively prove whether every upload chunk completed. It is possible this became an orphaned submission following an incomplete upload. 3. Troubleshooting moved to my local Mac After the second GitHub run became stuck, I stopped using GitHub Actions for troubleshooting. I moved the complete signing, packaging and notarization process to my local Mac so I could inspect every stage without consuming CI time. During this local work, I discovered additional mistakes in my custom signing process for nested components. I therefore expect some of my early local submissions to be invalid. However, they have never become Invalid or produced diagnostic logs. They remain In Progress: d3b3b11e-156d-4c71-a1e5-4f1ca6fa4de4 — In Progress fbf5de13-46c6-4a51-b75b-e9e4a02ecef3 — In Progress 4. Corrected and locally verified submission I corrected the signing process and added strict pre-submission verification covering: Main application signature All nested executables, frameworks and helper applications Developer ID certificate fingerprints Team ID Hardened Runtime Secure timestamps Distribution entitlements DMG integrity and checksum Final DMG signature Packaged-application launch testing The corrected 0.7.2 submission passed those checks but also remains stuck: 16101ad1-89a5-411f-94ff-326e10c3e966 — In Progress 5. Version 0.7.3 with definitively completed upload I have now built version 0.7.3 from current main and submitted it manually using verbose notarytool output: Submission ID: 60acb64e-7f3f-4ebe-8882-a189bcdb1bef File: Velvet-Avocado-0.7.3-macos-arm64.dmg Size: 161 MB Created: 2026-08-06T06:35:27Z Status: In Progress Unlike the earlier CI submission, I captured definitive proof that this multipart upload completed: Completed [33/33] chunks of a multipart upload. Upload progress: 100.00% (161 MB of 161 MB) Received new upload status: Succeeded Multipart upload process has completed successfully. Successfully uploaded file. The submitted DMG’s SHA-256 was: 46b3730a122d557c957a7709e1c9f7e6b8a2a66b83a34f85c473686bdb4af1dc For every submission still In Progress, notarytool log reports that the submission log is not yet available. I have opened an Apple Developer Support request asking for the older submissions to be cancelled or investigated. There appears to be no self-service cancellation mechanism. I understand that the incorrectly signed builds should fail. My concern is that they never reach a terminal status, never produce diagnostic logs, and may be interfering with subsequent corrected submissions. Apple’s documentation says most notarizations complete within five minutes and 98% complete within fifteen minutes. Some of these submissions have remained In Progress for more than a day. I do not want to create further duplicate submissions, but I cannot complete my macOS release until Apple returns a terminal result and makes the notarization ticket available. How should I proceed?

New Developer account: notarization submissions stuck In Progress over 32 hours I’m attempting to notarize my first macOS application for direct distribution outside the Mac App Store. I now have several submissions stuck indefinitely in In Progress, with no logs and no way to cancel them. The application is an Electron app containing: Standard Electron and Chromium components Native components written in Rust A Swift helper application used for voice dictation Submission chronology 1. First GitHub Actions submission — Invalid My first submission was produced and uploaded by my GitHub Actions CI pipeline. Apple processed it quickly and returned Invalid: 489bd350-8be3-407e-ad0e-799c6d8aa3ec — Invalid I investigated and discovered that some nested native components had not been signed correctly. That rejection was completely reasonable. 2. Second GitHub Actions submission — stuck In Progress I temporarily removed the affected optional Python-based local feature and ran the GitHub Actions pipeline again. This second GitHub submission was the first one to become stuck: f8fe6edd-c150-4427-9a26-77ac0ab27b8d — In Progress Created: 2026-08-05T04:21:23Z The GitHub job produced no output for approximately 20 minutes, so I believed it had stalled and cancelled the runner to avoid continuing macOS runner costs. The Apple submission remained In Progress after the GitHub job was cancelled. Because this CI invocation used JSON output, multipart-upload progress was suppressed. Apple created a submission record, but I cannot retrospectively prove whether every upload chunk completed. It is possible this became an orphaned submission following an incomplete upload. 3. Troubleshooting moved to my local Mac After the second GitHub run became stuck, I stopped using GitHub Actions for troubleshooting. I moved the complete signing, packaging and notarization process to my local Mac so I could inspect every stage without consuming CI time. During this local work, I discovered additional mistakes in my custom signing process for nested components. I therefore expect some of my early local submissions to be invalid. However, they have never become Invalid or produced diagnostic logs. They remain In Progress: d3b3b11e-156d-4c71-a1e5-4f1ca6fa4de4 — In Progress fbf5de13-46c6-4a51-b75b-e9e4a02ecef3 — In Progress 4. Corrected and locally verified submission I corrected the signing process and added strict pre-submission verification covering: Main application signature All nested executables, frameworks and helper applications Developer ID certificate fingerprints Team ID Hardened Runtime Secure timestamps Distribution entitlements DMG integrity and checksum Final DMG signature Packaged-application launch testing The corrected 0.7.2 submission passed those checks but also remains stuck: 16101ad1-89a5-411f-94ff-326e10c3e966 — In Progress 5. Version 0.7.3 with definitively completed upload I have now built version 0.7.3 from current main and submitted it manually using verbose notarytool output: Submission ID: 60acb64e-7f3f-4ebe-8882-a189bcdb1bef File: Velvet-Avocado-0.7.3-macos-arm64.dmg Size: 161 MB Created: 2026-08-06T06:35:27Z Status: In Progress Unlike the earlier CI submission, I captured definitive proof that this multipart upload completed: Completed [33/33] chunks of a multipart upload. Upload progress: 100.00% (161 MB of 161 MB) Received new upload status: Succeeded Multipart upload process has completed successfully. Successfully uploaded file. The submitted DMG’s SHA-256 was: 46b3730a122d557c957a7709e1c9f7e6b8a2a66b83a34f85c473686bdb4af1dc For every submission still In Progress, notarytool log reports that the submission log is not yet available. I have opened an Apple Developer Support request asking for the older submissions to be cancelled or investigated. There appears to be no self-service cancellation mechanism. I understand that the incorrectly signed builds should fail. My concern is that they never reach a terminal status, never produce diagnostic logs, and may be interfering with subsequent corrected submissions. Apple’s documentation says most notarizations complete within five minutes and 98% complete within fifteen minutes. Some of these submissions have remained In Progress for more than a day. I do not want to create further duplicate submissions, but I cannot complete my macOS release until Apple returns a terminal result and makes the notarization ticket available. How should I proceed?

My first notarization submissions have been stuck at "In Progress" for over 24 hours. This is a brand-new Apple Developer Program membership (enrolled this week), and these are the account's first submissions. Team ID: TSH4QXMCU8 Submission IDs (oldest first): c74c1f21-9847-44e7-96f6-a7370fff4fab (created 2026-08-05T00:20:22Z) 182000c9-abd8-47eb-b3fe-45ced930f4c5 (created 2026-08-05T00:58:55Z) d8f3f404-5fe8-47f3-9da3-8e1b278aa7a7 (created 2026-08-05T01:04:52Z) The app is a signed Electron desktop application (Developer ID Application certificate, hardened runtime enabled), submitted as a zip via notarytool through electron-builder. The three submissions are the same app; the duplicates exist because interrupted builds resubmitted. notarytool history shows all three as In Progress. I understand first submissions from new accounts can take longer for in-depth analysis, but at 24+ hours I'd appreciate someone taking a look. Happy to provide any further information.

Hi — first-time notarization for a newly enrolled individual team. Three submissions, none have resolved. The oldest has been In Progress for just over 18 hours. Team ID: MYFWTHMK9U Submissions (all still "In Progress" as of 2026-08-06T00:29Z): id: 2cab98b4-530c-4b82-9b2f-6580687d935a name: Sunnyside.zip createdDate: 2026-08-05T06:15:41.200Z elapsed: ~18h 13m id: 2d84505e-2379-4633-ab2d-271f7c8c6c50 name: Sunnyside AI.zip createdDate: 2026-08-05T06:28:55.557Z elapsed: ~18h 00m id: 67c5f798-6f33-4da1-94b9-8ed1f8706498 name: SunnysideAI-0.5.0-arm64.dmg createdDate: 2026-08-06T00:19:02.679Z elapsed: ~10m The first two are zipped .app bundles submitted by electron-builder. The third is a DMG I submitted manually, to rule out anything specific to the zip path. No submission from this team has ever reached Accepted or Invalid — every one has stayed In Progress. Environment: macOS 15.7.7 (24G720) Xcode 16.2 (16C5032a) notarytool 1.0.0 (37) Electron 32, electron-builder 25.0.5 Auth: notarytool keychain profile (App Store Connect API key, Developer role) The submissions upload cleanly and notarytool returns a submission ID each time, so credentials and the upload path appear fine. Signing looks correct to me. From the packaged app: $ codesign -dv --verbose=4 "Sunnyside AI.app" Identifier=com.trysunnyside.desktop Format=app bundle with Mach-O thin (arm64) CodeDirectory v=20500 size=772 flags=0x10000(runtime) hashes=13+7 location=embedded Authority=Developer ID Application: Deepu Nair (MYFWTHMK9U) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=5 Aug 2026 at 1:05:39 PM TeamIdentifier=MYFWTHMK9U $ codesign --verify --deep --strict --verbose=2 "Sunnyside AI.app" Sunnyside AI.app: valid on disk Sunnyside AI.app: satisfies its Designated Requirement Hardened Runtime is enabled, the signature carries a secure timestamp, and the nested helper binaries (a Swift ScreenCaptureKit helper in Contents/Resources, plus better_sqlite3.node) are all re-signed under the same Developer ID identity with the runtime flag — I checked each one individually rather than relying on --deep. I've read thread 821552, which describes a very similar situation on a new team. I understand from that thread that first submissions from a new team can be routed for in-depth analysis and take longer than usual. I'm not assuming this is a configuration error on my end — I'd just like to know whether these three are actually progressing, or whether they're wedged and I should resubmit. Since notarytool only reports "In Progress" with no queue position or estimate, there's no way for me to distinguish "still being analyzed" from "stuck". Any visibility into these submission IDs would be appreciated. Thanks.

I'm distributing an open-source command-line tool outside the App Store. Every notarization submission from my team has been stuck "In Progress" since my very first one on 2026-08-01. Fourteen submissions across five days, and not one has ever reached a terminal state — not Accepted, not Invalid, not Rejected. notarytool log returns "not yet available" for all of them, so I have no diagnostic output to work from. Team ID: HYZ2FM38JG Representative submission IDs (all "In Progress"): 3bc8fa7b-f35d-4a70-9b82-4b23b176f746 — 2026-08-01 19:49 UTC, the first submission my team ever made 79455e8c-b1bb-4bc4-9268-5a81b35dfdb7 — 2026-08-03 17:56 UTC 4ecaae74-8b43-4e1d-b18c-c3786d1f8c1e — 2026-08-04 18:11 UTC Plus two fresh submissions made today, 2026-08-05, after a bundle identifier change (see below). Full notarytool history available on request; all fourteen read the same. What I'm submitting: a single Mach-O command-line executable (Rust, arm64 and x86_64 built separately), zipped with ditto -c -k --keepParent <binary> <zip>. No app bundle, no DMG. Each zip is about 2 MB. Signature (codesign -dvvv, today's arm64 build): Identifier=dev.puchalla.trot Format=Mach-O thin (arm64) CodeDirectory v=20500 flags=0x10000(runtime) Authority=Developer ID Application: Marcus Puchalla (HYZ2FM38JG) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=5. Aug 2026 at 11:49:51 TeamIdentifier=HYZ2FM38JG Runtime Version=14.5.0 codesign --verify --strict --verbose=2 reports "valid on disk" and "satisfies its Designated Requirement". Hardened runtime is on, the signature carries a secure timestamp, and there are no entitlements at all, so no get-task-allow. Authentication: App Store Connect API key at Team level, via --key / --key-id / --issuer. Every submission is accepted immediately and returns an ID, so upload and authentication are clearly working — only the processing behind them never runs. Things I have already ruled out: Submission volume / throttling. The very first submission, made on an empty queue, stalled identically. Throttling also rejects at submit time with an error rather than issuing an ID. My CI setup. Some of these submissions come from a GitHub Actions macos-14 runner and others (trot-test.zip) were made by hand from my own Mac with notarytool directly. Both stall the same way, so this follows the account rather than any particular build environment. The bundle identifier. It was com.marcuspuchalla.trot, on a domain I do not own. I changed it today to dev.puchalla.trot, which is reverse-DNS off a domain I do control, and resubmitted. No change — the new submissions sit "In Progress" alongside the rest. (I did not expect this to matter for Developer ID distribution; I mention it so you know it has been eliminated.) Signing problems. Verified above. A signing error would come back Invalid with a log, quickly, rather than as indefinite silence. Expired or unaccepted agreements. Membership active, Program License Agreement accepted, nothing outstanding in the portal or App Store Connect. I understand from other threads here that uploads are sometimes held for in-depth analysis, and that new accounts see this more often — I'm entirely willing to wait if that's all this is. But five days with fourteen submissions and zero completions, including from a brand-new account that has never had a single submission succeed, seemed worth reporting in case something is genuinely wedged on my team's side. Could someone check whether these are actually progressing? One further question, in case it's relevant: I'm submitting a bare Mach-O executable rather than an app bundle, DMG or pkg. It's a command-line tool, so there's nothing to staple to. Is that path handled differently by the analysis pipeline? Every similar report I found here involved a bundle.

Hello, We are experiencing an issue where our recent notarization submissions are stuck indefinitely in the "In Progress" status, and no notarization logs are available to inspect. Here are the details for our impacted submissions: Team ID: 34AC638RKM Submission ID 1: 18020127-4742-4d5f-8f56-9742e1aab766 (Submitted: 2026-07-31 13:22 UTC) Submission ID 2: f00b0f39-8b6e-4b80-aaad-dd1690cc7d85 (Submitted: 2026-07-31 21:23 UTC) Prior submissions in June were accepted without issue using the same build pipeline and signing configuration. Is there a known backend delay with the notary service, or can an Apple engineer assist in checking the status of these submission tickets? Thank you!

Team ID: XBX2Z359B8 (Organization, enrolled 2026-07-31) Our first three notarizations succeeded on 2026-07-31: 2c7aee73-5dd3-4971-bc01-fb5e6eb43ae7 19:30:42 UTC Accepted 8f6c46bf-09fb-4ef2-ba29-e93663cbfd54 20:32:26 UTC Accepted a644d9ad-4b18-4bf8-8139-ab193ea40e1e 20:37:44 UTC Accepted Every submission since has been stuck In Progress. None has reached Accepted or Invalid. Earliest stuck request — now over 26 hours: 787e2c7f-8637-48e6-a0c7-0f18c3fd1ce2 2026-07-31 22:40:38 UTC Also stuck: b2fe3ce3-a071-4b23-a261-938e2f58175c 2026-08-01 12:45:39 UTC 26a2d35f-04c5-4309-81c1-3ac042fb58d3 2026-08-01 12:54:47 UTC 66997bd8-2398-41cc-8c28-e11ca1015e4a 2026-08-01 14:48:12 UTC bd05b4bc-d601-44c7-b6ed-b530a674983c 2026-08-01 16:52:12 UTC 3a5611cb-3537-4352-9855-78bf8bb8e2f6 2026-08-01 21:49:20 UTC 844af3e7-0d1d-4326-8ffb-b1ad2b26f781 2026-08-02 00:45:40 UTC I have already contacted Apple Developer Program Support about this — case number 20000125886455, opened 2026-08-02 — and have not yet had a reply. Ruled out: Payload and size — a 16 KB Developer-ID-signed hello-world (844af3e7) hangs exactly like our 40 MB DMG. Artifact type — DMG and ZIP of the .app behave identically. Incomplete upload — submitted with --verbose; upload completes, submission ID returned, every status poll returns 200 "In Progress". Signing — notarytool log for a644d9ad returns "Accepted", "Ready for distribution", issues: []. Developer ID + Hardened Runtime + secure timestamp; codesign --verify --strict --deep passes. Account — membership Active, no pending agreements. 10 submissions total, well under the rate limit. System status shows Developer ID Notary Service as Operational. Since a previously working submission and a 16 KB hello-world now behave identically, this looks like a held request blocking the queue rather than anything in our artifacts. Could someone look into 787e2c7f-8637-48e6-a0c7-0f18c3fd1ce2 and release or cancel it so the queue can drain? This is blocking releases of our app to users and we would be grateful for any help in getting it moving.

Since 2026-07-29 every notarization submission for my team (547L3Z8CNP) uploads fine, sits "In Progress" 24h+, then vanishes — notarytool info returns "Submission does not exist." None ever reach Accepted/Invalid. Last success 2026-07-27. Reproduces with a 5.85 KB Developer-ID-signed hello-world (hardened runtime + secure timestamp). codesign --verify --deep --strict is clean; auth works under both an app-specific password and an App Store Connect API key. Submission IDs: 17f9361a-e28d-4cc2-959f-2f3c7ba10325 — In Progress (07-30) f00de349-d449-4539-9d7d-82cac6ef04d7 — now "does not exist" (07-29) 17f1857a-fa44-430f-ad5b-cc42dcc41038 — now "does not exist" (07-29) 4af0cf5d-37e4-4d43-9edf-e78b8594d1db — 5.85 KB probe, In Progress Filed as FB24063069. Anyone else seeing this, or an engineer able to look?