You can now easily request access to managed capabilities for your App IDs directly from the new Capability Requests tab in Certificates, Identifiers & Profiles > Identifiers. With this update, view available capabilities in one convenient location, check the status of your requested capabilities, and see any notes from Apple related to your requests. Learn more about capability requests.

General: Forums topic: Code Signing Forums subtopics: Code Signing > General, Code Signing > Certificates, Identifiers & Profiles, Code Signing > Notarization, Code Signing > Entitlements Forums tags: Code Signing, Signing Certificates, Provisioning Profiles, Entitlements Developer Account Help — This document is good in general but, in particular, the Reference section is chock-full of useful information, including the names and purposes of all certificate types issued by Apple Developer web site, tables of which capabilities are supported by which distribution models on iOS and macOS, and information on how to use managed capabilities. Developer > Support > Certificates covers some important policy issues Bundle Resources > Entitlements documentation TN3125 Inside Code Signing: Provisioning Profiles — This includes links to the other technotes in the Inside Code Signing series. WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing Certificate Signing Requests Explained forums post --deep Considered Harmful forums post Don’t Run App Store Distribution-Signed Code forums post Resolving errSecInternalComponent errors during code signing forums post Finding a Capability’s Distribution Restrictions forums post Signing code with a hardware-based code-signing identity forums post New Capabilities Request Tab in Certificates, Identifiers & Profiles forums post Isolating Code Signing Problems from Build Problems forums post Investigating Third-Party IDE Code-Signing Problems forums post Determining if an entitlement is real forums post Code Signing Identifiers Explained forums post Mac code signing: Forums tag: Developer ID Creating distribution-signed code for macOS documentation Packaging Mac software for distribution documentation Placing Content in a Bundle documentation Embedding nonstandard code structures in a bundle documentation Embedding a command-line tool in a sandboxed app documentation Signing a daemon with a restricted entitlement documentation Defining launch environment and library constraints documentation WWDC 2023 Session 10266 Protect your Mac app with environment constraints TN2206 macOS Code Signing In Depth archived technote — This doc has mostly been replaced by the other resources linked to here but it still contains a few unique tidbits and it’s a great historical reference. Manual Code Signing Example forums post The Care and Feeding of Developer ID forums post TestFlight, Provisioning Profiles, and the Mac App Store forums post For problems with notarisation, see Notarisation Resources. For problems with the trusted execution system, including Gatekeeper, see Trusted Execution Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello! I am hoping a DTS engineer or someone who knows the Capability Requests portal can help, because I am stuck between a written support confirmation and what the portal actually shows. Background. We are building a native macOS iSCSI initiator for SOHO and home NAS use, developed over close to two years. A userspace daemon runs the iSCSI protocol and a DriverKit system extension presents the remote LUN as a block device. The code is essentially complete. Only the DriverKit extension cannot be signed, loaded and validated without the entitlement. We submitted request 32PC8MGU57 for two entitlements: com.apple.developer.driverkit.family.block-storage-device for the extension com.aviontex.iscsi.AviontexISCSI.AviontexInitiator com.apple.developer.driverkit.userclient-access for the app com.aviontex.iscsi.AviontexISCSI, scoped to the extension bundle id The problem. On June 25 Developer Support confirmed in writing that both entitlements were granted. The portal does not match that: Block Storage Device: No Requests: on both App IDs UserClient Access: Assigned: on the app SCSI Controller: Submitted: on the app So the one entitlement we actually need, Block Storage Device, shows as never requested, even though request 32PC8MGU57 covered it and support confirmed the grant. The case was escalated to the senior team on July 2 (case 102922935570). Follow-up emails since then have not received a response. Why Block Storage Device specifically Our initiator has no PCI or Thunderbolt bus and no DMA path, so SCSIControllerDriverKit does not fit. This is confirmed by DTS in thread 776020, where Kevin Elliott explains that SCSIControllerDriverKit passes data through fBufferIOVMAddr as a physical address with no mechanism to convert it into a VM address the dext can access. He also notes it cannot be used with any bus other than PCI or Thunderbolt. Block Storage Device is therefore the family we need. My questions: Am I reading the portal correctly: Block Storage Device not requested, UserClient Access assigned, SCSI Controller submitted? From here, what is the correct way to get Block Storage Device onto these two App IDs, with both the Development and the Distribution grant, since our public beta depends on Distribution? Should I submit a new request through the Capability Requests tab or does the escalated case handle it? Is there any way to get visibility on the escalated case, since email follow-ups are not being answered? A full technical justification is prepared and we are happy to share the source code. Any guidance would be appreciated. Thank you.

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, My NEURL Filter configuration (ID 9f3cbff8-63de-4c69-bf68-c19cd1c5d842) was approved on August 5, 2026, but it turned out to be attached to the wrong Apple Developer Team — an old individual account (S5VDH23BBZ) I no longer have access to, instead of my actual organization team, KRKJ76BC7W (SCOTTO), which owns and signs the app (bundle ID com.dropbet.DropBet). I contacted Developer Support, who said they couldn't transfer it and suggested replying to the original approval email — I did (on 08/08, then several times) with no response. I then tried resubmitting the same configuration under the correct team (KRKJ76BC7W), but the portal rejected it with: "A configuration with the same PIR Server Domain already exists." So a fresh submission is technically impossible while the original stays attached to the wrong account — the only real fix is transferring or re-attaching the existing approved configuration to KRKJ76BC7W. Has anyone dealt with this kind of Team ID mix-up before, or know who on the Network Extension / NEURL Filter team could help reassign an approved configuration? Happy to provide any additional details. Thanks in advance.

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]

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'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

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

App Store Connect rejects my iOS Flutter app with error 90035: “Code failed to satisfy specified code requirement(s).” The error affects the main app executable, App.framework, and Flutter.framework. Environment: macOS 26.5.2 Xcode 26.6 Flutter 3.44.8 Individual Apple Developer Program membership The Release archive and App Store IPA build successfully. The exported IPA is signed with an Apple Distribution certificate and contains the correct TeamIdentifier. However, verification reports: Runner.app: valid on disk Runner.app: does not satisfy its designated Requirement The certificate Common Name contains a non-ASCII character: “Ç”. The generated designated requirement appears to represent this character using a decomposed Unicode form. I suspect a Unicode-normalization mismatch between the certificate Common Name and the embedded designated requirement. I am also unable to create a local Apple Distribution certificate: Xcode Manage Certificates reports: “The data couldn’t be read because it isn’t in the correct format.” The Apple Developer certificate portal reports “An unexpected error occurred” after I upload a valid CSR. Has anyone encountered this issue when an Apple Distribution certificate Common Name contains a non-ASCII character? Is there a supported way to regenerate the cloud-managed certificate or have Apple repair the team’s certificate state? I can provide sanitized codesign output if an Apple engineer needs additional diagnostic information.

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.

I'm asking about how to ask for an addition to a managed entitlement, where we already have a grant of that entitlement (with a different value) and we already have other managed entitlements granted. This post https://developer.apple.com/forums/thread/789176 tells me I can request entitlements at the Requests tab here: https://developer.apple.com/account/resources/, which leads me to this form: https://developer.apple.com/contact/request/system-extension/ The form URL doesn't specify a particular App Identifier, but is the Identifier implied with this form submission? Or, put another way, is the entitlement we're asking for attached only to the Team ID, or also to the bundle ID of the app which is going to use the entitlement? So if I made another app which talks to my dext, I'd have to ask again for userclient-access to the same dext, but from a different bundle ID? The form says "Which DriverKit entitlements do you need" and "select all that apply", but I'm unclear about whether I need to request ALL the DriverKit entitlements we need for all our apps, or only for the specific App Identifier I reached this form from. It also isn't clear if I need to check both the USB Transport and the UserClient Access boxes in my case. We already have UserClient Access granted for at least one bundle ID, and I want to add another. We already have USB. Transport granted for two different vendor IDs. Do I need to mention that in my request here, and also check the USB Transport box, although I'm not requesting any new vendor ID values? I don't want to end up with new profiles which break new builds of existing apps which were relying on previously-granted entitlements that are now missing from the newly-generated profiles. Here: https://developer.apple.com/forums/thread/822652 user JackLongbow submitted a request for UserClient Access for two bundle IDs, presumably in the form of a simple two-line string like this: com.turing.TuringTouch com.turing.TuringTouch.TouchDriver but the resulting provisioning profile was malformed, it contained this value under com.apple.developer.driverkit.userclient-access <string>com.turing.TuringTouch com.turing.TuringTouch.TouchDriver</string> the Forum post said that the approved entitlement looks like this: <array> <string>com.turing.TuringTouch</string> <string>com.turing.TuringTouch.TouchDriver</string> <string>com.turing.TuringTouchDriver</string> <string>com.turing.virtualpad</string> <string>com.turingdraw.DigidrawTouch.DigidrawDriver</string> </array> Should I be formatting my request as above, as a chunk of xml, or is a plain text list of bundle IDs, one per line, acceptable? Is there a way for us to get a summary of all the managed entitlements already granted to our team? At present, it seems like I have to pick a particular profile, download it, and QuickLook at it - but not all profiles contain all entitlements, just as apps don't have to claim all the entitlements the profile offers .

When updating our Developer ID Application certificate, we encountered an issue where the Apple Developer portal consistently returns the exact same certificate file, regardless of the CSR submitted. Observed Behavior & Test Steps: We generated multiple new CSRs using both OpenSSL in the command line and Keychain Access (Certificate Assistant) on macOS following Apple's official guide: https://developer.apple.com/help/account/certificates/create-a-certificate-signing-request We uploaded these distinct CSRs to the Developer Portal (Certificates -> Add New -> Developer ID Application) on separate attempts. After downloading the issued .cer files, we performed a binary comparison (diff/checksum) across all of them. The comparison confirmed that the downloaded certificate files are 100% binary identical across all attempts. Key Pairing Verification: To further verify the key pairing, we checked the public key modulus hashes of the local Private Key and the downloaded .cer file via OpenSSL: Check local Private Key Modulus Hash: openssl rsa -noout -modulus -in new_developer_id.key | openssl md5 Check downloaded Certificate Modulus Hash: openssl x509 -noout -modulus -in developer_identity.cer -inform DER | openssl md5 The resulting MD5 hashes do not match. Attempting to export them to PKCS#12 (.p12) consistently fails with the error: no certificate matches private key. Question: Could this be related to a profile caching or binding issue on our team account, or is there a recommended way to clear this state and obtain a newly issued certificate? Any guidance or advice would be greatly appreciated.