We have a command line script that runs xcodebuild to make an archive, then runs xcodebuild again to export the archive to make an ipa, and then runs "altool --validate-app" to check that everything will be fine for a subsequent upload to the app store. This has been working fine for a few years but recently stopped working and we cannot figure out why. The validation fails with this error: ERROR: [altool.105912F20] Validation failed (409) Invalid Provisioning Profile. The provisioning profile included in the com. bundle [Payload/.app] is invalid. [Missing code-signing certificate]. A distribution provisioning profile should be used when uploading apps to App Store Connect. (ID: ) The project is configured with 'Automatically manage signing' unchecked, and the profile was created on developer.apple.com/account/resources/profiles and the matching profile magically appears in the "Provisioning Profile" drop down in Xcode. The profile was created with two certificates checked, but examining the embedded.mobileprovision profile that ends up in the compiled ipa payload it appears to contain 19 certificates (probably all of them for this org?). Is there a way to find out which certificate is missing exactly? And once identified is it a case of adding it to the profile used during compilation to fix this? Ancillary question: why does the embedded.mobileprovision file contain so many certificates, and how does xcodebuild decide which ones it includes there?

Hello! I need help with the following issue. I can't create a provisioning profile. The following error message appears: The following devices are either already present and have not been modified, or they contain invalid identifiers. I'm a beginner and have been struggling with this issue for a month and a half. Any help would be appreciated.

i am creating a app on "appmysite" while it runs its build test an error message pops up saying build failed. "it seems your app build has encountered an issue. the certificate used to generate the uploaded provisioning profile does not match the uploaded certificate." I understand why its saying it because the uploaded certificate had to be uploaded as ".p12". The certificate in the provisioning profile is made of ".cert". I am using a apple mac book and a xenovo windows computer. Im simply trying to figure out how to put the ".p12" certificate into the provisioning profile? whenever i go to my developer account and try to create a new provisioning account with the new ".p12" certificate. The only options that pop up for me to select are only the certificates that are in ".cert" form. I've tried exporting through "key access" and they show up in my files but no way to transfer to my developer account to combine it with a provisioning account. Any help is greatly appreciated, this is literally the only thing keeping my app from being ready for submission to review. ive been stuck on this for 3 days.

My provisioning profile isn't installing when I double-click it on my MacBook. Also no profile on this path ~/Library/MobileDevice/Provisioning Profiles. just empty folder

Certificate Details Certificate Name Expro International Group Ltd Certificate Type iOS Distribution Expiration Date 2029/02/11 Created By Thavaseelan Kudarsamy Enabled Capabilities iCloud, In-App Purchase, Personal VPN, Push Notifications App ID ESTSMobile (com.exprogroup.estsmobile) This profile is not installing.

Original Problem We use codesign and notarytool in a scripted environment to build and distribute binaries daily. We also do manual builds by logging into the build server using SSH. This has been working for many years, but after updating to a new "Developer ID Application" certificate, codesign was failing with errSecInternalComponent and the console logs showed errSecInteractionNotAllowed. Summary of Resolution Attempting to fix the problem resulted in multiple copies of the same Certificate which were NOT shown by Keychain Access. I had to run security delete-identity multiple times to clear out the redundant Identities and then imported the certificate using the security CLI tool. Details I originally followed these instructions for requesting and installing a new certificate: https://developer.apple.com/help/account/certificates/create-developer-id-certificates/ Tip: Use the security tool intead These instructions fail to mention two critical points: 1) they assume the machine you generate the request on is the same machine you will be using to perform signatures, and 2) KeyChain Access does not allow you to set permissions for applications like codesign. I made the mistake of following the instructions on my workstation, and then tried to import the certificate to the build machine by double clicking on the .cer file. When that did not work, I followed various forum suggestions and eventually realized I need to export the private key as a .p12 file from the workstation, and import it into the build machine. Tip: The term "Certificate" often refers to a public certificate by itself, while "Identity" to refers to the combination of a public certificate and private key. At this point, I could use codesign, but only within Terminal.app while logged into the build machine's console. I tried various security commands to reimport the Identity, set a key partition list, and unlock the keychain, but none of them allowed codesign to work from within SSH or cron scripts. Eventually I stumbled upon this: sudo security find-identity -v Password: 1) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 2) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 3) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 4) EA377…96DD "Developer ID Application: Data Expedition, Inc. (VK…8X)" 5) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 6) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 7) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 8) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 9) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 10) 3C255…1560 "Developer ID Application: Data Expedition, Inc. (VK…8X)" 10 valid identities found Keychain Access only showed one copy of the Identity in each keychain, but with security I could see there were actually 9. Tip: Keychain Access does not accurately display keychain contents. If it shows no contents at all, type a letter in the search box. Identities are distinguished from lone Certificates by a drop-down caret to the left of the certificate name. Clicking that shows the key. To fix the redundant Identities, I had to run this command four times to delete the nine copies: security delete-identity -Z 3C255…1560 I repeated this until the identity (I used the SHA1 hash of the certificate) no longer showed up in security find-identity -v. I then re-imported the certificate and key using security import, which is what I should have done from the begininng. The Correct Way Here are the commands I used to get things going after I deleted all the problem certificates: security import mycertificate.cer -k /Library/Keychains/System.keychain -T /usr/bin/codesign This next command I ran in Terminal.app on the console so it could display a password prompt: security import ImportThisKey.p12 -k /Library/Keychains/System.keychain -T /usr/bin/codesign After this, I used security find-identity -v to verify that there was only one copy of the Identity. I then verified that codesign could be used from SSH and cron-scripts even while logged out of the console. I suspect that a lot of mysterious certificate problems might be caused by duplicate certificates, each with different permissions. As far as I can tell, there is no way to uniquely identify a certificate/identity or the permissions attached to them. The system just searches based on hash, or team-id, or other non-unique property and seems to just arbitrarily pick one. I hope this helps someone else stuck with errSecInternalComponent errors!

I am on a mission to secure our key material for our iOS app's code signing certificate. My first endeavor with storing the code signing certificate on a YubiKey is a marginal success - it seems that with a pin policy that requires entering the PIN at least once we must enter the PIN umpteen times per build. Creating a certificate with a policy of never would be ill-advised. On the other hand, we could chose to store the code signing certificate in the Secure Enclave. However, it seems that I am only allowed to create eliptic curve private keys and not RSA keys in the secure enclave. When I attempt to upload a certificate signing request to AppStoreConnect, I am told that only an RSA2048 key will do. What I am after is a way to authenticate access to the certificate once per boot so that we can make multiple builds per day without manual intervention whilst also ensuring that the key material is not stored on disk. A yubikey would be preferable, but I am fine with the secure enclave if need be. Is there a way to achieve this? Best regards, Emīls

Every recent attempt to create a Installer certificate has failed, and now we've hit the maximum. We can't revoke them either — the portal only shows "Download," not "Revoke." Xcode also fails with: "Signing Certificates Error: There is a problem with the request entity. You already have a current Developer certificate or pending certificate request." This is completely blocking notarization and distribution of our macOS app. Has anyone resolved this, or does it require Apple to intervene on the backend? (This is a relatively new issue, we have successfully done this in the past hundreds of times over the years.)

I've seen a few posts about this online and it seems that Xcode generates random team ID's with it's automatic signing system. But I haven't seen any way to make this work properly. If I log into the dev portal and look at my account, in the upper right I can see my team ID. If I manually generate a cert, I get a totally different one. Question: How can I generate a cert with my proper team ID (my paid account) where the ID's on my certs, identifiers and profiles all match? I've never had this issue before and am unsure how to solve it.

Context: I am building an iOS productivity app using EAS Build. The project has 4 targets: the main app and 3 extensions (ShieldAction, ShieldConfiguration, ActivityMonitorExtension). The Issue: I have officially received approval from Apple for the Family Controls (Distribution) entitlement for my main Bundle ID. However, the build still fails during the Xcode phase. The Errors: Xcode reports that the generated provisioning profiles do not include the com.apple.developer.family-controls entitlement. For example: Provisioning profile "*[expo] com.*.** AdHoc 177247892...." doesn't support the Family Controls capability. All 3 extensions are failing with the exact same error. What I've done: Confirmed approval from Apple for com.*.**. Enabled Family Controls and App Groups on the Apple Developer Portal for all 4 Identifiers. Cleared EAS local and remote cache using eas build --clear-cache. Deleted existing profiles on both Expo.dev and Apple Portal to force regeneration. The Question: Even with official approval, why does EAS continue to generate "empty" profiles for my Ad-Hoc development build? Do I need separate approval for each extension's Bundle ID, or is there a way to force EAS to sync these "Managed Capabilities" correctly?

Hey everyone, I was granted access to Family Controls (Distribution) for my main App ID The entitlement is visible and enabled in the App ID configuration. I’ve successfully created and used a provisioning profile that injects com.apple.developer.family-controls for the main app. ✅ However, the issue is with an extension target under the same parent App ID and all others Despite enabling the Family Controls (Development) capability in this extension’s App ID config, every new provisioning profile I generate for the extension fails to include the entitlement. I’ve confirmed this by: • Dumping the .mobileprovision with security cms -D → no sign of com.apple.developer.family-controls • Recreating the profile multiple times (Development and Distribution) • Ensuring the entitlement is toggled on in the portal • Validating the parent app profile does include it ⸻ ❗Question: Is there a known issue where Family Controls doesn’t get injected into extension App IDs even after team approval? Or is there an extra step I need to take to get this entitlement injected properly into provisioning profiles for app extensions?

Hi, I have some doubts about certificates expiration given this "new" requirement around signing for some common third party SDKs: https://developer.apple.com/support/third-party-SDK-requirements/ Use case: I build an SDK that will be distributed as an XCFramework and will be used in AppStore apps from different people. My SDK internally uses some other third party libraries that are integrated as binaries Let's assume some of those third party libraries are from the list above and therefore seem to be required to be signed. I distribute my SDK with all in order (third party SDKs from that list with valid signatures) People using my SDK over the time provide an update to their apps on the AppStore but by then some of the third party libraries of my SDK has an expired certificate. What would happen? People using my SDK won't have any issues as far as my SDK has a valid signature (despite third party libraries from the list have expired signatures) People using my SDK will get a warning about it but still will be able to submit to the AppStore. In that case, would AppStore Review process decline the update? People using my SDK will get an error, not being able to submit to the AppStore and will require me an update version of the SDK with those third party libraries re-signed. My understanding is that all would work as far as my SDK has a valid signature (after all is the one taking responsibility of the code inside), independently of what happens with the signature of those libraries themselves, am I correct?.

Hello, we are currently encountering a similar issue. We need to inject our capabilities into a third-party app by re-signing it (not a full re-signing process—just requiring the provisioning profile and certificate to match). However, this seems to affect the functionality of universal links. We've found that this issue only occurs on iOS 18. We noticed that when re-signing the app, the entitlements related to associated domains are changed to a wildcard: [Key] com.apple.developer.associated-domains [Value] [Array] [String] * However, this doesn’t cause any issues on iOS 17. Through further testing, we discovered that in order for universal links to work properly, we need to restore the original value of com.apple.developer.associated-domains and use a provisioning profile that matches the app's bundle ID. This means our previous re-signing approach using a certificate and provisioning profile from another bundle will no longer work. We’d like to ask: is this a new restriction introduced in iOS 18? If we manually restore the original com.apple.developer.associated-domains entitlement and use a provisioning profile that matches the app’s bundle ID, will universal links function correctly going forward?

we have organization account I'm the admin of team. and i have additional resources: Additional Resources Access to Reports Access to Certificates, Identifiers & Profiles. Access to Cloud Managed Distribution Certificate Create Apps Generate Individual API Keys Issues: i can't find my team certificate in Xcode I don't have access to https://developer.apple.com/account/resources/

*** Error: ERROR: [ContentDelivery.Uploader] Validation failed (409) Invalid Provisioning Profile. The provisioning profile included in the com.baiyun-shuniu.scss bundle [Payload/HBuilder.app] is invalid. [Missing code-signing certificate]. A distribution provisioning profile should be used when uploading apps to App Store Connect. (ID: e21c7a63-520f-49c5-8298-9afa3aa14dd5) 2025-05-13 09:23:20.382 INFO: [ContentDelivery.Uploader]

Hi everyone, I'm following up on this post I made earlier about an issue I'm having with FamilyControls and the DeviceActivityMonitor extension not working for external TestFlight testers. To briefly recap: I have official Apple approval for the com.apple.developer.family-controls entitlement (distribution) The entitlement is added to both my main app and the DeviceActivityMonitor extension The App Group is correctly configured for both targets On internal TestFlight builds, everything works as expected: app blocking works, the extension runs, and selected apps are shielded. On external TestFlight builds, users get the Screen Time permission prompt, can select apps to block, but nothing is blocked. Since that post, I submitted a Code Level Support request, and Apple asked me to file a bug report via Feedback Assistant. I did that almost a month ago. The only reply I’ve received since is that they can’t give a timeframe or guarantee it will be resolved. I'm stuck in limbo with no updates and no fix. This feature is critical to my app and I cannot launch without it. I’ve reached out to other developers who use app blocking, and none of them have run into this issue. My setup seems correct, and Apple has not said otherwise. If anyone has experienced something similar, found a workaround, or knows how to get real movement on a bug report like this, I would really appreciate any help. It’s been weeks, and I just want to launch my app. Thanks so much.

I am distributing a macOS application outside the App Store using Developer ID and need to provide provisioning profiles to customers for installation during the package installation process. I have two questions: How can I package and provide the provisioning profile(s) so that the customer can install them easily during the application installation process? Are there any best practices or tools that could simplify this step? In my case, there are multiple provisioning profiles. Should I instruct the customer to install each profile individually, or is there a way to combine them and have them installed all at once? Any guidance on the best practices for this process would be greatly appreciated.

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.

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!

Hello everyone, I'm facing a critical build issue related to Family Controls entitlements and would appreciate any insights or help from the community or Apple engineers. My Goal: I am trying to build and run my app on a physical device to test my DeviceActivityMonitor and ShieldConfigurationExtension. I have already been approved for the Family Controls (Development) entitlement. The Problem: When I try to build, Xcode fails with the following errors, preventing me from testing: For my DeviceActivityMonitor target: Provisioning profile "..." doesn't include the com.apple.developer.deviceactivity entitlement. For my SOSAppShieldExtension target: Provisioning profile "..." doesn't include the com.apple.developer.screen-time-api entitlement. The Core Evidence: This seems to be a server-side issue with how the provisioning profiles are generated. I have used the security cms -D -i command to inspect the downloaded .mobileprovision files. The inspection reveals that the profiles do contain the parent com.apple.developer.family-controls entitlement. However, they are missing the required child entitlements: The profile for my monitor extension is missing com.apple.developer.deviceactivity. The profile for my shield extension is missing com.apple.developer.screen-time-api. Troubleshooting Steps I've Already Taken: I believe I have exhausted all possible client-side fixes. Here is what I have tried over the past few days: Confirmed Approval: I am fully approved for the Family Controls (Development) entitlement. Enabled Capabilities: The "Family Controls" capability is checked and enabled for all three relevant App IDs (main app, monitor extension, shield extension) on the developer portal. Profile Regeneration: I have deleted and regenerated all provisioning profiles for all targets multiple times. Forcing a Server Refresh: I have toggled the "Family Controls" capability off, saved, and then toggled it back on and saved again for each App ID. Creating New Identifiers: I created a brand new, clean App ID for the DeviceActivityMonitor extension (com.sosapp.ios.devicemonitor) and created a new profile for it, but the error persists. Xcode Configuration: I am using manual signing in Xcode and have double-checked that each target is pointing to the correct, newly downloaded provisioning profile. I have also cleaned the build folder and deleted Derived Data multiple times. My Question: Given that my account is approved and the capability is enabled, but the generated profiles are provably missing the necessary child entitlements, this points directly to a bug in the profile generation service on Apple's backend. Has anyone else experienced this specific issue where the parent entitlement is present but the required child entitlements are missing? Is there a known workaround, or can an Apple engineer please investigate the profile generation for my Team ID? Any help would be greatly appreciated. Thank you!