Updating App - Validation Hell - 90286, 91130

What platform are you targeting?

This matters because it seems like your app is using a unique App ID prefix, and those aren’t supported on the Mac.

which I assume is the same issue with a Developer ID instead of a Team ID.

OK, let’s clarify terminology. Developer ID isn’t a term we use in this context. Rather, it refer to the general mechanism for distributing Mac apps directly, rather than via the Mac App Store. See Developer > Developer ID.

You’re dealing with a unique App ID prefix. I explain that identifier, and many others, in Code Signing Identifiers Explained.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

To clarify, this is a 2021 MacOS app (not 2011), 346JXXXXXX is my Team Member ID, QZ99XXXXXX is my Team ID, my Bundle ID is in this format: com.company.app-name, this app's Apple ID is 1575XXXXXX. I'm the Admin for the Team (of one).

I have no idea why the Team Member ID prefix is appearing in the error messages for a MacOS app and causing this issue. I didn't even know I had that Team Member ID.

Hope this info can lead to some resolution. Thanks.

Here is the complete descriptions for the validation errors. Again, don't know why Automatic Signing Management for a MacOS app generates these.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346JXXXXXXX.com.enatal.Contact-Sheet-Maker” value for the com.apple.application-identifier key in “com.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal.

346JXXXXXX is my Team Member ID

No it isn’t. Rather, it’s your App ID prefix. That much is very clear from my view of your team, but you can prove it for yourself. Do this:

1. Go to the Certificates, Identifiers, and Profiles section of the Developer website
2. Switch to Identifiers.
3. Filter for App IDs containing com.company.app-name (well, your real bundle ID, not the redacted one we’re using here).
4. Open the one you find.

At the top right you’ll see your Team ID and in the App ID Prefix field you’ll see your… well… App ID prefix. Here’s an example of what that looks like for an App ID in one of the DTS test teams:

If you manually generate a provisioning profile for that App ID and then dump that profile you’ll see something like this:

% security cms -D -i AppIDPrefixTest_Mac_Dev.provisionprofile | plutil -p -
{
  …
  "ApplicationIdentifierPrefix" => [
    0 => "VYRRC68ZE6"
  ]
  …
  "Entitlements" => {
    "com.apple.application-identifier" => "VYRRC68ZE6.com.example.apple-samplecode.appidprefixtest"
    …
    "com.apple.developer.team-identifier" => "Z7P62XVNWC"
    …
  }
  …
  "TeamIdentifier" => [
    0 => "Z7P62XVNWC"
  ]
  …
}

Now how the App ID prefix differs from the Team ID.

The interesting thing is how you managed to ship a Mac app this way. We do not, in general, support unique App ID prefixes on macOS [1]. I think the answer likes in this:

% codesign -d --entitlements - "YourAppName.app"
…
[Dict]
    [Key] com.apple.security.app-sandbox
    [Value]
        [Bool] true
    [Key] com.apple.security.files.user-selected.read-write
    [Value]
        [Bool] true

Previously your app only used unrestricted entitlements, and thus had no need for a provisioning profile.

Note The terms I’m using — unrestricted entitlement, restricted entitlement, and so on — are from from TN3125 Inside Code Signing: Provisioning Profiles.

Nowadays this sort of thing is rare because most apps want to use TestFlight and TestFlight requires the use of restricted entitlements. See TestFlight, Provisioning Profiles, and the Mac App Store.

I’m not sure if Xcode’s automatic code signing is capable of dealing with this case, which suggests two paths forward. The best one, at least in the long term, is to migrate from a unique App ID prefix to using your Team ID. That will eliminate this problem and has numerous other benefits. For example, it’ll allow you to run a beta test programme using TestFlight.

However, there are some potential drawbacks. Specifically, this change could result in confusing privilege prompts for the user, especially if your app uses the keychain.

The alternative is to keep using a unique App ID prefix and abandon automatic code signing. That’s the simplest short-term solution, but it’s obviously suboptimal in the long term.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Because the concept of unique App ID prefixes was deprecated before the Mac App Store was introduced.

Wow, thanks for your lengthy response BUT I'm still in Validation Hell. I'm right back with the same errors.

I do not plan new MacOS apps at this point (which I hope can use Automatic Signing) so I chose the manual provisioning distribution profile route as you described.

The provisioning profile was created with my App ID with my one of my two Distribution certificates (Distribution for Use In Xcode and Mac App Distribution - I used the former). The signing certificate I myncluded Team ID QZ9XXXXXXX.

<key>AppIDName</key>
	<string>My App</string>
	<key>ApplicationIdentifierPrefix</key>
	<array>
	<string>346XXXXXXXX</string>
	</array>

nd this was the provisioning profile

Name: MyApp MacOS Dist Prov Profile Type: App Store App ID: 346XXXXXXX.com.mycompany.my-app

I imported this profile into Xcode for Manual, cleaned the build, archived it, tried to validate the archive, and got these same errors.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “com.company.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

And again,

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “ccompany.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

It seems the validation code still wants my Team ID (QZ9) as a prefix and not the App ID (346). Or did you mean that I should add my Team ID as part of my bundle identifier?

Oops, code block doesn't do what I thought (again). Here are the complete descriptions.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “com.company.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346XXXXXXX.com.company.My-App” value for the com.apple.application-identifier key in “ccompany.My-App.pkg/Payload/My-App.app/Contents/MacOS/My App” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID.

so I chose the manual provisioning distribution profile route as you described.

Ah, yeah, sorry, I was a bit too subtle there. I said that you had to use manual signing, but that didn’t mean a manual provisioning profile. Rather, I was suggesting that you sign your app without a provisioning profile.

There’s no way to generate a Mac provisioning profile [1] for an App ID with a unique App ID prefix. So your options are:

• Migrate from a unique App ID prefix to using your Team ID as the App ID prefix. This is the option I recommend in general, but it’s not without its pitfalls.
• Retain the unique App ID prefix and avoid using a provisioning profile. This means you won’t be able to use any restricted entitlements [2], and that in turn means that you won’t be able to use TestFlight.

Honestly, I’m not sure if the second option is actually feasible with modern versions of Xcode and App Store Connect. But it was obviously feasible in the past because you app previously shipped that way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I’m talking about native apps here. If you use the iOS Apps on Mac feature, the story is different.

[2] That is, entitlements that must be authorised by a profile, as explained in TN3125.

The first option works for me because I have never used TestFlight nor ever plan to with this amount of validating hell.

First of all, I haven't heard that any of this was my fault or stupidity from the beginning, and I guess I am stupid because I do not know how to "Migrate from a unique App ID prefix to using your Team ID as the App ID prefix".

I guess, I'll need step-by-step instructions because nothing I tried works.

I tried changing the bundle identifier in Xcode to "QZ9XXXXXX.com.company.My-App" with no provisioning profile.

And apparently, it thinks it's a new app, and not an update with a different SKU (the same as the Identifier but not the app's SKU).

I'm sorry that this is taking so much of your time. You helped me so much for an app even older than this wth BLE and it's still working at a least a decade later (and selling).

And then this:

I also tried creating a new App ID with the Team ID, but that doesn't seem to go anywhere when there is no provisioning profile to use it with???

I do not know how to "Migrate from a unique App ID prefix to using your Team ID as the App ID prefix"

That’s because it’s not something you can do yourself O-: You have to reach out to support via Apple > Developer > Contact Us > Development and Technical > Certificates, Identifiers, and Provisioning Profiles [1].

When you do this, you have to be really clear about what you want. So, say something like:

I would like to change my App ID 346JXXXXX.com.company.app-name from using a unique App ID prefix to use my Team ID as its App ID prefix, resulting in an App ID of QZ99XXXXX.com.company.app-name.

Also, if your app has any app extensions, make sure to include those in your request.

Oh, and on re-reading this thread I realised that I hadn’t included a link to my standard post about this topic: App ID Prefix Change and Keychain Access. If I had, you might’ve found TN2311 )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] This is actually documented, but it’s not easy to find. I filed a bug requesting better docs for this (r. 180616448)

I was obviously not in a hurry to update this app, but is it normal for DTS to take ~3 weeks, and counting, to change the App ID?

is it normal for DTS

App ID changes aren’t done by DTS (Developer Technical Support), but rather but Apple Developer Program Support, aka DevPrograms. I work for DTS rather than DevPrograms, so I can’t comment on their response times.

I’m presuming you got a case number from them. If so, you can ping them via that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Apple Developer Program Support is the WORST. After three weeks, and two advisors providing robotic/AI communications, their answer was basically one line saying the problem should be resolved, and if not, start all over again. The "new" error messages are exactly the same as they were a month ago but with an App ID different from the one I clearly requested as described previously. I am still unable to validate my update.

Hmmm, let’s start by checking that your App ID prefix was successfully changed. In Certificates, Identifiers, and Profiles section of the Developer website, navigate to your App ID, and look at App ID Prefix field. Here’s an example of a unique prefix:

And here’s what you see when it’s your Team ID:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The error contained this again: "Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346JXXXX.com.company.appname". I tried via Automatic signing and manual with the same results. So, Xcode is not using the Team ID????

And here's what Developer Support answered back:

"Thank you for your patience. I have an update from our engineering team.

Please reach out to the internal team handling code-level issues.

To get help with code-level issues from Developer Technical Support (DTS), you can submit a Technical Support Incident in the Code-level Support section in your account.

Stephanie Developer Support"

Don't really think this is a code-level issue???. So, back to the beginning with DTS (and I thought you were DTS)???

So, Xcode is not using the Team ID????

Right. But your screenshot is good evidence that the App ID prefix has actually been changed, which is good.

Try this:

1. Navigate to the Certificates, Identifiers, and Profiles section of the Developer website.
2. Under Profiles, start creating a new profile.
3. Select App Store Connect and click Continue.
4. Select your App ID and click Continue.
5. Complete the rest of the workflow.
6. Download the profile.
7. Dump it:

% security cms -D -i Test835497_Dist.mobileprovision | plutil -p -
{
  …
  "ApplicationIdentifierPrefix" => [
    0 => "Z7P62XVNWC"
  ]
  …
  "Entitlements" => {
    "application-identifier" => "Z7P62XVNWC.com.example.Test835497-T"
    …
    "com.apple.developer.team-identifier" => "Z7P62XVNWC"
    …
  }
  …
  "TeamIdentifier" => [
    0 => "Z7P62XVNWC"
  ]
  …
}

Here you can see the App ID prefix property (ApplicationIdentifierPrefix) matches the Team ID property (TeamIdentifier) and that the App ID entitlement (application-identifier) has the right prefix.

If you see the same result then the Developer website side of this is all sorted, and the next step is to re-educate Xcode (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Well first, going to App Store Connect for a new profile erred out when I installed it in Xcode because it did not include MacOS platform. But the profile did show the App ID prefix as I posted before and you wanted me to check. So I created another profile for the Mac App Store, the new profile again looks good with the Team ID, bundle identifier, etc. installed it, and did the Manual signing and everything looked good UNTIL I tried to validate the archive and again go the same??? errors (below).

I couldn't find 346JXXXXXX anywhere in Xcode but it keeps showing up. Even in the Archive Contents plist the Team ID is listed with the correct bundle identifier.

So, what now?

Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal. The server’s response was: ‘{ code = 91130; description = "Invalid Provisioning Profile. The provisioning profile included in the bundle com.enatal.Contact-Sheet-Maker [Photo Contact Sheets] is invalid. Invalid 'com.apple.application-identifier' entitlement value. For more information, visit the macOS Developer Portal."; }’.

Invalid code signing entitlements. Your application bundle’s signature contains code signing entitlements that aren’t supported on macOS. Specifically, the “346J2Y98RX.com.enatal.Contact-Sheet-Maker” value for the com.apple.application-identifier key in “com.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets” isn’t supported. This value should be a string that starts with your Team ID, followed by a dot (“.”), followed by the bundle ID. The server’s response was: ‘{ code = 90286; description = "Invalid code signing entitlements. Your application bundle\U2019s signature contains code signing entitlements that aren\U2019t supported on macOS. Specifically, the \U201c346J2Y98RX.com.enatal.Contact-Sheet-Maker\U201d value for the com.apple.application-identifier key in \U201ccom.enatal.Contact-Sheet-Maker.pkg/Payload/Photo Contact Sheets.app/Contents/MacOS/Photo Contact Sheets\U201d isn\U2019t supported. This value should be a string that starts with your Team ID, followed by a dot (\U201c.\U201d), followed by the bundle ID."; }’.

After weeks foiling the forum and Developer Support and then back to DTS, several hours with Claude allowed me to update my app. Fingers-crossed for Review.

Here is a summary of the issue provided by Claude.ai:

Xcode Organizer's "Validate App" / "Distribute App" GUI flow was silently reusing a stale, cached export/signing configuration from the very first failed attempts — made months earlier, before the Team ID issue was ever corrected. Every subsequent click of "Validate App" regenerated the same old broken identifier, regardless of how clean the underlying archive, profile, or certificates actually were. This cached state was invisible and not cleared by normal troubleshooting steps (deleting DerivedData, signing out of the account, even creating brand-new archives).

The fix was to bypass Organizer's GUI entirely and drive the export/validate/upload process from the command line instead, which uses only the settings explicitly provided each time — no hidden cache.

I’m glad you’re making progress here.

My experience helping folks with issues like this is that:

1. They first bump into the issue when they adopt an API that requires a restricted entitlement. Prior to that they didn’t need a provisioning profile, and thus the unique App ID prefix wasn’t a concern.
2. The first step is to contact DevPrograms to change the App ID prefix. There are a couple of pitfalls with that:
   • The App ID prefix change can affect APIs, most notably the keychain. See App ID Prefix Change and Keychain Access.
   • If the app includes app extensions, and those are also using a unique App ID prefix, you have to get DevPrograms to change their App IDs as well.
3. Once that’s done, you can confirm that things are working correctly by manually creating a profile. See the instructions here. Again, if you have app extensions, you have to repeat this for each extension.
4. Once that’s done it’s ‘merely’ a matter of getting Xcode to recognise the change. My process for that is:
   1. In the Xcode organiser, delete the archive that I’m trying to upload (or in the project, update the version).
   2. In the Xcode project, choose Product > Clean Build Folder.
   3. Quit Xcode.
   4. Trash the contents of ~/Library/Developer/Xcode/UserData/Provisioning Profiles [1].
   5. Relaunch Xcode.
   6. Choose Product > Archive.
   7. And then use the Xcode organiser to upload that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Or ~/Library/MobileDevice/Provisioning Profiles if you’re using an old version of Xcode.

Again, thanks for all of your time with this issue.

I guess I didn't know that in 5 years time away a user requesting a file was a "restricted" entitlement (it wasn't before), or that my explicit App ID from 5 years before needed to be changed by Apple to include my current Team ID prefix. And I have no idea about extensions, keychain access, TestFlight, etc. for this simple app LOL.

This Validation Hell is well-named, and I'm hoping no critical bugs are found in this update because this process is certainly not "Automatic".

I guess I didn't know that in 5 years time away a user requesting a file was a "restricted" entitlement

If you’re talking about com.apple.security.files.user-selected.read-only and com.apple.security.files.user-selected.read-write then, no, those are not restricted. And to be clear, I’m using restricted in the sense defined by TN3125 Inside Code Signing: Provisioning Profiles.

The big change in the last 5 years is that we now support TestFlight on the Mac. Most App Store apps want to take advantage of that, and doing so requires restricted entitlements. See TestFlight, Provisioning Profiles, and the Mac App Store.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"