Publish iOS apps on the App Store with GitLab and fastlane

How GitLab with fastlane collects, signs and publishes iOS apps in the App Store.

Recently we had a post on how to quickly build and run an Android application with GitLab and fastlane . Here we will see how to build and run an iOS application and publish it in TestFlight. Check out how cool I am making a change on the iPad Pro with the GitLab Web IDE , taking the build and getting an update of the test version of the application on the same iPad Pro where I developed it.

Here we take a simple iOS application on Swift , with which I recorded video.

A couple of words about the configuration of the Apple Store

We need an app in the App Store, distribution certificates, and an initialization profile to link everything together.

The most difficult thing here is to set up the rights to sign in the App Store. I hope you figure it out yourself. If you are a beginner, I will point out the right direction, but here we will not talk about the intricacies of managing Apple certificates, and besides, they are constantly changing. This post will help get down to business.

My applications

You need an application in App Store Connect so that you have an ID for the .xcodebuild configuration. The profile and application ID combine code builds, pricing and availability, and also TestFlight configuration for distributing test applications to users. Do not do public testing, and private is enough if you have a small group, simple setup and no additional permissions from Apple.

Initialization profile

In addition to the application setup, you need the distribution and development keys of iOS, created in the Certificates, Identifiers & Profiles section in the Apple Developer console. All these certificates can be combined into an initialization profile.

Users who will be authenticated need to be able to create certificates, otherwise you will see an error in the cert and sigh stages.

Other options

In addition to this simple method, there are other ways to configure certificates and profiles. So, if you work differently, you may have to rebuild. Most importantly, you will need the .xcodebuild configuration, which will point to the necessary files, and the keychain must be available on the build computer for the user under whose name the runner is running. For digital signatures, we use fastlane, and if there are problems or you want to know more, study their detailed documentation on digital signatures .

In this example, I use the cert and sigh approach , but for real use, the match is probably better suited.

GitLab and fastlane preparation

CI Runner Preparation

After collecting all this data, go to the GitLab runner configuration on a MacOS device. Unfortunately, making iOS apps is real only on MacOS. But things can change, and if you wait for progress in this area, watch for projects like xcbuild and isign , and our internal task is gitlab-ce # 57576 .

Configure a runner is very simple. Follow the current instructions for setting up GitLab Runner on macOS .

Note. A runner should use the shell executable. It is necessary to build iOS on macOS in order to work directly as a user, and not through containers. If you use the shell , the build and testing is done on behalf of the runner user, right on the build host. This is not as safe as containers, so it’s best to scroll through the security documentation so you don’t miss anything.

 sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64 sudo chmod +x /usr/local/bin/gitlab-runner cd ~ gitlab-runner install gitlab-runner start 

An Apple keychain must be configured on this host with access to the keys that Xcode needs to build. The easiest way to test this is to log in as the user who will start the build and try to build manually. If the system requests access to the keychain, select Always Allow for CI to work. It may be worth entering and watching the first pair of pipelines, to make sure they no longer ask for a keychain. The trouble is that Apple does not make it easier for us to work with the automatic mode, but when you adjust it, everything will be fine.

fastlane init

To use fastlane in a project, run fastlane init . Just follow the instructions for installing and running fastlane , especially in the section on Gemfile , because we need a quick and predictable launch through the automatic CI conveyor.

In the project directory, run these commands:

 xcode-select --install sudo gem install fastlane -NV # Alternatively using Homebrew # brew cask install fastlane fastlane init 

fastlane asks for a basic configuration, and then creates a fastlane folder in the project with three files:

1. fastlane/Appfile

There is nothing difficult. Just check that the Apple ID and application ID are correct.

 app_identifier("com.vontrance.flappybird") # The bundle identifier of your app apple_id("your-email@your-domain.com") # Your Apple email address 

2. fastlane/Fastfile

Fastfile defines build steps. We use a lot of fastlane built-in capabilities, so everything is also clear here. We create one line that receives certificates, builds and loads it into TestFlight. You can divide this process into different tasks, if necessary. All of these operations ( get_certificates , get_provisioning_profile , gym and upload_to_testflight ) are already in fastlane.

The actions get_certificates and get_provisioning_profile are associated with the cert and sigh signing approach. If you use match or something else, make a change.

 default_platform(:ios) platform :ios do desc "Build the application" lane :flappybuild do get_certificates get_provisioning_profile gym upload_to_testflight end end 

3. fastlane/Gymfile

This is an optional file, but I created it manually to change the default output directory and place the output in the current folder. This simplifies CI. If interested, read about the gym and its parameters in the documentation .

 https://docs.fastlane.tools/actions/gym/ 

Our .gitlab-ci.yml

So, we have a CI-runner for the project, and we are ready to test the pipeline. Let's see what we have in .gitlab-ci.yml :

 stages: - build variables: LC_ALL: "en_US.UTF-8" LANG: "en_US.UTF-8" GIT_STRATEGY: clone build: stage: build script: - bundle install - bundle exec fastlane flappybuild artifacts: paths: - ./FlappyBird.ipa 

All perfectly! We set the UTF-8 format for fastlane, as required , use the clone strategy with the shell executable so that we have a clean workspace for each build, and simply call flappybuild fastlane, as seen above. As a result, we get the assembly, signature and deployment of the last assembly in TestFlight.

We also get the artifact and save it with the assembly. Note that the .ipa format is a signed ARM executable file that does not run in the simulator. If you want output for the simulator, simply add the target of the assembly that produces it, and then turn it on in the path to the artifact.

Other environment variables

There are a couple of environment variables on which everything works.

FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD and FASTLANE_SESSION

Authentication for the App Store and download in TestFlight need authentication for fastlane. To do this, create a password for the application that will be used in CI. Details here .

If you have two-factor authentication, create a variable FASTLANE_SESSION (instructions there).

FASTLANE_USER and FASTLANE_PASSWORD

In order for cert and sigh to call the initialization profile and certificates upon request, you need to set the variables FASTLANE_USER and FASTLANE_PASSWORD . Details here . This is not necessary if you use another signing method.

Finally

You can see how it all works in my simple example .

I hope this was useful, and I inspired you to work with iOS builds in the GitLab project. Here are some CI tips for fastlane, just in case. You may want to use CI_BUILD_ID (for incremental builds) to automatically increment the version .

Another cool feature of fastlane is the automatic screenshots for the App Store, which are very easy to set up.

Tell us in the comments about your experience and share ideas on how to improve GitLab for developing iOS applications.