Deploy an iOS App to TestFlight or the App Store Using GitHub Actions

Build a continuous deployment pipeline to App Store Connect

Photo by Nicolas Tissot on Unsplash.

In this tutorial, we are going to configure a GitHub repository to deploy iOS app releases to App Store Connect using GitHub Actions. We will create a GitHub Actions workflow that builds our iOS app project every time we push commits to GitHub and uploads our built app to App Store Connect every time we push a release tag.

We are going to keep things as simple as possible with regard to code signing and provisioning profiles. This should work well for simpler apps and projects with only one primary developer. If you work on a large team or your project includes multiple targets, you may benefit from taking a different approach.

If you’d like to see a live example of a repository configured to use the workflow described in this tutorial, you can take a look at this project.

Workflow Assumptions

The GitHub Actions workflow described in this tutorial assumes that the repository it is running in contains a single Xcode project or workspace and that the first scheme of the project or workspace builds an iOS app.

The workflow also assumes that the iOS app target is configured as described below.

Code Signing and Provisioning Profiles

The situation with signing certificates and provisioning profiles used to be more confusing and toilsome. It has been a long ride, but with Xcode 11, things are pretty easy. Nearly every task that used to require a trip to the Apple Developer portal can now be handled from within Xcode. Signing certificates can be created from within Xcode’s preferences (for both development and distribution). Provisioning profiles are generated automatically when “Automatically manage signing” is enabled for the target.

Having signing automatically managed is great for development, but it makes things more complicated in the context of a platform like GitHub Actions. Because the signing certificate and provisioning profile aren’t stored in the project repository — and because the project is built on a different host every time — automatically managed signing…