Xcode 14 beta code signing issues when SwiftPM targets include resources

I was able to fix this issue on fastlane by adding skip_codesigning: true on gym

Adding skip_codesigning: true didn't actually fix the issue.
Entitlments and watch app would not be correctly signed.

What really solved the issue was adding xcargs: "CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=#{options[:teamid]}"

1 Like

This issue still alives on Xcode 14.0.1, and seems to be solved on fastlane with adding xcargs "CODE_SIGN_STYLE=Manual" to Gymfile.

1 Like

Thanks! That solved the issues for us.

Have you somehow disabled the archiving in a previous Xcode task, or are you not running any "clean", or "build" tasks? Is the action "archive" enough?

I'm asking, because your current version of the Xcode task looks so different from the previous one.

In the initial xcode Task, I used 'packageApp' that will run the ´archive´ mode. But later I figured that I still needed to sign the .ipa with the entitlements. Hence I only needed to archive with extra arguments.

Ideally, one should have a build pipeline that will run a clean-build and test the code, then such pipeline to deploy the .ipa after it's verified.

We use fastlane match for signing, so the project should be signed manually by default, so CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM=<TEAM_ID> didn't help.

The project is archived successfully on the local machine, but fails to be archived on GitHub actions....

Finally fixed the issue by disabling automatic signing for Pods.xcodeproj targets (it was enabled by cocoapods generation for xcframeworks)
Here you can find my post_install Podfile section

Is this still happening on Xcode 14.2?

1 Like

Confirmed, that this is still happening on Xcode 14.2


+1 still facing the same issue with Xcode 14.2.
issue with fastlane gym with SPM, passing arguments didn't worked for us. :smiling_face_with_tear:
still the same issue.
codesigning_identity: "", xcargs: "CODE_SIGN_STYLE=Manual DEVELOPMENT_TEAM="
Any other workarounds?

1 Like

Xcode 14.1 (14B47b)
Any arguments helps :frowning:
I have an iOS app target that embed 3 frameworks + widget target that is also embed those 3 frameworks.

I also tried to add predefined ExportOptions.plist but it doesn't help in any wait it ends up with following export options

"provisioningProfiles": {
   "com.***": "match AppStore com.***",
   "com.***.Widget": "match AppStore "com.***.Widget",
   "com.***.WebAPI": "match AppStore com.***.Widget",
   "com.***.SharedUI": "match AppStore com.***.Widget",
   "com.***.Core": "match AppStore com.***.Widget"
"method": "app-store",
"signingStyle": "manual"



Resolved the issue for me

Finally we found a workaround when using match + gym on Fastlane. Using update_code_signing_settings before match ins what did the trick, the resulting operations look like this:

    use_automatic_signing: false,
    team_id: team_id,
    targets: [target],
    code_sign_identity: "*****",
    profile_name: "your_profile_name",
    path: PROJECT_PATH

  # Signing and Building
    username: options[:username],
    git_url: certificates_url,
    app_identifier: app_identifier,
    type: "appstore", 
    team_id: team_id
    project: PROJECT_PATH,
    export_method: "app-store",
    configuration: "Release", 
    scheme: scheme,
1 Like

I've tried this and checking the .app file for code signing shows its not signed at all. Did you have to resign your .app?
Also where can I find documentations on

"Starting from Xcode14 when codesigning env variables (e.g. PROVISIONING_PROFILE_SPECIFIER, CODE_SIGN_IDENTITY) are passed as parameters to xcodebuild, that setting is applied to every target (even the target from SPM package) and this results in codesigning failure as not every SPM target supports codesigning."


Is it possible to disable code signing we provide SDK. We dont really need code sign
I have tried the following but it still requires signing on the bundle

xcodebuild \
        -workspace $xcworkspace \
        -scheme $scheme_name \
        -destination "$destination" \

Could somebody confirm if it is still an issue on XCode 14.3?