These code signing issues can be encountered in different scenarios-
- Swift Package Manager code signing issues
- CocoaPods code signing issues
- Conflicting provisioning profiles issues
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.
You could try to 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
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.