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!

Your development team has reached the maximum number of registered iPhone devices. I am use the free provisioning file. So how can I delete old device and use my new iPhone to develop my app. only way is use a paid account? or register a new Apple ID?

Hello, I have requested entitlements for my DriverKit-based driver, but the status has been "Submitted" since May 24, 2026. Below are the details of my request. Is there any way to expedite the process, as these entitlements are necessary for distributing the app? Also, what is the preferable way to follow up in such cases? Entitlements: DriverKit USB Transport - VendorID (0x0BDA), DriverKit UserClient Access Team: K89F9CL4ZU Request Id: 7W5RQ3D2X6 Requested At: May 24, 2026 Type: Team Status: Submitted Many thanks

Hello, trying to create a simple utility for personal use using Swift Playgrounds. I want to install the app locally on my iPad, I don’t want to have Swift Playgrounds open to run. Have not been able to resolve. See below: Environment: iPadOS Version: iPadOS 26.6.2 (23G90) Hardware: iPad Pro M4 Swift Playgrounds Version: 4.5+ Steps to Reproduce: Create a new App project (+ App button). Open App Settings > Team & Bundle Identifier. Ensure a free Apple ID is signed in. Tap the user's name under the "Team" list. Expected Result: The UI should register the selection, generate a local provisioning profile, and reveal the "Install on this iPad" button. If the user needs to accept a web agreement, an alert should guide them. Actual Result: Nothing happens. The row registers the touch visually, but the state remains "No Team Selected, Unknown Bundle Identifier". No error message is thrown, blocking local installation entirely. Thanks

I can’t launch an Xcode development build on my iPhone. The iPhone says “Unable to Verify App — An internet connection is required to verify trust of the developer,” and Xcode says the Developer App Certificate is not trusted. The app builds and installs successfully. I’ve tried Wi-Fi and cellular, and Developer Mode is enabled. A browser request to ppq.apple.com returned “OK,” but verification still fails. Could this be a PPQ verification issue?

We are building a native macOS client for an isolated numerical research runtime. Can the public launch/spawn and library-constraint mechanisms support the following combined admission requirement, or is their documented guarantee narrower? An independent verifier must establish that a hardware-bound, nonexportable TLS client identity is currently usable only by the exact approved native client build on the intended device and under the complete approved principal. Before that client's first execution, an independent enforcement point must also authenticate its complete executable dependency set, including the loader, shared-cache dependencies, weak dependencies and dynamically loaded code. The launch-constraint documentation describes kernel checks, launchd SpawnConstraint and cdhash facts. Library constraints restrict individual loads, including dlopen. We have not established whether this gives the required whole-closure guarantee before first execution, how the independently trusted verifier can prove enforcement is active, or how it binds to current key-use confinement rather than key origin or application-group membership. Endpoint Security exec authorization is another possible enforcement substrate, but the SDK states that exec target code-signing fields precede on-demand code-page validation. We have not treated that event as a complete closure proof. For this combined admission question, please identify the supported evidence producer, public evidence representation, independently trusted root, verifier and pre-execution enforcement point, with freshness/revocation limits. If the public APIs only establish narrower guarantees, please identify those limits. We seek public API guidance, not internal Apple settings or completion of our development work. References: https://developer.apple.com/documentation/security/defining-launch-environment-and-library-constraints https://developer.apple.com/documentation/security/applying-launch-environment-and-library-constraints https://developer.apple.com/documentation/endpointsecurity/monitoring-system-events-with-endpoint-security

Hello, What is the supported revocation-status source or documented validation procedure for the following exact intermediate certificate, encountered in signatures on Apple-supplied Command Line Tools Python 3.9? This concerns first-party Apple code signing, not Developer ID, public TLS, or S/MIME. Certificate details Subject: CN=Apple Code Signing Certification Authority, OU=Apple Certification Authority, O=Apple Inc., C=US Serial: 0x21 (33 decimal) DER SHA-256: 5bdab1288fc16892fef50c658db54f1e2e19cf8f71cc55f77de2b95e051e2562 Validity: 2011-10-24 17:39:41 UTC to 2026-10-24 17:39:41 UTC Issuer: Apple Root CA Issuer DER SHA-256: b0b1730ecbc7ff4505142c49f1295e6eda6bcaed7e2c68c5be91b5a11001f024 Embedded CRL distribution point: http://www.apple.com/appleca/root.crl This intermediate has no Authority Information Access extension. Retained observations from 1 October 2026 At approximately 16:59 UTC, one request to: https://www.apple.com/appleca/root.crl recorded HTTP 200 and returned a 511-byte CRL with: thisUpdate: 2025-03-10 21:28:16 UTC nextUpdate: 2025-07-23 21:28:16 UTC SHA-256: 02b300d7e2edc09a33c0e98c0291da47932320761f6060ea8d7624f6e344f1dd At approximately 20:02 UTC, a separate request to: https://crl.apple.com/root.crl recorded HTTP 404 and returned a 287-byte HTML error body. This was an alternative HTTPS candidate; it does not establish the behavior of its HTTP counterpart. Neither request followed redirects or retried. Response bodies and normalized collector records were retained, but raw HTTP headers and stderr were not retained. These are limited observations from that date, not a claim about global service availability or key compromise. Questions Which current Apple-published source provides signed revocation-status evidence covering this exact intermediate? If the distribution point has moved, what is the authoritative replacement and how is its scope established? Which CP/CPS or documented first-party validation mechanism applies to this certificate? In particular, does Apple Certificate Policy v7.0 (20 March 2026), sections 2.1 and 4.10, cover this chain? If a public revocation-status service is no longer supported for this legacy first-party CA, what documented verification approach should be used, or which Apple team handles this question? I am not treating an expired CRL or an HTTP error as evidence that the certificate is revoked. I am also not assuming that a standalone CRL lookup reproduces macOS trust evaluation. I am asking for the supported source and verification procedure, not for a way to bypass validation, change trust settings, or re-sign Apple binaries. Thank you.

Hi everyone, I’m trying to get my iOS app running on a physical iPhone for real-device testing, but I’m blocked by a persistent code-signing issue in Xcode. The project compiles successfully, but when I select my physical iPhone as the destination, the build fails during the signing stage: errSecInternalComponent Command CodeSign failed with a nonzero exit code The app therefore never gets installed on the device. What I’ve checked: Xcode recognises my Apple Development certificate. security find-identity -v -p codesigning reports the identity as valid. The certificate is present in my login keychain. Keychain Access shows the certificate with its private key underneath it. My login keychain is unlocked. The keychain search list contains my login keychain and the System keychain. I checked both keychains for the corresponding private key. There are no custom trust settings. The particularly strange part is that signing fails outside Xcode too. I tested signing /usr/bin/true directly using the same Apple Development identity, and that also fails with: errSecInternalComponent I also attempted to repair the private key’s signing access/partition list, but received: The specified item is no longer valid. It may have been deleted from the keychain. Certificate situation Xcode → Manage Certificates currently shows two Apple Development certificates: One current certificate One older certificate marked “Not in Keychain” When I try to create a new Apple Development certificate, Xcode says: You already have a current Development certificate or a pending certificate request. This is the only Mac I have used with this Apple Developer account, so there isn’t another Mac from which I can recover or export the original private key. What should I do? I’m trying to understand the safest next step without making the certificate/keychain situation worse. Should I: Revoke the older certificate and create a new development certificate/private-key pair? Try to repair the existing signing identity/private key? Take another Apple-supported approach? The immediate goal is to get the app onto a physical iPhone so I can begin real-device testing, followed by QA/beta testing and App Store launch. Any advice on what is actually causing errSecInternalComponent in this situation, and the safest way to resolve it, would be greatly appreciated. I can provide additional Terminal output, screenshots, or Xcode logs if helpful. Thanks!

I am seeing a reproducible Developer ID code-signing issue on an Apple Silicon Mac running macOS 26.6.2. A Universal macOS app and its Quick Look extension (arm64 + x86_64) are signed with a newly issued Developer ID Application certificate using Hardened Runtime and a secure timestamp. Immediately after signing, all verification succeeds, including: codesign --verify --strict --verbose=4 and architecture-specific verification for both arm64 and x86_64. At this point, codesign reports: valid on disk satisfies its Designated Requirement The expected Developer ID authority chain and TeamIdentifier are present. However, after some time, without modifying the bundle or executable, the exact same Quick Look extension starts failing verification for both architectures: invalid signature (code or signature have been modified) codesign -d then reports: Authority=(unavailable) Info.plist=not bound The executable SHA-256, size, and mtime remain unchanged. I also copied the now-invalid extension to a different directory, creating completely new inodes. The copy remains invalid. I verified that: all regular files in the original and copy are byte-for-byte identical executable SHA-256 is identical _CodeSignature/CodeResources is identical there are no hard links (link count is 1) there are no extended attributes anywhere in the extension com.apple.provenance, com.apple.quarantine, and com.apple.FinderInfo are absent copying the bundle to a new inode does not restore signature validity The affected extension executable currently has: SHA-256: 3b36d1aca258a371311a9c94e93d10606edc184ea120dd252cf230a251c67243 CDHash arm64: 178ff5b7b2cedbed00ec6bc07536d168e22d9ba5 CDHash x86_64: ada914101f5b107704b78958520c904c4f022894 Signing environment Developer ID Team ID: XY2B8MLPV8 The Developer ID Application certificate is newly issued with a new RSA 2048-bit private key. I have also observed the following message in the Security log during signing: CSSMERR_CSP_INVALID_KEYATTR_MASK No new occurrence of that error is logged when subsequently verifying the already-invalid extension. Troubleshooting already performed I have: issued a completely new Developer ID Application certificate with a new RSA 2048-bit private key verified the certificate chain and code-signing policy successfully reproduced related Keychain/identity problems in a fresh macOS user account tested with a newly created independent Keychain tested in Safe Mode reinstalled macOS without erasing user data Before reinstalling macOS, even security find-identity -v -p codesigning eventually failed to recognize otherwise valid Developer ID identities. After reinstalling macOS, security find-identity -v -p codesigning correctly reports all identities again. I then performed a durability test using the new Developer ID identity on a minimal Universal Mach-O binary. Verification succeeded: immediately after signing after approximately 2 minutes after approximately 5 minutes after copying the binary to a different directory The minimal binary remained valid throughout. However, the problem subsequently reproduced with the actual Quick Look extension. Notarization The application was packaged in a Developer ID Installer-signed PKG and submitted to Apple Notary Service. The submission was Accepted, stapling and validation succeeded, and Gatekeeper accepted the notarized PKG. Notarization submission ID: 54dc0de7-5089-4b8c-9c10-b5a74df8df97 I initially suspected the packaging process, but I subsequently found that the original pre-PKG Quick Look extension itself had become invalid. Therefore, this does not appear to be caused by PKG creation or extraction. Questions What could cause a Developer ID signature that initially verifies successfully to become invalid later when the signed files themselves have not changed? Is there a Security.framework / codesign diagnostic that can show exactly which part of the CMS signature or CodeDirectory validation is failing? Are there any known macOS 26.x issues involving code-signing validation or CSSMERR_CSP_INVALID_KEYATTR_MASK that could explain this behavior? I would be happy to collect additional Security logs, codesign diagnostics, or a sysdiagnose if that would help identify the cause.

I am diagnosing a trust failure for an archived iOS arm64 app, without changing trust settings or rebuilding speculatively. Environment: macOS 26.6.2 (25G83), Xcode 27.0 (27A266a), as reported by installed public metadata. The diagnostic is a non-interactive Python helper calling the installed Security/CoreFoundation APIs through a bounded child-process runner in a desktop coding-agent session. This is not an Xcode GUI operation; an effect of the session, keychain/cache, or service access has not been established. Observed results: The app's embedded code CMS supplies three certificates. One explicitly identified signer matches the stored signer receipt in memory. The helper places the signer first, followed by the other supplied certificates. It uses SecPolicyCreateWithProperties(kSecPolicyAppleCodeSigning), SecTrustCreateWithCertificates, and SecTrustSetNetworkFetchAllowed(false). The status-returning setup calls succeed. Disabling intermediate fetching does not prove that all OS revocation/cache/network activity is absent. One SecTrustEvaluateWithError call returns false. The top-level CFError and its single kCFErrorUnderlyingErrorKey child both report NSOSStatusErrorDomain / -26276. The child has no further underlying-error key. This designated key chain was collected completely; other userInfo and localized descriptions were not collected. A prior recorded evaluation returned a chain containing only the signer. The latest diagnostic did not request another evaluated chain. Supplied certificates and the evaluated/trusted chain are distinct observations. Separate metadata collection found three distinct supplied certificates within their validity intervals at the observation time. Issuer/subject names matched signer → supplied issuer → third certificate, and the third had equal issuer/subject names. This does not verify issuer signatures, CA purpose, or root trust. Existing independent codesign --verify --deep --strict verification exits 1 with CSSMERR_TP_NOT_TRUSTED for arm64; it does not identify the failing certificate. The extraction/trust helper does not validate the CMS/CodeDirectory signature. The public SecTrust header allows false both for denied trust and for an evaluation that cannot complete. The inspected installed SecBase header defines errSecInternalComponent as -2070 and errSecDecode as -26275; it provided no name for -26276. I am not treating -26276 as either code or as proof of certificate/profile damage, sandbox denial, or trust-service failure. Questions: What supported interpretation or specific conditions explain -26276 on this public Code Signing API path, including the underlying error repeating the same domain/code? What smallest independent public field or observation distinguishes policy rejection from evaluation failure while keeping the policy, intermediate-fetch=false, and trust settings unchanged? The underlying key chain supplies no more specific code. How should this be interpreted alongside CSSMERR_TP_NOT_TRUSTED from strict verification of an archived iOS app? What specific evidence separates an embedded-signature/signing-input defect from a local trust or evaluation-context failure and justifies a targeted correction? No certificate names, fingerprints, DER, profile identifiers, account details, private paths, raw payloads, or attachments are included.

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

Hi everyone, I'm building rewindDV, a macOS app for preserving recordings from older FireWire tape cameras and decks. Capture works on our development hardware, and I'm trying to get the PCI transport entitlement needed to move forward with Developer ID signing and notarization so testers can use it with SIP enabled. Our two original requests have been pending since August 1. Developer Support confirmed that DriverKit and UserClient Access are present, but PCI transport approval is still missing. They suggested resubmitting, so I sent a consolidated request today and added the new number to the existing support case. Here are the references: Original requests: 265MP3ZN42 and 49L9RB632H — August 1, 2026; both still showed Submitted today. New request: 5728BY853G — October 3, 2026. Developer Support case: 102964703572. We're requesting DriverKit PCI (PrimaryMatch) for Developer ID distribution, specifically com.apple.developer.driverkit.transport.pci with IOPCIPrimaryMatch = 0x590111C1. That's PCI vendor 0x11C1 (4545 decimal), device 0x5901 (22785 decimal): the Agere/LSI FireWire OHCI host controller, not the downstream camera or deck. We develop the software, not the controller, and are requesting only that exact pair. PCI development access is already assigned. Could someone familiar with the DriverKit review process check whether the new request is in the right queue and whether we're missing anything? I'd also appreciate guidance on which request to keep active, since I haven't cancelled either original. I understand there's no guaranteed turnaround time. After nine weeks, I'd just like to make sure nothing is waiting on us. Happy to provide more technical details if helpful. Thanks for your help!

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.

My two apps, com.qrafter.Qrafter and com.qrafter.QrafterPro, have been on the iOS App Store since 2011, and their App IDs still use my team's unique App ID prefix 99T3FA87E9 instead of the Team ID GH4CGS3B5H. I'm adding native Mac versions to the same App Store records (universal purchase), so the bundle IDs can't change. Every profile Apple generates for these App IDs pairs com.apple.application-identifier = 99T3FA87E9.com.qrafter.Qrafter with com.apple.developer.team-identifier = GH4CGS3B5H. iOS uploads are accepted, but Mac App Store validation (xcrun altool --validate-app -t macos) rejects even a minimal one-window app with exactly two errors: Invalid code signing entitlements. … the "99T3FA87E9.com.qrafter.Qrafter" value for the com.apple.application-identifier key … isn't supported. This value should be a string that starts with your Team ID, followed by a dot ("."), followed by the bundle ID. (90286) Invalid Provisioning Profile. … Invalid 'com.apple.application-identifier' entitlement value. (91130) Following "Code Signing Identifiers Explained" (thread 811970), I requested the prefix migration through Contact Us on 4 September (case 102953576372). On 20 September Developer Support asked me to confirm the one-time keychain data loss described in "App ID Prefix Change and Keychain Access" (thread 706128), and I confirmed. Since then the case has had no reply despite follow-ups on 24 and 29 September, and as of 6 October both App IDs still show 99T3FA87E9. Two questions: Is there anything else I need to do to get case 102953576372 completed, or a better route to escalate it? Is there any way to ship a Mac App Store build for these App IDs before the migration, or is the migration the only path? I have a minimal sample project and the full validation log if that helps.

Hello, My first notarization request with a new Developer ID account has been "In Progress" since October 2, 2026, with no result and no log. Submission ID: 204f7ef7-01ae-4d0e-a0c3-a4678edf93e6 Created: 2026-10-02T13:06:27Z File: settle-notarize-ELdioM.zip (macOS menu bar app, bundle ID com.settlewifi.Settle, version X.X) Team ID: XXXXXXXXXX Submitted with notarytool from my Mac; the upload completed and the request appears in notarytool history, still "In Progress" (checked on October 5) I understand 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, 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.

Hi, Canary Mail has had approval to use the Default Mail App entitlement for years. We have a longstanding Xcode Cloud export failure involving com.apple.developer.mail-client. In our latest iOS build, compilation and archiving succeed (ARCHIVE SUCCEEDED). All three subsequent exports—App Store, Ad Hoc, and Development—fail with the same error: error: exportArchive Entitlement com.apple.developer.mail-client not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. We checked the signing configuration and Developer portal: • The main app requests com.apple.developer.mail-client = true. • An existing manual App Store provisioning profile is active until June 2027. Decoding the downloaded profile confirms it contains com.apple.developer.mail-client = true and matches the app's bundle identifier and team. • Local development archiving also succeeds with our existing manual Default Mail App development profile. • However, Default Mail App is absent from both the Capabilities and Capability Requests tabs for this App ID. This appears related to these reports, where Apple corrected the entitlement's distribution grants: https://developer.apple.com/forums/thread/774506 https://developer.apple.com/forums/thread/800072 Our case differs because all three export modes fail, rather than only Ad Hoc. Apple's provisioning documentation describes migrating older additional entitlements into App ID managed capabilities for cloud-managed signing: https://developer.apple.com/help/account/reference/provisioning-with-managed-capabilities Could our older Default Mail App approval still be available through manual provisioning profiles but not migrated to the managed capability used by Xcode Cloud? What is the correct support route to have Apple verify/migrate this approval and ensure Development, Ad Hoc, and App Store export are supported? If the grant is already correct internally, could this be a Cloud provisioning service issue? Is there a supported way to use our approved manual App Store profile for Xcode Cloud's built-in export while this is investigated? We need to preserve default-mail functionality, so removing the entitlement is not a suitable production workaround. We can provide the full distribution logs and profile details privately to Apple Support. Thank you.