Written by Rudrank Riyam
Since the release of Xcode 14, numerous code signing issues have emerged, plaguing builds across various CI/CD platforms. And even though code signing process was never easy, issues like these were relatively uncommon in previous versions of Xcode, such as Xcode 13 and Xcode 12, leaving many developers worried.
If you are facing some unfamiliar code signing issues with Xcode 14, while everything seems to be fine with your keys and certificates, you aren’t alone. Fortunately, developers have already come up with workarounds for some of these errors. This article discusses recurring code signing problems related to Xcode 14, Swift Package Manager, and CocoaPods, as well as a few potential solutions and workarounds.
These code signing issues can be encountered in different scenarios and contexts, so we’ll go through several of them:
- Swift Package Manager code signing issues
- CocoaPods code signing issues
- Conflicting provisioning profiles issues
Let’s get started!
If you’re new to iOS code signing, read this guide.
Swift Package Manager code signing issues
The first dependency manager in which this code signing problem occurs is the Swift Package Manager. It works fine for Xcode 13 if you run it via a CLI, but running the same archive xcodebuild command on Xcode 14 throws an error similar to this:
spm-bundle-sign-package_TargetWithResources requires a development team. Select a development team in the Signing & Capabilities editor.
These errors may come from packages or local packages that have a resources bundle. Xcode 14 tries to code sign resource package bundles, but this is not supported.
A solution suggested by an Apple engineer is to pass CODE_SIGN_STYLE=Manual as an argument when building the IPA.
So, if you are using Codemagic, pass the arguments as xcargs in the xcode-project build-ipa command:
xcode-project build-ipa --project "$XCODE_PROJECT" --scheme "$XCODE_SCHEME --archive-xcargs "CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=<YOUR_DEVELOPMENT_TEAM>"
If you’re using fastlane, then you may be able to solve the issue by adding xcargs "CODE_SIGN_STYLE=Manual" to Gymfile.
CocoaPods code signing issue
Xcode 13 used to automatically set CODE_SIGNING_ALLOWED to NO by default for resource bundles. But that’s no longer the case in Xcode 14. Unfortunately, you need to assign a development team to each and every Pod target.
In your Podfile, you can add the following:
post_install do |installer|
installer.pods_project.targets.each do |target|
if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
target.build_configurations.each do |config|
config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
end
end
end
end
However, you have to be cautious about the above workaround, as there may be an invalid signature error, which will cause your app to be rejected. Here’s a sample error that you may receive from App Store review, where it complains about the wrong type of code signing certificate:
ITMS-90035: Invalid Signature
- The binary with bundle identifier 'SOME_IDENTIFIER' at path [SOME_APP.app] contains an invalid signature. Make sure you have
signed your application with a distribution certificate, not an ad hoc certificate or a development
certificate. Verify that the code signing settings in Xcode are correct at the target level (which override
any values at the project level). If you are certain your code signing settings are correct, choose 'Clean
All' in Xcode, delete the 'build' directory in the Finder, and rebuild your release target.
However, some developers have reported successfully passing App Store review regardless of the issue.
Another alternative is to set the development ID for each Pod target:
post_install do |installer|
installer.generated_projects.each do |project|
project.targets.each do |target|
target.build_configurations.each do |config|
config.build_settings["DEVELOPMENT_TEAM"] = "Your Team ID"
end
end
end
end
These workarounds should help you get your project code signed and working on Codemagic for Xcode 14.
Let us know on Twitter if the solution provided above solves your problem!
Flutter 3.3.3 fixes
In Flutter 3.3.3 and above, you do not have to manually add the above settings to get CocoaPods to work. The new version doesn’t code sign transitive dependencies, and you can find the pull request that fixed it here.
If you are using Flutter 3.3.3 and above, you may remove any build setting workarounds you have added to your Podfile.
Conflicting provisioning profiles issues
Another issue arising with the release of Xcode 14 has to do with the conflicting provisioning profiles. This problem is plaguing projects using both Swift Package Manager and CocoaPods. The error looks something like this:
spm-bundle-sign-package_TargetWithResources has conflicting provisioning settings. spm-bundle-sign-package_TargetWithResources is automatically signed for development, but an inconsistent code signing identity Apple Distribution has been manually specified. Set the code signing identity value to "Apple Development" in the build settings editor, or switch to manual signing in the Signing & Capabilities editor.
A potential fix for this issue is adding another flag to the xcode-project build-ipa command:
xcode-project build-ipa --project "$XCODE_PROJECT" --scheme "$XCODE_SCHEME --archive-xcargs "CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=<YOUR_DEVELOPMENT_TEAM>"" --archive-flags "-destination 'generic/platform=iOS' CODE_SIGNING_REQUIRED=YES CODE_SIGNING_ALLOWED=NO"
This works with both Swift Package Manager and CocoaPods projects. If you’re working on a CocoaPods project, you should run pod install before setting up signing using xcode-project use-profiles if you’re not doing so already.
Conclusion
Code signing is difficult to work with, and these new issues complicate things even more. But don’t worry! Codemagic has got you covered with the solutions provided above and by making code signing as seamless as possible with code signing identities and automatic code signing. You can now automatically fetch code signing certificates from Apple Developer Portal as well as upload code signing certificates and provisioning profiles to use them for multiple apps. With all that, you can redirect your efforts to providing a better experience for your users instead!
Our team is eager to know about your experience while solving this issue. If you have any suggestions or feedback, join our Slack community!
