Cannot upload to App Store Connect due to "ITMS-90288: Invalid Code Signing Entitlements" and ITMS-90885

I am referring to this post. I am struggling with this now, too, and thought it may get more likely some attention if I start a new post about it instead of adding a comment there (does it actually make a difference, though?).

I read through (most of) the posts, mainly by Quinn, and cannot find what I'm still doing wrong. Upload with Xcode 13.4.1 still works, but with Xcode 16.3 or later I get both these errors and the warning of this topic:

ITMS-90288: Invalid Code Signing Entitlements - The entitlements in your app bundle signature do not match the ones that are contained in the provisioning profile. According to the provisioning profile, the bundle contains a key value that is not allowed: '25856V4B4X.org.tempel.findanyfile.helper' for the key 'com.apple.application-identifier' in 'Find Any File.app/Contents/Library/LaunchServices/org.tempel.findanyfile.helper'

ITMS-90885: 'Cannot be used with TestFlight because the executable “${executable}” in bundle “${bundle}” is missing a provisioning profile but has an application identifier in its signature. Nested executables are expected to have provisioning profiles with application identifiers matching the identifier in the signature in order to be eligible for TestFlight.'

I must admit that I only have an entitlement file for the main app, not for the embedded apps and frameworks. Until now, it appeared that they got automatically adopted. So, I don't understand what the entitlement for the embedded apps needs to contain.

The main apps's entitlement file is now:

codesign -d --ent - …/"Find Any File.app"
Executable=…/FAFv2 MAS Release 31.10.26, 13.38.xcarchive/Products/Applications/Find Any File.app/Contents/MacOS/Find Any File
[Dict]
	[Key] com.apple.application-identifier
	[Value]
		[String] 25856V4B4X.org.tempel.findanyfile
	[Key] com.apple.developer.team-identifier
	[Value]
		[String] 25856V4B4X
	[Key] com.apple.security.automation.apple-events
	[Value]
		[Bool] true
	[Key] com.apple.security.cs.allow-jit
	[Value]
		[Bool] true
	[Key] com.apple.security.personal-information.addressbook
	[Value]
		[Bool] true
	[Key] com.apple.security.personal-information.calendars
	[Value]
		[Bool] true

(I just added the application-identifier and team-identifier to the entitlement file in hopes that would solve this but it made no difference.)

I also checked with the other cmd on the app in the xcarchive, getting this:

tempi@TTsMini24 ~ % security cms -D -i …/Find\ Any\ File.app/Contents/embedded.provisionprofile 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>AppIDName</key>
	<string>Find Any File</string>
	<key>ApplicationIdentifierPrefix</key>
	<array>
	<string>25856V4B4X</string>
	</array>
	<key>CreationDate</key>
	<date>2026-10-31T12:30:46Z</date>
	<key>Platform</key>
	<array>
		<string>OSX</string>
	</array>
	<key>IsXcodeManaged</key>
	<true/>
	<key>DeveloperCertificates</key>
	<array>…</array>
	<key>DER-Encoded-Profile</key>
	<data>…</data>
	<key>Entitlements</key>
	<dict>
		<key>com.apple.application-identifier</key>
		<string>25856V4B4X.org.tempel.findanyfile</string>
		<key>keychain-access-groups</key>
		<array>
			<string>25856V4B4X.*</string>
		</array>
		<key>com.apple.developer.team-identifier</key>
		<string>25856V4B4X</string>
	</dict>
	<key>ExpirationDate</key>
	<date>2027-10-31T12:30:46Z</date>
	<key>Name</key>
	<string>Mac Team Provisioning Profile: org.tempel.findanyfile</string>
	<key>ProvisionedDevices</key>
	<array>
		…
	</array>
	<key>TeamIdentifier</key>
	<array>
		<string>25856V4B4X</string>
	</array>
	<key>TeamName</key>
	<string>Thomas Tempelmann</string>
	<key>TimeToLive</key>
	<integer>365</integer>
	<key>UUID</key>
	<string>…</string>
	<key>Version</key>
	<integer>1</integer>
</dict>
</plist>

Any help would be appreciated.

Actually, I just realize that I may be confusing entitlements and profile - the latter is the one I claim from Apple's website, right? I haven't visited that for years (though I already struggled understanding it back in the early years when this all started). Gonna see if I can make sense of it on the Apple dev website now.

Update - no, that can't be it. When i create a new profile, I need to choose an identifier that describes the entitlements for my app, right? So I checked my current identifier for my app, and that lists lots of options like "5G Network Slicing" and "Access Wi-Fi Information", but none of them look anything like the entitlements that I am using. So, my plain identifier that has none of these options checked should be fine, shouldn't it? Which also means that the current profile I have used for years should be fine as well.

What am I missing here? These error msgs from the MAS upload are not helpful at all. They tell me things that seem right to me, and then there's that text with the unfilled ${executable} and ${bundle}, which isn't helping either. This could be so much better. And there's no way to reliably get help from DTS directly any more either - that option has apparently been dropped for having to ask here in the forum, where I can only hope that someone will take a look at this. If it weren't for Quinn, we'd all be doomed already, probably.

Til then, I may just have to keep building and submitting with Xcode 13, and admitting to my MAS customers that I'm unable to make my app look modern while the indie build release works with the modern look as that's not locked out by Apple.

Answered by Thomas Tempelmann in 914013022

Okay - I've resolved it.

Quinn's article was giving the right answers - though some details weren't clear to me initially:

  1. I don't need provisioning profiles for my embedded programs, just as Xcode says.
  2. However, I do need to temporarily add some Capability to every sub project as well - I had initially only done this for the main project.

Adding the Capability (and then removing it again) to each sub project did add

CODE_SIGN_ENTITLEMENTS = "PRJNAME TARGETNAME.entitlements";

to the project file, which was key to getting rid of the error – and the error message was quite misleading in this way, indeed!

I wondered if the problem is that my certificate was using the exact bundle ID, not a wildcard. That would explain why it complains about 25856V4B4X.org.tempel.findanyfile.helper when the cert only was made for 25856V4B4X.org.tempel.findanyfile (despite the fact that this worked before, and still does with Xcode 13, with this setup).

I made a new identifier for "25856V4B4X.org.tempel.findanyfile.*" and then created a new cert ("Apple Development") from that, imported it into the keychain, and also deleted the older cert with the same name from the keychain. Still, I'm getting the very same errors on upload. I don't understand what's wrong.

For other folks following along at home, I put a bunch of the experience from that other thread into this post: TestFlight, Provisioning Profiles, and the Mac App Store


Regarding your issue, it seems that your app contains multiple main executables. At a minimum this includes the executable for the app itself and some sort of helper in Contents/Library/LaunchServices. Are there any others?

ps In this thread you’ll find a copy of my handy-dandy FindMachO.sh script (-:

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

Accepted Answer

Okay - I've resolved it.

Quinn's article was giving the right answers - though some details weren't clear to me initially:

  1. I don't need provisioning profiles for my embedded programs, just as Xcode says.
  2. However, I do need to temporarily add some Capability to every sub project as well - I had initially only done this for the main project.

Adding the Capability (and then removing it again) to each sub project did add

CODE_SIGN_ENTITLEMENTS = "PRJNAME TARGETNAME.entitlements";

to the project file, which was key to getting rid of the error – and the error message was quite misleading in this way, indeed!