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

My post-build script takes the "developeridexport" archive export, zips it up and uses notarytool to notarize it. I then add the .zip to a .dmg disk image. The next step is to codesign the disk image before notarizing that too. The issue is my Developer ID Application certificate is not accessible to the build host. (When I was doing this in Microsoft AppCenter (now defunct), it had a copy of my Developer ID Application certificate.) What steps do I need to take to get the disk image signed for notarization? Thanks! Lance

productsign Command Appears to Succeed but Package has No Valid Signature Category: Security, macOS, Code Signing Question: productsign command, when signing a PKG created with productbuild, appears to succeed with a success message (Wrote signed product archive to ...) but spctl verification results in rejected, source=no usable signature, indicating that the signature was not actually applied. Details: Goal: To sign a distribution package created with productbuild using a Developer ID Installer certificate. Certificate Used: Developer ID Installer: [Company Name] ([Team ID]) This certificate was issued by Previous Sub-CA and is not the latest G2 Sub-CA recommended by Apple. We cannot create a new G2 Sub-CA certificate as we have reached the limit of 5. productsign Command: productsign --sign "Developer ID Installer: [Company Name] ([Team ID])" [input.pkg] [output.pkg] productsign Output: Wrote signed product archive to [output.pkg] (Appears as a success message). spctl Signature Verification: spctl -a -vv [output.pkg] Result: rejected, source=no usable signature Notarization Service Results (Behavioral difference between Macs): On Mac A, the submission status was Accepted. On Mac B, the status was Invalid, with the notarization log message being The binary is not signed.. Troubleshooting Steps Taken: We attempted to sign both component and distribution packages with productsign, and in both cases, the signature was not recognized by the system. We skipped productsign and relied on the notarization service's auto-signing, but the notarization log still reported The binary is not signed., and the notarization failed. We have confirmed that the certificate and private key are properly associated in Keychain Access. My Questions: Given that we are using an older Previous Sub-CA certificate and cannot create a new one, why does productsign appear to succeed when the signature is not being applied? What could cause the behavioral difference where notarization is Accepted on Mac A but Invalid on Mac B? Is this a known issue with Apple's tools, or is it possibly caused by the specific structure of our PKG? What is the recommended workflow or debugging method to successfully sign and notarize a PKG under these circumstances? Thank you for your assistance

Apple is encouraging VPN apps on macOS to transition to Network Extension APIs, if they haven't done so yet, see: TN3165: Packet Filter is not API WWDC25: Filter and tunnel network traffic with NetworkExtension Using Network Extension is fine for VPN apps that are distributed via the Mac App Store. Users get one pop-up requesting permission to add VPN configurations and that's it. However, VPN apps that are distributed outside of the App Store (using Developer ID) cannot use Network Extension in the same way, such apps need to install a System Extension first (see TN3134: Network Extension provider deployment). Installing a System Extension is a very poor user experience. There is a pop-up informing about a system extension, which the user has to manually enable. The main button is "OK", which only dismisses the pop-up and in such case there is little chance that the user will be able to find the correct place to enable the extension. The other button in that pop-up navigates to the correct screen in System Settings, where the user has to enable a toggle. Then there is a password prompt. Then the user has to close the System Settings and return to the app. This whole dance is not necessary for VPN apps on the Mac App Store, because they work with "app extensions" rather than "system extensions". As a developer of a VPN app that is distributed outside of the App Store, my options are: Implement VPN functionality in an alternative way, without Network Extension. This is discouraged by Apple. Use a System Extension with Network Extension. This is going to discourage my users. I have submitted feedback to Apple: FB19631390. But I wonder, why did Apple create this difference in the first place? Is there a chance that they will either improve the System Extension installation process or even allow "app extensions" outside of the Mac App Store?

I'm trying to distribute a sandboxed macOS app with a PacketTunnelProvider (system extension) via direct distribution (outside of AppStore). The app and the extension both use the same app group, using the new group.com.XXXX.YYYY format detailed here for 10.15+ https://developer.apple.com/forums/thread/721701 I've also followed the instructions below to get around the quirk of not being able to directly process it via XCode: https://developer.apple.com/forums/thread/737894 I've re-signed with Developer ID certificate, all that is smooth and successfully notarized. However upon running the app I get: "My.app" would like to access data from other apps. Checking ~/Library/Containers ~/Library/Group Containers I see the correct files folders have been created before I select Don't Allow and Allow. My app does not access any files or folders outside of the sandboxed directories. How can I prevent this from happening? In order to diagnose further, how to diagnose exactly which files/folder the app is trying to access that is causing this problem?

I am responsible for the mobile app and thus also of the apple developer and app store connect accounts of a company. An external freelancer developed a software package for us which we aim to offer for installation and use on macOS systems of our customers; distributed exclusively outside of the Apple App Store. The software package has nothing to do with the mobile app. MacOS' Gatekeeper currently warns or even prevents our customers regarding the installation of the package on their device; pretty much as described here: https://developer.apple.com/developer-id/. According to a previous talk with Apple's Support, the software package (.app) the Freelancer developed must be signed with one of our own certificates. As we cannot grant selective app store connect access to third persons (only for the concerned certificates), we prefer to not provide access to our entire apple developer account to the freelancer, for the sole reason of the certificate & signing process. According to previous attempts with Apples' support regarding the most feasible solution in this case, they recommended me to manage the signing of the package of the freelancer, and simply request the package from the freelancer. I've thus generated an according Developer ID Certificate, but regarding the signing process, I'm confused. I know how signing works with mobile apps in XCode, but regarding software that is not distributed throughout the App Store on macOS, I'm unsure about the process. Also, as far as I know, the entitlements of the application are involved in the signing process. So my concern is that simply having the software package (.app) from the freelancer is not really enough to complete the signing + notarization process? Won't I need further information about the app's entitlements etc.? I would like to have a clear solution about the procedure that is required in these cases, as online documentations and / or forums as well as previous talks with your non-technical support from Apple did not resolve the issue.

There is no plus button ![](" https://developer.apple.com/kr/forums/content/attachment/4c286784-7329-4e31-a5b1-8dd0c9aaf9ad" "title=test.png;width=2330;height=982")

Hi I am building obs studio using cmake and Xcode. I used cmake --preset macos -DOBS_CODESIGN_IDENTITY="" to generate the build folder and inside X code used Provisioning Profile with Developer ID Application certification. The build was generated successfully but when I tried to turn on the virtual camera I see missing Missing entitlement com.apple.developer.system-extension.install error. (My Provisioning profile has System Extension Capability checked on apple developer portal) If I use this flow instead: cmake --preset macos -DOBS_CODESIGN_TEAM=63B5A5WDNG Build using Xcode with Automatic manage signing with Apple Developer Certificate. Obs studio builds successfully and Virtual camera extension also works fine. My primary goal is to notarise my app which contains OBS studio and Blackhole Audio driver for distribution outside app store. If I try to sign my obs app generated in second step codesign --deep --force --timestamp --verify --verbose \ --options runtime --sign "Developer ID Application:***" "OBS.app" The obs app fails to launch due to some errors. Can anyone please guide me which step I might be doing wrong, Much Appreciated. Thanks

Please provide a descriptive title for your feedback: Downloading Developer ID provisioning profiles - missing new entitlements Which area are you seeing an issue with? App Store Connect What type of feedback are you reporting? Incorrect/Unexpected Behavior Please provide the App name/App ID if possible: com.onexengineering.themedeck.macos Please describe the issue and what steps we can take to reproduce it bug in App Store Connect where downloading Developer ID provisioning profiles are missing the new entitlements regenerated from scratch -- App Store Connect says entitlements are good, but actual file confirms entitlements are missing App Store provisioning profiles seem to be unaffected (ignore my incorrect naming of files)

Hi everyone, After I recently changed my Apple ID (iCloud) password, my Developer ID certificate stopped working for signing macOS apps. Symptoms: Signing fails with the Developer ID certificate that was previously working fine. I tried re-downloading the certificate from my Apple Developer account and importing it into the Keychain, but the issue persists. It seems that the Developer ID identity is no longer trusted or properly linked to my system since the password change. Attempts: Re-downloaded and installed the certificate from the developer portal. Verified that the private key is present and linked. Checked keychain access and code-signing identity — everything appears normal, but the signed apps are rejected or the signing process fails. Blocking issue: I am unable to delete or revoke the Developer ID certificate on my account (Apple Support says it's not possible). Also, I can't create a new one due to the certificate limit. Questions: Is it expected for a Developer ID certificate to become invalid after changing the Apple ID password? Is there a recommended way to refresh or restore the certificate trust on macOS? How can I invalidate the current certificate and generate a new one if I'm stuck? Any insights or official guidance would be really appreciated. Thanks in advance!

I have a valid Developer ID Certificate, I've used it to sign an app locally and send the app to other machines of my colleagues to make sure it works and does not get triggered by GateKeeper Now I want to automate the process of signing and notarization on github actions and so I want to export my certificate and upload it there. Initially I tried uploading both the Developer ID Certificate and the G2 CA both as .cer files encoded in base64. But apparently I need my certificate to be in .p12 format When I try to export it from keychain access the option to export as .p12 is disabled. So how can I do it ?

This is a continuation of my own old post that became inactive to regain traction. I am trying to resolve issues that arise when distributing a macOS app with a SysExt Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate. To directly distribute the app, I start with exporting the .app via Archive in Xcode. After that, I create a new Developer ID provisioning profile for both the app and sysext and replace the embedded ones in the .app package. After I have replaced the provisioning profiles and the have the entitlements files ready, I start signing the frameworks, sysext and parent app. codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Library/SystemExtensions/<sysext>.systemextension/Contents/MacOS/<sysext> codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app After validation is successful with codesign --verify --deep --strict --verbose=4 <app>.app I zip the package, notarize and staple it ditto -c -k --keepParent "<app>.app" "<app>..zip" xcrun notarytool submit <app>.zip --keychain-profile “”<credents> --wait xcrun stapler staple <app>.app After that I finish creating signed and notarized .dmg/.pkg. hdiutil create -volname “<app>” -srcfolder “<app>.app/" -ov -format UDZO ./<app>.dmg codesign --force --sign "Developer ID Application: <name>" <app>.dmg xcrun notarytool submit <app>.dmg --keychain-profile "<credentials>" --wait xcrun stapler staple <app>.dmg Then when I move the .dmg to a clean system, open the .dmg, move the .app to the Applications folder, the attempt to run it fails with “The application “” can’t be opened.”. When I look into the console, the gatekeeper disallows the launch job with the message:
 86127 debug ProvisioningProfiles taskgated-helper ConfigurationProfiles entitlements: { "com.apple.developer.networking.networkextension" = ( "packet-tunnel-provider-systemextension" ); "com.apple.developer.system-extension.install" = 1; "com.apple.developer.team-identifier" = <teamid>; "keychain-access-groups" = ( “<teamid>.<app>.AppGroup" ); } com.apple.ManagedClient
<app>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, keychain-access-groups, com.apple.developer.system-extension.install, com.apple.developer.team-identifier LAUNCH: Runningboard launch of <app> <private> returned RBSRequestErrorFailed, error Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x600001a25830 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}, so returning -10810

 I went through all possible formats (macOS-Style and iOS-Style App Group IDs) and combinations of appgroups according to the post “App Groups: macOS vs iOS: Working Towards Harmony”. But none of those work for me. The weird part is that when I try the same steps on different developer account, I am able to get the app running. What can be wrong?

I’m having issues trying to codesign a .app file. We generated the Developer ID Application certificate using the organization owner’s account. I downloaded the certificate to my Mac and imported it into my keychain, but when I run the codesign command below, I get the following error. Could you help me? What am I doing wrong? Is there any other way to sign the .app executable? From what I’ve seen in other posts, it looks like the certificate needs to have a private key, but the certificate I download from the developer portal doesn’t include the key. Also, about exporting it as a .p12 — I couldn’t quite understand if that’s considered a safe practice, since the organization owner’s private key would be included in this certificate that we plan to use in our pipeline.

I think from January 2025 I'm trying to become a developer for apple. The process was an adventure. First time I used the website to become a registered developer. All good until i wasn't able to make any inputs in a disabled required field that was required but empty. I said ok, I'll try to use their support to guide me. After couple of mails I've understood that those answers were like: "sorry for inconvenience but try again maybe you didn't do something as expected". I've restarted the process many times and did tried, nothing worked. So... go back to email with support (note, there is no quick reply, sometimes it takes near a week or so to respond: and the response is "try again, sorry to hear that, let us know if we can help you") After a month or so i got an email that told me to use the application to enroll. So I decided to use it. So I've canceled my active enroll and moved to the device. My iPad Pro didn't worked, so I moved to MacBook Pro and tried from there with the Developer App. Didn't work.... Go back to email support. After a while they told me that is an issue with my card and they can't get my money from it, (is the same that I'm using on their store to buy app and it works without any issue). After another months spent on emails (copule because of their response timing, maximum 2 reply each week) and after I said I'll do my best to find someone from their management to let them know the nightmare that I'm forced to live with the support team, they said let me call you. They called me and their tool for remote view desktop didn't worked so it was like, do this, do that, I did, I did, I tried...ok let's try one more time and don't touch anything after. I did what they said and they told me that I'll be contacted soon. 2-3 days I waited for the call and...nothing... I did sent reply email support to understand the status of enrollment. I got this: " Thanks for your message. I will be happy to provide a status update. Your orders have not been successful. I am trying once again today. Since it is Friday, it will take a little longer to process. I will check on it again on Monday, when we are back in the office. Kind regards, " And today is Tuesday and nothing... I did asked also if you can't take my money just let me know the error that you receive so I'll be able to contact card issuer and ask to verify if that is an issue with it. I did asked and they told me they don't see any issue. Now I'm stuck,,,, Do I need to contact Tim just to open a developer account? I think he's busy with more important stuff. @support

使用direct distribution进行分发时，safari web extension 在safari setting 中显示没有权限读取、修改或传输任何网页的内容。 但是我在看公证日志显示插件是正常的公证的 这导致safari extension 无法使用。 公证日志 https://www.coupert.com/img/2025-04-10/notarization-log.json

Hi all, I'm developing a simple Finder Sync Extension, using Xcode 16.3. When running in Debug with Xcode, everything works fine. Instead, when compiling in Release and launching the containing app (by double-clicking on it), the Extension is not recognized (neither loaded) by the system. The only difference between Debug and Release stands in Signing configuration: Debug: Release: As you can see, in Release I'm using a Provisiong Profile, configured with my company's Developer ID. I'm wondering if Capabilities and Entitlements are not what is needed by my app. Anyway, I have no idea what the issue is. Any suggestion will be appreciated. Thank you in advance _Alex

Thank you very much for choosing me to go to Apple Park to participate in WWDC. I am looking forward to participating in this event. May I ask you some questions? I am a young Apple Developer Program from China. And I am the winner of the Swift Student Challenge in 2024. I am over 13 years old. I used my own Developer account, not my parents', to apply for WWDC activities and all the events I carry out. Since I am under 18 years old, my parents may need to sign the Special Event Parental Permission Statement. Where can I find it? My parents will sign it. At the same time, I noticed that the bottom of the RSVP form requires me to guarantee that I am at least 18 years old, but I am not. And I used my own account to apply for WWDC, so I want to know how to meet this need? I need a non-immigrant visa to go to the United States. So, I need to prove to the visa officer that I have received an invitation from Apple. Could Apple send me a formal invitation letter to prove that I have received an invitation from Apple? At the same time, as a teenager, I need to go to the United States with my mother, so can you mention the information of my guardian (my mother) in the invitation letter? Ps: I am very independent. I am well aware that the number of people in WWDC is limited. My mother will not enter the venue unless otherwise required.

Hello. I paid 1012 Turkish Liras from Turkey a month ago, maybe more than a month ago, through my Apple Developer Account, and my order number is as follows: W1340824368 The fee has been reduced but I have not received any notification or email! All documents are available. Please guide and help me, thank you.

My Developer ID certificate will expire in few days, so I downloaded and installed new certificate in login keychain. However my key is still linked to my old certificate. I have my .p12 but even if I delete the old certificate from login keychain and reinstall the .12 file, my old certificate reappears in the login keychain. I tried to select the new certificate in the login keychain and choose Files > Export Items (in Keychain Access) but in the Save dialog under File Format the "Personal Information Exchange (.p12)" option is grayed out. How can I generate a key/.p12 file that will be linked to my new certificate?

Hi, I'm having a really hard time figuring out why I cannot perform cloud signing via Developer ID with xcodebuild. I have a macOS application, which I can perfectly cloud sign the following way: Sign into Xcode with my Admin + Account Holder Apple ID. Delete my Developer ID Application certificate from Keychain Access. In Xcode, click Archive. When archived, click "Distribute App" in Xcode Organizer. The app is cloud signed. I prove this by extracting the certificate codesign --extract-certificates -- /path/to/app.app then locate the 1.2.840.113635.100.6.1.32 bit mentioned by Quinn in this post. I however do it by simply opening the certifiacte with Keychain Access, where I can investigate the content of the certificate, rather than use that tool he does. Then, I do the following to attempt to cloud sign via xcodebuild: Create an API Key for the whole team in Users and Access > Integrations > App Store Connect with the "Admin" role selected. Download the private key .p8 file to ~/Downloads. Sign out of my Apple ID in Xcode by removing the account in Settings > Accounts. Create an archive: xcodebuild archive -scheme "<redacted scheme name>" -archivePath ~/Downloads/archive.xcarchive -authenticationKeyIssuerID <redacted issuer id> -authenticationKeyID <redacted key id> -authenticationKeyPath ~/Downloads/AuthKey_<redacted key id>.p8 -allowProvisioningUpdates The archive is successfully created, with a new "Apple Development: Created via API (TEAM ID)" naming. Export the archive: xcodebuild -exportArchive -archivePath ~/Downloads/archive.xcarchive -authenticationKeyIssuerID <redacted issuer id> -authenticationKeyID <redacted key id> -authenticationKeyPath ~/Downloads/AuthKey_<redacted key id>.p8 -allowProvisioningUpdates -exportOptionsPlist ~/Downloads/exportOptions.plist -exportPath ~/Downloads which then fails: 2025-03-07 10:27:58.706 xcodebuild[2152:40704] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path "/var/folders/tn/yy7ynz3d0yb4p3sd_5q_wl0h0000gn/T/<redacted app name> macOS_2025-03-07_10-27-58.706.xcdistributionlogs". error: exportArchive Cloud signing permission error error: exportArchive No signing certificate "Developer ID Application" found ** EXPORT FAILED ** Opening the distribution logs, I find this in the Provisioning Log: 2025-03-07 09:09:58 +0000 2025-03-07 09:09:58 +0000 IDEProvisioningRepair(<redacted app name>.app): 2025-03-07 09:09:58 +0000 IDEProvisioningRepair(<redacted app name>.app): Sending request 84E57539-BC1D-407A-8402-7BCE9F2FD100 to <https://appstoreconnect.apple.com/xcbuild/v1/certificates> for session DVTServicesTeamBasedSession <issuer: <redacted issuer id>; key identifier: <redacted key id>>. Method: POST Headers: { Accept = "application/vnd.api+json"; "Accept-Encoding" = "gzip, deflate"; Authorization = "Bearer <redacted bearer token>"; "Content-Length" = 116; "Content-Type" = "application/vnd.api+json"; "User-Agent" = Xcode; "X-HTTP-Method-Override" = GET; "X-Xcode-Version" = "16.2 (16C5032a)"; } Payload: {"urlEncodedQueryParams":"teamId=<redacted team id>&filter%5BcertificateType%5D=DEVELOPER_ID_APPLICATION_MANAGED&limit=200"} 2025-03-07 09:09:59 +0000 2025-03-07 09:09:59 +0000 IDEProvisioningRepair(<redacted app name>.app): 2025-03-07 09:09:59 +0000 IDEProvisioningRepair(<redacted app name>.app): Received response for 84E57539-BC1D-407A-8402-7BCE9F2FD100 @ <https://appstoreconnect.apple.com/xcbuild/v1/certificates>. Code = 0 2025-03-07 09:09:59 +0000 2025-03-07 09:09:59 +0000 IDEProvisioningRepair(<redacted app name>.app): 2025-03-07 09:09:59 +0000 IDEProvisioningRepair(<redacted app name>.app): Response payload: { "errors" : [ { "id" : "3d09690a-e26f-497f-b576-25104064387e", "status" : "403", "code" : "FORBIDDEN_ERROR", "title" : "This request is forbidden for security reasons", "resultCode" : 7495, "detail" : "You haven't been given access to cloud-managed distribution certificates. Please contact your team's Account Holder or an Admin to give you access. If you need further assistance, contact Apple Developer Program Support at https://developer.apple.com/contact/." } ] } Which is really weird, since I am using an API key with Admin rights. If I create a new key, and use it only for this command, App Store Connect does show the "Last Used" date as today after running the command. I thought some time might need to pass, but the issue has been persisting since yesterday. What could be wrong here? I do have a managed Developer ID Application certificate showing in my account but I still can't retrieve it with an Admin right imbued API key.

Is it possible to directly distribute a macOS app with a Developer ID Certificate that belongs to a different team? I am trying to resolve issues that arise when distributing a macOS app with a Network Extension (Packet Tunnel) outside the App Store using a Developer ID Certificate from a different team than the app’s provisioning profiles and entitlements. I started by attempting Direct Distribution in Xcode with automatic signing. However, it fails with the following message: Provisioning profile "Mac Team Direct Provisioning Profile: ” failed qualification checks: Profile doesn't match the entitlements file's value for the com.apple.developer.networking.networkextension entitlement. I suspect the issue is that the provisioning profile allows "packet-tunnel-provider-systemextension", whereas the entitlements generated by Xcode contain "packet-tunnel-provider". When I manually modify the .entitlements file to include the -systemextension suffix, the project fails to build because Xcode does not recognize the modified entitlement. If there is a workaround for this issue, please let me know. Due to these issues, I resorted to manually creating a signed and notarized app. My process is as follows: Export the .app from the Xcode archive. Since the exported .app does not contain the necessary entitlements or provisioning profile for direct distribution, I replace Contents/embedded.provisioningprofile in both the .app and the .appex network extension. Sign the app and its components in the following order: codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/Frameworks/<fw>.framework/ codesign --force --options runtime --timestamp --sign "Developer ID Application: <name>"<app>.app/Contents/PlugIns/<netext>.appex/Contents/Frameworks/<fw>.framework/Versions/A/<fw> codesign --force --options runtime --entitlements dist-vpn.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app/Contents/PlugIns/<netext>.appex/ codesign --force --options runtime --entitlements dist.entitlements --timestamp --sign "Developer ID Application: <name>" <app>.app Verify the code signature: codesign --verify --deep --strict --verbose=4 <app>.app - <app>.app: valid on disk - <app>.app: satisfies its Designated Requirement Create a ZIP archive using: ditto -c -k --sequesterRsrc --keepParent <app>.app <app>.zip Notarize the app with notarytool and staple it. The notarization completes successfully with errors: nil. Package the notarized app into a DMG, notarize, and staple the DMG. The app runs successfully on the development machine. However, when moved to another machine and placed in /Applications, it fails to open. Inspecting Console.app reveals Gatekeeper is blocking the launch:
 taskgated-helper <bundleid>: Unsatisfied entitlements: com.apple.developer.networking.networkextension, com.apple.developer.team-identifier taskgated-helper entitlements: { "com.apple.developer.networking.networkextension" = ("packet-tunnel-provider-systemextension"); "com.apple.developer.team-identifier" = <teamid>; } As mentioned earlier, the Developer ID Certificate used for signing belongs to a different team. We are a third-party developer and do not have access to the Developer ID Certificate of the team assigned as the team-identifier. When I changed the bundle identifier (app ID), team, entitlements, and provisioning profiles to match the team associated with the Developer ID Certificate, the app worked. My question is:
 Is this failure caused by using a Developer ID Certificate from a different team, or should it still work if the provisioning profiles and entitlements are correctly set? Could there be an issue elsewhere in the provisioning profiles or entitlements for the original app ID?