Cut iOS build times with Magic Actions

Time spent on uploading the .ipa binary to App Store Connect is notorious for taking anywhere from seconds up to an hour. This is not because the upload takes a long time, but because Apple needs to process the build and run checks for possible issues before making the uploaded build available in App Store Connect. Waiting for Apple to finish the processing so that we can make further actions with the build can really eat into one’s build minutes and delay getting feedback about the build. Keep reading to find out how Codemagic and Magic Actions resolve those issues.

In order to distribute the builds to testers or upload release notes, there are a few actions that have to be performed in App Store Connect after the build has been uploaded, such as

Approve the application for beta review
Upload release notes in multiple languages
Release our application for external testers

The issue is that before the build becomes available in TestFlight to perform these actions, Apple needs to process it, which can take a long time. Regardless of whether you’re performing these actions manually or trusting your CI with these tasks, you cannot upload release notes or make the build available to testers until Apple has finished processing.

Problem 2. Waiting after Apple costs money

Waiting for Apple to process the build can cost you both time and money. You can either wait for that email from App Store Connect saying your build was successfully uploaded to App Store Connect and start clicking away to upload release notes, or you can automate the task in a CI workflow and keep the build machine busy until Apple is done processing. If you’re paying for the used build minutes, this can quickly skyrocket your CI costs.

Spoiler alert: neither manual actions or paying for the processing time is required with Codemagic!

Problem 3: Long feedback cycle

Last but not least, long processing time increases the time it takes for your team to get feedback on whether or not the tests have passed and the compilation and code signing was successful on the CI. It is evident that the faster we can get feedback from CI on build status without resorting to manual actions, the more productive and happier the developers in the team.

Solution: Magic Actions

To address all these problems, the Codemagic team released post-processing of App Store Distribution jobs or Magic actions for short.

Magic actions are quite cool. Once the build is uploaded to App Store Connect, we start post-processing asynchronously outside of the macOS virtual machine. MacOS is required for the iOS build process because it has Xcode, which is necessary to compile the .ipa artifact, you also need to have xOS runtimes for instrumentation tests. Every other part of the pipeline can be executed in any other OS.

This means that you don’t need to wait around and pay for Apple to process your builds in order to get a green build and continue with development. Your build will finish right after the app artifact has been uploaded and you will receive a build status update. All the following steps, like waiting for Apple to process the build, submitting the build to beta review, uploading release notes or distributing the build to beta groups, take place asynchronously.

The timeout on the post-processing step is set to 120 minutes and this does not count towards build minutes or concurrencies, it’s completely free.

Moreover, as your team grows, cutting build times even by 20 minutes on each deploy to testers is a major win since resources will become free sooner and teams need not to spend money on buying new racks of macOS machines or increasing their capacity with a CI provider. Check out some real life examples of how much time you can with Magic Actions below.

Getting started with post-processing a.k.a. “Magic Actions”

If you are building native iOS, Flutter, React Native, Ionic or Unity apps using codemagic.yaml, then post-processing takes place automatically provided that you are using app_store_connect in the publishing section of your configuration file as shown in the following example:

    artifacts:
      - build/ios/ipa/*.ipa
    publishing:
      app_store_connect:
        api_key: $APP_STORE_CONNECT_PRIVATE_KEY      # Contents of the API key
        key_id: $APP_STORE_CONNECT_KEY_IDENTIFIER    # Alphanumeric value that identifies the API key
        issuer_id: $APP_STORE_CONNECT_ISSUER_ID      # Alphanumeric value that identifies who created the API key
        submit_to_testflight: false        # Optional boolean, defaults to false. Whether or not to submit the uploaded build to TestFlight to automatically enroll your build to beta testers.
        # beta_groups:                     # Specify the names of beta tester groups that will get access to the build once it has passed beta review. 
        #   - group name 1
        #   - group name 2

Uploading the .ipa will be done asynchronously as a post-processing action.

Submitting your app for TestFlight beta review using submit_to_testflight will also be handled during post-processing.

For more information about post processing with codemagic.yaml, please see here.

If you are publishing Flutter iOS apps with the Workflow Editor, then post-processing will be handled automatically when uploading the .ipa to App Store Connect or if you have checked the option to submit your app to TestFlight beta review.

Worflow Editor and codemagic.yaml users should also note that if you have also added a release_notes.json file to the root of your repository, as described here, this will also be handled as a post-processing task.

Real life examples of how Magic Actions cut build times

To find out how much Magic Actions reduces build times by, we decided to do a test using several CI/CD providers using the same build scripts we use on Codemagic. This was possible thanks to Codemagic’s open source CLI tools which can be used to build, code sign, and publish iOS apps on any build infrastructure.

Test 1. Codemagic CI/CD

In the first test we ran the workflow for a simple iOS app on a Codemagic standard macOS instance. The overall build time was 3m 25s (205 seconds) when using Magic Actions. A total of 1m 49s was saved which means the build was 153% quicker than if they hadn’t been used.

Test 2. Bitrise

In the second test we used a Bitrise standard macOS machine using the same build script used in the Codemagic test. The overall build time was 7m 15s (435 seconds) which means Codemagic was 212% quicker.

Test 3. GitHub Actions

In the final test, we set up the same application on Github actions using the same build script that was used on Codemagic and Bitrise. The total build time was 9m 27s (567 seconds) which means the Codemagic build was 277% quicker than Github with Magic Actions.