Skip to main content

Managing dependencies with CocoaPods

Abstract

With the Run CocoaPods install Step, you can easily install CocoaPods dependencies on Bitrise. You just need a Podfile and the Step. Bitrise also offers dedicated Steps to cache your pods.

CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. An iOS app with CocoaPods dependencies needs to have a Podfile with a number of pods listed in it: these pods are installed during the process of building the app.

You can, of course, easily install CocoaPods dependencies during a Bitrise build. You just need our dedicated Step: Run CocoaPods Install. The Step can run both pod install and pod update commands.

Installing CocoaPods dependencies

To install your dependencies with CocoaPods:

Workflow Editor

bitrise.yml

  1. If you need a specific version of CocoaPods, make sure you define it either in the Gemfile or the Podfile.

    The Step first looks for the cocoapods gem in the Gemfile. If there's no cocoapods gem, the Step uses the CocoaPods version defined in the Podfile. If the version is not defined there either, the preinstalled system version will be used which you can check in the system reports.

  2. Make sure that the Xcode Step building your app uses your .xcworkspace file: the Project path input of the Step should point to the path of .xcworkspace.

  3. Add the Run CocoaPods Install Step to your Workflow.

    It should come after any Step that pulls from the build cache. If you don't have any caching Steps, add the Step right after the Git Clone Step.

  4. In the CocoaPods command input, select the command you wish to run.

    • install: Installs the version specified in the Podfile for each pod.

    • update: Installs the latest version for each pod listed in the Podfile.

    pod-install.png

  5. Optionally, you can specify a path to your Podfile in the Podfile path input.

    This is not mandatory: if you leave the input empty, the Step performs a recursive search in the root directory of your app, and uses the first Podfile it finds.

  1. If you need a specific version of CocoaPods, make sure you define it either in the Gemfile or the Podfile.

    The Step first looks for the cocoapods gem in the Gemfile. If there's no cocoapods gem, the Step uses the CocoaPods version defined in the Podfile. If the version is not defined there either, the preinstalled system version will be used which you can check in the stack reports.

  2. Make sure that the Xcode Step building your app uses your .xcworkspace file: the project_path input of the Step should point to the path of .xcworkspace.

  3. Add the cocoapods-install Step to your Workflow.

    It should come after any Step that pulls from the build cache. If you don't have any caching Steps, add the Step right after the git-clone Step.

    my-workflow:
  steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - restore-cocoapods-cache: {}
    - cocoapods-install:
        is_always_run: true
    - save-cocoapods-cache: {}

  4. In the command input, select the command you wish to run.

    • install: Installs the version specified in the Podfile for each pod.

    • update: Installs the latest version for each pod listed in the Podfile.

    my-workflow:
  steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - restore-cocoapods-cache: {}
    - cocoapods-install:
        is_always_run: true
        inputs:
          - command: update
    - save-cocoapods-cache: {}

  5. Optionally, you can specify a path to your Podfile in the podfile_path input.

    my-workflow:
  steps:
    - activate-ssh-key: {}
    - git-clone: {}
    - restore-cocoapods-cache: {}
    - cocoapods-install:
        is_always_run: true
        inputs:
          - command: update
          - podfile_path: ./path/to/podfile/
    - save-cocoapods-cache: {}

    This is not mandatory: if you leave the input empty, the Step performs a recursive search in the root directory of your app, and uses the first Podfile it finds.

Caching CocoaPods dependencies

There are two ways to cache your pods in a build, depending on whether you use key-based caching or branch-based caching.

Key-based caching

Key-based caching is only available for credit-based accounts!

Key-based caching

Branch-based caching

With key-based caching, you only need the Restore CocoaPods cache and the Save CocoaPods cache Steps to cache your pods. These Steps require no configuration as they automatically set up the cache keys needed for your dependencies.

Setting specific cache paths

You don't have to use the default cache paths that the dedicated key-based caching Steps use. If you need to set a specific cache path, you can do so by configuring the Save Cache and the Restore Cache Steps: Using key-based caching in your builds.

  1. Add the Restore CocoaPods cache Step to your Workflow

    It should come before the Run CocoaPods install Step or any Step that needs dependencies to build your app, such as Xcode Archive & Export for iOS.

    restore-pods.png

  2. Add the Save CocoaPods cache Step to the end of your Workflow.

Branch-based caching relies on the built-in feature of the Run CocoaPods Install Step to collect cache content. To use it, you just need to use the dedicated caching Steps without any extra configuration.

Setting specific cache paths

You don't have to use the default cache paths that the built-in caching options use. If you need to set a specific cache path, you can do so in the Bitrise.io Cache:Pull and the Bitrise.io Cache:Push Steps: Including files and folders in the build cache.

  1. Add the Bitrise.io Cache:Pull Step to your Workflow. The best way is to put immediately after the Step that clones your repository.

  2. Enable content caching in the Run CocoaPods Install Step: set the Disable collecting cache content to false.

    cache-cocoapods-install.png

  3. Add the Bitrise.io Cache:Push Step to the end of your Workflow.

    The Step requires no extra configuration in this case.

In this section:
app

A Step is a block of script execution that encapsulates a build task on Bitrise: the code to perform that task, the inputs and parameters you can define for the task, and the outputs the task generates.

A Workflow is a collection of Steps, Environment Variables, and other configurations. When Bitrise starts a build, it runs one or more Workflows according to the configuration defined in the bitrise.yml file.