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"

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

Hi Apple Developer Support, The ARM64 build of our macOS app, has remained In Progress for over five days. The x64 build of the same release, submitted shortly afterward, has been accepted. Pending ARM64 submission: Submission ID: f2aa218e-680c-4497-a977-17b7f3d85ae1 Submitted: September 23, 2026, at 12:57:14 UTC Archive: signed-arm64.zip Status: In Progress Accepted x64 submission: Submission ID: bbae43b0-3846-46d0-a160-3b3af3aede9b Submitted: September 23, 2026, at 12:59:28 UTC Archive: signed-x64.zip Status: Accepted I checked both submissions again on today using xcrun notarytool info. For the ARM64 submission, notarytool log returns: Submission log is not yet available or submissionId does not exist However, notarytool info successfully finds that submission and still reports In Progress. Could someone please check whether this submission is still undergoing additional analysis, or whether there is an issue requiring action on our side? If another support channel is more appropriate after this length of time, please let us know. This is blocking our Apple Silicon release. We would appreciate any guidance.

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.

I regularly see folks run into problems with their Developer ID signing identities. Historically I pointed them to my posts on this thread, but I’ve decided to collect these ideas together in one place. If you have questions or comments, start a new thread here on DevForums and tag it with Developer ID so that I see it. IMPORTANT Nothing I write here on DevForums is considered official documentation. It’s just my personal ramblings based on hard-won experience. There is a bunch of official documentation that covers the topics I touch on here, including: Xcode documentation Xcode Help Developer Account Help Developer > Support > Certificates For a lot more information about code signing, see the Code Signing Resources pinned post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" The Care and Feeding of Developer ID Most Apple signing assets are replaceable. For example, if you accidentally lose access to your Apple Development signing identity, it’s a minor inconvenience. Just use the Developer website to revoke your previous certificate and create a replacement. Or have Xcode do that for you. IMPORTANT If you don’t understand the difference between a certificate and a digital identity, and hence signing identity, read Certificate Signing Requests Explained before reading this post. Some signing assets are precious. Losing access to such assets has significant consequences. Foremost amongst those are Developer ID signing identities. These allow you to sign Mac products that ship independently. Anyone with access to your Developer ID signing identity can sign code as you. This has a number of consequences, both for you and for your relationship with Apple. Identify a Developer ID Signing Identity A Developer ID signing identity consists of two parts: the certificate and the private key. There are two different flavours, identifiable by the subject name in the certificate: Developer ID Application — This is named Developer ID Application: TTT, where TTT identifies your team. Use this to sign code and disk images. Developer ID Installer — This is named Developer ID Installer: TTT, where TTT identifies your team. Use this to sign installer packages. Note If you do KEXT development, there’s a third flavour, namely a KEXT-enabled Developer ID Application signing identity. For more details, see KEXT Code Signing Problems. This post focuses on traditional signing identities, where you manage the private key. Xcode Cloud introduced cloud signing, where signing identities are “stored securely in the cloud”. These identities have the Managed suffix in Certificates, Identifiers, and Profiles. For example, Developer ID Application Managed is the cloud signing equivalent of Developer ID Application. To learn more about cloud signing, watch WWDC 2021 Session 10204 Distribute apps in Xcode with cloud signing. To identify these certificates ‘in the wild’, see Identifying a Cloud Managed Signing Certificate. Limit Access to Developer ID Anyone with your Developer ID signing identity can sign code as you. Given that, be careful to limit access to these signing identities. This is true both for large organisations and small developers. In a large organisation, ensure that only folks authorised to ship code on behalf of your organisation have access to your Developer ID signing identities. Most organisations have some sort of release process that they use to build, test, and authorise a release. This often involves a continuous integration (CI) system. Restrict CI access to only those folks involved in the release process. Even if you’re a small developer with no formal release process, you can still take steps to restrict access to Developer ID signing identities. See Don’t Leak Your Private Key, below. In all cases, don’t use your Developer ID signing identities for day-to-day development. That’s what Apple Development signing identities are for. Create Developer ID Signing Identities as the Account Holder Because Developer ID signing identities are precious, the Developer website will only let the Account Holder create them. For instructions on how to do this, see Developer Account Help > Create certificates > Create Developer ID certificates. For more information about programme roles, see Developer > Support > Program Roles. IMPORTANT In an Organization team it’s common for the Account Holder to be non-technical. They may need help getting this done. For hints and tips on how to avoid problems while doing this, see Don’t Lose Your Private Key and Don’t Leak Your Private Key, both below. Limit the Number of Developer ID Signing Identities You Create Don’t create Developer ID signing identities unnecessarily. Most folks only need to create one. Well, one Developer ID Application and maybe one Developer ID Installer. A large organisation might need more, perhaps one for each sub-unit, but that’s it. There are two reasons why this is important: The more you have, the more likely it is for one to get into the wrong hands. Remember that anyone with your Developer ID signing identity can sign code as you. The Developer website limits you to 5 Developer ID certificates. Note I can never remember where this limit is actually documented, so here’s the exact quote from this page: You can create up to five Developer ID Application certificates and up to five Developer ID Installer certificates using either your developer account or Xcode. Don’t Lose Your Private Key There are two standard processes for creating a Developer ID signing identity: Developer website — See Developer Account Help > Create certificates > Create Developer ID certificates. Xcode — See Xcode Help > Maintaining signing assets > Manage signing certificates. Both processes implicitly create a private key in your login keychain. This makes it easy to lose your private key. For example: If you do this on one Mac and then get a new Mac, you might forget to move the private key to the new Mac. If you’re helping your Organization team’s Account Holder to create a Developer ID signing identity, you might forget to export the private key from their login keychain. It also makes it easy to accidentally leave a copy of the private key on a machine that doesn’t need it; see Don’t Leak Your Private Key, below, for specific advice on that front. Every time you create a Developer ID signing identity, it’s a good idea to make an independent backup of it. For advice on how to do that, see Back Up Your Signing Identities, below. That technique is also useful if you need to copy the signing identity to a continuous integration system. If you think you’ve lost the private key for a Developer ID signing identity, do a proper search for it. Finding it will save you a bunch of grief. You might be able to find it on your old Mac, in a backup, in a backup for your old Mac, and so on. For instructions on how to extract your private key from a general backup, see Recover a Signing Identity from a Mac Backup. If you’re absolutely sure that you previous private key is lost, use the Developer website to create a replacement signing identity. If the Developer website won’t let you create any more because you’ve hit the limit discussed above, talk to Developer Programs Support. Go to Apple > Developer > Contact Us and follow the path Development and Technical > Certificates, Identifiers, and Provisioning Profiles. Don’t Leak Your Private Key Anyone with your Developer ID signing identity can sign code as you. Thus, it’s important to take steps to prevent its private key from leaking. A critical first step is to limit access to your Developer ID signing identities. For advice on that front, see Limit Access to Developer ID, above. In an Organization team, only the Account Holder can create Developer ID signing identities. When they do this, a copy of the identity’s private key will most likely end up in their login keychain. Once you’ve exported the signing identity, and confirmed that everything is working, make sure to delete that copy of the private key. Some organisations have specific rules for managing Developer ID signing identities. For example, an organisation might require that the private key be stored in a hardware token, which prevents it from being exported. Setting that up is a bit tricky, but it offers important security benefits. Even without a hardware token, there are steps you can take to protect your Developer ID signing identity. For example, you might put it in a separate keychain, one with a different password and locking policy than your login keychain. That way signing code for distribution will prompt you to unlock the keychain, which reminds you that this is a significant event and ensures that you don’t do it accidentally. If you believe that your private key has been compromised, follow the instructions in the Compromised Certificates section of Developer > Support > Certificates. IMPORTANT Don’t go down this path if you’ve simply lost your private key. Back Up Your Signing Identities Given that Developer ID signing identities are precious, consider making an independent backup of them. To back up a signing identity to a PKCS#12 (.p12) file: Launch Keychain Access. At the top, select My Certificates. On the left, select the keychain you use for signing identities. For most folks this is the login keychain. Select the identity. Choose File > Export Items. In the file dialog, select Personal Information Exchange (.p12) in the File Format popup. Enter a name, navigate to your preferred location, and click Save. You might be prompted to enter the keychain password. If so, do that and click OK. You will be prompted to enter a password to protect the identity. Use a strong password and save this securely in a password manager, corporate password store, on a piece of paper in a safe, or whatever. You might be prompted to enter the keychain password again. If so, do that and click Allow. The end result is a .p12 file holding your signing identity. Save that file in a secure location, and make sure that you have a way to connect it to the password you saved in step 9. Remember to backup all your Developer ID signing identities, including the Developer ID Installer one if you created it. To restore a signing identity from a backup: Launch Keychain Access. Choose File > Import Items. In the open sheet, click Show Options. Use the Destination Keychain popup to select the target keychain. Navigate to and select the .p12 file, and then click Open. Enter the .p12 file’s password and click OK. If prompted, enter the destination keychain password and click OK. Recover a Signing Identity from a Mac Backup If you didn’t independently backup your Developer ID signing identity, you may still be able to recover it from a general backup of your Mac. To start, work out roughly when you created your Developer ID signing identity: Download your Developer ID certificate from the Developer website. In the Finder, Quick Look it. The Not Valid Before field is the date you’re looking for. Now it’s time to look in your backups. The exact details depend on the backup software you’re using, but the basic process runs something like this: Look for a backup taken shortly after the date you determined above. In that backup, look for the file ~/Library/Keychains/login.keychain. Recover that to a convenient location, like your desktop. Don’t put it in ~/Library/Keychains because that’ll just confuse things. Rename it to something unique, like login-YYYY-MM-DD.keychain, where YYYY-MM-DD is the date of the backup. In Keychain Access, choose File > Add Keychain and, in the resulting standard file panel, choose that .keychain file. On the left, select login-YYYY-MM-DD. Chose File > Unlock Keychain “login-YYYY-MM-DD“. In the resulting password dialog, enter your login password at the date of the backup. At the top, select My Certificates. Look through the list of digital identities to find the Developer ID identity you want. If you don’t see the one you’re looking for, see Further Recovery Tips below. Export it using the process described at the start of Back Up Your Signing Identities. IMPORTANT If the original Mac was running macOS 26.4 or later, you might also need to recover this keychain’s protected entropy file. For more about that, see TN3137 On Mac keychain APIs and implementations Once you’re done, remove the keychain from Keychain Access: On the left, select the login-YYYY-MM-DD keychain. Choose File > Delete Keychain “login-YYYY-MM-DD”. In the confirmation alert, click Remove Reference. The login-YYYY-MM-DD.keychain is now just a file. You can trash it, keep it, whatever, at your discretion. This process creates a .p12 file. To work with that, import it into your keychain using the process described at the end of Back Up Your Signing Identities. IMPORTANT Keep that .p12 file as your own independent backup of your signing identity. Further Recovery Tips If, in the previous section, you can’t find the Developer ID identity you want, there are a few things you might do: Look in a different backup. If your account has more than one keychain, look in your other keychains. If you have more than one login account, look at the keychains for your other accounts. If you have more than one Mac, look at the backups for your other Macs. The login-YYYY-MM-DD keychain might have the private key but not the certificate. Add your Developer ID certificate to that keychain to see if it pairs with a private key. Revision History 2026-09-29 Added a link to the protected entropy file discussion in TN3137. 2025-03-28 Excised the discussion of Xcode’s import and export feature because that was removed in Xcode 16. 2025-02-20 Added some clarification to the end of Don’t Leak Your Private Key. 2023-10-05 Added the Recover a Signing Identity from a Mac Backup and Further Recovery Tips sections. 2023-06-23 Added a link to Identifying a Cloud Managed Signing Certificate. 2023-06-21 First posted.

Hello. I was trying to build a project on my Macbook via XCode and came across the message: "Communication with Apple failed. Your maximum App ID limit has been reached. You may create up to 10 App IDs every 7 days". Is there a solution to this? I don't know how much the prices are but I don't think I can afford it. What can you suggest to continue building projects with a free account?

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.

I’m trying to distribute a macOS application outside the Mac App Store using Developer ID signing and notarization. The Sensitive Content Analysis capability is enabled for this App ID in Certificates, Identifiers & Profiles. My application requires the following entitlement: com.apple.developer.sensitivecontentanalysis.client However, when I create and download a new Developer ID provisioning profile for this App ID, the generated profile does not contain this entitlement. I have regenerated and downloaded the profile after confirming that Sensitive Content Analysis is enabled. I also decoded the newly generated .provisionprofile to inspect its entitlements. It contains the application identifier, team identifier, and keychain access groups, but does not contain com.apple.developer.sensitivecontentanalysis.client. As a result, Xcode will not export the Developer ID build because the application requests the Sensitive Content Analysis entitlement but the provisioning profile does not authorize it. Does anyone know the answers to these questions: Is com.apple.developer.sensitivecontentanalysis.client supported for macOS applications distributed outside the Mac App Store using Developer ID? If it is supported, why is the entitlement not being included in newly generated Developer ID provisioning profiles for this App ID? Is there an additional approval, agreement, or configuration required for this entitlement to be included in a Developer ID profile? Sensitive Content Analysis is a required feature of this application, so removing the entitlement is not an option for our distribution build.

Following up with a full diagnostic summary since my last post, in case it helps narrow this down. Certificates: Developer ID Installer and Developer ID Application (Team ID 6VCLSHAN7R), both freshly created Aug 19, 2026. Both show as valid/trusted in Keychain Access and match the developer portal (expiration 2031/08/20). What I've verified/tried, all pointing to the same conclusion: Local signature is valid. pkgutil --check-signature shows a full chain (Developer ID Installer → Developer ID Certification Authority → Apple Root CA) with a trusted timestamp. codesign -dvv on the embedded binaries (VST3, AU component, standalone app) all show Authority=Developer ID Application: ..., hardened runtime enabled, valid secure timestamp. No account/cert issues found. No duplicate certificates (security find-identity -v -p basic returns exactly 2 valid identities). No pending Program License Agreement. developer.apple.com/system-status shows Notary Service operational. Signed with productsign directly, not just via the packaging GUI (Packages/Whitebox) — same result. Isolated from product content: a minimal pkgbuild test package (single text file, signed only with productsign, no relation to my actual product) fails with the exact same error. Waited 3+ days in case of certificate propagation delay — no change. Tried both authentication methods — Apple ID + app-specific password, and a Team-scoped App Store Connect API key — both fail identically. Every single attempt returns: "message": "The binary is not signed with a valid Developer ID certificate." Latest Submission IDs (all Invalid, same error): 5b495af5-1a31-41cd-b8a3-d1e33ab2a12a (product pkg, API key auth) 91eee4f0-778a-4edb-9515-eabfc6711f3f (minimal test pkg, Apple ID auth) At this point I've ruled out everything on my end I can think of — package contents, signing tool, authentication method, certificate freshness/propagation, account status. This looks like something wrong with how these specific certificates are provisioned on Apple's side for notarization. Could someone from DTS take a look at the account/certificates directly? Happy to provide any further diagnostics needed. Thanks for your patience.

Hi all I'm stuck on a notarization failure that doesn't match any cause I can find or fix locally — looking for either a known explanation or a pointer to the right support channel. Setup: macOS 15.7.2 (24G325) Certificate: "Developer ID Installer" Issued: 16 Aug 2026, expires 17 Aug 2031 Confirmed on developer.apple.com as Active (not revoked) — matches the certificate installed locally by serial/expiry Signing a component .pkg containing a notarized-requirements-compliant plugin bundle (hardened runtime, secure timestamp, universal x86_64/arm64, signed with a valid "Developer ID Application" cert from the same team) What I've verified locally, all pass cleanly: pkgutil --check-signature on the .pkg: full valid chain, Developer ID Installer -> Developer ID Certification Authority -> Apple Root CA, with a trusted timestamp spctl -a -vvv -t install on the .pkg: recognizes it as "Developer ID" origin, correctly reports "Unnotarized Developer ID" (i.e. Gatekeeper trusts the signature itself, just knows it isn't notarized yet) codesign -dv --verbose=4 on the inner plugin bundle (both architecture slices checked individually): valid Developer ID Application signature, hardened runtime flag set, trusted timestamp present What I've tried, no change in any case: Originally built/signed via the third-party "Packages" app — failed notarization Re-signed the same .pkg independently with Apple's own productsign directly (bypassing Packages entirely, to rule out a third-party tool bug) — productsign's own console output explicitly confirmed it added both the "Developer ID Certification Authority" and "Apple Root CA" certificates to the signature — still failed notarization, identical error Found and accepted a pending Program License Agreement banner on developer.apple.com that I hadn't noticed before — resubmitted after accepting — still failed, identical error Rebuilt the plugin bundle from source fresh, repackaged, resubmitted — still failed, identical error Every attempt gets the same result from xcrun notarytool log <id>: "status": "Invalid", "statusSummary": "Archive contains critical validation errors", "statusCode": 4000, "issues" "severity": "error", "path": "<the .pkg filename itself>", "message": "The binary is not signed with a valid Developer ID certificate.", "architecture": null Note "path" is the top-level .pkg itself and "architecture" is null — so this is flagging the Installer signature on the package, not the inner bundle's Application signature. Some submission IDs for reference, in case anyone from Apple can look at the notary service's own logs directly: 9a5364bf-7b0e-4cf8-a68c-0508bc081855 caa2a263-d4af-443b-89dd-1c26d93a7bee f15fcf6d-99c3-4810-8c42-926e4328a042 Has anyone seen this combination before — a certificate that verifies as fully valid by every local tool (pkgutil, spctl, codesign) and shows as Active on the portal, but is rejected by the live notary service specifically? Is there some other account-level state (beyond agreements, which I've now accepted) that can cause this? Trying to figure out whether this needs a Technical Support Incident or if it's a known/documented gotcha I'm missing. Thanks for any pointers.

Hi, I have a hard time renewing my certificates. The double click on the .cer file just opens the Keychain Acces but doesn't install anything. I'm missing a step. Thanks in advance for your help.

We have a complete iPadOS DriverKit USB extension for a Stripe Reader M2 (USB-C, M-series iPad). Development builds sign and run. We cannot ship Ad Hoc, App Store, or Enterprise builds because the distribution DriverKit entitlements are either not granted or not present in the provisioning profile Apple generates. Stripe’s iOS USB instructions say to request the entitlement at developer.apple.com/system-extensions: select HID and USB Transport, and enter USB vendor ID 11369. Platform is iPadOS. The extension also needs com.apple.developer.driverkit. The host app uses com.apple.developer.driverkit.communicates-with-drivers. We have two teams. The driver bundle ID is prefixed with the host app bundle ID and signed with the same team. Inc — Team ID HPL6Q4V5TF (Development, Ad Hoc, App Store) Host app Driver extension com.atxinnovation.union.development com.atxinnovation.union.development.usbDriver com.atxinnovation.union.qa com.atxinnovation.union.qa.usbDriver com.atxinnovation.union.production com.atxinnovation.union.production.usbDriver These are not granted. Latest submission is system-extensions request 39WL64S3LR (September 3, 2026). That form has no status page, and we have received no email. LLC — Team ID 3MAPQA4NZ6 (Enterprise in-house) Host app Driver extension com.atxinnovation.union.enterprise com.atxinnovation.union.enterprise.usbDriver Capability request ACL9VQ3BA4. The portal shows DriverKit and DriverKit USB Transport – VendorID granted and enabled on com.atxinnovation.union.enterprise.usbDriver. The Universal Distribution profile POS Prod USB Driver (platform iOS, active, expires 2027/01/22, UUID a3627c1e-451d-4d62-b871-1cb6fe21431e, created 2026-09-02 16:05:20 UTC) lists those capabilities as enabled on the Review Provisioning Profile page. The downloaded profile does not contain them. Decoding it yields only: application-identifier com.apple.developer.team-identifier get-task-allow keychain-access-groups The string driverkit does not appear in the profile. We regenerated it five times, including deleting and recreating the profile, with the same result. DriverKit development profiles for the corresponding development App ID do contain com.apple.developer.driverkit and com.apple.developer.driverkit.transport.usb. Xcode then fails the archive: Provisioning profile "POS Prod USB Driver" doesn't include the com.apple.developer.driverkit entitlement. We also do not know which idVendor values the VendorID grant assigned. The extension must match them exactly. We need 11369. What we already tried July 30: Account Holder submitted DriverKit and DriverKit USB Transport for both teams through the system-extension Contact Us form. No confirmation email. That form does not collect bundle IDs. Those July requests later showed up on the host App ID com.atxinnovation.union.enterprise, not on the usbDriver App IDs. August 12: Resubmitted on each usbDriver App ID under Certificates, Identifiers & Profiles → Capability Requests. Enterprise request ACL9VQ3BA4. August 27: Developer Support case 20000149322724. The reply pointed us back at the capability status page. September 2: Enterprise grant appeared. Enabling it on the App ID and regenerating the distribution profile still produced a profile with no DriverKit entitlements. Developer Support case 102951939894. No resolution. September 3: Resubmitted the Inc team via the system-extensions form (39WL64S3LR). The form would not accept another LLC submission because that App ID is already granted. No status since. What we are Requesting Grant DriverKit, HID, and USB Transport (vendor ID 11369) for iPadOS — Development, Ad Hoc, and App Store — on the three Inc driver App IDs above. Assistance debugging the issue of failing to embed the already-granted DriverKit entitlements in the LLC Enterprise distribution profile for com.atxinnovation.union.enterprise.usbDriver, and confirmation of the assigned idVendor values.

Hi, I am working on a personal HIDDriverKit project. The documentation suggests that you do not need the entitlements from Apple to do local development - that all you need to do is turn of SIP, enable developer mode, and turn signing to "Sign to Run Locally". However, I have followed all of these steps, and am still running into the error that to build, I need to have a provisioning profile with the DriverKit (development) feature (MacOS 15.2 Xcode 16.2). Am I missing something here regarding the steps for local development? Does one need to request a development version of the entitlements even for local development? Do I need a paid developer account to do this? Thank-you in advance.

Our app Newton Mail (App ID com.CloudMagic.Mail, App Store app 721677994, Team 53X8EK4BSQ) held the com.apple.developer.mail-client entitlement for years. Newton shipped as a default-mail-capable app starting with iOS 14, and our January 2024 App Store distribution profile (release_appstore_com.CloudMagic.Mail) still contains the entitlement. The grant is no longer active. Automatic signing now fails with: 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. The Default Mail App capability does not appear on our App ID in Certificates, Identifiers & Profiles, nor in the Capability Requests tab. This looks like the same migration issue described in these threads: https://developer.apple.com/forums/thread/821303 (same error on a years-old grant, fixed server-side by Apple) https://developer.apple.com/forums/thread/806537 (grant only "partially migrated" to the managed capability) What we have tried since July 2026: July 9: emailed the entitlement team. No response. August 31 and September 5: submitted the Default Mail Client request form. No confirmation page or reference number either time. September 13: resubmitted the form and received Request ID L8JM288VBQ. Support case 102959495479: support confirmed we are not currently granted the entitlement. Our follow-ups on September 18 and September 23 got no reply. Phone case 102973381060: the callback was marked "no answer" 44 seconds after we requested it, and the phone never rang. The current App Store version (10.0.94) meets all four published requirements: mailto: is declared in Info.plist, the app sends to any recipient, the mailto handler opens a compose view with To: pre-filled, and the app receives from any sender. Could someone from DTS take a look, or tell us the right channel to get the migrated grant restored? Thank you.

xcrun notarytool submit crashes with a SIGBUS during upload, every time, for one specific build of our app. Filing this as its own post since it is a distinct, reproducible crash with a clear crash report, separate from general In Progress slowness. The exact exception, from the macOS crash reporter, is EXC_BAD_ACCESS (SIGBUS), subtype KERN_PROTECTION_FAILURE, with the message "Could not determine thread index for stack guard region." It happens on a background thread named nio.nioTransportServices.connectionchannel, which is the SwiftNIO Network.framework transport thread handling the upload connection. The faulting stack is inside notarytool's own code, going through String.init(format:), then Foundation's NSString formatting, then CoreFoundation's CFString formatting functions, almost certainly while it is trying to format a log or progress line during the upload. The same small set of return addresses repeats many times in a row right before the crash, which looks like unbounded or very deep recursion in that logging path. Reproduction: run xcrun notarytool submit yourbuild.zip --apple-id ... --password ... --team-id ... --wait against a roughly 180 MB zip of a signed .app. The tool prints Submission ID received, starts the S3 multipart upload, and crashes within about a second, before any upload progress is shown, with no error message. The submission is left behind on Apple's side, stuck at status In Progress, and disappears entirely about 11 to 12 hours later, at which point notarytool info for that id returns Submission does not exist or does not belong to your team. This is completely reproducible for us: it has now happened on five separate submissions of our x64 (Intel) build, and zero times submitting our arm64 (Apple Silicon) build of the exact same app, same machine, same credentials, same day. We also tried setting the upload timeout higher with defaults write com.apple.gke.notary.tool nt-upload-connection-timeout 300, which did not help, same crash. We have full macOS crash reports (.ips files) for two separate occurrences of this and are happy to attach or send them, along with the zip that triggers it.

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.

Hello, I’m seeing what appears to be a system-wide code-signing / trust issue on a MacBook Pro running macOS Tahoe 26.7 (25G229). I originally discovered the issue while preparing to build a local Swift command-line tool. However, the problem is not limited to my own code or to Xcode. Apple system apps fail strict code-signature verification as well. Environment: MacBook Pro, Apple Silicon macOS Tahoe 26.7 (25G229) Xcode 26.6 (17F113) /usr/bin/codesign /usr/sbin/spctl Observed behavior: Strict code-signature verification of Terminal.app fails with: CSSMERR_TP_NOT_TRUSTED Strict code-signature verification of TextEdit.app also fails with: CSSMERR_TP_NOT_TRUSTED Xcode 26.6 fails strict code-signature verification with the same error: CSSMERR_TP_NOT_TRUSTED A Gatekeeper assessment of Xcode fails with: internal error in Code Signing subsystem Reading trust settings for both the user and admin scopes fails with: SecTrustSettingsCopyCertificates: No keychain is available. You may need to restart your computer. /System/Library/Keychains/SystemRootCertificates.keychain exists, but read-only certificate queries through the security command did not return an accessible certificate record. The following services are registered and running: trustd securityd syspolicyd Troubleshooting already performed: Restarted the Mac: no change. Updated macOS from Tahoe 26.6.2 to Tahoe 26.7: no change. Repeated the checks after the 26.7 update: Terminal.app, TextEdit.app and Xcode still fail as described above. I have intentionally NOT performed any of the following: Resetting any keychain Deleting or importing certificates Changing trust settings Disabling Gatekeeper Disabling or changing SIP Re-signing Xcode or Apple system applications Erasing or reinstalling macOS Apple Developer Support reviewed my description but explained that their support channel is primarily for App Store Connect, app distribution, and Developer account management, and suggested posting the issue here. My main concern is that this does not appear to be an ordinary Developer ID or signing-certificate issue because Apple system applications such as Terminal.app and TextEdit.app also fail trust verification, while trust-settings queries report that no keychain is available. Questions: What additional read-only diagnostics would you recommend to determine why the macOS trust/keychain subsystem cannot establish trust even for Apple system applications? Is there an Apple-supported way to verify the integrity and accessibility of SystemRootCertificates.keychain and the system trust store without modifying or resetting the keychains? Does the combination of CSSMERR_TP_NOT_TRUSTED for Apple system apps and “No keychain is available” from SecTrustSettingsCopyCertificates indicate a known trust-store/keychain problem? Before considering a non-destructive macOS reinstall from Recovery, are there additional safe diagnostics I should perform? I would prefer not to reset keychains or manually modify certificates unless there is evidence that doing so is appropriate. I can provide the exact commands and full outputs from the read-only diagnostics if that would help. Thank you.

Notarization submissions stuck In Progress then disappear, x64 only Team ID CJLCWP5NP3, app Write (com.connerkennedy.write), Xcode Command Line Tools notarytool 1.1.3 (42), macOS 26.6.2 build 25G83. Every x64 (Intel) notarization submission for this app gets stuck at status In Progress and never resolves. After roughly 11 to 12 hours, the submission disappears entirely: notarytool info with that submission id starts returning "Submission does not exist or does not belong to your team," and the submission no longer appears in notarytool history at all, not as Accepted, Invalid, or Rejected, just gone. This has happened identically on three consecutive x64 submissions. The submission ids and creation times, in UTC, are: b532a8a4-1dab-4eab-b37c-81b53b3573bb, created 2026-09-20 20:25:48 3a1ea67f-f88d-43e6-9ef5-62a6de1aa5d2, created 2026-09-20 21:22:16 8bc19842-e93a-4ea7-b3cc-3c1aeb20b423, created 2026-09-21 11:28:53 All three followed the same pattern: stuck in progress, then vanished roughly 11 to 12 hours later. In sharp contrast, every arm64 (Apple Silicon) submission from the same team, same day, same build pipeline, succeeded normally, typically within a few minutes. Five separate arm64 submissions across September 8 through September 20 all came back Accepted with no issues. This is the first time this team has ever submitted an x64 build for notarization. Every prior successful submission was arm64. That is the only meaningful difference we can find between the submissions that succeed and the ones that get stuck. Before concluding this is server side, we ruled out several things on our end. It is not a local network or VPN issue, since we reproduced it with a VPN active, after fully disconnecting the VPN, and after a full machine reboot. It is not local resource pressure, since we reproduced it with over 18 GB of free RAM after a reboot, the same conditions under which arm64 succeeds instantly. It is not the specific file, since we reproduced it with a completely fresh rebuild of the app and also when submitting a dmg instead of a zip. It is not our build tooling, since we bypassed electron-builder's built in notarize step entirely and submitted directly with xcrun notarytool submit and info, with the same result. And it is not a one off blip, since it reproduced three times in a row over about 36 hours, always the same stuck then vanished pattern, with arm64 unaffected the whole time. We would appreciate help understanding why x64 submissions under this team are getting stuck and then disappearing after 11 to 12 hours, while arm64 submissions from the same team notarize normally. Either an explanation of what is happening so future x64 submissions process normally, or confirmation that this is a first time x64 review hold that needs manual clearing on Apple's side, would be very helpful. Happy to provide the actual zip we submitted, full notarytool logs, or anything else that would help investigate

I’m seeing a reproducible code-signing failure on macOS 26.6.2 with Xcode 26.6 while building an iOS XCTest bundle for a physical device. A newly created Apple Development identity is valid and can successfully sign and verify a standalone test binary using /usr/bin/codesign. However, xcodebuild build-for-testing reaches the first XCTest re-sign operation and the macOS Keychain authorization dialog for the same development private key becomes unresponsive after entering the login Keychain password and clicking “Always Allow.” The failing command is effectively: /usr/bin/codesign --force --sign -o runtime --timestamp=none ... libXCTestSwiftSupport.dylib and returns: errSecInternalComponent The exact same development certificate successfully signs a standalone binary immediately beforehand. The build is running from an ordinary logged-in Terminal session, not SSH or CI. After aborting the build, inspection showed the XCTest artifacts retained Apple’s original Software Signing certificate rather than the Development certificate, confirming the re-sign did not complete. I have already recreated the login Keychain once and recreated the Apple Development identity. I do not want to make further Keychain ACL/partition changes without understanding the underlying cause. Question: What diagnostic should I collect to determine why SecurityAgent/codesign cannot complete private-key authorization for the XCTest re-sign operation when direct signing with the same identity succeeds?

I have a narrow follow-up question about file-based Keychain partition lists, this time specifically for Developer ID Installer signing with productbuild. I’ve reviewed the existing guidance around Keychain ACLs and partition lists. For codesign, the security documentation explicitly calls out the apple: partition requirement. I haven’t been able to find an equivalent supported statement for productbuild. My setup uses separate private keys for the two roles: Developer ID Application → /usr/bin/codesign Developer ID Installer → /usr/bin/productbuild The trusted-application ACL is also role-specific. I’m trying to determine the corresponding partition constraint for the Installer key without inferring it from a configuration that merely happens to work. So my question is: When /usr/bin/productbuild uses a Developer ID Installer private key from a file-based Keychain, what partition-list requirement should that key use according to the supported macOS contract? In particular, should the Installer key use apple:, apple-tool:, some combination of partitions, or something else? I’m not looking for a broad CI workaround or an “Allow all applications” configuration. I’m trying to keep the Application and Installer roles separate and use only the partition constraint actually required by the Apple signing tool. If there is no documented/supported partition value for productbuild, knowing that limitation would also answer the question. Thanks.

I’m evaluating whether Apple cloud signing can replace locally managed Developer ID private keys in a macOS distribution pipeline. I’ve read the documentation on cloud-managed certificates and the Xcode cloud-signing workflow. I understand the supported Developer ID Application flow through Xcode’s archive/export distribution process, but I haven’t been able to find an equivalent documented workflow for Developer ID Installer. I’m also checking this against the current Xcode 27 / macOS 27 toolchain, in case the supported cloud-signing scope has recently expanded. My distribution pipeline produces custom flat installer packages using productbuild. It uses separate Developer ID Application and Developer ID Installer identities, as expected. So my main question is: Can a custom macOS .pkg be signed with a cloud-managed Developer ID Installer identity using a currently supported Apple workflow? More specifically, is there a supported cloud-signing equivalent of using a local Developer ID Installer identity with productbuild / productsign, or are Developer ID Installer package signatures still expected to use a locally or externally available signing identity? I’m specifically asking about custom Developer ID packages distributed outside the Mac App Store, rather than an App Store or Xcode-managed installer workflow. If cloud-managed Developer ID Installer signing isn’t currently supported, knowing that limitation would answer my question as well. Thanks.