ITMS-90334 error when executing a Xcode Cloud TestFlight build

When I try to create a TestFlight build of my app using Xcode Cloud, I get a couple of ITMS-90334 errors and the build fails. The error messages look like:

ITMS-90334: Invalid Code Signature Identifier - The identifier 'MySwiftPackage-55554944e95A2da4fe9e3357b44de57c3ba890e8' in your code signature for 'MySwiftPackage_-658550CFFF128C8B_PackageProduct' must match its Bundle Identifier 'MySwiftPackage'

Where MySwiftPackage is a Swift Package which is used by a framework as well as the application. The dependencies look like this:

MyApp
+ MyFramework
  + MySwiftPackage
+ MySwiftPackage
  • MyApp is a macOS app
  • MyFramework is a mixed Swift and Objective-C framework
  • MyApp is also mixed Swift and Objective-C
  • When I run an archive build on my local Mac and upload the build to App Store Connect to be used as a TestFlight build, everything seams to be fine and the build is accepted
  • I found some discussions on ITMS-90334 but not related to using Swift Packages and Frameworks

Any ideas what might be going on or where I can look to get more info on the nature of ITMS-90334?

Up vote post of zykloid Down vote post of zykloid
2.5k views
Posted by
zykloid
Reply
Add a Comment

Apple Recommended

macOS 13.1 beta 4 addresses the issue creating ITMS-90334: Invalid Code Signature Identifier in Xcode Cloud. No update to Xcode is necessary to address the issue. This beta was released yesterday, and is available in Xcode Cloud when you configure a workflow to specify the macOS version used to execute your build. As this version is currently a beta, it is only available as part of the "Latest Beta or Release" macOS configuration, or as a dedicated choice for the macOS version, at this time.

If you find this issue is not addressed with this configuration change to your Xcode Cloud workflow, continue to provide us feedback through Feedback Assistant, and share the FB numbers here so I can follow up on them.

Posted by
edford
Post not yet marked as solved Up vote reply of edford Down vote reply of edford
Post marked as Apple Recommended

  • That's good news! I will adjust my workflow accordingly and test it with the new macOS beta.

    —
    zykloid

  • Thanks a lot, i wish to have a better reactivity and clarity in the answer next time. in 5 months waiting, I switch 3 apps to Fastlane.

    —
    riderx

  • 👍 Thanks a lot it is working as expected now!!!!

    —
    denismartin

Replies

Same issue for us. Works fine manually via Xcode.

Trigger Xcode Cloud build. 2 of our packages result in the same error.

The packages are pure Swift. Our codebase is pure swift. It is an iOS app.

Posted by
stephenbrown90
Up vote reply of stephenbrown90 Down vote reply of stephenbrown90
Post marked as solved

  • This is interesting. I assumed it has something to do with my Swift Packages used and embedded by the Objective-C frameworks. But this seams not to be the case.

    By the way, flagging your reply as "accepted solutions" was an "accident" on my part. But there seams to be now way to un-flag a reply once it has been set. So from my point of view, I'm still looking for an answer!

    —
    zykloid
Add a Comment

Hi, has anyone had any luck with this? I have the exact same problem.

I tried fetching the archive from the Xcode Cloud build artifacts, replace the "Frameworks" directory with one from a local build, tried the validation from the Xcode Organizer and it worked.

I also opened the framework binaries with an hex editor, and those built with Xcode Cloud have those bogus identifiers (which btw all begin with 55554944), whereas the ones built locally have my Team ID.

I have absolutely no idea how to change this when building from Xcode Cloud, but maybe it's a hint?

Posted by
matteoc
Up vote reply of matteoc Down vote reply of matteoc

  • Thank you for the details! But no luck so far.

    —
    zykloid
Add a Comment

I also have same issue. My issues resulted by RxSwift from SPM.

Posted by
Martin-K
Up vote reply of Martin-K Down vote reply of Martin-K
Add a Comment

For me it was related to static vs dynamic builds, detailed it here: https://stackoverflow.com/questions/72291080/itms-90334-invalid-code-signature-identifier-when-building-via-xcode-cloud/73653319#73653319

Posted by
jdowd7
Up vote reply of jdowd7 Down vote reply of jdowd7
Add a Comment

There is an issue with Ad-Hoc signing of dynamic libraries built either through a Swift Package, or through an Xcode target with a non-standard Bundle ID (i.e. one not using reverse DNS format), resulting in the ITMS-90334 error message. We'd appreciate getting reports of this filed through Feedback Assistant, and then posting the FB number here so that I can follow-up on the reports internally. Even if the following workaround information is helpful to you, we'd still appreciate getting the Feedback reports.

The best practice for Swift packages is to not explicitly specify the LibraryType in the Product. By not specifying this value, you let Xcode decide the best linkage type for your app's usage of the package. If you have a package that is explicitly marked as dynamic, removing the library type means Xcode will link the package statically if the package is only imported by one target, which will avoid the issue.

If the package is imported by more than one target, Xcode will choose dynamic linkage if the LibraryType is not specified; manually selecting static in this scenario is not a workaround, as it will introduce duplicate symbol issues into the app. To workaround the issue in this scenario, refactor how your targets are structured, reducing the reliance on the package to a single target, so that this becomes the first scenario I described where Xcode can safely link the library statically while avoiding the code signing error, as well as avoiding duplicate symbol issues.

Posted by
edford
Post not yet marked as solved Up vote reply of edford Down vote reply of edford

  • @edford

    "To workaround the issue in this scenario, refactor how your targets are structured, reducing the reliance on the package to a single target"

    This doesn't seem like a very feasible workaround... Take a library like PromiseKit for example, how should one simply refactor the target structure to include the package only in one single target. It would defeat the purpose of using the library.

    —
    crazedcrapaud

  • i did open a case in the support of Apple...

    please you have to simplify the procedure, i opened it a month ago and they are still on the "understanding my problem" phase because they couldn't see the video i send, and they need to have it upload in a link they send in separate email i never received.

    —
    riderx

  • @edford FB11517354

    —
    matteoc

macOS 13.1 beta 4 addresses the issue creating ITMS-90334: Invalid Code Signature Identifier in Xcode Cloud. No update to Xcode is necessary to address the issue. This beta was released yesterday, and is available in Xcode Cloud when you configure a workflow to specify the macOS version used to execute your build. As this version is currently a beta, it is only available as part of the "Latest Beta or Release" macOS configuration, or as a dedicated choice for the macOS version, at this time.

If you find this issue is not addressed with this configuration change to your Xcode Cloud workflow, continue to provide us feedback through Feedback Assistant, and share the FB numbers here so I can follow up on them.

Posted by
edford
Post not yet marked as solved Up vote reply of edford Down vote reply of edford
Post marked as Apple Recommended

  • That's good news! I will adjust my workflow accordingly and test it with the new macOS beta.

    —
    zykloid

  • Thanks a lot, i wish to have a better reactivity and clarity in the answer next time. in 5 months waiting, I switch 3 apps to Fastlane.

    —
    riderx

  • 👍 Thanks a lot it is working as expected now!!!!

    —
    denismartin