I’ve had access to Xcode Cloud for nearly 6 months now and have used it for CI/CD with my game Puck Drop. I was surprised to see the invite in my mailbox, especially since even today I’m seeing larger devs not having access to it yet. Not sure if the selection is completely random or Apple uses some criteria behind the scenes. Anyways let’s have a look at some of what the service offers.
It’s still in beta so there are clearly some rough edges here and there, but it is very easy to setup and your CI/CD solution can be ready in a matter of minutes. Needless to say it’s strongly tied to Xcode, so there’s little use for it if your app is built differently.
The workflow is used to define when and what you want the service to do for you. Unsurprisingly, compared to a service like Bitrise, Xcode Cloud is much more streamlined when it comes to setting up a workflow.
You start off by connecting your code repository and selecting the Xcode project/workspace. Available projects are automatically listed by the service, and you can also set a path to the project manually if needed. You also define your build environment (Xcode and macOS version) along with custom environment variables if needed. You are allowed to pick a specific version for each or can choose the option to always use the latest stable or beta release.
Xcode Cloud allows custom scripts to be executed during specific moments of the build process:
- A post-clone script that runs after Xcode Cloud clones your Git repository.
- A pre-
xcodebuildscript that runs before Xcode Cloud runs
- A post-
xcodebuildscript that Xcode Cloud runs after running
These scripts must be placed within
ci_scripts directory at the root of your project and each script must have a specific name in order to be executed. Visit the official documentation for details.
A start condition determines when the workflow is triggered and can be defined in a number of ways:
- Branch change
- Pull request change
- Tag change
- Scheduled run for a branch
The “change” conditions can also be fine–tuned by filtering on changes made to any specific files, folders or file extensions — neat.
Setting up actions, i.e. what you want Xcode Cloud to do, is as straightforward as it gets. There are four options to pick from:
Simple, just what the Xcode IDE offers. You can have multiple actions added to the workflow and each action comes with its own set of options as you would expect.
The final step can be used to deploy any archives from earlier step to internal or external TestFlight groups. Additionally there is also an option for sending an email to selected recipients or Slack channels.
These are all the steps needed to setup a workflow for a project.
Workflows can be deactivated with a simple toggle, so you don’t have to tamper with the start conditions in case you want to temporarily disable the build.
I’ve used both Bitrise (Standard VMs) and App Center over the years to build and deploy apps, and the build time has been pretty much the same on all these services. The thing about Xcode Cloud is that if you choose to deploy the build to TestFlight (as a post-action) then the time it takes for the build to be processed by App Store Connect afterwards is included in the total build time. Due to this it takes a bit longer to receive the final “build successful” notification.
As mentioned at the beginning, Xcode Cloud is not exactly flawless at the moment. I haven’t noticed any fatal, deal-breaking issues, but rather annoying and counterproductive ones.
Getting Redirected Out of Xcode Cloud
Although workflows can be created and managed directly from Xcode 13, I’ve used the web interface for the most part. When I started using Xcode Cloud I had a hard time getting any changes to save when using Xcode (it simply didn’t work), hence I resorted to the web app. The problem I’ve encountered a number of times in the web app is getting redirected out of the Xcode Cloud page to the main App Store Connect page after random actions, for example saving a workflow or simply navigating between builds. Nothing critical, just fairly annoying.
Number of times I’ve been unable save any changes made to a workflow (similar to what I experienced in Xcode early on). Clicking the “save” button would make it spin for a second and then actually not do anything. When I would try to navigate out of the workflow page after that, I would be asked if I wanted to save my changes. Tapping the save button on the alert would again redirect me to the main App Store Connect page and any changes would remain unsaved. I would have to come back to it later to find it working as expected.
Error Preparing Build for App Store Connect
A couple of times I’ve had a build fail for no apparent reason. The actual archiving process succeeded and the artifacts were generated, however the subsequent process of preparing the build for App Store Connect has failed without any specific message. Starting a new build right after usually worked fine.
UI Errors and Warnings
The web app sometimes shows unnecessary errors and warnings, for example it complains about a potentially missing build scheme not available in the repository (even if it’s clearly there), or an issue related to your GitHub account. The builds can still be triggered and succeed just fine even with these messages popping up.
All in all, I really like how simple Apple has made it to create the workflows to get your CI/CD solution ready while allowing some flexibility via custom scripts if needed. I have no complaints regarding the build performance as well. There are some annoying issues still but surely those can be ironed out before the service becomes publicly available. Overall Xcode Cloud is more than enough for my needs and I’m certainly curious to see what kind of pricing will Apple go with.