Xcode Archive - specify API Key and Issuer ID

Description of the feature request

Currently, Xcode Archive step can use only Team member App Store API connection for code signing. In the deprecated iOS Auto Provision step, it was possible to specify API Key and Issuer ID in step variables. It would be great if Xcode Archive has a similar feature and help us to not use Team member connection.

As a software house, we have to manage many App Store accounts and Bitrise apps and it is really hard to properly maintain CI. We don’t want to store the connections in the company employees’ accounts, because some of them can leave the company, then their accounts are deactivated and we have to set up the API connection again. It is also usually hard to add a client to Team members because many of them are not technical and we don’t want to bother them with our technical staff. Because of that we still have to use deprecated steps, where we can specify API variables, which are stored in secrets and Code Signing general file storage.

There is also an issue with the same request on the GitHub page of the step.

Hey Bitrise team, it would be really nice to have this configuration.


We would also need that feature on several of our projects.


We absolutely need this before the old iOS Auto Provision Step is deprecated in removed on 2022-07-15


We are in a similar situation, multiple clients and multiple apps, having the ability to continue to use the api key and issuer id would maintain our current CI model. Definitely not looking to add extra hassle to the devs for something that is already working well (but will soon be deprecated).


We need this badly too. We definitely also face the issues with CI, managing lots of projects, and less technical team members, and would love to continue as we used to.


Hello everyone!

I’m happy to announce that the latest step version adds the ability to override the App Store Connect connection: Release 4.6.0 · bitrise-steplib/steps-xcode-archive · GitHub

Thank you for your patience and let us know how it’s working for your use case!


@oliver.falvai Hey, we’re really grateful that you already responded to the feature request, we just have a favor to ask :pray:

Could our team have an extension of say 2 weeks on the removal of the iOS Auto Provision with Apple ID Step, which our Bitrise setup currently uses?

On our side, we’ve been trying to make the new updated Xcode Archive & Export 4.6.0 work for us, but need more time testing things.

Originally my coworker was assigned this task, but they came down with Covid… I’m taking over, and am catching up on what needs doing as quick as I can.

Thanks for considering it!


You can continue to use the step in your bitrise.yml but it will be no longer supported should anything break you would need to move to the new steps.

You can continue to use the step in your bitrise.yml but it will be no longer supported should anything break you would need to move to the new steps.

Above is from damien.murphy’s comment.

@oliver.falvai Is this true? We actually can continue using the iOS Auto Provision with Apple ID Step after Sept 15, even though when we execute the Step, it seems to say “Removal date: Sep 15”?

edit: Ah sorry, I didn’t realize @damien.murphy is part of Bitrise’s team too! At first, when I looked through your profile, I only saw things like “Member” and “Has read community guidelines”. But then I looked again at your messages and saw you’ve made PRs as DamienBitrise.

1 Like

In the new Xcode Archive & Export Step 4.6.0, what’s the right way to fix the archive portion choosing to:

  1. Use the Xcode Managed Profile,
  2. Use the development export method,
  3. And use an “iOS Team Provisioning Profile” like what Xcode managed profiles are named,

even though we set as a Step Input variable Distribution method: app-store?

I think this will lead to problems when we send builds to App Store review.

I can see in my build logs that when it exports the IPA and tries to determine the Code sign group, it “Failed to find Codesign Groups”.

  • On the way there, the list of “Installed profiles” it filters through only includes those with Apple Development certificates and export_type: development, and it references only the iOS Team Provisioning Profile in bundle_id_profiles.

Previously with the iOS Auto Provision Step 2.0.3, we used the Input variable Should the step try to generate Provisioning Profiles even if Xcode managed signing is enabled in the Xcode project? yes

  • Bitrise would generate Provisioning Profiles we could see in our Apple Developer account, titled things like “Bitrise ios app-store - (<bundle_id>)”

You can run any step from any repo. Deprecation and removal from the Bitrise Step Library does not remove the ability to fork any step and run it directly

See: Step reference/ID format - Bitrise Docs

1 Like

Thank you @damien.murphy! Forking the Step seems to be working for now - it’ll buy us time to keep figuring things out.

1 Like

@damien.murphy I wanted to ask about a new error after some fiddling:

In my build logs, soon after “Starting the Archive …”, I now see

❌  error: No account for team <a_different_team_id_than_our_App_Store_Connect_override_API_key_settings_should_lead_to>. Add a new account in the Accounts preference pane or verify that your accounts have valid credentials. (in target <correct_value> from project <correct_value>)

❌  error: No profiles for <correct_bundle_id> were found: Xcode couldn't find any iOS App Development provisioning profiles matching <correct_bundle_id>. (in target <correct_value> from project <correct_value>)

It seems that even though I’ve set up the App Store Connect connection override by:

  • Automatic code signing method: api-key
  • Parameterizing the private key, key ID, and Key Issuer ID as custom environment variables that expand to the right values I’ve stored either as Secrets or in the Code Signing tab (the .p8 file’s URL)
    • In our case, we call Bitrise API with some things added to the environments key, kind of like:
"environments":[{"mapped_to":"API_KEY_ID","value":"$TEAM1_API_KEY_ID","is_expand":true},{"mapped_to":"API_KEY_ISSUER_ID","value":"$TEAM1_API_KEY_ISSUER_ID","is_expand":true}, {"mapped_to":"PRIVATE_KEY_URL","value":"$BITRISEIO_TEAM1_API_KEY_URL","is_expand":true}]

I get errors like

  • “No account for team <wrong_team_id>”, where <wrong_team_id> is another team ID our company uses that the private key, key ID, and key issuer ID in the custom env vars should not lead to.
  • “No profiles for <bundle_id> were found” - which seems related to the above if it is searching the wrong Team ID.