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 Apple Developer Support Team and Community, Our company enrollment has been pending for several weeks. Support Case References: Primary Case ID: 103001946204 (Escalated to Senior Advisor Team) Additional Program Enrollment Case ID: 103005762781 We have submitted our supporting documents, including our Trade License, Emirates ID, Labour Card, and Employment Certificate. On November 2, 2026, Apple Developer Support confirmed that our information had been escalated to the Senior Advisor Team for document review. However, as of November 11, 2026, we have not received further updates regarding the review. We are also awaiting clarification on Apple's request for a solicitor-certified English translation, as the specific document requiring translation was not identified. Our most recently submitted Employment Certificate is already entirely in English. Our Android application is already live on Google Play, and the pending organization enrollment is delaying our planned iOS release. Could an Apple representative or community member advise how we can obtain an update regarding the Senior Advisor review and confirm whether additional documentation is required? We appreciate your assistance and guidance. Thank you.

Hello Developer Community, Our company enrollment has been pending for several weeks. We submitted the requested information and received confirmation on November 2, 2026, that our application had been referred to a senior review team. We have not received further updates and would appreciate advice from anyone who has experienced a similar delay. Could someone share how long their review took and what steps helped them obtain an update? Thank you for your assistance.

Hi Apple Support Community, We requested access to the MDM Vendor CSR Signing Certificate on October 21 (Case ID: 103003418539), but haven't received any response or update since then. Could someone from Apple provide an update or guide us on the expected approval timeline and next steps? Thanks!

Hello, I'm trying to enroll in the Apple Developer Program as an individual from Pakistan. My enrollment stops before the payment step with the message: "Your enrollment in the Apple Developer Program could not be completed at this time." No payment has been made. I opened case 103017052484 on November 2 and followed up on November 9, but so far I've only received the automatic confirmation. My Apple Account name originally didn't match my passport. I've since updated it to match exactly, and two-factor authentication is enabled. I'm ready to provide my passport or anything else needed for verification. Could someone from Apple Developer Support please take a look at my case? Thank you.

We're getting a build failure from Xcode Cloud on the Export Archive step for the Developer ID distribution destination. The App Store Connect and Development exports in the same build both succeed, only the Developer ID export fails. Environment Xcode 27.2 (27B48), macOS SDK 27.2 Build: Vor (macOS), Build 1270 Team ID: BB23FH7873 When Xcode Cloud queries for a certificate of type DEVELOPER_ID_APPLICATION_MANAGED zero results are returned: Payload: {"urlEncodedQueryParams":"teamId=BB23FH7873&filter[certificateType]=DEVELOPER_ID_APPLICATION_MANAGED&limit=200"} Response: { "data" : [ ], "meta" : { "paging" : { "total" : 0 ... } } }It then attempts to create one, which is rejected: POST .../certificates {"certificateType":"DEVELOPER_ID_APPLICATION_MANAGED","teamId":"BB23FH7873"} Response: { "errors" : [ { "status" : "409", "code" : "ENTITY_ERROR", "resultCode" : 7460, "title" : "There is a problem with the request entity", "detail" : "You already have a current Developer ID Application Managed certificate or a pending certificate request." } ] }The export step then fails with: error: exportArchive No signing certificate "Developer ID Application" found No "Developer ID Application" signing certificate matching team ID "BB23FH7873" with a private key was found. error: exportArchive No profiles for 'app.getvor.macOS' were found Xcode couldn't find any Developer ID provisioning profiles matching 'app.getvor.macOS'. ** EXPORT FAILED **xcodebuild -exportArchive then exits with status 70. We have two Developer ID Application Managed (Xcode Cloud) certificates already in Certificates, Identifiers & Profiles, and no certs pending that we can see. So it looks like something is preventing Xcode Cloud from seeing its own previously created managed certificates. Is there a way to get Xcode Cloud to recognize the existing certificates? Other posts suggest revoking existing Developer ID Application certificates, however our understanding is this has the potential to break currently signed and shipped versions of the application. A version of this question was also submitted as case ID 103008361082.

Two notarization submissions for a Developer ID–signed macOS app have been "In Progress" for over an hour. Earlier submissions from this same team, credentials and workflow were all Accepted within minutes. Submissions Created (UTC)IDFileStatus2026-11-05 15:54:4802956de4-0ec7-4009-8f8e-1635f93a10d1ProxyPal.zipIn Progress2026-11-05 16:37:25e38d47a1-6709-4008-9682-18f9b96af217ProxyPal.zipIn ProgressThe second one is a resubmission of the identical zip, sent after the first had been stuck for about 40 minutes. What I've checked xcrun notarytool info <id> returns In Progress. xcrun notarytool log <id> returns "Submission log is not yet available". Authentication and upload work, and notarytool history lists both submissions. codesign --verify --deep --strict passes on the app. Every executable in the bundle has the hardened runtime and a secure timestamp. The zip is made with ditto -c -k --keepParent, the same command as the earlier accepted releases. The bundle contents are essentially unchanged since the last accepted release. The differences are a small generated static HTML help folder and version-number changes. Environment Submitted with xcrun notarytool submit ... --keychain-profile ... --wait from a script. macOS 26 (Darwin 25.6), Xcode toolchain notarytool. Zip is 89 MB, 193 files, and includes two nested .apk files that were also in earlier accepted releases. Questions Are these two submissions held for additional analysis, or stuck in the queue? Is there anything on my side I should change?

My macOS app, AnimacX, cannot complete Developer ID distribution export in Xcode Cloud. The affected build is 1144, and the preceding build 1143 contains the following certificate lookup and creation failures. Environment: Team ID: SWWMY4BCX7 Bundle ID: app.anix.AnimacX Xcode version recorded in the Build 1143 logs: 27.1 (27A9275) Automatic signing enabled Failing step: Export archive for developer-id distribution xcodebuild -exportArchive exits with code 70 The provisioning log shows this sequence: Xcode Cloud queries certificates with type DEVELOPER_ID_APPLICATION_MANAGED. The response contains an empty data array and a total count of 0. Xcode then attempts to create a managed Developer ID Application certificate. The creation request fails with: HTTP 409 code: ENTITY_ERROR resultCode: 7460 You already have a current Developer ID Application Managed certificate or a pending certificate request.The export subsequently reports: No signing certificate "Developer ID Application" found No "Developer ID Application" signing certificate matching team ID "SWWMY4BCX7" with a private key was found. No profiles for 'app.anix.AnimacX' were found.However, the Certificates page for this team lists two Developer ID Application Managed (Xcode Cloud) certificates, both created by Xcode Cloud and expiring on February 2, 2027. I have an Admin role on the team. This workflow was working normally until recently, and I have not created, revoked, or otherwise modified any certificates. Building and uploading the macOS app to App Store Connect directly from local Xcode still succeeds. The iOS and tvOS builds and distribution workflows also continue to work normally. The failure is limited to Developer ID distribution export for macOS in Xcode Cloud. I contacted Apple Developer Support under case 103008194927 and was directed to post here. Screenshots are attached, and I can provide the full distribution logs. Could an Apple engineer help determine why Xcode Cloud returns no certificates while the creation service reports an existing certificate or pending request? What action is required to restore Developer ID export, and does this require investigation of the team’s cloud-managed signing state?

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

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

I’m developing a macOS VPN app distributed directly with Developer ID. Its NEPacketTunnelProvider is packaged as a System Extension (packet-tunnel-provider-systemextension). On macOS 15.6 (24G84), I installed a configuration profile containing: A com.apple.security.acme payload with HardwareBound=true, Attest=true, and a P-256 key. A com.apple.vpn.managed payload whose PayloadCertificateUUID references that ACME payload. VPNSubType and ProviderBundleIdentifier identify my app and provider. macOS issued the certificate, and the managed VPN starts the provider. In startTunnel, protocolConfiguration.identityReference is non-nil (20 bytes). However, resolving it in the provider returns -25291 (errSecNotAvailable): `let query: [CFString: Any] = [ kSecClass: kSecClassIdentity, kSecValuePersistentRef: identityReference, kSecUseDataProtectionKeychain: true, kSecReturnRef: true, kSecMatchLimit: kSecMatchLimitOne ] var result: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &result) The containing app receives the same non-nil reference, but its identity query returns -25306. Neither binary currently has the com.apple.managed.vpn.shared keychain access group; I understand that this group requires a separate managed capability. An Apple Device Management Engineer states that third-party processes cannot access hardware-bound ACME identities in the Data Protection Keychain, with an exception for VPN extensions. The NETunnelProviderManager documentation says that apps and Packet Tunnel Providers need com.apple.managed.vpn.shared to use credentials supplied by configuration profiles. Is com.apple.managed.vpn.shared the supported way for a Developer ID Packet Tunnel System Extension to resolve this specific hardware-bound ACME identity? If granted, should the provider use the query above, or another public API? Does the VPN-extension exception apply when the System Extension runs outside the logged-in user’s keychain context? If this is unsupported for a System Extension, what is the supported approach for a directly distributed Developer ID VPN app to perform client authentication with this non-exportable key? I need a usable SecIdentity or signing operation, not the private-key bytes.

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.

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?

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.

Environment: App: Developer ID signed, non-sandboxed macOS app Browsers affected: Google Chrome, Mozilla Firefox Safari: Working fine on macOS 27 Working on: macOS 26 and earlier Broken on: macOS 27 (Golden Gate) Issue Our non-sandboxed, Developer ID signed macOS app interacts with Chrome and Firefox directories under ~/Library/Application Support/ as part of its browser extension deployment workflow. On macOS 26 and earlier, this worked without any special permissions. On macOS 27, the same operations are silently blocked — no TCC prompt is shown to the user, access is simply denied. Granting Full Disk Access to our app via System Settings > Privacy & Security > Full Disk Access resolves the issue completely on macOS 27. Safari is unaffected — our Safari extension is bundled directly inside our app and continues to work correctly on macOS 27 without any additional permissions. Question Has macOS 27 intentionally introduced TCC or MACL-based protection over Chrome and Firefox directories under ~/Library/Application Support/, blocking access from non-owner processes including non-sandboxed Developer ID apps? If this is an intentional change, is Full Disk Access the expected requirement going forward, or is there a more targeted entitlement or Apple-recommended approach for a non-sandboxed app that legitimately needs to access browser directories as part of an extension deployment workflow?

Hi, Developer ID notarization from our team has been broken for two days. Submissions sit in In Progress for hours and never finish, and an earlier batch disappeared from notarytool history entirely without ever reaching Accepted or Invalid. This is blocking a release. Team ID: UFB3325L3Q (Shenzhen Minimal Future Technology Co., Ltd.) First batch (submitted 2026-09-09 ~02:15 UTC) — now VANISHED: CowAgent-2.1.8-arm64.dmg — id 4df22081-b3dd-41fe-b6d5-cebbd3ab40ff CowAgent-2.1.8-x64.dmg — id 6b2bfdee-1b56-4da5-a107-c6184c5695a7 These two sat In Progress for 8+ hours, then silently disappeared from notarytool history. They never returned Accepted and never returned Invalid — the records are simply gone. xcrun notarytool info no longer shows any meaningful state for them. Second batch (rebuilt & resubmitted 2026-09-10 ~04:36 UTC) — currently stuck In Progress (~2.5h): CowAgent-2.1.8-arm64.dmg — id 8fb34878-ebf2-4efc-8366-223169dc053a — submitted 2026-09-10T04:36:33Z CowAgent-2.1.8-x64.dmg — id 5f306801-32fc-42e1-987b-6c0799bac510 — submitted 2026-09-10T04:39:39Z The packages are correctly signed. Local verification passes every check: codesign --verify --deep --strict → "valid on disk" and "satisfies its Designated Requirement" Hardened Runtime enabled (flags=0x10000(runtime), Runtime Version 14.0.0) Authority=Developer ID Application: Shenzhen Minimal Future Technology Co., Ltd. (UFB3325L3Q), full chain to Apple Root CA Secure timestamp present All embedded Mach-O binaries (Electron frameworks/helpers + ~180 PyInstaller backend binaries) signed inside-out. Our previous releases from this same Team ID (2.1.7, 2.1.7-alpha, and a related app) all notarized within minutes and were Accepted. xcrun notarytool log returns "Submission log is not yet available" for the stuck ones (processing never completes). The Developer ID Notary Service system status shows green (no events) the entire time. The combination of (a) submissions vanishing from history without a verdict and (b) every new submission from this team getting stuck looks like an account-level backend issue, not a package problem. Could a DTS engineer please look at the backend logs for Team ID UFB3325L3Q and either release the queue or tell me what is blocking these submissions? Thank you.

Hi, I will make an enrollment application on behalf of the organization. But I saw on the screen that the developer name was wrong. But the trade name and my name on the top right are correct. Will the developer name appear when the application goes live? Or will only the trade name appear?

I’m seeing several Developer ID notarization submissions stuck in “In Progress” after an app transfer. This is for a macOS app distributed outside the Mac App Store. The app was recently transferred to a new Apple Developer team. After the transfer, notarization uploads succeed, but the submissions never complete. The app appears to be Developer ID signed correctly with the new team. I submitted the app through both Xcode Direct Distribution and command-line notarytool. The upload succeeds, but the submissions remain in “In Progress”, and no notarization log is available. Example submission IDs: 5e411dc6-0610-4f9c-8eef-e2a3d0b6a2fb 01bdeeda-3c7e-421a-ae72-6dc081b75e79 986b0c5e-e32f-489f-bc86-3b3c7d7ec91d 193f29b7-b23a-40e7-8324-c076859ca843 notarytool log returns: Submission log is not yet available or submissionId does not exist I also see older submissions from the previous day still stuck in “In Progress”, so this does not look like a normal notarization delay. I’m trying to determine whether this is caused by the recent app transfer / Team ID change, or whether there is anything else I can check locally. Questions: Is it expected for Developer ID notarization jobs to remain “In Progress” for more than a day with no log available? Is there any known issue with Developer ID notarization after an app transfer? If the upload succeeds but no log is ever generated, is there a recommended escalation path for stuck notarization backend jobs?

Every notarytool submit from my team is rejected with: "status": "Rejected", "statusSummary": "Team is not yet configured for notarization. Please contact Developer Programs Support…", "statusCode": 7000 This has persisted for 10+ days across many submissions (most recent job ID 00042820-f5d8-4c6b-a178-9b98d247170d, 2026-07-09). I distribute a macOS app outside the Mac App Store via Developer ID, so there is intentionally no App Store Connect app record. Everything on my side is verified correct: Apple Developer Program membership is active (Individual), team ID 5JDP238JFX. Valid Developer ID Application certificate; codesign --verify --strict passes with hardened runtime + secure timestamp; the signature chains cleanly to Apple Root CA. notarytool authenticates successfully — notarytool history returns my submission list — so credentials and team are correct; only notarization eligibility appears not to be enabled. I've signed in as Account Holder and see no pending agreements to accept. (← edit this line to match what you actually find — see note below.) My trader information was recently approved (received Apple's confirmation email). I've filed a Developer Program Support request but have had no response in over a week. The statusSummary reads like a team-level provisioning flag that hasn't been enabled. Ask: Can a DTS/forums engineer help get the notary service provisioned/enabled for team 5JDP238JFX, or point me to what account-side step is still outstanding? Happy to provide additional submission IDs or logs.

Hi everyone, I’m posting here because I’m unsure what else I can do at this point. About three weeks ago, I encountered an issue with Developer ID Application certificates in my Apple Developer account. During the certificate creation process, the Apple Developer website appears to have generated multiple certificates at once — five certificates were created, which immediately exhausted my available certificate quota. Unfortunately, I no longer have access to the corresponding private keys, and there is no option available in my account to revoke these Developer ID Application certificates myself. Because of this, I’m currently unable to create a new Developer ID Application certificate, which means I cannot properly sign and notarize my macOS app for distribution outside the Mac App Store. This is blocking my ability to use the Apple Developer Program normally, even though it is a paid service. I opened a support case with Apple Developer Support more than three weeks ago, but so far I have not received any substantive resolution. The case still appears unresolved, and I have not been given a way to revoke the old certificates or reset the quota. Has anyone experienced a similar issue with Developer ID certificate quota exhaustion? Is there any recommended escalation path for this kind of case? For Apple staff: I would really appreciate it if someone could help escalate or review this issue. I simply need the unusable Developer ID Application certificates revoked or my certificate quota reset so I can continue signing and notarizing my app. Thank you.