Skip to main content

Building an iOS app for testing

You can build an iOS app specifically for testing: our dedicated Step builds your app and its associated tests and also exports an .xctestrun file. Once built, you can upload the app to a third-party testing service or install it on a simulator or a physical device. You can also use this Step to set up virtual device testing with Firebase.

The Step uses the build-for-testing action of xcodebuild. To learn more about it, see How do I implement the Build For Testing and Test Without Building features from the command line?

Code signing

Installing the app on a test device requires code signing. The Xcode Build for testing for iOS Step has a built in code signing configuration: it allows code signing with automatic provisioning. In most use cases, you don't need any other Step to code sign your app for testing.

To build your iOS app for testing:

Workflow Editor

bitrise.yml

  1. For code signing, make sure you have connected your Apple service account to Bitrise.

    The Step accepts Apple ID and API key authentication for automatic code signing. We recommend using API key authentication.

    Manual code signing

    You can also use manual code signing: in that case, do not configure the automatic code signing options of the Step.

  2. Make sure you install all of the app's dependencies in your Workflow.

  3. Add the Xcode Build for testing for iOS Step to your Workflow after the Step or Steps installing dependencies.

  4. Make sure the Project path input points to the correct location.

    The input asks for the path to your .xcodeproj or .xcworkspace file. In most cases, you don't need to change this input: when adding a new app, the project scanner automatically finds the relevant file and stores its location in the Environment Variable that is the default value of the input.

    Checking the default value

    If you are not sure whether the default value of the Project path input points to the right location, go to the Env Vars tab and check that the $BITRISE_PROJECT_PATH variable's value is the correct path to your .xcodeproj or .xcworkspace file.

    CocoaPods

    If you use CocoaPods as your dependency manager, the Project path input must point to the .xcworkspace file.

  5. Make sure the Scheme input points to the scheme you want to use to build the app.

    The default value is the Environment Variable that stores the scheme you set during the initial configuration of the app. If you wish to use a different scheme, type its name into the input field.

  6. Set the build configuration you want to build in the Build Configuration input.

    The default value is Debug.

    build-for-testing-step.png
  7. Configure the device destination in the Device destination specifier input: the input takes comma-separated key-value pairs.

    Since the build-for-testing action can be performed without an actual specific device, we recommend targeting a platform generically:

    // building for physical iOS devices
    generic/platform=iOS
    
    // building for simulators
    generic/platform=iOS Simulator

    The input sets the -destination option of xcodebuild. Read more about the possible options: How do I run unit tests from the command line?

  8. Optionally, set a specific test plan in the Test plan input.

    The input sets the -testPlan option of the build-for-testing action of xcodebuild. If you leave this empty, the test plan specified in the Xcode scheme will be used.

  9. If you need code signing, we recommend using the automatic code signing option: find the Automatic code signing input group, and choose a method from the dropdown menu of the Automatic code signing method input.

    auto-code-signing-input.png

    Code signing certificates

    Keep in mind that you need to upload code signing certificates to Bitrise in order to successfully sign your app.

    We recommend using API key authentication: a Bitrise-managed authentication method configured on the App settings page.

    If you want to control API authentication on a Step level instead, you can override the default Bitrise-managed connection by setting all three inputs that define a different API key authentication in the App Store Connect connection override input group:

    api-connect-override.png
  10. Add the Deploy to Bitrise.io Step to the end of your Workflow to be able to access the generated artifacts either on the Artifacts tab or in the Test Reports add-on.

  1. For code signing, make sure you have connected your Apple service account to Bitrise.

    The Step accepts Apple ID and API key authentication for automatic code signing. We recommend using API key authentication.

    Manual code signing

    You can also use manual code signing: in that case, do not configure the automatic code signing options of the Step.

  2. Make sure you install all of the app's dependencies in your Workflow.

  3. Add the xcode-build-for-test Step to your Workflow after the Step or Steps installing dependencies.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test: {}
  4. Make sure the project_path input points to the correct location.

    The input asks for the path to your .xcodeproj or .xcworkspace file. In most cases, you don't need to change this input: when adding a new app, the project scanner automatically finds the relevant file and stores its location in the Environment Variable that is the default value of the input.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test: {}
            inputs:        
            - project_path: "$BITRISE_PROJECT_PATH"

    Checking the default value

    If you are not sure whether the default value of the Project path input points to the right location, go to the Env Vars tab and check that the $BITRISE_PROJECT_PATH variable's value is the correct path to your .xcodeproj or .xcworkspace file.

    CocoaPods

    If you use CocoaPods as your dependency manager, the Project path input must point to the .xcworkspace file.

  5. Make sure the scheme input points to the scheme you want to use to build the app.

    The default value is the Environment Variable that stores the scheme you set during the initial configuration of the app. If you wish to use a different scheme, type its name into the input field.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - project_path: $BITRISE_PROJECT_PATH
    
  6. Set the build configuration you want to build in the configuration input.

    The default value is Debug: if you do not set a value for the input, the build will target the Debug configuration.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - configuration: Debug
              - project_path: $BITRISE_PROJECT_PATH
    
  7. Configure the device destination in the destination input: the input takes comma-separated key-value pairs.

    Since the build-for-testing action can be performed without an actual specific device, we recommend targeting a platform generically:

    // building for physical iOS devices
    - destination: generic/platform=iOS
    
    // building for simulators
    - destination: generic/platform=iOS Simulator

    The input sets the -destination option of xcodebuild. Read more about the possible options: How do I run unit tests from the command line?

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - configuration: Debug
              - destination: generic/platform=iOS Simulator
              - project_path: $BITRISE_PROJECT_PATH
    
  8. Optionally, set a specific test plan in the test_plan input.

    The input sets the -testPlan option of the build-for-testing action of xcodebuild. If you leave this empty, the test plan specified in the Xcode scheme will be used.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - configuration: Debug
              - destination: generic/platform=iOS Simulator
              - test_plan: my_plan
              - project_path: $BITRISE_PROJECT_PATH
    
  9. If you need code signing, we recommend using the automatic code signing option: set the automatic-code-signing input to either of two values:

    Code signing certificates

    Keep in mind that you need to upload code signing certificates to Bitrise in order to successfully sign your app.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - configuration: Debug
              - destination: generic/platform=iOS Simulator
              - test_plan: my_plan
              - automatic_code_signing: api-key
              - project_path: $BITRISE_PROJECT_PATH
    

    We recommend using API key authentication: a Bitrise-managed authentication method configured on the App settings page.

    If you want to control API authentication on a Step level instead, you can override the default Bitrise-managed connection by setting three inputs that define a different API key authentication:

    • api_key_path: Local path or remote URL to the private key (p8 file) for the App Store Connect API.

    • api_key_id: Private key ID used for App Store Connect authentication.

    • api_key_issuer_id: Private key issuer ID used for App Store Connect authentication.

    All inputs required

    All three inputs must be set for the authentication override to work!

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - api_key_path: path/to/p8        
              - api_key_id: key_id        
              - api_key_issuer_id: issuer_id
    
  10. Add the deploy-to-bitrise-io Step to the end of your Workflow to be able to access the generated artifacts either on the Artifacts tab or in the Test Reports add-on.

    your-workflow:
      steps:
        - git-clone: {}
        - xcode-build-for-test:
            inputs:
              - scheme: $BITRISE_SCHEME
              - configuration: Debug
              - destination: generic/platform=iOS Simulator
              - test_plan: my_plan
              - automatic_code_signing: api-key
              - project_path: $BITRISE_PROJECT_PATH
        - deploy-to-bitrise-io: {}