iOS – Bitrise

Automate your Bundle Version in Xcode increments with your Build numbering
All Bitrise builds have a build number. The first build of your app is, by default, number 1, and the build number gets incremented with each build. You can get a build’s Bitrise build number on the website (on the Build Details page), as well as via the $BITRISE_BUILD_NUMBER Environment Variable.

Depending on how you handle your build and bundle versioning, your build might fail with an error stating that the Xcode Project Version is not greater than the current version. This is because it is expected for your bundle version to increment away from the last uploaded version and will result in issues uploading the .ipa file.

Thankfully, we have a script that will get you sorted out! The following allows you to enter your own Project Path and ensure that the bundle version increments each time and is equal to the build number of the build that runs the script. You can add this anywhere before your Archive Step:

cd $BITRISE_SOURCE_DIR
#Insert your project path below
PROJECT=./EXAMPLE_PATH.xcodeproj/project.pbxproj
sed -i '' -e 's/CURRENT_PROJECT_VERSION \= [^\;]*\;/CURRENT_PROJECT_VERSION = '$BITRISE_BUILD_NUMBER';/' $PROJECT
build_number=`sed -n '/CURRENT_PROJECT_VERSION/{s/CURRENT_PROJECT_VERSION = //;s/;//;s/^[[:space:]]*//;p;q;}' $PROJECT`

That is all! You have now automated your bundle versioning process to work off of changes in your build numbering.

Happy Building 🚀
Automatic code signing limitations
If you wish to use the automatic code signing options of Bitrise Steps, there are a few limitations to keep in mind.

The limitations only apply if all three of the following conditions are true:
- In your Xcode project, you do NOT use the Automatically manage signing option.
- On Bitrise, you use Apple ID or Step inputs for authentication when connecting to Apple services. If you use API key authentication, these limitations don't apply.
- You run your builds on Xcode 12 or earlier versions. With Xcode version 13 and above, the limitations don't apply.
Let's go through the limitations!
Can't configure certain App ID capabilities

You can add new capabilities to an Xcode project during a Bitrise build, even without running it locally at first. However, certain capabilities can't be added this way:
App Groups: can’t enable missing App Groups.

Apple Pay Payment Processing: can’t enable missing Merchant IDs.

iCloud: can’t enable missing iCloud Containers.

Push Notifications: can’t set Development SSL Certificate and Production SSL Certificate.

Sign In with Apple: enable as a primary App ID/Group with an existing primary App ID and Server to Server Notification Endpoint.

Mac Catalyst: can’t Choose a bundle ID configuration for your existing Mac app.
Can't register a new App Clip App ID

If the limitations apply to your project, Bitrise can't register a new ID for an App Clip. If you have an App Clipp target in your Xcode project, you should first build the project locally so that Xcode can create an identifier for it.
xcodebuild process hangs indefinitely
Issue:

While building an app using an xcodebuild process, you experience one of the following:
You receive an error: EXC_BAD_ACCESS

The process hangs indefinitely.
Possible solutions:

Although the Xcode.app automatically generates a shared scheme if it can't find one, xcodebuild does not. This usually generates an error: "scheme not found", but sometimes it can result in the process hanging indefinitely.

To fix this issue make sure that you have a shared user scheme.
Error: No profiles found
Issue

You might be receiving the below error message related to outdated provisioning profiles:
```
error: There are no accounts registered with Xcode. Add your developer account to Xcode (in target '&lt;TARGET_NAME&gt;' from project '&lt;PROJECT_NAME&gt;')
error: No profiles for '&lt;BUNDLE_ID&gt;' were found: Xcode couldn't find any iOS App Development provisioning profiles matching '&lt;BUNDLE_ID&gt;'. (in target '&lt;TARGET_NAME&gt;' from project '&lt;PROJECT_NAME&gt;') 
```
Possible solutions

The above error message might happen if, for example:
You use the manual code signing with the Certificate and Profile Installer Step or you use Xcode managed signing with Xcode managed profiles.

You might have been building on Xcode 12 and uploaded the respective profiles and certificates to Bitrise and then switched to the Xcode 13 stack (osx-xcode-13.1.x, osx-xcode-13.0.x and osx-xcode-edge) without updating your profiles on Bitrise.
In all cases the provisioning profiles were generated before Xcode 13, therefore they do not match with the Xcode 13 stack you use on Bitrise.

We suggest you refresh the provisioning profiles uploaded to Bitrise. The local version of your provisioning profiles might have been already updated automatically by Xcode so you need to make sure the same profiles are used by Bitrise too.
Segmentation fault
Issue:
```
clang: error: unable to execute command: Segmentation fault: 11
```
Possible solutions:

This is usually due to Xcode version mismatch - that you use a different Xcode on your Mac than the one you use on bitrise.io.

The solution is simple, just make sure that you use the same Xcode version everywhere.
Xcode Unit Test fails without any error, with exit code 65
Issue:

This can be caused by a lot of things, Xcode or some other tool simply omits / does not present any error message.
Possible solutions:
First of all, if you use xcpretty to format the output try a build without it (if you use the Xcode Test Step you can set xcodebuild as the “Output Tool” option/input to not to format the log produced by xcodebuild). The cause is: xcpretty sometimes omits the error message in it’s output.

If you don’t use our Xcode Test Step to run your UI Test you should try to run it with our Xcode Test Step. We always try to improve the reliability of the Step, implementing known workarounds for common issues.

If you use our Xcode Test Step: make sure you use the latest version, as it might include additional workarounds / fixes.

Try another Xcode version, there are issues which are present in one Xcode version but not in another one.

Make sure your desired Xcode scheme is shared. Don’t forget to commit and push the changes if you just enabled it.

It might also be a project configuration issue in your Xcode project, a code issue in your tests, or a multi-threading issue in your code.

We received reports that this might also be caused by Code Coverage report generation, you can disable the Generate code coverage files? option of the Xcode Test Step to not to generate Code Coverage files.
Xcode / the iOS Simulator has issues in performance limited environments
Issue:

The root cause of the issue is that Xcode / the iOS Simulator has issues in performance limited environments. This included Virtual Machines (which is how your builds are running on bitrise.io), MacBook Airs, Mac Minis with HDD storage, …

It can happen even if you use Apple’s Xcode Bots CI server on non SSD Mac Mini.

Examples:
UI Tests fail to start

One or more UI Test case hangs
Possible solutions:
As reported in this StackOverflow answer & in this Apple dev forum discussion a possible workaround can be to not to store **XCUIApplication()** in a variable, instead reference / use it directly. E.g. instead of: let app = XCUIApplication() ; ... ; app.launch() do: XCUIApplication().launch()

Others reported that if you add a delay (sleep(10)) after every app.launch() related to your tests, it can leave enough time for Xcode / the iOS Simulator to initialize the Accessibility labels, so that UI Tests can properly find the elements by the Accessibility labels. (Related Apple developer forum discussion)

Related: remove every explicit app.terminate() in your tearDown() method(s)

Try another Simulator device

Use the Async testing APIs

Some users had success with splitting the tests into multiple Schemes, and running those separately, with separate Test Steps.

A great article about splitting tests into multiple Schemes: http://artsy.github.io/blog/2016/04/06/Testing-Schemes

Sometimes it’s related to a code which makes Xcode to misbehave

Try another Xcode version.
Related links and reports:
XCode bot error: Early unexpected exit, operation never finished bootstrapping

UI Testing Failure - Failed to launch within 2.5s, Interrupting test

Assertion Failure: UI Testing Failure - Failed to receive completion for …

Assertion Failure: UI Testing Failure - Failed to receive completion for XCDeviceEvent: page 12 usage 64 duration 0.01s within 10.0s

UI Testing Failure - Failed to perform AX action for monitoring the event loop

UI Testing Failure due to failed AX Action

Every other test case being skipped - UI Testing Failure - App state for <XCUIApplicationProcess: …> is XCApplicationStateRunningActive (3), still not XCApplicationStateNotRunning

System dialog blocks the tests to run

Issue:

Unit tests run and pass. However, a few of the unit tests are FBSnapshotTestCase tests which are kind of UI Tests but are still kept in the unit test bundle. They launch the app and compare screens with reference images of the screen.

When a FBSnapshot TestCase is run, it launches the app and launches a system alert dialog asking the user for permission for push notifications (this is just something that’s done in the AppDelegate in my app at every fresh install).

When the UITests start, the permissions dialog is still visible and overlaying the screen.

The application tries to access some XCUIElements but fails because of the overlaying permissions dialog and eventually fails.

2016-09-08 07:30:34.535 XCTRunner[6174:22447] Running tests...\
07:30:35.399 XCTRunner[6174:22454] _XCT_testBundleReadyWithProtocolVersion:minimumVersion: reply received\
07:30:35.403 XCTRunner[6174:22453] _IDE_startExecutingTestPlanWithProtocolVersion:16\
2016-09-08 07:30:46.670 XCTRunner[6174:22447] Failed to background test runner within 10.0s.\
** TEST FAILED **\
\
}

Possible solutions:

You can resolve this by adding a check in the AppDelegate (where we fire the permissions dialog) if we are running in unit test mode and only asking for permissions when not running unit tests:

(huge thanks to @AronI who reported this issue and the solution)

let unitTestMode = NSProcessInfo.processInfo().environment["XCTestConfigurationFilePath"] != nil
if !unitTestMode {
// IMPORTANT: Only ask permission for push notifications (or any notifications) when not running unit tests.
// The reason for doing this is that it's causing a build failure when the CI runs unit and UI tests.
// The build failure happens like this:
// 1. FBSnapshotTestCase unit tests run and open the application
// 2. The application asks user for the permission to enable push notifications
// 3. FBSnapshotTestCase finish but the permissions dialog is still visible
// 4. UITests start with the permissions dialog overlaying the screen
// 5. UITest doesn't know what the hell is going on and eventually fails because the dialog is blocking everything

// 6. BUILD FAILURE

askForNotificationPermission()
}

Duplicated Schemes
Issue:

If you have multiple Schemes in your Xcode Project or Workspace with the exact same name, Xcode will select one of these Schemes/Configurations randomly when building your project. This can result in random build success / failure, and if you check the raw Xcode output, you’ll see something like this: xcodebuild: error: Scheme YOUR_DUPLICATED_SCHEME is not currently configured for the test action when it fails.

This can also happen if you use CocoaPods and one of your Pods have the same name as your project.
Possible solutions:

To debug this, list the available Schemes with Xcode’s command line tool. In your project’s directory, run:
```
xcodebuild -workspace ./path/to/workspace/file -list
```
If you use a project file instead of a workspace file, run this:
```
xcodebuild -project ./path/to/project/file -list
```
There should be no duplicated Scheme in the printed list. To run this command on bitrise.io, add it to a Script Step. Compare the results after running it both on your computer and on bitrise.io: the lists should be identical.
No mobileprovision path found / No embedded.mobileprovision found in …

Issue:

No embedded.mobileprovision found in ...

Or: No mobileprovision_path found

Possible solutions:

Solution 1: Skip Install Xcode Settings

If you get this error in the Xcode Archive Step, you should check your Xcode Projects settings. Most likely you have the Skip Install option set to YES.

This should only be used for iOS frameworks! For iOS apps this should be set to NO.

You can check out the official documentation. Look up the Xcode successfully archived my application, but the Archives Organizer does not list my archive section.

Solution 2: Installation Directory Xcode Settings

If something modifies the Build Setting -> Deployment -> Installation Directory settings in your Xcode Project, it can result in an .xcarchive where your app is not generated into the canonical Products/Applications folder, but instead into a Products/Users/USERNAME/... folder, including the full absolute path of an intermediate build.

Make sure that the Installation Directory option is set to $(LOCAL_APPS_DIR) (the default value when you generate a new iOS Xcode Project) or /Applications (which is the default value of $(LOCAL_APPS_DIR) in your Xcode Project settings, and that no build tool you use modifies this option.

Huge thanks to Antje, who reported this solution!
No identity found
Issue:

You uploaded the correct Provisioning Profile and Certificate pair, if you check the identity hash it matches with the one you can see in your Keychain, but you still get an error like:
```
22...D11: no identity found
```
Possible solutions:

You probably have a configuration in your Xcode project settings which specifies which keychain should be used for the build, your scheme might include something like --keychain /../../xxx.keychain code signing flag and a CODE_SIGN_KEYCHAIN variable set in the .pbxproj.

This might happen if you migrate your Xcode Bot based setup into Bitrise.

To fix the issue you have to remove the keychain selection configurations from your Xcode project settings.
Invalid IPA

Issue:

Invalid IPA: get-task-allow values in the embedded .mobileprovision don’t match your binary.

Possible solutions:

Generate a new Certificate on the Apple Developer portal, NOT in Xcode.

Another possible solution is to make sure you have the proper Signing Identity and Provisioning Profile in Xcode project settings for both the target and for the project.
No dSYM found

Issue:

A couple of services require debug symbols (dSYM) to be present for deployment but dSYM generation might have been disabled in your Xcode project.

Possible solutions:

To generate dSYM, go to your Xcode Project's Settings -> Build Settings -> Debug Information Format and set it to DWARF with dSYM File.
Installing an Enterprise app: Untrusted Enterprise Developer
Issue:

If you try to install an Enterprise distribution signed app you might get a popup when you try to run the app the first time, with the title Untrusted Enterprise Developer.
Possible solutions:

Starting with iOS 9, there’s no option to “Trust” the developer right from the popup.

You can Trust the developer and enable the app to run in iOS Settings:
Open the Settings app on your iPhone or iPad.

Select the General category.

Select the Profile option.

starting with iOS 9.2 the option was renamed to Device Management instead of Profile.

Tap on the Enterprise App option related to the app (the one mentioned in the popup).

Tap the Trust "The Developer's Name" button.

A popup will appear, tap on Trust again.
You should now be able to run the app, and any other Enterprise app from the same developer.
CocoaPods frameworks signing issue
Issue:

This error is related to how CocoaPods expects code signing configurations for frameworks.
```
=== CLEAN TARGET Pods-Xxxxxxxxx OF PROJECT Pods WITH CONFIGURATION Release ===

Check dependencies
[BEROR]Code Sign error: No code signing identities found: No valid signing identities (i.e. certificate and private key pair) matching the team ID “(null)” were found.
[BEROR]CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'
```
Possible solutions:

A wildcard development provisioning profile

When Xcode performs an initial code signing (when it compiles the framework projects), it requires a certificate and provisioning profile which can be used for signing the CocoaPods framework projects.

On your Mac, you most likely have your own Development certificate and Wildcard team provisioning profile, which is enough for Xcode to do the initial code signing for the framework projects.

So upload these (Development identity/certificate (.p12) and the Team wildcard provisioning profile) to bitrise.io. Xcode will do an initial code signing with the development signing files, and then it’ll resign the archive when it exports the final IPA.
Modifying code signing settings through Podfile

One of our beloved users sent us the following fix for this problem. Add the following script as a Post script to your Podfile:

post_install do |installer| installer.pods_project.targets.each do |target| target.build_configurations.each do |config| config.build_settings['EXPANDED_CODE_SIGN_IDENTITY'] = "" config.build_settings['CODE_SIGNING_REQUIRED'] = "NO" config.build_settings['CODE_SIGNING_ALLOWED'] = "NO" end end end
Additional information:
You can find a related CocoaPods issue and discussion at: https://github.com/CocoaPods/CocoaPods/issues/4331

You can also find possible solutions at CocoaPod’s official GitHub issues page, like this one: https://github.com/CocoaPods/CocoaPods/issues/3063.
A Step hangs - check your app's code

Issue:

It can also be something in your app’s code. For example, one of our users had a simple popup in the app, presented only at the first start of the app. Once the popup was dismissed, the fact was stored in the app’s local storage, and the popup was not shown anymore. They did dismiss the popup on their iOS Simulator, but on Bitrise every build runs in a brand new, clean environment, which means that the simulator is in the same state as if you’d hit “Reset Content and Settings” in the iOS Simulator’s menu.

Possible solutions:

Try to clean out the simulator/emulator before running tests on your Mac/PC, to simulate the “first run” experience.

Occasionally, a build just doesn’t generate any log output. This can happen for various reasons; you can find an example in case of an iOS library project.
A Step hangs - scheme not shared

Issue:

You try to build a scheme which is not marked as shared. Usually, it hangs right after you start any xcodebuild command (for example, xcodebuild -list or xcodebuild .. archive).

Possible solutions:

Make sure that you marked the scheme as shared, and that you actually committed & pushed it into your repository.

Fastlane export issue

This article was contributed by @kwoylie, and applies if you have a Gemfile in your repository and you use the fastlane step which uses the Gemfile automatically if present.

Issue:

Gemfile content was:

gem "fastlane", "1.104.0" 
gem "gym", "1.10.0" 
gem "badge", "0.5.0" 
gem "CFPropertyList","2.3.3" 
gem "sqlite3", "1.3.11"

Fastlane, with xcpretty disabled, produced the following error on Bitrise:

$/usr/bin/xcrun /usr/local/lib/ruby/gems/2.3.0/gems/gym-1.10.0/lib/assets/wrap_xcodebuild/xcbuild-safe.sh -exportArchive -exportOptionsPlist '/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/gym_config20161003-2206-1f0vw3k.plist' -archivePath /Users/vagrant/Library/Developer/Xcode/Archives/2016-10-03/App\ 2016-10-03\ 05.57.17.xcarchive -exportPath '/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/gym_output20161003-2206-wjhjai'
+ xcodebuild -exportArchive -exportOptionsPlist /var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/gym_config20161003-2206-1f0vw3k.plist -archivePath '/Users/vagrant/Library/Developer/Xcode/Archives/2016-10-03/App 2016-10-03 05.57.17.xcarchive' -exportPath /var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/gym_output20161003-2206-wjhjai
2016-10-03 06:01:58.299 xcodebuild[5284:14924] [MT] IDEDistribution: -[IDEDistributionLogging _createLoggingBundleAtPath:]: Created bundle at path '/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/App_2016-10-03_06-01-58.298.xcdistributionlogs'.
2016-10-03 06:01:59.596 xcodebuild[5284:14924] [MT] IDEDistribution: Step failed: <IDEDistributionThinningStep: 0x7f868c80f810>: Error Domain=IDEDistributionErrorDomain Code=14 "No applicable devices found." UserInfo={NSLocalizedDescription=No applicable devices found.}
error: exportArchive: No applicable devices found.

Error Domain=IDEDistributionErrorDomain Code=14 "No applicable devices found." UserInfo={NSLocalizedDescription=No applicable devices found.}

** EXPORT FAILED **
[06:01:59]: Exit status: 70
[06:01:59]: 2016-10-03 13:01:58 +0000 [MT] Running step: IDEDistributionSigningAssetsStep with <IDEDistributionContext: 0x7f868c51ed70; archive(resolved)='<IDEArchive: 0x7f868c4af8d0>', distributionTask(resolved)='2', distributionMethod(resolved)='<IDEDistributionMethodEnterprise: 0x7f868c202a00>', teamID(resolved)='(null)'>
        Chain (2, self inclusive):
        <IDEDistributionContext: 0x7f868c51ed70; archive = '(null)', distributionMethod='<IDEDistributionMethodEnterprise: 0x7f868c202a00>', teamID='(null)'>
        <IDEDistributionContext: 0x7f868c4b0e70; archive = '<IDEArchive: 0x7f868c4af8d0>', distributionMethod='(null)', teamID='(null)'>
</IDEDistributionContext: 0x7f868c51ed70>

This error is misleading: it looks like it might be a code signing error or some configuration issue with fastlane. But if you look further into the error, you may see the following:

2016-10-03 13:01:58 +0000 [MT] Running /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool '/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/IDEDistributionThinningStep.s1x' '--json' '/var/folders/90/5stft2v13fb_m_gv3c8x9nwc0000gn/T/ipatool-json-filepath-RUCdRR' '--info' '--toolchain' '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr' '--platforms' '/Applications/Xcode.app/Contents/Developer/Platforms'
2016-10-03 13:01:58 +0000  ruby 2.0.0p648 (2015-12-16 revision 53162) [universal.x86_64-darwin15]
2016-10-03 13:01:59 +0000  /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/definition.rb:181:in `rescue in specs': Your bundle is locked to json (1.8.3), but that version could not be found in any of the sources listed in your Gemfile. If you haven't changed sources, that means the author of json (1.8.3) has removed it. You'll need to update your bundle to a different version of json (1.8.3) that hasn't been removed in order to install. (Bundler::GemNotFound)
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/definition.rb:175:in `specs'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/definition.rb:235:in `specs_for'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/definition.rb:224:in `requested_specs'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/runtime.rb:118:in `block in definition_method'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/runtime.rb:19:in `setup'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler.rb:99:in `setup'
        from /usr/local/lib/ruby/gems/2.3.0/gems/bundler-1.13.1/lib/bundler/setup.rb:20:in `<top (required)>'
        from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
        from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
2016-10-03 13:01:59 +0000 [MT] /Applications/Xcode.app/Contents/Developer/usr/bin/ipatool exited with 1
2016-10-03 13:01:59 +0000 [MT] ipatool JSON: (null)

What happens is that fastlane reverts back to the Mac OS system's Ruby for exporting. But the system Ruby doesn't have json 1.8.3 installed.

Possible solutions:

Add a Script Step to run the following:

sudo /usr/bin/gem install bundler

This will install bundler on the system Ruby and when the fastlane plugin calls bundle install, then system Ruby will also install the necessary dependencies.

CocoaPods (missing) dependency issue
Issue:

ld: library not found for -lPods-... clang: error: linker command failed with exit code 1 (use -v to see invocation)

OR:

no such module '...'
Possible solutions:

The problem, usually, is that you use Cocoapods but you specified the Xcode project (.xcodeproj) file instead of the Workspace (.xcworkspace) file.

Go to your App’s Workflows tab on Bitrise.

Click Env Vars and change the BITRISE_PROJECT_PATH item. This will change the default Project Path configuration for every workflow.

If it worked before and the BITRISE_PROJECT_PATH did not solve the issue, then check your App’s other Environment Variables. The project file path might be overwritten by a Workflow environment variable, or you might have specified a Project Path for the related Xcode step directly.
Xcode Scheme not found
Issue:

You can’t see your Xcode project’s scheme during setup, or if you get a The project named "Foo" does not contain a scheme named "Bar" error during build.
Possible solutions:
Note

We recommend you check your Xcode project settings.

Check if the desired Scheme is shared - Bitrise only works with shared schemes.

When you share your scheme, the Xcode project changes. Don’t forget to commit and to push your changes!

If the related validation is still running on Bitrise, abort it and try to run it again.

Don’t forget to commit & push the changes if you just enabled the Shared option! This change should be reflected in your git repository, under you project / workspace (which is actually a directory, just seems like a file in Finder): *.xcodeproj OR *.xcworkspace/xcshareddata/xcschemes/SchemeName.xcscheme.

If you still can’t see the desired Scheme, look into your .gitignore file and check if you are ignoring the config files of your Xcode project.
Building test targets fails due to missing provisioning profiles

Issue:

Code signing is set up using the iOS Auto Provision with App Store Connect Step, but building the test target fails because of a missing provisioning profile.

Possible solutions:

The iOS Auto Provision with App Store Connect Step currently can only download provisioning profiles for the main target. If you need to sign your unit or UI test target (for example, testing on a physical device using Firebase Test Lab), then you need to use one of the other two code signing methods of Bitrise:

- iOS Auto Provision with Apple ID Step

- Manual provisioning with the Certificate and profile installer Step

Additional information:

iOS code signing
Installing additional simulators for Xcode UI tests
Issue:

You need a simulator for your Xcode UI tests that is not available on the stack that you are using. For example, you wish to run a simulator for an older iOS version.
Possible solutions:

Add the following code in a Script Step (replace 'iOS 13' with the version you need):
```
gem install xcode-install
xcversion simulators --install='iOS 13'
```
Can't install private SwiftPM dependency
Issue:

Xcode is unable to fetch your private Swift Package Manager dependencies and because of that, the Xcode Test or the Xcode Archive Step fails.
Possible solutions:

By default, Xcode isn't using the system source control manager settings. To make it do so:
Open the relevant Step in the Workflow Editor.

Find and open the Debug input group.

In the Additional options for xcodebuild call input, pass the following flag:

-scmProvider system
Additional information:

Building Swift Packages or Apps that Use Them in Continuous Integration Workflows
Releasing all schemes in a single build

Issue:

You have multiple schemes (targets) to be released, but you are not sure how to release all the targets in a single build.

Possible solutions:

Although currently there is no way to release all the schemes in one build, you can separate these build configurations into different Workflows and use Workflow chaining.

This way you can run your builds for technically all of the schemes with one trigger, start the first one on commit and use that to trigger the other Workflows.
iOS UI tests are failing intermittently
Issue:

The same tests sometimes fail and sometimes succeed, without any changes either in the code or the Workflow configuration.
Possible solutions:

When tests are flaky like this it's usually because of one of two things:
Your tests are reliant on an external network resource that should be mocked.

The simulator hasn't had a chance to warm up or recover from the previous test. In this case adding a delay before the test can help. Pre-starting the simulator can also help reliability greatly: you can add a Script Step before the tests run, such as this example:

npm install -g ios-sim ios-sim start --devicetypeid "com.apple.CoreSimulator.SimDeviceType.iPhone-8, 14.4" sleep 60
Deploy to App Store Connect with Deliver (formerly iTunes Connect) Step fails with "Connected Apple Developer Portal Account not found."

Issue:

The Deploy to App Store Connect with Deliver (formerly iTunes Connect) Step fails with the following error:

Possible solution:

All inputs are given under the Step:

However the TEAM tab has to be configured as well for this to work:

Select the appropriate profile based on the connection entered from the Step (Apple ID / API)
Deploy to iTunesConnect Step Fails with Error Code -22014
Issue:

The Deploy to iTunesConnect Step fails with error code -22014.
Possible solution:

This issue is cause when the Step cannot establish an authenticated session when attempting to deply to iTunesConnect. The error looks something like this:
```
Error Domain=ITunesSoftwareServiceErrorDomain Code=-22014 \"We are unable to create an authentication session.\" UserInfo={NSLocalizedDescription=We are unable to create an authentication session., NSLocalizedFailureReason=Unable to validate your application.}
```
Verify that your Apple ID and password are correct in the Step input. Regenerate the app specific password and specify the new value.
Ship Addon fails after uploading a new iOS provisioning profile

Issue:

After changing your app's provisioning profile, the Ship Addon fails. Typically the logs show a 500 internal server error.

Possible solution:

Ship is currently in beta and we're still working out the bugs. In this case, there's a known issue where Ship will continue to search for the old provisioning profile even after the new one is uploaded.

If you encounter this issue, please contact support. We can resolve it for you in our backend systems.
Error: contents.xcworkspacedata does not exist
Issue:

Running the Recreate User Schemes Step fails with this error:
```
Searching for workspace shared schemes... Failed to list shared schemes, error: contents.xcworkspacedata does not exist at: Project.xcworkspace/contents.xcworkspacedata
```
Possible solution:

If you are using CocoaPods this can occur if you do not commit your .xcworkspace file. To resolve, add the Recreate User Schemes Step after your CocoaPods step. This will cause the .xcworkspace file to be created.
Xcode 12 fails with the "double-quoted include" error
Issue:

The Xcode Archive & Export for iOS Step fails with the following error:
```
/Users/vagrant/git/Pods/Target Support Files/nanopb/XXXX:13:9: double-quoted include "pb.h" in framework header, expected angle-bracketed instead [-Werror,-Wquoted-include-in-framework-header]
```
Possible solutions:

This is a Cocoapods issue that occurs because Xcode 12 expects umbrella headers to use <> for imports instead of "" .

The workaround is simple: in the Xcode build settings for all Pods, set CLANG_WARN_QUOTED_INCLUDE_IN_FRAMEWORK_HEADER option to NO.
Useful links:
https://github.com/CocoaPods/CocoaPods/issues/9902

Can't configure certain App ID capabilities

Can't register a new App Clip App ID

Issue:

Possible solutions:

Issue

Possible solutions

Issue:

Issue:

Possible solutions:

Issue:

Possible solutions:

Related links and reports:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Solution 1: Skip Install Xcode Settings

Solution 2: Installation Directory Xcode Settings

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

A wildcard development provisioning profile

Modifying code signing settings through Podfile

Additional information:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solutions:

Note

Issue:

Possible solutions:

Additional information:

Issue:

Possible solutions:

Issue:

Possible solutions:

Additional information:

Issue:

Possible solutions:

Issue:

Possible solutions:

Issue:

Possible solution:

Issue:

Possible solution:

Issue:

Possible solution:

Issue:

Possible solution:

Issue:

Possible solutions:

Useful links: