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)