App Store Connect Errors for embedded dylibs

Question

Created Feb ’23

Replies 5

Boosts 0

Views 1.8k

Participants 2

I have a Mac app that was accepted to the App Store when I built it using Xcode 13 (with code signing set to automatic, just like I do now), but with Xcode 14.2 I keep getting mails with ITMS-90288: Invalid Code Signing Entitlements and TMS-90286: Invalid Code Signing Entitlements, two very similar errors for each embedded dynamic library.

The exact wording is this:

TMS-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: '(My team id).' for the key 'com.apple.application-identifier' in 'Spatterlight.app/Contents/Frameworks/libc64diskimage.dylib'

ITMS-90286: Invalid Code Signing Entitlements - Your application bundle's signature contains code signing entitlements that are not supported on macOS. Specifically, value '(My team id).' for key 'com.apple.application-identifier' in 'Spatterlight.app/Contents/Frameworks/libc64diskimage.dylib' is not supported. This value should be a string starting with your TEAMID, followed by a dot '.', followed by the bundle identifier .

The post https://developer.apple.com/forums/thread/710598 seems to indicate that dylibs shouldn't have entitlements at all, but apparently Xcode is adding them anyway, making the app unacceptable to the App Store.

How do I fix this?

Answered by Dalaplan in 744701022

This was solved in a reply on Stackoverflow (https://stackoverflow.com/questions/75422505/how-to-prevent-xcode-from-adding-malformed-entitlements-to-my-dylibs/75422519#75422519), which seems to be written by ChatGPT of all things. The problems seems to have been that my dylibs didn't have any .entitlements files. I created new ones, and in the review shown by Xcode before submitting the app, it seems as if the entitlements in them were stripped, which makes sense if dylibs are not supposed to have entitlements. What makes less sense is that they need entitlements files.

Boost

Answer 1

Dalaplan OP

Feb ’23

Accepted Answer

This was solved in a reply on Stackoverflow (https://stackoverflow.com/questions/75422505/how-to-prevent-xcode-from-adding-malformed-entitlements-to-my-dylibs/75422519#75422519), which seems to be written by ChatGPT of all things. The problems seems to have been that my dylibs didn't have any .entitlements files. I created new ones, and in the review shown by Xcode before submitting the app, it seems as if the entitlements in them were stripped, which makes sense if dylibs are not supposed to have entitlements. What makes less sense is that they need entitlements files.

0

Answer 2

DTS Engineer OP

Apple

Feb ’23

Xcode should not be signing dynamic libraries with entitlements. Are you building libc64diskimage.dylib from within Xcode? Or building it with an external build system and then using Xcode to pull it into your app?

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

0

Answer 3

Dalaplan OP

Feb ’23

Nope, everything is built from within Xcode. As I wrote, is seems to be the fact that the dynamic library targets had no entitlements files that confused the "sign for App Store" stage somehow, as simply adding those files fixed everything.

If you are really interested, the full project is available here: https://github.com/angstsmurf/spatterlight/tree/appstore . Going back to the commit before the last should make the problems reappear. Note that only the appstore branch is signed and has everything properly set up for the App Store.

0

Answer 4

DTS Engineer OP

Apple

Feb ’23

Earlier I wrote:

Xcode should not be signing dynamic libraries with entitlements.

Blah. I did a quick test of this today and, lo!, Xcode is signing a dynamic library with entitlements. This is not just when you run through the distribution process. It’s also happening for development builds. For example, if I build a dynamic library target and then go to the build products directory, I see this:

% codesign -d --entitlements - libLLL.dylib
Executable=/Users/quinn/Library/Developer/Xcode/DerivedData/Test724808-dfziifmnmrshrrbjqahsmjjammiu/Build/Products/Debug/libLLL.dylib
[Dict]
    [Key] com.apple.application-identifier
    [Value]
        [String] SKMME9E2Y8.

This problem then flows through the whole distribution workflow, where it ends up causing problems for the App Store.

Notably, Xcode does the right thing for a framework target:

% codesign -d --entitlements - FFF.framework
Executable=/Users/quinn/Library/Developer/Xcode/DerivedData/Test724808-dfziifmnmrshrrbjqahsmjjammiu/Build/Products/Debug/FFF.framework/Versions/Current/FFF

Please file a bug against Xcode about this and then post your bug number here so that I can add my findings to it.

Anyway, given the above, your workaround seems reasonable enough.

*sigh*

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

0

Answer 5

Dalaplan OP

Feb ’23

Right, I think I managed to file a bug report, with number FB11990678.

https://feedbackassistant.apple.com/feedback/11990678

0