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

I just purchased the Apple Developer Paid Account on the 3rd of October to start development on an App and hasn't been able to use it even once I’m having an iOS code-signing/provisioning issue where development/Ad Hoc builds complete successfully, but the app cannot be installed on my registered iPhone. The same issue occurs with builds produced through both Xcode and Expo EAS Build, so at this point I don’t think this is specific to EAS. When installing the app on the device, iOS shows: Unable to Install “Sencard” This app cannot be installed because its integrity could not be verified. The device logs give a much more specific error. Environment Apple Developer account type: Individual Team ID: 26K9NDX728 Main bundle identifier: com.sencard.mobile Widget extension bundle identifier: com.sencard.mobile.widgets App Group: group.com.sencard.mobile Physical iPhone registered in the Apple Developer portal Expo SDK: 57 EAS distribution: Internal / Ad Hoc The same device is included in both provisioning profiles The issue also occurs when building/installing through Xcode The application contains a WidgetKit extension, so there are two targets: Sencard com.sencard.mobile ExpoWidgetsTarget com.sencard.mobile.widgets Both targets use the same Apple Distribution certificate, with separate provisioning profiles as expected. Current signing configuration I completely reset the signing credentials and let EAS regenerate them. Both targets now use the same distribution certificate: Distribution Certificate Serial: 64FE74F9A8F0091A81671D9CDE9F7CDB The main application has its own active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile Provisioning Profile: 7D9CS7B97R Status: active Registered device: included The widget extension has a separate active Ad Hoc provisioning profile: Bundle ID: com.sencard.mobile.widgets Provisioning Profile: DY3D63UHPX Status: active Registered device: UDID: 00008130-************001C EAS reports: All credentials are ready to build @sencard/sencard (com.sencard.mobile, com.sencard.mobile.widgets) The build itself completes successfully. Device-side failure I captured the device system log while reproducing the installation failure. The important part appears to be Apple’s online provisioning authorization service rejecting the profile: online-auth-agent: The server returned: {"actions":["REJECT_PROFILE"],"authorized":false,...} online-auth-agent: Permanently rejected profile This is immediately followed by: installd(libmis.dylib): No online authorization (0x2) installd(libmis.dylib): validation failed because of failing online authorization (-402620392) Then MobileInstallation reports: The identity used to sign the executable is no longer valid. and: Failed to verify code signature of .../Payload/Sencard.app 0xe8008018 (The identity used to sign the executable is no longer valid.) Finally: Verification stage failed and the installation fails. What seems particularly significant is that the device contacts the online authorization service successfully, but the response is explicitly: "actions":["REJECT_PROFILE"] "authorized":false Things I have already tried I have done a fairly extensive clean reset of the signing configuration: Deleted the existing Ad Hoc provisioning profiles. Removed the existing distribution certificates from EAS. Revoked the corresponding distribution certificates in the Apple Developer portal. Created a completely new Apple Distribution certificate. Generated completely new Ad Hoc provisioning profiles. Verified that the provisioning profiles show as active in EAS. Verified that both profiles contain the physical iPhone being used for testing. Verified that both targets belong to Apple Team 26K9NDX728. Configured both the main app and widget extension to use the same distribution certificate. Created separate provisioning profiles for: com.sencard.mobile com.sencard.mobile.widgets Confirmed the App IDs still exist in the Developer portal. Confirmed the App Group exists and is assigned correctly. Confirmed the registered iPhone is present in the Developer portal. Rebuilt the app from scratch after regenerating all credentials. Confirmed that the EAS build succeeds. Reproduced the installation failure again on the physical device. Captured the iPhone system logs using idevicesyslog. Reproduced the problem with Xcode as well as EAS. Initially, before resetting the credentials, I also encountered a build-time error similar to: Provisioning profile ... doesn't include signing certificate "iPhone Distribution: ... (26K9NDX728)" I then deleted and regenerated the certificates/profiles and ensured both targets shared the same distribution certificate. That resolved the build failure — the application now builds successfully — but the resulting application is still rejected by iOS during installation with the REJECT_PROFILE / 0xe8008018 error above. What I’m trying to determine Is there some server-side state associated with my Apple Developer team/account that can cause a newly generated, apparently valid Ad Hoc provisioning profile to be returned as: REJECT_PROFILE by Apple’s online authorization service? Specifically: What causes online-auth-agent to return REJECT_PROFILE for a newly created provisioning profile? Can an Apple Developer team/account get into a state where newly generated Development/Ad Hoc profiles are rejected by device-side online authorization? Is there any additional server-side reset or validation Apple Developer Support can perform for Team ID 26K9NDX728? Is error -402620392 associated with a specific provisioning/profile authorization condition? Is there anything else I should inspect in the .mobileprovision file or code signature to determine exactly why Apple is rejecting it? Since I can reproduce this with both Xcode and EAS, is there any known issue affecting Ad Hoc/Development profile authorization rather than the build tooling itself? At this point I’m reluctant to keep generating new certificates and provisioning profiles because I’ve already done a complete signing reset and the newly generated profiles are still being rejected. Any guidance on what REJECT_PROFILE means internally, or what Apple Support should check on the Developer account/team, would be greatly appreciated.

My two apps, com.qrafter.Qrafter and com.qrafter.QrafterPro, have been on the iOS App Store since 2011, and their App IDs still use my team's unique App ID prefix 99T3FA87E9 instead of the Team ID GH4CGS3B5H. I'm adding native Mac versions to the same App Store records (universal purchase), so the bundle IDs can't change. Every profile Apple generates for these App IDs pairs com.apple.application-identifier = 99T3FA87E9.com.qrafter.Qrafter with com.apple.developer.team-identifier = GH4CGS3B5H. iOS uploads are accepted, but Mac App Store validation (xcrun altool --validate-app -t macos) rejects even a minimal one-window app with exactly two errors: Invalid code signing entitlements. … the "99T3FA87E9.com.qrafter.Qrafter" value for the com.apple.application-identifier key … isn't supported. This value should be a string that starts with your Team ID, followed by a dot ("."), followed by the bundle ID. (90286) Invalid Provisioning Profile. … Invalid 'com.apple.application-identifier' entitlement value. (91130) Following "Code Signing Identifiers Explained" (thread 811970), I requested the prefix migration through Contact Us on 4 September (case 102953576372). On 20 September Developer Support asked me to confirm the one-time keychain data loss described in "App ID Prefix Change and Keychain Access" (thread 706128), and I confirmed. Since then the case has had no reply despite follow-ups on 24 and 29 September, and as of 6 October both App IDs still show 99T3FA87E9. Two questions: Is there anything else I need to do to get case 102953576372 completed, or a better route to escalate it? Is there any way to ship a Mac App Store build for these App IDs before the migration, or is the migration the only path? I have a minimal sample project and the full validation log if that helps.

How do I write a macOS (no need for i/Pad/OS at all) application which supports HomeKit for my own private use only? My original idea was simply to write it non-provisioned, which would solve all problems perfectly. Nevertheless, that, triple alas, seems not possible (https://developer.apple.com/forums/thread/849288). Provisioned one built locally has a lot of problems, among which there are e.g., big hurdles to run it at my other Macs (https://developer.apple.com/forums/thread/848903?answerId=907702022#907702022) an extremely limited expiration date A reasonable solution would be a creation of a provisioning profile which would include an expiration date in a far future and also IDs of my other computers; alas, far as I understand, this does not seem to be possible with a Personal Team, as detailed in https://developer.apple.com/forums/thread/848903?answerId=907568022#907568022. Whilst a sort of solution might be the nuclear one, it does not feel right the slightest — I need just to run my own app, nothing more, and whilst naturally I gladly accept all the possible dangers of code I wrote myself, I definitely would not want to get completely vulnerable where all the other apps (and other threats) in the world are concerned. I've checked also the Unlisted distribution; far as understand it properly, won't do either, e.g., since it will be declined ... if your app is in a beta or prerelease state — the application is fully intended to be used locally for months or even years in this state. Besides, even Unlisted apps must go through Review, and when I bump to a need to make any kind of change, I want simply do that locally and launch my new version immediately without any Review hassle. Also, in this case the otherwise important privacy issues like e.g., determining the proper computer name (https://developer.apple.com/forums/thread/813853?answerId=874075022#874075022) are of absolutely no importance. Are there other, more reasonable options? What's the proper solution, after all? Thanks!

How to write a macOS (no need for i/Pad/OS at all) application which supports HomeKit without provisioning? Might be a non-GUI plain tool or essentially anything runnable, if it makes the solution easier. All it ever needs is access to HomeKit (in future probably also Matter) APIs and the filesystem (to write logs). The application will be used locally and privately only. Thus, the provisioning is definitely not needed, and it brings ugly problems (compare please the thread https://developer.apple.com/forums/thread/848903). Thanks!

Hi everyone, I’m unable to select my developer team or upload my app to App Store Connect from Swift Playgrounds on my iPad. Both of these actions produce the same error: Open the app project → Team & Bundle Identifier → Team. Select Upload to App Store Connect. The error reads: “Failed to Fetch Teams Your session has expired. Please log in.” No team appears for me to select, so I cannot proceed with uploading the app. My account status: Apple Developer Program membership is active. Paid Apps Agreement is Active. Bank account is Active. I can sign in to App Store Connect through a browser. Activating the Paid Apps Agreement and banking information did not resolve the error. I reported this to Apple Developer Support on September 15 and provided a screen recording showing both failures. A Senior Advisor has now recommended asking in this forum. Has anyone encountered this exact error and resolved it? Is there a specific way to refresh the developer-account session used by Swift Playgrounds, or any diagnostic information I can collect to identify the cause? Thank you.

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

When attempting to build an Apple Vision Pro application written in Swift in Xcode, we get the following status errors: "Provisioning profile [Profile Name] doesn't include the Main Camera Access capability.” and "Provisioning profile [Profile Name] doesn't include the com.apple.developer.arkit.main-camera-access.allow entitlement.” The provisioning profile we are attempting to use DOES have the Main Camera Access capability enabled through the Apple Developer portal. We have tried deleting and remaking the profile multiple times, as well as creating new profiles with the same settings, but completely different names and bundle identifiers, but keep getting the same errors. We DO have the "com.apple.developer.arkit.main-camera-access.allow” added to the entitlements file of the Xcode project, and we DO have the “NSMainCameraUsageDescription” key added to the info.plist file, along with the needed string describing the camera usage. Our organization has a valid and active Enterprise account, through which we have requested and been granted access to the “Main Camera Access” capability. We have built this applications multiple times before in the past year with no issues, these errors began after one of our provisioning profiles expired and we re-made it. We have tried clearing the Provisioning Profile Cache on our machine, clearing the Derived Data in the Xcode settings, and clearing the Xcode build cache. We are experiencing these errors on multiple machines, with different versions of our app, and with completely different apps that use the Main Camera Access entitlement. We experience these errors when the profile is downloaded directly in Xcode, and when it is downloaded from a browser and imported into Xcode. When we use “Automatically manage signing” our app properly builds and deploys to the Vision Pro, but when we use the app and attempt to access the main camera, the app crashes with the exception: "Exception: This app failed to request an authorization.” We have searched online forums and found several instances of others that have experienced this problem, but have not found a solution that works. Software Versions: Xcode Version: 26.6 macOS Version: Tahoe 26.5.1 VisionOS Version: 26.5

Hi, I am trying to make my app build on GitHub Action CI pipeline. App builds fine on xcode on my mac. For CI I am using command line xcode. I am getting following error: No profiles for 'com.snslocation.electricians-now' were found: Xcode couldn't find any iOS App Development provisioning profiles matching 'com.snslocation.electricians-now'. Automatic signing is disabled and unable to generate a profile. To enable automatic signing, pass -allowProvisioningUpdates to xcodebuild. (in target 'myapp' from project 'myapp') You can see full log of the build here: https://github.com/nbulatovi/ElectriciansNow/actions/runs/12603115423/job/35127512689 The provisioning profile is present, and verified in the previous steps in the pipeline, however xcode refuses to find it. If I add -allowProvisioningUpdates error stays. I tried manually mapping app id to profile name. Is there a way to get any debug log from xcode profile search, to see why is it not picking up the correct profile? Or can you maybe help in some other way? xcode version is 15.4, iOS SDK 17.5

Hello, I am building an multiplatform app for iOS and macOS that uses CloudKit. I want give prerelease versions of my app to testers in my team. I want those builds to use the CloudKit development environment, as some of the schema is still experimental and subject to breaking changes. However, when I distribute my app via TestFlight, the iCloud container environment is automatically set to production, even though in my entitlements file I've set the iCloud container environment to development. I also tried the 'Release Testing' distribution method, but also with this option the container environment is overridden and set to production. Does anyone know how I can distribute a release build for internal testing that uses the CloudKit development environment?

Installing a development build on a physical iPhone fails with: 0xE8008018 - The identity used to sign the executable is no longer valid. On the same Mac, same iPhone, same codebase and same Xcode, switching to a free personal Apple ID team installs and runs with no error. Only builds signed with our paid organisation team fail. Nothing else changes between the two runs. We have already regenerated certificates and provisioning profiles, deleted the profiles folder, cleared DerivedData, removed old identities from the keychain, trusted the profile on device, and tried both automatic and manual signing. None of it changes the result. We have also gone through the existing threads on this error and none of the suggested fixes apply. The build validates locally but the device rejects the identity. Since the signing team is the only variable between success and failure, what should we be looking at? A support case is open with Developer Support but we have not had a technical response yet.

We are seeing a startup issue with in-house enterprise iOS apps on iOS 27 Developer Beta. We would like to understand whether this could be related to changes in iOS 27 Developer Beta startup validation, code signing validation, provisioning profile validation, certificate chain validation, entitlements, embedded frameworks, enterprise developer trust state, or device-specific launch behavior. This issue blocks our enterprise app compatibility validation on iOS 27 Developer Beta, especially on iPhone 11 and iPhone 12 devices. If this is a known beta issue, we would appreciate confirmation from Apple and any available fix plan or workaround. Symptoms: After installing the same enterprise app, some iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta cannot launch it correctly. There are two visible behaviors: When launched from the Home Screen icon, the app stays on the Launch Screen. The normal app UI never appears. When launched from Spotlight/Search, the app crashes immediately. Additional observations: iPhone 13 and later devices do not show this issue. Other enterprise apps distributed with the same provisioning profile or provisioning setup show the same behavior. This makes the issue look less like a single app's business logic problem and more like an iOS 27 Developer Beta validation, trust, or launch-time behavior difference on specific device models. We added logs and breakpoints at the earliest possible app startup points, including main, AppDelegate, SceneDelegate, and before crash-reporting SDK initialization. On affected devices, none of these logs are printed. Based on this, it appears that our app code is never reached. The failure seems to happen before iOS transfers control to the app, possibly while launching the process or loading the app binary/frameworks. Our current suspicion is that the failure may happen during one of these system-level steps: Enterprise code signing validation embedded.mobileprovision validation Certificate chain validation Enterprise developer certificate trust validation Mach-O / embedded frameworks / dynamic libraries loading Entitlements validation Bundle ID / App ID / provisioning profile matching Reuse of stale local enterprise trust, provisioning, or signing validation state on the device Temporary workaround observed: We found a temporary workaround on affected devices: Completely uninstall the existing enterprise app from the device. Download and install the app again. Trust the enterprise developer certificate again in Settings. Launch the app again. After doing this, the app can start normally on the affected iPhone 11 / iPhone 12 devices running iOS 27 Developer Beta. The Launch Screen hang and Spotlight/Search crash no longer reproduce. This suggests that the IPA itself may not be permanently invalid, and the issue may not be caused by app business logic. It may instead be related to stale or invalid local enterprise trust, provisioning profile, certificate chain, or signing validation state after upgrading to iOS 27 Developer Beta. Questions: Does iOS 27 Developer Beta introduce any new restrictions or behavior changes for enterprise in-house app launch validation, code signing validation, enterprise developer trust state, embedded frameworks loading, entitlements, or provisioning profile validation? Are there any known differences in this area between iPhone 11 / iPhone 12 and iPhone 13 or later devices on iOS 27 Developer Beta? If multiple enterprise apps distributed with the same provisioning profile or provisioning setup fail before app code runs, does that point more strongly to a provisioning profile, certificate chain, enterprise trust state, or system validation issue? Given that completely uninstalling the old enterprise app, reinstalling it, and trusting the enterprise developer certificate again fixes the issue, could this be caused by stale trust, provisioning profile, certificate, or code-signing validation state cached on the device after upgrading to iOS 27 Developer Beta? For an enterprise app that stays on the Launch Screen before app code runs, or crashes immediately when launched from Spotlight/Search, what are the most common signing, certificate, provisioning profile, entitlement, or enterprise trust problems to check? Which system logs or crash log fields should we focus on for this kind of pre-main launch failure? For example: device console, crash log, Termination Reason, dyld message, Code Signature Invalid, profile validation, or trust evaluation messages. Are there recommended commands or checks to verify that the IPA's code signature, certificates, entitlements, embedded.mobileprovision, and embedded frameworks are all valid and consistent? If this is an iOS 27 Developer Beta regression, is there any known workaround until the issue is fixed? Environment: Distribution type: Apple Developer Enterprise Program / In-House distribution Affected OS: iOS 27 Developer Beta Affected devices: iPhone 11 / iPhone 12 Unaffected devices: iPhone 13 and later Same provisioning profile or provisioning setup: other enterprise apps show the same behavior Behavior 1: stuck on Launch Screen when launched from Home Screen Behavior 2: crashes immediately when launched from Spotlight/Search App code execution: not reached main/AppDelegate/SceneDelegate logs: not printed Crash SDK initialization: not reached Temporary workaround: completely uninstall the old enterprise app, reinstall it, and trust the enterprise developer certificate again. After that, the app launches normally. Impact: blocks enterprise app compatibility validation on iOS 27 Developer Beta for affected devices Suspected area: iOS 27 Developer Beta startup validation / code signing / provisioning profile / certificate / enterprise developer trust state / entitlements / embedded frameworks / device-specific validation behavior We are looking for guidance on how to confirm whether this is caused by an iOS 27 Developer Beta signing, provisioning profile, or enterprise developer trust validation change on iPhone 11 / iPhone 12, rather than an app-level crash. If this is a system issue in iOS 27 Developer Beta, we hope Apple can provide a fix or a practical temporary workaround as soon as possible.

Our iOS app fails to install via Ad Hoc or Development distribution with error: 0xe8008018 (The identity used to sign the executable is no longer valid). Environment: macOS 15.6.1, Xcode 16.0 Team ID: 8CJTVD465A Tested on iPhone 8 (iOS 16.7 + iOS 16.2) What works: TestFlight ✅, App Store ✅ What fails: Ad Hoc ❌, Development ❌ Key evidence: OCSP returns "good" for all certificates Brand new certificate (created today) → same error Install succeeds in Airplane mode but app shows "not available" at launch 4 different certificates, 3 profiles, 2 Xcode versions, 2 devices → all fail codesign --verify passes locally Full cert chain verified: Leaf → WWDR G3 → Apple Root CA This indicates Apple's online verification service is rejecting our team's signatures. Has anyone seen this or know how to resolve?

I'm trying to register the App ID ai.mycompany.app under our company Apple Developer account, but the portal says: "An App ID with Identifier 'ai.mycompany.app' is not available. Please enter a different string." We own the domain mycompany.ai, and no app is published with this identifier (an App Store lookup by bundle ID returns no results). I believe it was auto-registered earlier by Xcode's automatic signing under my personal Apple ID while testing a build, not under our company team. So it's now holding the identifier globally but isn't in use. I have access to both accounts — my free personal Apple ID and our paid company Developer account. The problem: under the free personal account, the Identifiers list (Certificates, IDs & Profiles) is restricted — free accounts can't access it on the portal, so I can't see or remove the Bundle ID there myself. And from the company account it doesn't appear, since it's owned by the personal team. What I want: release/remove this Bundle ID so I can register it under our company Developer account. Questions: If a Bundle ID was auto-created under a free personal team, how can it be removed when free accounts can't access the Identifiers list? Is contacting Developer Support the only way to release it in this case? Once released, does the identifier become available immediately, or is there a hold period before another team can register it? Any guidance appreciated.

Hello, I have been unable to install any development-signed app on any physical device for five months. Builds succeed, code signing passes locally, but every device rejects the app at install time with: Failed to verify code signature of .../extracted/MyApp.app : 0xe8008018 (The identity used to sign the executable is no longer valid.) ApplicationVerificationFailed The app installs briefly, then iOS immediately removes it. This started right after my account (Team ID MB4DXDTDMT) was reinstated following a duplicate-account flag. Background: I had a personal account that was converted to a business account (Wakeout LLC), then created a new personal account, which Apple flagged as a duplicate and later reinstated. The signing failure began immediately after that reinstatement. Isolation already done (this is not a local-setup problem) I have run the full isolation sequence — including every step DTS typically asks for — and the result points squarely at the account/team, not my machine: New blank Xcode project, automatic signing, new bundle ID → same 0xe8008018. Brand-new macOS user account → same failure. Multiple Macs, fresh Xcode installs → same failure. Multiple iOS devices (iPhone 17 Pro, iPhone 15 Pro, others) → same failure. Different Apple ID / different developer team on the same Mac + same device → installs fine. This is the decisive one: the local environment is healthy; only Team MB4DXDTDMT is rejected. Xcode Cloud builds for this same team install fine. Apple's cloud signing trusts MB4DXDTDMT; the device-verification backend does not. That gap can only exist server-side. I have also: revoked/regenerated all certificates multiple times, deleted/recreated all provisioning profiles, cleared ~/Library/MobileDevice/Provisioning Profiles, cleared DerivedData and CoreDevice, removed device pairing records, re-paired devices, confirmed Developer Mode and correct system time. Simulators work. codesign --verify --deep --strict passes. Profile certificate SHA-1 matches the signing cert exactly. Entitlements match. Why I'm posting here This is the same failure documented in thread 755762, where Quinn concluded: "this seems to be tied to your primary developer account and only DevPrograms has access to those details." That matches my evidence exactly: the problem isolates cleanly to one team, and only DevPrograms can see the account-side state. I've already gone through Developer Support on this — an open case has been with them for about five months without a resolution, which is what convinced me the fix isn't something I can reach from the support side. I'm posting here in case a DTS engineer can confirm the diagnosis and point me to the right path. Question for any DTS engineer: given that the failure isolates to a single team — different teams sign and install fine on the same Mac and same device, and Xcode Cloud builds for this same team install fine — can you confirm this is an account-side signing-trust state that has to be reset by Apple, and what's the most direct way to get that reset actioned? Happy to attach a sysdiagnose, full console output, or codesign -dvvv dumps on request. Thank you.

I previously attempted to apply for the hotspot-provider entitlement but was rejected. I no longer require this entitlement. I need to remove the hotspot-provider permission although the Network Extensions capability is checked. However, the generated provisioning profile still includes the hotspot-provider permission, which causes error 409 when I upload the IPA file. I only need the Network Extensions entitlement. Could you please advise how to remove hotspot-provider from the provisioning profile?

We are unable to add/remove Merchant IDs in App IDs identifier profile, after pressing "Edit" button on "Apple Pay Payment Processing" section, then choosing desired Merchant ID to check/uncheck from the available Merchant IDs, then pressing Continue/Save/Confirm buttons - nothing happens, the "Save" button text briefly changes to "Processing" and then back To "Save" and we still have previously enabled Merchant IDs and the Save button is still in enabled state, any help?

am seeing a persistent WeatherKit JWT generation failure with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 I already reviewed the related forum discussion where DTS noted that the WeatherKit App Service must be enabled separately from the WeatherKit capability on the App ID. I have confirmed that both are enabled. Confirmed configuration Team ID: FYGW4LHN42 Diagnostic app bundle ID: com.elilindenDinematch.AppleServiceDiagnostics Device: physical iPhone iOS version: 26.5 App version: 1.0 (1) I created a fresh diagnostic app specifically to isolate this from my main app. The issue reproduces in the clean diagnostic app. I have confirmed: WeatherKit is checked under the App ID capabilities. WeatherKit is enabled under Certificates, Identifiers & Profiles → Services. The Services page shows WeatherKit with “Manage your WeatherKit usage,” a “View” button, and “100% of calls available.” A fresh provisioning profile was generated. The embedded provisioning profile is present in the app. The embedded provisioning profile includes WeatherKit. The app is running on a physical iPhone, not only the simulator. Location services are enabled and authorized. The diagnostic app logs show the provisioning profile is found and includes WeatherKit: profile=FOUND appID=FYGW4LHN42.com.elilindenDinematch.AppleServiceDiagnostics team=FYGW4LHN42 WeatherKit=YES Location authorization also looks valid: servicesEnabled=true authorization=authorizedWhenInUse accuracy=fullAccuracy Failure When the app calls WeatherKit, JWT generation fails: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Then WeatherKit fails with: WeatherKit error[0] domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors code=2 description=The operation couldn’t be completed. (WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2.) Relevant excerpt: AppleDiag 2026-06-08T20:20:17.448Z App bundle=com.elilindenDinematch.AppleServiceDiagnostics version=1.0(1) AppleDiag 2026-06-08T20:20:17.448Z Device iOS=26.5 model=iPhone name=iPhone AppleDiag 2026-06-08T20:20:17.455Z PROFILE profile=FOUND name=iOS Team Provisioning Profile: com.elilindenDinematch.AppleServiceDiagnostics uuid=f42899e3-029a-4e85-b6ac-0aa515fc0028 appID=FYGW4LHN42.com.elilindenDinematch.AppleServiceDiagnostics team=FYGW4LHN42 WeatherKit=YES AppleDiag 2026-06-08T20:20:31.882Z BEGIN WeatherKit AppleDiag 2026-06-08T20:20:31.884Z WEATHERKIT start lat=40.7128 lon=-74.006 Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" AppleDiag 2026-06-08T20:20:34.652Z WEATHERKIT failed elapsedMs=2764 AppleDiag 2026-06-08T20:20:34.655Z WeatherKit error[0] domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors code=2 description=The operation couldn’t be completed. (WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2.) AppleDiag 2026-06-08T20:20:34.655Z WeatherKit error[0] userInfo=empty Because this happens in a clean diagnostic app, with WeatherKit enabled both on the App ID and under Services, and with the embedded provisioning profile confirming WeatherKit=YES, this does not appear to be an app-specific code issue or a missing App ID capability issue. Has anyone else seen WDSJWTAuthenticatorServiceListener.Errors Code=2 after confirming both the WeatherKit App ID capability and the separate WeatherKit App Service are enabled? Could someone from Apple/DTS check whether WeatherKit JWT minting is correctly enabled on the backend for Team ID FYGW4LHN42 and bundle ID com.elilindenDinematch.AppleServiceDiagnostics?

Hi Apple DTS, FivePrayer is a live App Store app and we are blocked by Family Controls (Distribution) after an app transfer. Bundle ID: com.fiveprayer.app Current team: FivePrayer LLC Previous team: Gansoft Inc. App Store: https://apps.apple.com/us/app/fiveprayer/id6755536905 This same app previously had Family Controls (Distribution) approved under Gansoft Inc. After the transfer to FivePrayer LLC, the capability did not carry over, so we had to request it again. It has now been pending for almost one month, and we cannot ship critical updates because Family Controls is a core dependency of the app. Is there a way to re-associate the previously approved entitlement with the transferred App ID, or route this to the correct Managed Capabilities / Entitlements team? Thank you.

We are seeing what looks like a signing / managed-capability mismatch for Contactless Pass Provisioning. Environment Team ID: S7AUTD2C2B Bundle IDs: com.swiftpass.ios com.swiftpass.ios.dev Xcode: 26.4 macOS: 26.4 Problem Our app has had Contactless Pass Provisioning approved by Apple for a long time, and builds were working until a few days ago. Without any intentional signing/capability changes on our side, Xcode started failing with the following error: Provisioning profile "Swiftpass prod Appstore" doesn't include the Contactless Pass Provisioning capability. Contactless Pass Provisioning capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. Observed behavior Xcode marks the relevant provisioning profiles as "Ineligible" in the profile selector. This affects both development/debug and release/App Store builds. If we remove Contactless Pass Provisioning from the app entitlements/capabilities, the exact same profiles immediately become eligible and the signing error disappears. Important detail The downloaded provisioning profiles already contain the entitlement that Xcode claims is missing. We verified the downloaded profile with: security cms -D -i /Users/sergej/Downloads/Swiftpass_prod_Appstore\(1\).mobileprovision and it contains: <key>com.apple.developer.contactless-payment-pass-provisioning</key> <array> <string>shareablecredential</string> </array> So the issue appears to be that the profile contents look correct the capability is still present in the developer portal but Xcode's eligibility check still says the profile does not include the capability What we verified Contactless Pass Provisioning is still enabled for the App ID in the Apple Developer portal Newly recreated / redownloaded profiles still contain the entitlement Both dev and distribution profiles are affected The behavior is reproducible across profile refreshes and local cleanup What we already tried Reinstalled Xcode Updated Xcode and macOS Updated command line tools Cleaned DerivedData Deleted local provisioning profile cache Refreshed/redownloaded profiles from Xcode Recreated provisioning profiles in the developer portal Removed and re-added the capability in Xcode Expected behavior If the downloaded provisioning profile contains com.apple.developer.contactless-payment-pass-provisioning, Xcode should treat that profile as eligible. Actual behavior Xcode reports that the capability is missing and marks the profile as ineligible, even though the entitlement is present in the downloaded profile. Question Has anyone seen this specific mismatch with Contactless Pass Provisioning or other managed capabilities? This currently looks like either: an Apple backend/App ID capability-assignment sync problem, or an Xcode eligibility-validation bug for managed capabilities Feedback Assistant ID: FB22439399. It contains screenshots that showcase the issue as well.

I am experiencing an issue with Apple Development certificate creation in Xcode for my organization account. Account details: Organization: Jtecx LLC Team ID: 8V397ULNY4 Issue: When I attempt to create a new Apple Development certificate in Xcode under the Jtecx LLC (8V397ULNY4) team, the certificate is consistently generated under a different team: Apple Development: Joseph Salmond (67P4AAZ5TA) This appears to be my personal team, not the organization team. Impact: Because of this mismatch: Provisioning profiles created under 8V397ULNY4 cannot find a matching signing certificate Xcode shows “Signing Certificate: None” Xcode reports that the provisioning profile does not include the signing certificate I am unable to run or test the app on physical devices due to signing failures Troubleshooting performed: Deleted all Apple Development certificates from Keychain Access Revoked existing Apple Development certificates in the Apple Developer Portal Created a new Certificate Signing Request (CSR) using Keychain Access Generated a new Apple Development certificate through the Apple Developer portal Downloaded and installed the certificate into Keychain Attempted certificate creation via Xcode (Settings → Accounts → Manage Certificates → + → Apple Development) Verified installed identities using Terminal (security find-identity) Confirmed that only the following development identity is being created: Apple Development: Joseph Salmond (67P4AAZ5TA) Deleted this identity and repeated the process multiple times Recreated provisioning profiles after generating new certificates Downloaded and installed new provisioning profiles Attempted both manual signing and “Automatically manage signing” in Xcode Revoked certificates directly from Xcode and allowed Xcode to regenerate them Confirmed that Apple Distribution certificates are correctly issued under 8V397ULNY4 Despite all of the above steps, every new Apple Development certificate continues to be created under Team ID 67P4AAZ5TA instead of 8V397ULNY4. Expected behavior: When creating an Apple Development certificate while the Jtecx LLC (8V397ULNY4) team is selected, the certificate should be issued under that same team: Apple Development: Joseph Salmond (8V397ULNY4) Requested fix: Please investigate and correct the team association so that: Apple Development certificates are generated under the correct team (8V397ULNY4) is properly associated with the Jtecx LLC developer team for certificate issuance Xcode correctly creates and uses development certificates for the organization team Additional notes: Apple Distribution certificates are working correctly under 8V397ULNY4 Only Apple Development certificates are affected This issue is blocking local development and testing on physical devices Thank you.