General: Forums topic: Code Signing Forums subtopic: Code Signing > Notarization Forums tag: Notarization WWDC 2018 Session 702 Your Apps and the Future of macOS Security WWDC 2019 Session 703 All About Notarization WWDC 2021 Session 10261 Faster and simpler notarization for Mac apps WWDC 2022 Session 10109 What’s new in notarization for Mac apps — Amongst other things, this introduced the Notary REST API Notarizing macOS Software Before Distribution documentation Customizing the Notarization Workflow documentation Resolving Common Notarization Issues documentation Notary REST API documentation TN3147 Migrating to the latest notarization tool technote Fetching the Notary Log forums post Q&A with the Mac notary service team Developer > News post Apple notary service update Developer > News post Notarisation and the macOS 10.9 SDK forums post Testing a Notarised Product forums post Notarisation Fundamentals forums post The Pros and Cons of Stapling forums post Resolving Error 65 When Stapling forums post If your notary requests are stuck in the In Progress state, see my reply here. If your notary requests are failing with Team is not yet configured for notarization, see my reply here and also the follow-up here. Many notarisation issues are actually code signing or trusted execution issue. For more on those topics, see Code Signing Resources and Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello, All of our notarization submissions except one are stuck in "In Progress" with no terminal state. I would appreciate it if someone could confirm whether they are still queued, or whether something on our side is blocking them. Team ID: 7MK3979GD2 Account: individual, newly enrolled; Developer ID Application certificate issued 2026-10-29 Tool: xcrun notarytool submit with an App Store Connect API key (Team Key, Admin role) Auth/upload work fine: notarytool info returns "In Progress"; notarytool log says the log is not yet available. Submissions (all times UTC): created submission id file status 1 2026-10-29T23:59:53Z 10b84260-955d-4ed5-a7ad-aa7484228427 GsGPT.zip In Progress 2 2026-10-30T01:24:44Z 2fa44ce1-345e-467b-8ea9-97362be6f45f GsGPT.app.zip Accepted (~2.5 min) 3 2026-10-30T01:28:09Z 097fee47-6fec-4645-b4af-f8250820dc8f GsGPT-mac-arm64-8.31.0.dmg In Progress 4 2026-10-30T09:21:25Z 9f4ec58b-d116-4e84-b859-9281ec0e5b92 GsGPT.app.zip In Progress 5 2026-10-30T11:05:58Z d0b9cebb-7795-4699-94b7-2c040fd06028 GsGPT.app.zip In Progress Notes: Submission #2 was accepted in about two and a half minutes, and its log reports "status": "Accepted", "issues": null. All submissions come from the same account, the same certificate and the same build job, so I believe the signed content is compliant. I have not resubmitted the same content. Later attempts are different artifacts from the same pipeline (app zip and DMG). App: GsGPT, an Electron-based macOS desktop app (bundle id cc.ekoaku.gsgpt, version 8.31.0, arm64), signed with Developer ID Application with hardened runtime, to be distributed outside the App Store as a notarized, stapled DMG. I understand that first notarizations from a new account may undergo additional screening. The oldest stuck submission has now been waiting over 13 hours, so I would just like to know whether these are still being processed or have been held. Could you please confirm the current state of Team 7MK3979GD2's submissions and let me know if anything on our side needs action? I am happy to provide any logs or additional details. Thank you very much for your time.

Unfortunately Radar has been down for several hours tpday, so I figured I'd post here to see if anyone else is having the same issue. All of our Notarization and Stapling for our non-App Store apps is done via Terminal. It's generally worked pretty well for the past 12 months. But for the last 6 days, Notarization has been fine, but Stapling results in a NSURLErrorDomain Code=-1005 error ("The network connection was lost.") about 50% of the time. Needless to say this is getting to be pretty frustrating. I haven't noticed any hiccups with my Internet connection. Using Xcode 26.3 on Sequoia 15.8.2, and again doing everything on the command line. Anyone else seeing the same thing? Here's the most recent Stapling failure from a few minutes ago: error is Error Domain=NSURLErrorDomain Code=-1005 "The network connection was lost." UserInfo={_kCFStreamErrorCodeKey=-4, NSUnderlyingError=0x6000007983f0 {Error Domain=kCFErrorDomainCFNetwork Code=-1005 "(null)" UserInfo={NSErrorPeerAddressKey=<CFData 0x600002a84050 [0x20221bfa8]>{length = 16, capacity = 16, bytes = 0x100201bb11f8f13c0000000000000000}, _kCFStreamErrorCodeKey=-4, _kCFStreamErrorDomainKey=4}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=( "LocalDataTask <E200F376-9A02-4636-944C-7DAA6BEECFEC>.<1>" ), NSLocalizedDescription=The network connection was lost., 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)

App Name: Barbro Studio Apple ID / App ID: 6816361007 Platform: iOS Associated Support Case IDs: 102993165132, 103010022185 We are submitting this formal appeal to the App Review Board regarding an abnormal 12-day review delay, persistent queue stall, and the complete absence of developer support communication. Summary of Timeline & Critical Issue: 1. Guideline 4.8 Resolution: In our previous review cycle, feedback was received regarding Guideline 4.8 (Login Services). We made all necessary code and UI adjustments, fully satisfied the guideline requirements, and submitted a freshly updated build on October 18, 2026. 2. 12-Day Unattended Queue: As of today, October 30, 2026, the updated build has remained untouched in "Waiting for Review" for 12 straight days without a reviewer assigned. 3. Prior Delays: Our first submission sat in "Waiting for Review" for 8 days before any reviewer looked at it. In total, our initial launch has now been delayed by over 20 days solely waiting in queues. 4. Unresponsive Support: We have raised and followed up on two official support tickets (Case IDs: 102993165132 and 103010022185) with documented inquiries on Oct 11, Oct 19, Oct 25, and Oct 27. Despite paying the annual Apple Developer Program fee, we have received zero human responses from Apple. Business Impact: This indefinite queue stall has paralyzed our commercial launch, merchant salon onboarding, and public marketing campaign. Request to the Board: We request the App Review Board to: 1. Intervene and investigate why our build is trapped indefinitely in the "Waiting for Review" queue. 2. Directly assign a reviewer to Barbro Studio (App ID: 6816361007) so the review can proceed without further delay. We are ready to provide any additional testing credentials or technical clarifications immediately upon request. Thank you, Kevinkumar Dobariya Founder / Lead Developer, Barbro Studio Team Email: dobariya007kevin@gmail.com

My macOS app notarized in 22-24 seconds on every release for months under my previous Developer ID team. I often shipped several releases a day, even with minor changes. Since moving to a new Developer ID team (FPRW433858) on Oct 25, every submission of the same app is held for hours: 85da38d3-1874-458a-9bb5-e4656c770037 (Oct 25 19:09 UTC): still In Progress when my CI job hit its 6-hour limit; accepted later. e4bf6e71-58dc-4710-abc0-ba0b459b099f (Oct 29 17:02 UTC): Accepted after 1h56m. Log: "issues": null, "Ready for distribution". Useless because GitHub CI crashed on it. 0c21d8be-cd60-45c0-b990-f7ebb616201a (Oct 29 19:02 UTC): In Progress, 1.5+ hours and counting. Same source, same build pipeline, same Sparkle framework, hardened runtime, inside-out signing. The only change is the team. The build is clean, and you have accepted it twice. I've read the "some uploads are held for in-depth analysis" answers. That is not an answer I can work with. A bugfix release now takes hours or fails outright on CI time limits (6h on github), for an app you have already accepted twice under the new Dev ID and countless times under the old Dev ID. I need concrete answers: Is team FPRW433858 flagged for in-depth analysis, and why? When does that end? After how many accepted submissions, or on what date? Is there anything I must do on my side? If so, what exactly? If nothing on my side causes this, please clear the team or escalate it to someone who can. I cannot accept to wait hours/days on app releases that are straightforward otherwise.

Hello Apple Developer Support, All notarization submissions for my macOS application are being rejected with the following error: "Team is not yet configured for notarization." Both DMG and PKG submissions have failed. Recent submission IDs: a65c01f3-2897-42c5-a3a1-39583a771df0 9cfc86e0-00fd-4c7e-ae94-1f9a647eb966 Could you please check whether my Developer Team is properly provisioned for the Apple Notary Service and escalate this to the team responsible for notarization provisioning? This issue is blocking the release of my macOS application.

Our organization team (OMNIX TECH LTD, Team ID 8PKGR2HTA7, enrolled 6 June 2026) has never been able to notarize. Every notarytool submission since 9 June 2026 is rejected with statusCode 7000 "Team is not yet configured for notarization", including a 33 KB test zip containing only /bin/ls (latest: baacf441-da6e-4cbf-8b90-04a9e7bc179c, 16 Oct 2026, minutes after accepting the October 2026 Program License Agreement). Signing with our Developer ID Application certificate works; the notary service never evaluates the upload. An earlier case (102913653946, 30 June 2026) got no resolution. A new case 102998191235 was filed today under Development and Technical / Other Development or Technical Questions. Could someone confirm the team has been enabled for the notary service, or tell us what is missing on our side?

Requesting staff review. Team ID: RMHZ6VXS4C (individual, Account Holder, India). Case ID: 103000814312. What happened My Apple Developer Program membership lapsed. I renewed it on 18 October 2026. developer.apple.com/account → Membership details now shows the renewal: Renewal date October 18, 2027, annual fee US$99. So the renewal is recorded on my account. Even so, App Store Connect still shows "Your Apple Developer Program membership has expired," and the agreement banner that used to be there disappeared without anything to accept. App Store Connect → Business → Agreements lists no agreements at all. Notarization has failed the whole time. Every notarytool call returns: HTTP status code: 403. A required agreement is missing or has expired. This request requires an in-effect agreement that has not been signed or has expired. This happens with xcrun notarytool history as well as submit, using an app-specific password and the Team ID above. Last checked 23 October 2026. What I have checked The US$99 renewal was charged on 18 October 2026. I am the Account Holder, and there is no pending agreement to accept anywhere on developer.apple.com/account or in App Store Connect. My Developer ID Application certificate for this team is valid; code signing works, only notarization is refused. I corrected my membership address (city/state) on 23 October in case an identity check was holding the renewal. Impact I distribute a macOS app outside the App Store under Developer ID. Without notarization, new users get Gatekeeper's "Apple could not verify" block, so I am shipping unnotarized builds as a stopgap and my launch is on hold. I emailed Developer Support a week ago (case above) and have had no reply; the contact form offers no phone or callback option for India. Ask Could someone on the Developer Program team check why this team's membership shows as renewed on the account page but expired for App Store Connect and notarization, and push it through, or tell me what is still missing on my side? Happy to provide the receipt and logs.

We ship an Endpoint Security system extension inside a host app. On one managed Mac (macOS 26.6.2, build 25G83, arm64) the extension can't be activated, while the same package works on other Macs with the same macOS build. WHAT WE SHIP AND HOW IT'S NOTARIZED Host app: ElasticEndpoint.app (co.elastic.endpoint), Developer ID signed, notarized, with the ticket stapled (codesign -dvv shows "Notarization Ticket=stapled"). System extension: ElasticEndpoint.app/Contents/Library/SystemExtensions/co.elastic.systemextension.systemextension (co.elastic.systemextension), same Team ID, Developer ID signed. It was part of the same notarization submission as the host app but has no ticket stapled to itself (stapler validate says "does not have a ticket stapled to it"). Delivery: a root-owned service extracts the app into /Applications with tar (so no quarantine attribute) and then runs "ElasticEndpoint --install" as root to request activation. Versions: first reported on 9.0.8, and the same on 9.5.1. 9.1.0 and 9.5.4 have the same layout. Public packages: https://artifacts.elastic.co/downloads/beats/elastic-agent/elastic-agent-9.0.8-darwin-aarch64.tar.gz , with the app in data/elastic-agent-*/components/endpoint-security-resources.zip -> 64_Bit_Elastic_App_macOS.tgz. The 9.5.1 package is at the same URL pattern. SYMPTOMS ON THE AFFECTED MAC syspolicyd: [com.apple.syspolicy:default] Unable to parse ticket. syspolicyd: [com.apple.syspolicy:default] error registering ticket: -1 sysextd: Error checking with notarization daemon: 3 sysextd: bundle code signature is not valid - does not satisfy requirement: -67050 code failed to satisfy specified code requirement(s) sysextd: co.elastic.systemextension: extension failed to validate! uninstalling... "spctl -a -vv -t execute" prints "accepted / source=Developer ID", not "Notarized Developer ID", for our app and for an unrelated vendor's notarized app. Healthy Macs print "Notarized Developer ID". "syspolicy_check distribution" reports a notary error, and "codesign -R="notarized" --check-notarization" fails. RULED OUT The stapled ticket (Contents/CodeResources, 1716 bytes, SHA-256 e8679543f9934bd43b127210c10348f764b78a53360ec515ccbcb4afc0920e28) is byte-identical on the affected Mac, on a healthy Mac, and in the official 9.5.1 package. The network: TLS to api.apple-cloudkit.com and valid.apple.com works, there's no proxy, and the clock is correct (sntp offset 0.03 s). WHAT A HEALTHY MAC DOES (fresh macOS 26.6.2 VM, app without quarantine) Running the app's binary produces: "Extracting ticket from bundle" -> "Registering stapled ticket with system" -> CloudKit fetch -> "Inserting ticket". /var/db/SystemPolicyConfiguration/Tickets gains rows in the "tickets" and "hashes" tables, including the extension's cdhash. sysextd then validates the extension locally ("isNotarized = 1"), so the extension's notarization is established through the host app's ticket. If I truncate CodeResources on the VM, I get the same "Unable to parse ticket" / "-1" lines and then -67050. So on the affected Mac, ticket registration seems to fail even though the ticket file is intact. A third-party write-up describes the same signature on one Mac ("stapler validate" exit 65 for every vendor's app): https://github.com/fsnow/cst/blob/main/docs/implementation/NOTARIZATION_TICKET_ISSUE.md They report that none of these helped: resetting the Tickets database with SIP off, restarting syspolicyd/trustd, a fresh user account, or OS upgrades up to macOS 27.0.1. QUESTIONS What can make syspolicyd fail to parse or register a valid stapled ticket on a single Mac? Is there a supported way to repair ticket registration without erasing the Mac? Is it expected that sysextd validates nested code (the extension) only against the local ticket database, with no online fallback? What should we collect for you: a sysdiagnose, or a Feedback Assistant report? [FB number if filed]

I'm hitting what looks like a service-side notarization problem and could use a pointer on how to get it escalated. Over the past 3 days I've submitted 9 times with notarytool. Only 2 came back Accepted. The other 7 are stuck at "In Progress" and never reach a terminal state, no Accepted, no Invalid, no log (notarytool log says it isn't available yet), and no email. The oldest has been sitting ~71 hours. Signing checks out: codesign --verify --deep --strict passes and satisfies the Designated Requirement, hardened runtime with a secure timestamp, no get-task-allow, signed with my Developer ID, and the DMGs are signed before submission. The 2 submissions that completed were Accepted, so credentials and signing are fine. It really looks like the service just isn't processing most of my submissions. This is a newly enrolled account, and I've filed FB22939442 and have an open Developer Support case. Is this a known issue for new accounts, and is there a way to get these submissions looked at? Environment: macOS 26.2, Xcode 26.5, notarytool 1.1.2 (41).

2022-07-24 16:43:30.074 *** Error: Notarization failed for '/var/folders/r1/3j8rdbl95l9csz588j1nc6xc0000gn/T/electron-notarize-gGm3Fr/git-icons.zip'. 2022-07-24 16:43:30.075 *** Error: You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881 You do not have required contracts to perform an operation (-19208) { NSLocalizedDescription = "You do not have required contracts to perform an operation. With error code FORBIDDEN_ERROR.CONTRACT_NOT_VALID for id bb96a1a8-c3c3-4ded-a3c8-2abe369d8881"; NSLocalizedFailureReason = "You do not have required contracts to perform an operation"; }

Hi — submissions from my account have been stuck "In Progress" for 3+ days, and as of today even a tiny control probe is being held, while an identical probe submitted two days earlier was accepted in under an hour. Notary service status is green. This is blocking our first signed beta release. Team ID: 35L272URMA (individual account, enrolled 2026-10-16) App submissions (all still In Progress): fbed8a42-a43e-436f-bc99-49262ee4189d, 2026-10-16 04:55 UTC 090bd775-a288-435a-a2c6-95253e36b4cf, 2026-10-16 05:22 UTC (current build) 698e88b0-e111-41c0-8a5b-4da74aff6599, 2026-10-16 08:22 UTC ec3bd245-9306-4b56-b799-3d84782fc833, 2026-10-17 05:43 UTC App: "Octopus Beta" - Developer ID-signed, hardened-runtime, darwin-arm64 Electron app (131 MB zip, ~10k nested files, submitted as ditto zip, not DMG). Tooling: electron-builder 26.15.2 / notarytool (Xcode CLT) / macOS 26. Control probes (same account, same credentials, same flow, ~10 KB signed test apps): 5dda20a1-3f03-4757-90bb-52fce39427f3, hello.zip, 2026-10-16 09:54 UTC, Accepted in under 1 hour 7889bf07-f4ba-4aa8-9b77-10b504ce9a18, hello2.zip, 2026-10-18 15:29 UTC, STILL In Progress 17+ hours later The first probe passing quickly while an identical second probe now hangs suggests this is no longer just in-depth analysis of the large app. Either the whole account is now being held, or there is a service-side backlog window. Could you confirm which, and whether anything on our side is contributing? We have stopped resubmitting per the guidance in thread/814841. Happy to provide artifacts. Thank you!

I'm trying to notarize a macOS app under my individual team, WPJCQG3698. I enrolled in the Apple Developer Program in June 2026. Membership is active, all agreements are accepted, and the Developer ID Application certificate is valid. All 12 notarytool submissions since June 20 have failed the same way: statusCode: 7000 statusSummary: Team is not yet configured for notarization issues: null I'm authenticating with an App Store Connect team API key. Authentication and upload succeed every time, then the submission gets rejected in under a minute. As a control I copied /bin/ls, signed the copy with the same certificate, and submitted that. Same error, so it doesn't look app-specific. The latest submission is 03369f51-9929-4ec1-8940-e488cf1d00a7, uploaded 2026-07-10T08:30Z. Developer Programs Support case 102922992178 has been open since June 23 and was escalated to engineering on July 7. I retried today and nothing changed. This has been blocking our macOS release for three weeks now and I'm out of things to check on my side. Have I missed an account-side step, or is this something only Developer Programs Support can fix for the team?

Our team's notarization has been fully blocked since Oct 9 with statusCode 7000 "Team is not yet configured for notarization" (issues: null) on every submission - app, .pkg, and standalone binaries alike. Team ID: 7AVQDHV488 (US organization) Critically, this is a REGRESSION, not a first-time setup problem. The exact same binary that Apple ACCEPTED on Oct 9 returns 7000 when re-submitted, with nothing changed on our side: 9a603fde-f005-4803-ba0e-9f7ce0a61ac4 - ACCEPTED Oct 9 2f27d7eb-2530-46d2-8439-d12664233a3d - the SAME binary, re-submitted Oct 12 -> 7000 eddbcd23-c423-4e7f-a95b-15346e2be440 - our app (.zip), Oct 12 -> 7000 846be3bc-b90b-45fc-afae-1081a23c97b6 - our .pkg, Oct 12 -> 7000 Everything on our side checks out: Membership active (renews Aug 2027) Apple Developer Program License Agreement signed Oct 8, 2026 Signing valid: codesign --verify --deep --strict passes; the .pkg is signed with "Developer ID Installer: NUREV.IO Inc. (7AVQDHV488)" and a trusted timestamp Because Apple returns issues: null, the rejection happens before any binary inspection, which points to an account-configuration issue on Apple's side rather than our code or signing. I filed support case 102991640706 on Oct 9 and have only received the automated acknowledgment (3+ days, no human response). This is blocking our product launch. Could an Apple engineer please look into this, or route it to the team that can re-enable notarization for 7AVQDHV488? Happy to provide any additional submission logs. Thank you.

Hello, My notarization submissions have all stayed "In Progress" and produced no log. The first one has been waiting for almost a week: 07701908-cfc9-416b-93d8-783b50cb25c2, created 2026-09-29T18:11:38Z (the earliest) 11ab0aff-70d2-4cc6-a26f-8169e2f2a749, created 2026-10-04T14:23:28Z 99bfd78f-d4be-488a-aa1a-b6a81931d1c5, created 2026-10-05T15:24:00Z These are the only submissions that have been made. Team ID: YHQLC8PBT3 App: Termstead (com.pavelkhorenyan.Termstead), a macOS SSH client, universal (arm64 + x86_64) Signed with Developer ID Application, with the hardened runtime and a secure timestamp; codesign --verify --deep --strict passes Submitted as a zip with xcrun notarytool submit --wait from my Mac Could you take a look? Thank you, Pavel

Team JHNW3WU9NQ (Individual). Every submission is rejected with statusCode 7000 and issues null, the newest on 2026-10-06 (submission 4ab80a9a-2dae-437e-a3f1-52a33751d3c0). Developer Support case 102939827032 has been open since 2026-08-17; the identity verification Apple requested was accepted; the case has been with engineering since, with no update since 2026-09-15. Agreements are accepted, the Developer ID Application certificate is valid, and the build is signed with the hardened runtime. Several other threads report the same status for 5 days to 5+ weeks. Has anyone had a team configured after a case of this age, and what finally worked? An Apple engineer, please pick this up: the status text itself sends us to Developer Programs Support, who have not resolved it.

Our team (Team ID WQS88HK2V3) began notarizing with a new Developer ID Application certificate on October 2nd. Since then, no submission has completed. Every one sits at "In Progress"; two production app uploads from October 2nd are still there after three days. To rule out our app, I submitted a minimal signed hello-world binary (a main that returns 0, signed with hardened runtime and a timestamp, zipped with ditto). Today's one, 151fa89a-f115-4b8b-9713-d3c733f7b3ad, submitted 2026-10-05 15:32 UTC, was still "In Progress" after 20 minutes with --wait. Earlier hello-world tests took many hours to reach "Accepted"; one from October 3rd (1274bb4c-a0a5-4af6-a991-ac8fc3194656) is still "In Progress". What we've verified: notarytool history authenticates and lists every submission under the team, so credentials and upload are fine. codesign -dv shows TeamIdentifier=WQS88HK2V3 and the Developer ID chain. The Apple Developer Program License Agreement was accepted on 2026-10-02; nothing is pending on the Membership page. System Status shows the Developer ID Notary Service as available. No App Store Connect app record exists, which I understand is expected for Developer ID distribution. Stuck production submissions: 258583f0-2322-4048-a97c-f290c63d849c — 2026-10-02 17:45 UTC a7d7b1b1-286f-47ae-ab51-f20b0634f27e — 2026-10-02 19:41 UTC We have a Developer Support case (102984780721); so far the guidance has been to upload to App Store Connect, which doesn't apply to Developer ID notarization. Is there a known hold on first submissions from a newly provisioned team, and is there anything on our side that would clear it? This is blocking a release to our customers.

Hello, My macOS app notarization submissions have been stuck in the "In Progress" status for several days. There are no errors, logs, or rejection messages available. Could someone please help check if the backend analysis is stuck? Submission IDs: 9480dd02-ca54-4c79-9467-cfaeb046f772 (Submitted Oct 1) b3a11e2e-72b3-490b-a431-4fb1b67af9e9 (Submitted Sep 30) Team ID: S9ANDPPCK5 Thank you!

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

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

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