Release private Pods using GitHub Actions

Another example of: "let's make a blogpost out of this cobbled together note, so I don't have to figure it out in a year again".

Using CocoaPods' private Pods allows you to modularize your Application while hosting the code in different private repositories1. Releasing a new version of your private Pod can be time-consuming and is therefore a perfect opportunity for automation, in this case using GitHub Actions.
This workflow assumes that you already created your private spec repo and successfully pushed an initial version of your Pod.

I substitued all variables with <>. Example of the file with actual values: Gist to release.yml

When to trigger the workflow

You first need to decide on when to trigger your automation workflow. In this example I decided to use the workflow dispatch trigger. This gives the engineer the freedom on when to trigger a new release while, providing additional information like the semantic version to be used or a name for the release2. We start our release.yml with the following:

name: Release

        description: 'Version  (i.e. 1.1.3)'
        required: true
        description: 'Name of the Version'
        required: true

Setup the job

We now need to decide and what machine to run our automation and install the required tools:


    runs-on: macos-latest

    - uses: actions/checkout@v2
        fetch-depth: 1
    - name: Bundle Install
      run: bundle install

We run the job on hosted Macs provided by GitHub actions macos-latest, as we require Xcode to release a new version of our module. We assume a Gemfile exists in the root of the repository that defines the dependency on gem cocoapods. (To automatically bump the .podspec-version, we also require gem "fastlane"). We install the tools using Bundle install.

Add the private spec repo to CocoaPods

We need to make the CocoaPods installation of the Action Runner aware that our private spec repo exists and give it the rights to modify this repo:

    - name: Add Pod Spec
      run: pod repo add <NAME_OF_REPO> https://<GIT_ACTOR>:<GIT_TOKEN><ORG>/<REPO_NAME>.git

We are passing the username and personal access token of a user with write permissions to the spec repo along the pod repo add command. I suggest defining the username and the access token as encrypted secrets.

Optional: Bump the Podspec version

We can use the version parameter passed along the workflow_dispatch trigger and a fastlane action to automatically update the podspec version of the dependency. We commit these changes and automatically open a PR with it.

    - name: Bump Podspec version
      run: fastlane run version_bump_podspec path:"<NAME_OF_POD>.podspec" version_number:<VERSION>
    - name: Create Pull Request
      uses: peter-evans/create-pull-request@v3
        title: Release/<VERSION>
        base: main
        branch: Release/<VERSION>
        body: |
          Release: <VERSION>
          - Bump version to <VERSION>

Create a release tag and push the new version

As a last step, we create a release on GitHub3 and push the new version of our pod to the spec repo:

    - name: Create Release
      uses: actions/create-release@v1
        commitish: Release/<VERSION>
        tag_name: "<VERSION>"
        release_name: "<VERSION>"
        body: "<VERSION>"
        commit-message: "Bump pod version"
    - name: Push Pod Spec
      run: pod repo push <NAME_OF_REPO> <NAME_OF_POD>.podspec

Run the action

You can now run the action using GitHub's UI, as outlined again here.


  1. The necessity of hosting your code in different repositories and the upsides/downside this brings is a whole different topic. Not even talking about the choice of dependency manager here. 

  2. The name could be used to automatically create a new release on a CHANGELOG file or give the created GitHub Release more context. 

  3. This automatically creates a git tag. We use the version number and name provided by the trigger to populate the title/body of the release.