I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

Hi Apple Developer Support, I am writing to escalate an urgent unresolved request regarding our app BetterUs (Team ID: TK8M23SECQ, Bundle ID: com.dalesidebottom.betterus). Timeline of attempts: ~1 May 2026 — Submitted FamilyControls Distribution entitlement request via the official form at developer.apple.com/contact/request/family-controls-distribution for bundle IDs com.dalesidebottom.betterus.shield and com.dalesidebottom.betterus.report. No confirmation number received, no response. ~20 May 2026 — Raised support case 102892887667 via developer.apple.com/contact. Received acknowledgement from Eugene. ~21 May 2026 — Replied with all requested information (date of submission, business need, bundle IDs). Today — Still no approval and no further response. It has now been over 3 weeks since the original request. What I need: The FamilyControls Distribution entitlement is already approved on my account for: com.dalesidebottom.betterus ✅ com.dalesidebottom.betterus.monitor ✅ I simply need it extended to these two sub-extensions of the same app: com.dalesidebottom.betterus.shield (Shield Configuration extension) com.dalesidebottom.betterus.report (DeviceActivity Report extension) These are not new use cases — they are part of the same approved parental screen time app. Without this, BetterUs cannot be submitted to the App Store at all. I have active testers waiting and this delay is significantly impacting our launch. I would greatly appreciate urgent attention on this matter. Thank you, Dale Sidebottom

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] Xcode 26.2, currently being seeded as Release Candidate, is much better about this (r. 155327166). Give it a whirl! Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.in-app-purchase.non-consumable — Likewise. com.apple.developer.in-app-purchase.subscription — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. com.apple.developer.musickit — There is no MusicKit capability. Rather, enable MusicKit via the App Services column in the App ID editor, accessible from Developer > Certificates, Identifiers, and Profiles > Identifiers. These app services are tied to your App ID on the server side, meaning that they have no presence in your code signature. com.apple.developer.shazamkit — There is no ShazamKit capability. Like MusicKit, this is an app service. com.apple.mail.extension — Creating an app extension based on the MailKit framework does not require any specific entitlement. com.apple.security.accessibility — There’s no entitlement that gates access to the Accessibility APIs on macOS. Rather, this is controlled by the user in System Settings > Privacy & Security. Note that sandboxed apps can’t use these APIs. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. com.apple.developer.adservices — Using the AdServices framework does not require any specific entitlement. com.apple.security.device.audio-input-monitoring — The com.apple.security.device.microphone entitlement is what restricts microphone access on macOS. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2026-05-28 Added com.apple.security.device.audio-input-monitoring to the common hallucinations list (Kevin) 2026-04-23 Added com.apple.developer.shazamkit to the common hallucinations list. Added a little more info about app services. 2025-12-09 Updated the Xcode footnote to mention the improvements in Xcode 26.2rc. 2025-11-03 Added com.apple.developer.adservices to the common hallucinations list. 2025-10-30 Added com.apple.security.accessibility to the common hallucinations list. 2025-10-22 Added com.apple.mail.extension to the common hallucinations list. Also added two new in-app purchase hallucinations. 2025-09-26 Added com.apple.developer.musickit to the common hallucinations list. 2025-09-22 Added com.apple.developer.storekit to the common hallucinations list. 2025-09-05 Added com.apple.developer.device-activity to the common hallucinations list. 2025-09-02 First posted.

Ive spent nearly one month to develop my first app, and now its done. but i am stuck with getting Family Controls Distribution entitlement. i`ve request that one month and half ago. but still get no response. I tried connect the apple developer support、send post on Forum、send code-level support on appstoreconnect. All completely disappeared into a black hole. I understand that you may be facing a significant backlog, waiting for nearly two months without any response or update regarding the Family Controls Distribution entitlement is extremely difficult for me to understand. I genuinely cannot understand why Apple’s review process is operating with such low efficiency.

Every notarization submission from my team is being rejected by the notary service with this message: statusCode: 7000 statusSummary: "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." 23 submissions in the past few days all returned this same rejection. Before submissions started returning Rejected, they would sit at "In Progress" indefinitely (sometimes for days), which I initially mistook for the in-depth-analysis slow-lane. Once Apple's queue cleared the backlog, every one of them surfaced as statusCode 7000. Ruled out on my side: Apple Developer Program membership is active License Agreement signed (days before the submissions) Code signing is valid (Developer ID Application chain), hardened runtime enabled, secure timestamp present ASC API key successfully submits and queries (the issue is in server-side processing/policy, not auth) Tested with both a minimal binary and a full app, same rejection Team ID: XSN9V8JZ75 Reference submission ID (the small isolated test): ba67edaf-c3d9-44dd-9974-5fc1811e0f72

These have been stuck in progress for a long time. Usually this process is fairly quick for this app: id: 92caae7f-1796-4928-bb35-72f5f2667786 id: 3645e93f-a8ac-4826-8a4a-690f980dde8e id: 3645e93f-a8ac-4826-8a4a-690f980dde8e What can be done, it is holding back deployments :(

I made a small 20MB .pkg installer for some Logic Pro Drum Machine Designer patches so the user doesn't have to manually place the files by hand. Tried to notarize 3 times, all attempts have been stuck "in progress" since yesterday and can't seem to get any log files that might explain where things are getting stuck. Are the duplicate submissions causing this and if so is there a way to de-duplicate? My first time doing this so when notarization was hanging on the first attempt I thought I had done something incorrectly. Not sure how to troubleshoot this and would appreciate any guidance.

Adding application ID to .pkg file seemed to work Original My modified version I created a .pkg file which installed to Applications folder and the app worked fine, but when I uploaded the app with transporter I got the message 'executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true'

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.

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

Team ID: C5S6LNK274 Issue Description: Starting from 2026-05-21 06:31:24 UTC, all my notarization submissions have been stuck in "In Progress" status for over 4 hours. Yesterday (2026-05-20) and all days before that, submissions completed successfully with status "Accepted". Today's submission history shows a clear queue blockage pattern: First stuck task: 94e73c5d-9c54-4ad2-9a63-f1f158aa6647 (created at 06:31:24) Total stuck tasks so far: 20 (all with status "In Progress") The 20 stuck tasks span from 06:31:24 to 10:05:02 UTC No tasks after 06:31 have completed Here is the stuck queue: createdDate: 2026-05-21T10:05:02.525Z id: 03055f30-afc3-42ca-ab42-25cfffa7aef3 status: In Progress createdDate: 2026-05-21T10:04:56.904Z id: 4f9daed0-a911-43db-aa00-74ba27cf6d69 status: In Progress createdDate: 2026-05-21T09:41:15.173Z id: 80e0677c-f9ce-4eb6-94d8-435ca6b0c05f status: In Progress createdDate: 2026-05-21T09:41:09.030Z id: 564c5cc5-6a1e-4ac7-8c87-e15c6a7e8a98 status: In Progress createdDate: 2026-05-21T09:39:01.267Z id: 0531d545-20f9-44eb-87b5-b6a0074f6efb status: In Progress createdDate: 2026-05-21T09:38:46.491Z id: dc67c99e-f7ee-4d50-8771-399ff77598f9 status: In Progress createdDate: 2026-05-21T09:26:12.019Z id: 65105788-6e03-4d18-a21d-e3229007f9d5 status: In Progress createdDate: 2026-05-21T09:26:02.085Z id: 508da919-d7e2-4357-af40-c66255f7765f status: In Progress createdDate: 2026-05-21T09:11:58.772Z id: b6cdbe19-22a2-4667-8104-86bd9ef476d5 status: In Progress createdDate: 2026-05-21T09:11:53.703Z id: e27c10ee-0cfa-4528-971e-a2582041ff83 status: In Progress createdDate: 2026-05-21T08:51:08.738Z id: 3defc9fe-57ed-4343-a312-45fb3aec3d9e status: In Progress createdDate: 2026-05-21T08:51:08.526Z id: a46c5740-c908-4744-a404-c6a79ce06883 status: In Progress createdDate: 2026-05-21T08:37:20.380Z id: fc5364be-0944-4e43-b277-12917db7c1c0 status: In Progress createdDate: 2026-05-21T08:37:16.382Z id: cf78e06d-105f-4fcf-bdd0-f67875ec8349 status: In Progress createdDate: 2026-05-21T08:04:48.709Z id: 7ffc08ca-52a8-48f8-8196-93faa65b7bce status: In Progress createdDate: 2026-05-21T08:04:34.254Z id: 087d0c51-eef1-4af7-85fd-52b4809c46f1 status: In Progress createdDate: 2026-05-21T07:31:57.221Z id: f9d2a9f8-ddbf-48d6-b3fc-95df8e442239 status: In Progress createdDate: 2026-05-21T07:31:51.103Z id: 7a1da2ed-8e39-40cd-a155-b23abab4aed9 status: In Progress createdDate: 2026-05-21T06:31:24.535Z id: 94e73c5d-9c54-4ad2-9a63-f1f158aa6647 status: In Progress createdDate: 2026-05-21T06:31:21.188Z id: b443dceb-c92e-47b4-8458-057e9304b60e status: In Progress Key observations: This is NOT a new developer account - submissions from yesterday and all prior days completed successfully No changes to the app bundle between yesterday (working) and today (stuck) All stuck submissions are for the same file (VV AI.zip) No error messages - just permanently "In Progress" What I've tried: Waited 4+ hours Stopped all new submissions (no retries after 10:05 UTC) Request: Could someone from Apple DTS please check the server-side queue status for Team ID: C5S6LNK274 Specifically, please check if the first stuck task (94e73c5d-9c54-4ad2-9a63-f1f158aa6647) has encountered an internal error that is blocking the entire submission queue. Thank you.

Hi Apple DTS, FivePrayer is a live App Store app and we are blocked by Family Controls (Distribution) after an app transfer. Bundle ID: com.fiveprayer.app Current team: FivePrayer LLC Previous team: Gansoft Inc. App Store: https://apps.apple.com/us/app/fiveprayer/id6755536905 This same app previously had Family Controls (Distribution) approved under Gansoft Inc. After the transfer to FivePrayer LLC, the capability did not carry over, so we had to request it again. It has now been pending for almost one month, and we cannot ship critical updates because Family Controls is a core dependency of the app. Is there a way to re-associate the previously approved entitlement with the transferred App ID, or route this to the correct Managed Capabilities / Entitlements team? Thank you.

Hello, Between April 20 and April 25 of this year, I submitted a request for the Family Controls Distribution entitlement through the following page: https://developer.apple.com/contact/request/family-controls-distribution After submitting the request, I clearly saw the message: “Thank you for your submission. We’ll review your request and contact you soon with a status update.” However, I have not received any further update or feedback since then. Afterward, I contacted Apple multiple times. Unfortunately, the responses I received consistently indicated that the relevant teams were unable to check the status or progress of the entitlement request, and no clear timeline or follow-up commitment was provided. Eventually, I was informed via email that the issue had already been escalated to the operations team for handling. However, many more days have now passed without any progress or update. At this point, it has been nearly one month since I submitted the entitlement request, yet I still have not received any result, status update, or meaningful feedback. I genuinely do not understand why the tracking and communication process for this entitlement request is so unclear and slow. I would sincerely appreciate it if the relevant team could provide a clear update regarding the current status of my request and the expected next steps. Thank you.

It has been 20 days since we applied for Family Controls (Distribution) permission, but the status still shows as Submitted. Is there any way to expedite the review process?

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.

Hello, Between April 20 and April 25 of this year, I submitted a request for the Family Controls Distribution entitlement through the following page: https://developer.apple.com/contact/request/family-controls-distribution After submitting the request, I clearly saw the message: “Thank you for your submission. We’ll review your request and contact you soon with a status update.” However, I have not received any further update or feedback since then. Afterward, I contacted Apple multiple times regarding this issue through Case ID: 102881595688. Unfortunately, the responses I received consistently indicated that the relevant teams were unable to check the status or progress of the entitlement request, and no clear timeline or follow-up commitment was provided. Eventually, I was informed via email that the issue had already been escalated to the operations team for handling. However, many more days have now passed without any progress or update. At this point, it has been nearly one month since I submitted the entitlement request, yet I still have not received any result, status update, or meaningful feedback. I genuinely do not understand why the tracking and communication process for this entitlement request is so unclear and slow. I would sincerely appreciate it if the relevant team could provide a clear update regarding the current status of my request and the expected next steps. Thank you.

Hello, Between April 20 and April 25 of this year, I submitted a request for the Family Controls Distribution entitlement through the following page: https://developer.apple.com/contact/request/family-controls-distribution After submitting the request, I clearly saw the message: “Thank you for your submission. We’ll review your request and contact you soon with a status update.” However, I have not received any further update or feedback since then. Afterward, I contacted Apple multiple times regarding this issue through Case ID: 102881595688. Unfortunately, the responses I received consistently indicated that the relevant teams were unable to check the status or progress of the entitlement request, and no clear timeline or follow-up commitment was provided. Eventually, I was informed via email that the issue had already been escalated to the operations team for handling. However, many more days have now passed without any progress or update. At this point, it has been nearly one month since I submitted the entitlement request, yet I still have not received any result, status update, or meaningful feedback. I genuinely do not understand why the tracking and communication process for this entitlement request is so unclear and slow. I would sincerely appreciate it if the relevant team could provide a clear update regarding the current status of my request and the expected next steps. Thank you.

I'm posting this so other devs hitting error 7000 know they're not alone, and so this gets some visibility outside the support ticket black hole. Timeline: End of February 2026: first notarization attempts. All rejected with status code 7000 March 1st: first support case opened Today, beginning of May: still blocked. Still error 7000 Four cases: 102833704616, 102836645198, 102842517951, 102865000390. Different advisors each time. I've uploaded my government ID twice. When I ask for a status, the answer is "I'll get back to you when I have news." Then silence. My setup is fine. Team ID is Y564MF82K8. App is signed with Developer ID Application, hardened runtime, secure timestamp, no get-task-allow, deep verify clean. Apple rejects the submission before inspecting the binary. The block is on Apple's side. Somebody needs to push a button but they cannot agree who needs to push it, so they just pass it from one department to another. The "correct escalation path" doesn't work. Quinn (Apple DTS engineer) keeps saying on this forum that error 7000 is administrative and the path is Developer Program Support (https://developer.apple.com/forums/thread/118465?answerId=379585022#379585022). I followed that path four times. The cases just sit there. Threads on this forum about error 7000 go back to 2019. Six years. Devs report cases stuck for weeks, months, with the same scripted responses. Apple knows. Apple does nothing. I'm a solo dev and I want to do a proper launch of my SaaS on all major desktop platforms. I paid the $99. I built the app. I signed every agreement. I cannot launch on macOS because Apple's departments cannot agree on who needs to push a button. If anyone here has actually unblocked error 7000, please share what worked. The official path obviously doesn't.

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!