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

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).

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

Notarization has been rejecting every submission with statusCode 7000 ("Team is not yet configured for notarization") for over five weeks. I'd appreciate any Apple staff who can confirm the gate status or re-route this internally. Account: Team ID: ZLPP2G8NG3 Account type: Individual, ACTIVE membership Region: EU (Czech Republic) The submission is technically clean — this is rejected at the gate, not on content: Developer ID Application cert valid (expires 2031), full WWDR chain Signed with hardened runtime + secure timestamp codesign --verify --deep --strict passes notarytool uploads succeed, then Rejected in ~30-60s log shows "issues": null (the archive is never opened) Confirmed it is NOT app-specific: a 50 KB hello-world C binary, signed the same way, is rejected identically. Latest canary submission: 95833847-e70f-41fe-b61f-c9dc9ffd90ed (2026-05-27) -> 7000 Timeline: 2026-04-20 first 7000 rejection (app, after ~60h "In Progress") 2026-04-29 escalated to engineering (case 102873818441, advisor Ronan) 2026-05-13 advisor Ira (case 102887849530) requested government photo ID + address verification — uploaded same day via the official file-upload portal, autoreply confirmed receipt 2026-05-14 to 05-27 silence; case was closed on Apple side, issue NOT resolved 2026-05-27 still 7000 I've completed everything on my side: License Agreement accepted, Free Apps agreement Active, DSA trader designation done, and the identity-verification documents submitted on May 13. Two weeks later the gate is still down with no reply on either case. Question for Apple staff: can someone confirm whether the identity-verification documents from May 13 reached the team that flips the notarization flag, and whether anything further is needed from me? The support cases have gone quiet and I have no other channel to check status. Thank you.

Hello, Adding our case to the long-running thread on this issue (https://developer.apple.com/forums/thread/118465). Our team is the latest to be hit by statusCode 7000 "Team is not yet configured for notarization", and we'd like to (a) document the data points in case it helps Apple correlate cases and (b) ask the community whether anyone has seen a faster resolution path than what's been reported here over the past 6 years. Our situation Team ID: A92X4FJ5HU Last successful notarization: 2026-05-18 11:23:26 UTC First rejection: 2026-05-18 17:19:15 UTC (~6 hours later, no apparent trigger on our side) Total rejections since: 22 submissions across 9 days, 100% rejected with statusCode 7000 Open support case: 102900780153 What we have already verified Apple Developer Program membership Active (Renewal Sept 17, 2026) Apple Developer Program License Agreement: Accepted Apr 15, 2026 Free Apps Agreement: Active (Apr 15, 2026 — Sept 16, 2026) Paid Apps Agreement: Active (Mar 17, 2026 — Sept 16, 2026) Banking and tax information complete Developer ID Application certificate valid (notBefore 2025-10-12, notAfter 2027-02-01) What we tested Variable Result API key A (Admin role, created 2025-10) Rejected, statusCode 7000 API key B (Admin role, created 2026-05-22) Rejected, statusCode 7000 Same Issuer ID, both keys Same rejection Bundle ID com.matrixai.app (one product) Rejected Bundle ID com.flowith.os.beta (different product) Rejected Locally-rebuilt clean DMG Rejected Pre-existing already-signed DMG Rejected The rejection happens server-side after upload completes — authentication, signing, hardened runtime, and timestamp are all confirmed correct (codesign verifies cleanly, both keys authenticate). The submission is accepted by the notary service, then rejected with statusCode 7000 after a few minutes of "In Progress". Sample submission IDs (all rejected, statusCode 7000) ac52531f-1b9e-4210-8123-54afea90f66f (2026-05-27 10:20 UTC) baba6420-e245-4597-b229-ec5af4b309c5 (2026-05-27 10:23 UTC) 72118f71-9f1d-4ce9-8068-3eca5017104d (2026-05-27 09:49 UTC) Question to the community I've read this entire thread (all 4 pages, 6 years of reports) and the related threads (749857, 813624, 825906, 827589, 130479, 130494, 741721, 809228). The consistent answer from DTS is "this is a Developer Program Support issue, escalate via official channels", but the threads also document wait times of 1 day to 3+ months with no SLA and no transparency. A few questions: Has anyone in 2025 or 2026 had this resolved in under 2 weeks? If yes, what (if anything) on your side accelerated it? Did anyone identify a specific account-level signal (recent agreement re-acceptance, banking change, AppID/Bundle ID conflict, recent role/Account Holder change, recent device verification, etc.) that correlated with the trigger date? Is there any escalation path beyond Case → DPS → "engineers are working on it" loop? Several users on this thread report 39 days, 3 months, 4 separate cases — and DPS still cannot give an ETA. I understand the official answer is "wait for Developer Program Support". Posting this here primarily so Apple has more correlated data points for the engineering team that owns notarization, and so other developers who hit this in the future can find one more datapoint. Thanks.

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Hello Apple Developer Support Team, This is my first app submission. I submitted my app on 18 May 2026, and since then all notarization submissions have remained in “In Progress” for an unusually long period without completing. Environment macOS 26.2 Notarization tool: xcrun notarytool submit Team ID: HRZ4D6R846 Developer ID signing identity is valid and correctly detected Timeline Issue started on 18 May 2026 Multiple submissions have remained in “In Progress” for 24–72+ hours Current count: 3+ submissions stuck in progress Checks already completed Verified the Developer ID Application certificate is valid and properly installed. Verified app signatures using: codesign -vvv --deep --strict Checked Apple Developer System Status, which currently shows all services as operational Re-submitted using fresh builds and credentials, but the behavior remains unchanged Could you please confirm whether there is any known notarization processing issue on Apple’s side during this period, and advise on the following: How to unblock the currently stuck submissions Whether the “In Progress” submissions should be cancelled and re-submitted Thank you for your assistance. Best regards, Rishikesh Galande

Hi, Two notarization submissions on my Team ID are stuck "In Progress" well past normal turnaround. Looking for guidance on whether this is normal first-time-enrolment latency or whether something needs escalating. Team ID: U7N63C278S Submissions: 2ac71ef0-cbfa-4bdd-9059-c2554050de48 — submitted 2026-05-14 08:09 UTC (currently ~48 hours In Progress) c2b557c5-92a2-4c36-996e-812b61b67fe6 — submitted 2026-05-14 11:33 UTC (currently ~46 hours In Progress) Status: xcrun notarytool history shows both as "In Progress" xcrun notarytool info <id> returns no log URL, no message, no error No rejection email received at the APPLE_ID address Apple System Status shows Developer ID Notary Service as green Context: This is my first notarization from a newly enrolled Developer Program account (enrolled ~5 days ago). I'm aware first-time submissions can be subject to longer in-depth analysis, which is why I haven't escalated sooner. Build verification (already done): codesign --verify --deep --strict -verbose=2 exits 0 Hardened runtime flag (0x10000) present on top-level .app and every nested Mach-O Full Developer ID Application chain (signed by Developer ID Application: poojan (U7N63C278S)) Secure timestamp present Universal binary (x86_64 + arm64) Every nested framework, helper app, and binary signed Built with electron-builder, hardened-runtime entitlements, notarized via notarytool submit --wait Question: Is this within expected first-time-enrolment latency, or is there something on the notary service side that needs a nudge? Happy to provide additional codesign output or the .app bundle structure if useful. Thanks for any guidance.

Hi all, I'm submitting a Developer ID-signed, hardened-runtime app for notarization. Every submission returns: "statusCode: 7000 statusSummary: Team is not yet configured for notarization. Please contact Developer Programs Support..." Team ID: V67NRZ84A2. Apple Developer membership is active, Developer ID Application certificate is valid, signing/verification all clean. Already opened a support case last week via the recommended path. The "contact page" on the developer site said Apple usually responds within 2 business days.... Has anyone hit this and gotten it resolved? How long did it take, and was there a more effective channel than the standard support form? I've seen people on Reddit claim they've actually been able to call a Developer phone line, but I haven't seen a valid phone number anywhere. I appreciate your response!

Hello, We are currently in the process of creating our Developer ID Application certificate which is due to expire. While creating the certificate, we were posed with the option of choosing a Developer ID Certificate Intermediary G2 Sub CA which is supported by Xcode 11.4.1 and later Previous Sub CA We currently build our application out of Xcode using Make or CMake files and perform the codesign and productsign using the codesign commands. We also use 2 different build machines, Ventura with Xcode 14.3 for our latest releases High Sierra (10.13) with Xcode 10.1 for legacy releases to support some customers. Can you please let us know which Developer ID Certificate Intermediary we should choose for generating the new Developer ID Application certificate?

Hi DTS, I have 4 notarytool submissions all stuck in "In Progress" with no movement for 12+ hours. 'xcrun notarytool log <id›' returns "Submission log is not yet available" for all of them - they don't appear to have been processed at all. Team Identifier: NS22D2XK8A 1 .dmg submission at 2026-05-12T01:35Z (12+ hours stuck) dmg submissions between 10:04Z and 12:12Z This is my first time notarizing with this Team ID - possibly the new-account first-submission "in-depth analysis" delay? The DMG passes every standard check: Signed with Developer ID Application (Team NS22D2XK8A) Hardened runtime on all 6 embedded binaries (codesign flags 0x10000) Full authority chain: Developer ID App → Developer ID CA → Apple Root CA Secure timestamp present Entitlements: allow-jit, allow-unsigned-executable-memory, disable-library-validation, network.client, network.server, files.user-selected. read-write codesign --verify -deep --strict passes cleanly spctl source = "Developer ID Application" (correct) DMG itself signed inside-out per TN2206 I have read the other recent "stuck In Progress" threads from new Developer IDs - same pattern. Could the queue be unblocked, or is there a team-side configuration that needs flipping? Happy to provide submission UUIDs + filenames privately via Feedback Assistant or DM. Thanks!

(Note: I don't need DTS support. This is not a DTS issue, and the standard responses aren't relevant to the situation. I would ask that DTS not respond in lieu of the developer support official) Yesterday, a poster in this forum wrote about his experience waiting several months to get approved to have his apps notarized. He had hit the "status code 7000; Team ID not configured for notarization" block. An Apple Developer Support account responded to him saying they would help the poster. After a month of waiting and praying for Developer Support to approve my Team ID for notarization, and no progress via the official channels, I am rolling the dice that asking Developer Support here will get my account approved or at least moved forward. I just can't wrap my head around why it takes so long to allow a Team ID to submit apps for notarization. My Team ID is V67NRZ84A2, and my support ticket is 102874600970. Spending months and months developing an app, paying the Developer Support annual fee, and then having to sit on your hands for months while your app gathers dust due to the Status Code 7000 bottleneck is very demoralizing. Again, not a DTS issue. The official channels 100% do not work. Developer Support did respond to a poster yesterday, so this is the pathway I'm hoping will lead to my Team ID getting permission to notarize apps. As it stands, no other method is leading to the problem getting resolved.

Hello, My macOS notarization has been blocked since March with: "status": "Rejected", "statusCode": 7000, "statusSummary": "Team is not yet configured for notarization", "issues": null Latest fresh probe: Submission ID: 3201b921-2313-45fd-b274-0e46d3fb03c2 Upload time: 2026-05-09T12:37:16Z Archive: KwantflowNotaryProbe-20260509T123714Z.zip Status: Rejected Error: -2052 / 7000 Issues: None Support cases: 102842156916 — Development and Technical → Other Development or Technical Questions 102882811151 — Development and Technical → Code Signing The archive uploads successfully and notarytool history/log work, but every submission is rejected before binary validation. The log shows no signing, entitlement, hardened runtime, timestamp, or executable issues. Apple forum answers say this is a Developer Program Support issue, not DTS/code-level. I have already contacted Developer Support, but the issue is still unresolved and blocks our macOS release. Has anyone recently resolved -2052 / 7000 / “Team is not yet configured for notarization”? Did Apple need to manually enable something on the team/account? Thank you.

I've tried to notarize my app recently and got the error:{ "logFormatVersion": 1, "jobId": "...", "status": "Rejected", "statusSummary": "Team is not yet configured for notarization", "statusCode": 7000, "archiveFilename": "myapp.dmg", "uploadDate": "2019-06-20T06:24:53Z", "sha256": "...", "ticketContents": null, "issues": null }I've never heard about "team configuration for notarization" previously. What are the steps to resolve that issue?Thanks in advance.

Hi all — looking for diagnosis help, posting publicly in case other devs hit the same issue. Symptom Every notarytool submission for the past 32 days returns: statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support..." Account state (all healthy as far as I can tell) Team ID: P6V2783F8M Membership: Active, Individual, paid Free Apps Agreement: Active Paid Apps Agreement: Active (signed Jan 4, 2026) W-8BEN tax form: Active Bank account: Active Developer ID Application certificate: valid, used for signing Bundle ID: dev.tinyclaw.desktop (registered) App is correctly signed codesign -dvvv shows: Authority=Developer ID Application: Yang Yang (P6V2783F8M) Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=Apr 11, 2026 Hardened runtime + secure timestamp both enabled. spctl --assess passes locally. Submissions (all rejected with 7000) 5a903f08-bd17-4d59-ac63-12e191e2bb5a 49b670da-0f79-4814-809a-f675791f15c3 febfb37a-b445-4d03-b7c4-bf573304f219 9013e185-10e2-42d4-91c1-3378083266eb bfc64627-5eb6-402c-ac25-e79648d2c251 (latest, 2026-05-02) Different builds, different versions (0.5.22-beta.7 → 0.5.27), different DMGs. Same 7000 every time. Credentials revalidated with a fresh app-specific password — same result. DTS Case 102855668616 open since Apr 2 — 4+ weeks of template responses, no engineering progress. Question Has anyone seen 7000 persist this long after a clean Individual enrollment? Is there a specific team-side flag that has to be flipped server-side, that DTS L1 can't see or escalate? Any suggestion on which DTS topic forces escalation to the notarization service team specifically? Happy to share more diagnostic output. Thanks.

Hi all, I enrolled in the Apple Developer Program on April 29 and immediately started notarizing my Electron-based macOS app. All submissions are stuck "In Progress" for 24–67 hours, with no Accepted or Invalid verdict. Team ID: VKFQG6Q29S Account: Individual, newly enrolled 2026-04-29 Submissions stuck (all "In Progress"): 2142f524-4c36-4452-a25d-2260d3b7010d (created 2026-04-30, ~50h) 6237312a-ae36-4a98-8ffe-37193c150a69 (created 2026-04-30, ~54h) 5184f493-f574-4f34-a536-8184bf4ce4eb (created 2026-04-29, ~64h) c108ed9f-1908-4c47-9b32-c55d34da99c7 (created 2026-04-29, ~67h) e1502fcd-dad6-402d-a0aa-550a1907ee46 (created 2026-05-01, fresh — submitted via App Store Connect API key as a control) What I have verified: Developer ID Application certificate is valid and trusted (security find-identity -v -p codesigning shows it) Inside-out signing: every Mach-O binary signed individually with hardened runtime, secure timestamp, entitlements; Helper apps and frameworks sealed top-level AFTER inner binaries; parent .app sealed last; DMG container codesigned codesign --verify --deep --strict --verbose=2 /path/to/app → "valid on disk" and "satisfies its Designated Requirement" I tried both auth methods: App-Specific Password (notarytool keychain profile A) and App Store Connect API Key (Team Key, Developer role, validated successfully). Both produce the same "In Progress" stall. Three earlier submissions returned "Invalid" within minutes with concrete errors (missing entitlements on shm-bridge .dylib, broken parent seal etc.), which I fixed. After the fixes, every submission gets stuck "In Progress" with no terminal status. I opened a Code Signing support case (102882655678) on April 30, no response yet. Has anyone else experienced extended "In Progress" hold on a freshly enrolled Developer ID? Is there a known first-submission review queue, and what's the typical SLA? Any way to escalate or is waiting the only path? Thank you.

Dear Apple Support, sometimes we observe exit code 68 in stapling via xcrun stapler staple <pkg_file.pkg> The notarization went fine but then stapling does not work. The output for the last ast failed launch looks like Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={_kCFStreamErrorCodeKey=-2102, NSUnderlyingError=0x60000363c7b0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <4F2E1620-9251-4525-91E7-C5F3E3681CD0>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <4F2E1620-9251-4525-91E7-C5F3E3681CD0>.<1>" NSLocalizedDescription=The request timed out., NSErrorFailingURLStringKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, NSErrorFailingURLKey=https://api.apple-cloudkit.com/database/1/com.apple.gk.ticket-delivery/production/public/records/lookup, _kCFStreamErrorDomainKey=4} CloudKit's response is inconsistent with expections: (null) As per manual of stapler and sysexit(3) the exit code means EX_NOHOST (68) The host specified did not exist. This is used in mail addresses or network requests. Make a retry sense or is there any other things which is not set correctly at that time? What is your suggestion to avoid this failure and stabilizing our automation of notarization? Best ergards, Stefan

Hello, I have been hitting status code 7000 on every notarization submission since April 21, 2026. The notable detail: earlier submissions on April 18 and April 20 from the same team were Accepted normally. Whatever flag flipped between April 20 and April 21 is on the notary side, because nothing changed on my end. Team details Team ID: ZS76A62WJ4 Organization: KENOPA LTD (UK private limited company) Role: Account Holder Apple Developer Program: Active until April 17, 2027 Apple Developer Program License Agreement: accepted April 16, 2026 Paid Apps Agreement, Free Apps Agreement: both Active in App Store Connect W-8BEN-E and banking: Active Certificate Type: Developer ID Application Identity: "Developer ID Application: KENOPA LTD (ZS76A62WJ4)" Valid through 2027-02-01, full chain trusted App details Platform: macOS (native AppKit, Objective-C, no Electron) Hardened runtime: enabled Code signing passes verify and strict checks Sandbox: not used (Developer ID distribution outside the App Store) Submission history (Team ID ZS76A62WJ4) Accepted submissions: 2026-04-18 10:00 UTC 39856e43-... 2026-04-18 10:03 UTC 3edf2f4f-... 2026-04-18 10:25 UTC 858c52e7-... 2026-04-20 17:17 UTC 4766f3ce-... 2026-04-21 03:58 UTC 9eed3336-... 2026-04-21 05:44 UTC b759941f-... Then everything since flips to Rejected with code 7000: 2026-04-21 19:10 UTC bedc99ad-... 2026-04-21 20:24 UTC 4dbb55f0-... 2026-04-22 07:36 UTC 50e1420e-... 2026-04-24 04:11 UTC 7e4adf81-... 2026-04-25 04:31 UTC 4c0367ea-... 2026-04-25 08:02 UTC a3ce5f56-... (still In Progress at the time of posting) I can paste the full submission IDs in a follow-up if helpful. Sample notary log The body of every Rejected log is the same: status: Rejected statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support..." Submissions all upload successfully, sit "In Progress" for hours-to-days, then flip to Rejected with this code. What I have verified All four agreements (Apple Developer Program License, Apple Developer Agreement, Paid Apps, Free Apps) are accepted and Active. Re-checked under the Account Holder login on both portals. Banking and W-8BEN-E are Active. Developer ID Application, Apple Distribution, and Apple Development certificates are all valid and the private keys import cleanly. App Store Connect API key works (notarytool history returns the full list with no auth errors). Same codesign invocation, same notarytool submit flags, same hardened runtime entitlements that worked on April 18-20 still produce the rejection on April 21+. Existing support channels Opened a support ticket via the developer contact form under "Development and Technical / Other Development or Technical Questions" (the exact path the error message specifies). Also emailed Developer Programs separately. Question Has anyone with the same "was working, then suddenly 7000 with no other change" pattern had it resolved? I am aware that DTS engineers have stated on this forum that they cannot escalate this. I am trying to get a sense of: Typical resolution time once a Developer Programs case is open (reports range from days to two-plus months). Whether anyone has found a particular wording of the support request that gets routed faster. Whether the Account Holder doing anything specific in the portal (re-accepting an agreement, toggling something in Membership, etc.) ever cleared this for someone. Thanks.

Hi, I have two notarization submissions stuck "In Progress" for over 18 hours. This is my first time notarizing on this Developer ID account. Submission 1: c1ae7112-79d9-4ada-92a8-bcf87930b5a3 (submitted ~24 hours ago) Submission 2: e201629a-35ef-48a9-b6c4-efbdeecee839 (submitted ~12 hours ago) Team ID: PH4PLAN782 Bundle ID: com.SoundHawkStudio.ComboDyn Type: macOS Audio Unit plugin (.component), universal binary (x86_64 + arm64), Developer ID Application signed, hardened runtime enabled. I have also filed support case 102876329587. Both submissions remain In Progress with no transition to Accepted or Invalid. Any assistance would be greatly appreciated.

Hey everyone, Just enrolled in the Apple Developer Program yesterday and tried to notarize my first macOS app. I submitted via notarytool and the submission has been sitting at "In Progress" for over 22 hours now. I've submitted twice and both are stuck. The app is a macOS utility built with PyInstaller. I signed it with my Developer ID Application cert, enabled hardened runtime, added a secure timestamp, and included the appropriate entitlements. Everything looked fine on my end. When I query with notarytool info it just says status: In Progress. No rejection email, no acceptance email, nothing. Is this a known issue for first-time submissions? Or is there something specific about PyInstaller apps that causes this? Submission IDs if anyone from Apple is reading this: b512bd92-7eca-4975-823e-9561d5c2ad63 f90cd69f-cf36-4762-bcda-0d0b047d5f49 Already filed a support ticket but wanted to check here too.

Hi, I have a notarization submission that has been stuck in "In Progress" for over 26 hours with no resolution. Apple's system status page shows no incident for the Developer ID Notary Service. Submission details: Submission ID: 23dc147c-6355-49a8-8ebf-78ae40ba19a3 Team ID: 5DX9FFYJHV App: Chakra Browser (Chromium-based, arm64, macOS) Bundle ID: com.chakra.Browser.development Submitted: 2026-04-22 at 19:09 UTC Current status: In Progress I also have two earlier submissions for the same app that are stuck in the same state: 23fe6ea2-325b-4ae8-84a4-4f913e7d3aea (submitted ~17:58 UTC, same day) 943e737a-1c45-468d-ae6b-1ef7358fc1a5 (submitted ~18:32 UTC, same day) The app is signed with a valid Developer ID Application certificate. The zip is ~243 MB (738 MB app bundle). Entitlements used: com.apple.security.cs.allow-jit, com.apple.security.cs.allow-unsigned-executable-memory, com.apple.security.cs.disable-library-validation. These are standard for Chromium-based browsers. xcrun notarytool log returns "Submission log is not yet available" for all three submissions, so there is no error output to share. Has anyone seen notarization stuck this long without a reported service incident? Is there anything I can do to get these unblocked, or do I need to file a TSI? Thanks