Application Identifier Entitlement Value Has Changed

Application Identifier Entitlement Value has Changed?

Have you transferred the app from another developer account to your one? The previous provisioning ID will obviously be different.

UPDATE - For clarification

I have noticed that this answer is getting a lot of views so I will just edit it to include my further explanation from the comments below.

Basically the previous version of your application will NO longer be able to access keychain in order to save secure strings such as passwords (if it contains this functionality). This is because the distribution/provisioning profile it was signed with contains a different ID than the one you are using in your new distribution/provisioning profile because you have transferred your app from a previous account to your new one.

However any NEW versions of your app which are signed with the latest distribution/provisioning profile WILL be able to access keychain as normal in order to save secure data if they need this functionality because they are signed with a distribution/provisioning profile which contains the latest App ID for that app.

ERROR ITMS-90283 with Invalid 'com.apple.application-identifier' entitlement value when submitting Mac Catalyst app

I finally got this to work by giving up on the automatically derived "maccatalyst" bundle ID and using a custom bundle ID. Here are the steps I took:

1. In Xcode, turn off the "Derive Mac Catalyst Product Bundle Identifier" build setting.
2. Edit the "Product Bundle Identifier" build setting and add a separate bundle ID for the macOS platform. (screen shot 1)
3. In the iOS Provisioning Portal, edit the App ID for the associated iOS app and turn off the Mac Catalyst option.
4. Create a new App ID for the Mac version of the app, and enter the new macOS bundle ID.
5. Create new development and distribution profiles using the new App ID. When creating the profiles, these must be Mac Catalyst, not Mac, profiles. Xcode would only accept Mac Catalyst profiles when validating. (screen shot 2)
6. In App Store Connect, edit the macOS app record and change the bundle ID from the maccatalyst ID to the custom ID. This was still editable because I hadn't yet successfully uploaded a binary.

My new profiles now appear as Eligible on the Signing & Capabilities tab in Xcode, but they do not appear as options on the validation page when submitting. However, as with my original setup, I can click the Import Profile option there and select the file downloaded from the provisioning portal.

Note that this is the setup to use if you do not want Universal Purchase. If you do want that, you would need to use the same bundle ID as for the iOS app, and you might need to wait until Xcode 11.4 is released in order to submit the app with that setup. I'm not sure about that, but I am sure that you cannot submit apps with the Xcode 11.4 beta, because I tried it. (screen shot 3)

I didn't try automatic signing with the custom bundle ID setup. I think that would work because I think somehow the problem was related to the automatically derived bundle ID. That is basically deprecated with the upcoming Xcode 11.4 and Universal Purchase capability, so I suspect that a change on Apple's end has broken the validation of that style of bundle ID, perhaps only in limited cases that affected my app due to some factor that neither I nor Apple were able to identify.

Custom bundle ID settings:

"Profile is not a 'Mac Catalyst App Store' profile":

Cannot submit from Xcode beta:

Profile doesn't match the entitlements file's value for the application-identifier entitlement

I'm not sure why this fixed it, but I went into my Target's Capabilities tab, turned iCloud ON, tried to do an archive build, it failed, I turned iCloud OFF again, tried to do an Archive build and it succeeded, and after that it was able to automatically resolve certificates again.

App installation failed due to application-identifier entitlement

I had this problem with an iPhone app, and fixed it using the following steps.

• With your device connected, and Xcode open, select Window->Devices
• In the left tab of the window that pops up, select your problem device
• In the detail panel on the right, remove the offending app from the "Installed Apps" list.

After I did that, my app rebuilt and launched just fine. Since your app is a watchOS app, I'm not sure that you'll have the same result, but it's worth a try.

The application-identifier entitlement is not formatted correctly - iOS Xcode 4

Turns out now in Xcode 4+ you do not need an Entitlements.plist for your Release build (or at least, Xcode 4 does something weird with it that Xcode 3 didn't).

Anyway, to fix my issue I simply removed the reference to my Entitlements.plist from the release parameter under 'Code Signing Entitlements' in Build Settings.

Built, Archived, Validated, Submitted to iTunes Connect.

Provisioning doesn't match the entitlements file's value for the com.apple.developer.parent-application-identifiers entitlement

There are two values that need to match up. First, locate the provisioning profile Xcode is using for your App Clip (they're in ~/Library/MobileDevice/Provisioning Profiles) and inspect it by highlighting the file and pressing space. The parent ID value in there:

..has to match the same field in your .entitlements file in your App Clip target in Xcode. If it doesn't you can just edit the entitlement manually.

Ad Hoc application-identifier entitlement doesn't match?

The mismatch is in the provisioning profile being used. I can't tell you why, but the entitlements are being extracted from your provisioning profile during signing, based on the portal appID that profile was created from. There's a mismatch between the bundle ID of the target you built and the bundle ID of the portal's appID record that the signing provisioning profile was created with.

First, make sure that the profile is the one you're meaning to use (the AdHoc Distribution provProf for a portal appID that matches the bundle ID of your target, and if that looks right, consider regenerating the AdHoc provisioning profile and installing it using the Xcode>Preferences >Accounts "Download Manual Profiles" option.

Sometimes Xcode will get confused if you have old versions of provisioning profiles installed, and I've even seen times in the past where a wild card profile was matching instead of the intended one. So, there could be some Xcode confusion around the installed provProfs. The fact that you had no issues with Xcode 8 but do with Xcode 9 might explain that. Changes in Xcode can cause changes in behavior.

If regenerating the provProf and installing it doesn't help, I'd suggest deleting all of your installed mobile provProfs and then reinstalling them. To delete them, open a terminal window and enter

rm ~/Library/MobileDevice/"Provisioning Profiles"/*.mobileprovision

Then go back to the Xcode>Preferences>Accounts and do the "Download Manual Profiles" option to install them again. If it still doesn't work, you're missing something. See the debugging tip below.

Focus on the appID's bundle ID in the Dev portal, the bundle ID of your target, and the provisioning profile you're signing with (making sure it's for an AdHoc build of that appID). At least one of those isn't matching up.

One last debugging tip. Drag the provisioning profile you're signing with to TextEdit (I keep that in my dock for pretty much this reason.) TextEdit will display the information in the provProf, so you can check the entitlements and make sure they match what you're expecting.

Hopefully that's enough to sort this out.

Entitlement 'application-identifier' has value not permitted by a provisioning profile

First the entitlements format changed, then it became auto generated when archiving an application. Delete the entitlements file altogether and remove any references to it in the build settings.

---

Related Topics