Hello

This is not related to which provisioning profile you choose, but to your app’s entitlements configuration. One or several of those entitlements contain a wildcard character, and that isn’t accepted with a distribution profile.

See the documentation about entitlements and how to configure them using a plist file. Basically you need to open the entitlements plist file your app uses and fix the relevant key/values as indicated by Apple in the message you received.

My apologies, I probably said something wrong in my reply. It does seem the problem could come from your wildcard profile, but I wonder how is it possible that you could upload your app signed with a *distribution* certificate and a *wildcard* profile ? Normally, distribution certificates require explicit provisioning profiles.

Please go to the iOS Provisioning Portal online and check the configuration of the provisioning profile you use for App Store submission. It's likely that you're using the wrong profile (and that would also mean there's a "bug" in the App Store upload tool, because it should detect that discrepancy and prevent you to upload in the first place.)

You need an explicit (non-wildcard) profile that's purposed for App Store submission, that embeds a Distribution certificate, and sign your app with that distribution certificate. Let me know if that was indeed the cause.

Let's correct 2 misunderstandings first.

1. Creating multiple certificates from one private key is not a problem.

2. The entitlements of an app do not go in its Info.plist, instead they are stamped in the app binary itself at signing time. You may view then on Mac with the command-line utility "codesign -d --entitlements" and on PC with the command-line utility "ldid -v" (in the builder's Toolchain directory).

I would like to completely clarify the situation because you're reporting a lot of different combinations, and in each of them just a single thing off track could lead to the manifestation of the problem. Let us focus on one single use case please.

I see in the screenshots you posted that you use a DEVELOPMENT certificate ("Certificate Type: Development"). You may use this certificate to sign your app and deploy it to your device, but you *may not* submit to the App Store an app signed with a development certificate. In order to submit your app to the App Store, you must either rebuild+sign it (or simply re-sign it), using a DISTRIBUTION certificate.

The provisioning profile you use is okay though.

When you sign your app, you typically choose a provisioning profile in the droplist, and the certificate to use is automatically deduced from it. Assuming you chose the provisioning profile you posted in the screenshot, what is the name of the certificate that is displayed in the builder UI? Does it start with "Apple Development: Your Name" (or "iOS Development: Your Name"), or does it start with "Apple Distribution: Your Name" (or "iOS Distribution: Your Name")? It *has* to mention the word "Distribution". If that's not the case, the entitlements will not be set up correctly in the signed app.

Technical note: by "correctly" hear "filtered and fixed so that they are accepted by the App Store". The App Store has more strict requirements about entitlements: some which provide convenience privileges during development have to be stripped, and some others which include generic names or wildcards must have these wildcards replaced with the exact bundle ID of the app.

So, to be completely clear, let me know if the issue persists when the .ipa you uploaded to the App Store is signed with the provisioning profile shown in your screenshot stamped in it, and with a certificate whose 2nd word spells "Distribution".

If the issue persists then, it will mean that the filtering/patching rules I mentioned in the technical note 2 paragraphs above needs to be reviewed.

Do not post multiple replies that change the problem's data, please. Just answer this question clearly, and we'll proceed from there.

Okay. It was just a wrong screenshot, so that clears a bit of the confusion.

You must not run ldid or codesign on the .ipa file, you must extract the .ipa file first like a zip archive and run the tool on the app’s main binary.

.ipa (iTunes Packaged Archive) is just a zip file renamed. Zip files can’t be signed, but their individual contents may.

If you want to send me both .ipa files (the one generated by Xcode and the one generated by the builder, both signed for App Store distribution) by mail I can compare them and check for discrepancies. Confidentiality is guaranteed.

Thank you, I downloaded it.

.xcarchive is a packaging variant which stores the .app directory and the .dSYM bundles (debug symbols). It's a "bundle", which in Apple's terminology means a simple directory masquerading itself as a file. Just right-click on the .xcarchive file in macOS' file explorer (the "Finder") and select "Show package contents" to browse inside this directory. If you use the Terminal, it's even simpler: simply "cd" in it like you would for any other directory.

I'll be looking at your app's entitlements in the Windows build now and report back what I find.

So here are your entitlements (I used "ldid -e" to show just the entitlements instead of the whole code signature information):

% ldid -e Gambonanza
<?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>application-identifier</key>
        <string>RX5HNX6Z2T.com.strayfawnstudio.gambonanza</string>
        <key>beta-reports-active</key>
        <true/>
        <key>com.apple.developer.game-center</key>
        <true/>
        <key>com.apple.developer.icloud-container-identifiers</key>
        <array>
        </array>
        <key>com.apple.developer.icloud-services</key>
        <string>*</string>
        <key>com.apple.developer.team-identifier</key>
        <string>RX5HNX6Z2T</string>
        <key>com.apple.developer.ubiquity-container-identifiers</key>
        <array>
        </array>
        <key>com.apple.developer.ubiquity-kvstore-identifier</key>
        <string>RX5HNX6Z2T.*</string>
        <key>get-task-allow</key>
        <false/>
        <key>keychain-access-groups</key>
        <array>
                <string>RX5HNX6Z2T.*</string>
        </array>
</dict>
%

And indeed, these entitlements contain:

%
        <key>com.apple.developer.icloud-services</key>
        <string>*</string>
%

and

%
        <key>com.apple.developer.ubiquity-kvstore-identifier</key>
        <string>RX5HNX6Z2T.*</string>
%

which is consistent with the error message Apple sent you. I would be interested in knowing whether these entitlements are *stripped* or *edited* (e.g. the '*' character is resolved with your app's bundle ID?) in the version produced by Xcode.

:: @Pierre-Marie Baty added on 19 Nov ’25 · 15:08

*edit* According to Apple here https://developer.apple.com/documentation/bundleresources/entitlements/com.apple.developer.icloud-services?language=objc the "com.apple.developer.icloud-services" entitlements *cannot* have '*' as a value, the only accepted values are either "CloudDocuments", "CloudKit" and "CloudKit-Anonymous". So I wonder where this '*' value comes from. Probably a misconfigured value in the Unity editor? This also hints towards the hypothesis that Xcode silently drops invalid entitlements (such as this one) from binaries it's signing, which is - in my opinion - a somewhat brutal way of gettings things done! Isn't there at least a warning about it in the Xcode build logs?

I downloaded it.

Well, it clears up a lot of things !

Here are the final entitlements that are stamped in the app binary by Xcode:

% ldid -e Gambonanza
<?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>application-identifier</key>
        <string>RX5HNX6Z2T.com.strayfawnstudio.gambonanza</string>
        <key>beta-reports-active</key>
        <true/>
        <key>com.apple.developer.team-identifier</key>
        <string>RX5HNX6Z2T</string>
        <key>get-task-allow</key>
        <false/>
</dict>
</plist>
%

As you can see, Xcode simply stripped 80% of them silently. Amazing...

I suppose the ones that contain empty values (such as empty arrays) can be legitimately stripped. These are "com.apple.developer.icloud-container-identifiers" and "com.apple.developer.ubiquity-container-identifiers". I also suppose that those that contain "default values" can be stripped as well. Those would be: "com.apple.developer.game-center" (default value: "true"), and "keychain-access-groups" (default value: "<team identifier>.*")

And indeed, after having stripped all those for legitimate reasons, the only 2 keys that remain are those that Apple complain about because their value is invalid. Which means Xcode simply strips them too.

Now, how to fix that. I *could* align with Xcode's behavior here and do the same thing, but 1°) it's pretty brutal and 2°) that would require me to maintain a list of all possible values for all possible entitlement keys. I don't think that would be good design.

A better thing to do at this point, even if it doesn't align with what Xcode does, would be to remove those entitlements from the Entitlements.plist that's created by Unity, or fix their value so that they are accepted by the App Store. What do you think?

Thank you for the Xcode build log. Not a single warning indeed...

The search feature in the Windows Explorer is utterly broken. Don't expect it to find files containing something. When I look for strings in files I use another search tool, such as Midnight Commander's (a "traditional" text-mode two-panel file manager).

There can also be a list of entitlements in your provisioning profile. These ones are merged with your app's explicit entitlements at signing time. To check that, open your provisioning profile with a text editor. Skip the leading binary garbage (it's the entitlement's signature) and reach the part where the XML data starts. You might find the entitlement you're looking for there (although I wonder why the Apple Provisioning Portal would generate provisioning profiles with invalid entitlement values??) But we can't rule that out, so let me know if it's the case.

Your point that the tool should ideally mimic 1:1 what Xcode does because that's what the users expect is a heavy one and I'll take it into consideration.

:: @Pierre-Marie Baty added on 19 Nov ’25 · 16:18

*edit* Bingo.

I checked your app's embedded.mobileprovision file (that's your provisioning profile) and here goes:

% embedded.mobileprovision, Entitlements part:

	<key>Entitlements</key>
	<dict>
		<key>beta-reports-active</key>
		<true/>
				
				<key>com.apple.developer.ubiquity-container-identifiers</key>
		<array></array>
				
				<key>com.apple.developer.game-center</key>
		<true/>
				
				<key>application-identifier</key>
		<string>RX5HNX6Z2T.com.strayfawnstudio.gambonanza</string>
				
				<key>keychain-access-groups</key>
		<array>
				<string>RX5HNX6Z2T.*</string>
				<string>com.apple.token</string>
		</array>
				
				<key>get-task-allow</key>
		<false/>
				
				<key>com.apple.developer.team-identifier</key>
		<string>RX5HNX6Z2T</string>
				
				<key>com.apple.developer.ubiquity-kvstore-identifier</key>
		<string>RX5HNX6Z2T.*</string>
				
				<key>com.apple.developer.icloud-services</key>
		<string>*</string>
				
				<key>com.apple.developer.icloud-container-identifiers</key>
		<array></array>
				
				<key>com.apple.developer.icloud-container-development-container-identifiers</key>
		<array></array>

	</dict>
%

Indenting errors preserved.

So it does look like Apple generates provisioning profiles with invalid entitlement values, as per their own documentation, and the only way they seemingly were able to fix that was to make Xcode silently strip those poor entitlements instead of fixing the problem at the source.

Well, I guess that's what I need to do too...

You won't be able to post-process the built .ipa, that would break the signature.

I am building an experimental version of ldid (the code signer) in which I extended the entitlements "blacklist" to mimic what Xcode does:

% ldid.c somewhere
               is_distribution_signature = true; // remember we're signing for distribution

               // we are signing for distribution; cycle through all keys in the entitlements collection so as to exclude the blacklisted ones
               for (key_index = 0; key_index < ents_collection.key_count; key_index++)
               {
                  // if the entitlement name contains "-development-", it has no place in a DISTRIBUTION binary, so strip it out
                  // also, "com.apple.developer.icloud-container-identifiers" keys that contain empty arrays should be stripped
                  // also, "com.apple.developer.icloud-services" keys that contain a wildcard string should be stripped
                  // also, "com.apple.developer.ubiquity-container-identifiers" keys that contain empty arrays should be stripped
                  // also, "com.apple.developer.ubiquity-kvstore-identifier" keys that contain just the team identifier with a wildcard should be stripped
                  if ((strstr (ents_collection.keys[key_index].name, "-development-") != NULL)
                      || ((strcmp (ents_collection.keys[key_index].name, "com.apple.developer.icloud-container-identifiers") == 0) && (Buffer_CompareWithCharArray (&ents_collection.keys[key_index].raw_data, "<array></array>") == 0))
                      || ((strcmp (ents_collection.keys[key_index].name, "com.apple.developer.icloud-services") == 0) && (Buffer_CompareWithCharArray (&ents_collection.keys[key_index].raw_data, "<string>*</string>") == 0))
                      || ((strcmp (ents_collection.keys[key_index].name, "com.apple.developer.ubiquity-container-identifiers") == 0) && (Buffer_CompareWithCharArray (&ents_collection.keys[key_index].raw_data, "<array></array>") == 0))
                      || ((strcmp (ents_collection.keys[key_index].name, "com.apple.developer.ubiquity-kvstore-identifier") == 0) && (Buffer_CompareWithCString (&ents_collection.keys[key_index].raw_data, xmlenclosed_team_identifier_with_wildcard) == 0)) )
                  {
                     memmove (&ents_collection.keys[key_index], &ents_collection.keys[key_index + 1], (ents_collection.key_count - (key_index + 1)) * sizeof (plistkey_t));
                     ents_collection.key_count--; // shift the entitlements collection array one slot down (don't bother reallocating smaller)
                     key_index--; // and reparse this slot
                  }
               }
%

I would like you to test it and report to me if it solves the problem. If it does, I'll push a toolchain update.

Here it is: https://www.pmbaty.com/darwinbuildenv/ldid-ateo.zip

Unzip it and put it in the Toolchain directory of the builder, replacing the old one. Rebuild and let me know if Apple accepted your upload this time. You may also do a development build and test on your device to make sure both use cases work correctly.

That aligns better with what Xcode does. The only extra keys are "com.apple.developer.game-center" and "keychain-access-groups" but they wear acceptable (default) values, so it matches.

Did you test a development build and an OTA deployment of the app on your iPhone with this code signer?

I don't understand how you can get *these* entitlements on a *development* binary. The entitlements filtering rules I posted above only enforce when a distribution certificate is detected:

%
               if (Certificate_FindSignerCommonName (&certificates[certificate_index], certificate_common_name, sizeof (certificate_common_name))
                   && ((strncmp (certificate_common_name, "iPhone Distribution: ", 21) == 0) || (strncmp (certificate_common_name, "Apple Distribution: ", 20) == 0)))
%

But this is obviously not the case in the build log you posted:

%
 + Signing code as Apple Development: xxxxxxxx (XXXXXXXXXX) with team ID XXXXXXXXXX...
%

Are you sure you ran ldid on the right executable ? That would mean there's one more bug I need to fix...