Meet Xcode Cloud

♪ ♪ Hi, my name is Holly, and I’m a manager on the Continuous Integration Technologies Team, and I’ll later be joined by my teammate Geoff McGinnis. Today, it’s my pleasure to introduce Xcode Cloud, an easy-to-use continuous integration and delivery service designed for developers just like you, anyone who’s building apps and frameworks for Apple platforms. In this session, we’re gonna start with an introduction to continuous integration and meet Xcode Cloud. Then we’ll setup a project, make a code change, and learn how to use Xcode Cloud to collaborate with your team.

Let’s get started.

Continuous integration or CI is the practice of integrating code changes regularly, so that issues are caught and fixed early. Adopting this practice allows teams to work collaboratively while also creating high-quality products.

A typical CI workflow is a set of automated steps that runs when you or a team member push a code change to your repository. These steps can do things like build, run tests, or any other number of actions needed to ensure that the code change meets your team’s established level of quality. With CI, you can have peace of mind that integrating a change is low-risk and that your next release is stable. Now, to think about what CI might look like for you, let’s take a look at the life cycle of an app.

As a developer, you’re likely working with feedback from multiple sources. You fix bugs and create features in Xcode, you receive code review feedback from your team on pull requests, and you distribute new versions via TestFlight and integrate tester feedback.

Your team’s ability to iterate on code and feedback productively is essential to creating a high-quality app or framework. That’s where Xcode Cloud comes in. Xcode Cloud builds upon the idea of CI while connecting the dots between Apple developer tools to provide you with the complete development pipeline to build, test, distribute, collect feedback, and quickly iterate on your projects. Let’s take a tour of the features to learn about what you can do.

You spend most of your time developing in Xcode, and Xcode Cloud is right there in Xcode. Here, you can see Xcode Cloud in action. There are multiple workflows set up and builds are running and catching issues. You also get a new insight into all of the work your team is doing.

A workflow is a configuration that tells Xcode Cloud which actions to perform and when to perform them. You can breeze through the easy onboarding and get your first workflow up and running quickly. Then you can come back and edit it, or make new workflows to support different use cases.

The result of running a workflow is called a build. Xcode Cloud runs builds in Apple managed Cloud infrastructure that provides code signing and access to multiple operating system versions and Xcode releases. When you click on your app in the Cloud tab of the report navigator, you can view the status of all of your workflows and the latest builds in the sidebar.

Clicking your app also opens the build group overview, which shows all of your builds organized by the way your development team works, not just by workflow but also by git branch, allowing you to use one workflow for many branches but still see the results separately.

You can also filter down the list to see only builds started by your code changes, by clicking the Mine filter above the overview... or by selecting the person icon in the report navigator.

One level down from the build group overview is the build report for a single run of a workflow. This is where you can deep-dive into the results specific to your code change. You can view test reports, logs, and jump directly into the code that caused an issue. Geoff will go into more details of the build report later.

Everything we just saw is not only available in Xcode, but it’s also available in App Store Connect. This includes starting and viewing builds, managing workflows, viewing and downloading artifacts, sharing results with your team, and managing notification settings. And if you’re already working in TestFlight, Xcode Cloud is the tab right next door in App Store Connect for quick access.

In App Store Connect, you can also set up your personal notification settings. I like to set up Slack notifications for failing builds so I can continue working after pushing my code but get alerted quickly if there’s something to fix. Everyone on your team can set up notifications that work best for them.

Whether you’re on the go, or want visibility into builds of a project you don’t have set up in Xcode, or you’re a member of a team who isn’t committing code to a project, Xcode Cloud in App Store Connect provides a fully-featured web-based experience. When we created Xcode Cloud, we designed it for your development process and for collaboration with your team, but it has also been built with privacy at its core. Your source code is the heart of your project. That’s why all aspects of Xcode Cloud are designed to ensure that your data is protected.

Build environments are temporary. Workloads are completely isolated, and environments are torn down and created from scratch between builds. Source code is never stored. Xcode Cloud fetches your code only within the temporary build environment. Build data is encrypted at rest and stored in a dedicated CloudKit database. And you’re in control of your data. You can delete your data at any time, and it will be completely removed from the system.

Now that I’ve introduced Xcode Cloud, I’m gonna hand it over to Geoff to walk through getting set up.

Let’s get started onboarding to Xcode Cloud. It takes only a few simple steps to get started thanks to the powerful integration with Xcode. The process begins by visiting the Xcode Cloud section of the product menu and selecting Create Workflow.

Next, I select which app I’d like to onboard from these options detected for my local project. Today, I’ll pick this new smoothie ordering app my team is developing called “Fruta.” The app supports both iOS and macOS, and we’ll onboard both platforms together at once.

Our app begins with a default first workflow created automatically for me. By inspecting my local project, Xcode Cloud can tailor these initial workflow settings to match my team’s existing configurations.

Workflows are made up of a start condition, an environment, the set of actions to be performed, and post-actions such as deployments and notifications.

And I can see Xcode Cloud selected every push to the main branch as the start condition, the latest released Xcode for my environment, and archive actions for both iOS and macOS. I have the option of changing these settings, but this looks good to me, so I’ll continue on. For a deep dive into workflow editing, check out the “Explore Xcode Cloud Workflows” session later in the conference.

Next, I’ll authorize Xcode Cloud to access my source code. This is a one-time action covering all source repositories required to build my project including the primary repo, any submodules, and private Swift packages. For any publicly accessible repositories, no additional authorization is necessary.

Xcode Cloud discovered the two private repos within my project, so, next, we’ll grant explicit permissions to GitHub where the source is hosted. Clicking Grant Access takes me to App Store Connect with more details about the next steps. It’s important to note that this process will vary depending on the source provider, and I can revoke access at any time for any reason.

Granting source code access to Xcode Cloud is completed on the web, and this assistant guides me through the process.

First, I connect my Apple ID with my source account, which is used to enable a personalized experience in Xcode Cloud. This step leverages the provider’s native authentication flow and Xcode Cloud’s secure encryption, so I know my code and personal information remain protected.

Then I install the Xcode Cloud application to my GitHub organization, enabling access to the repos I select.

Great! With those steps complete, my GitHub account is all set. Let’s finish the onboarding in Xcode locally.

Repositories are ready. I’ll continue.

In the final step, Xcode Cloud will offer to register my application and bundle ID to App Store Connect. Our application is already created, so I’ll just confirm the details here. Everything looks good.

Now that my app is configured for Xcode Cloud, I can wrap up the onboarding process, which will kick off my first build. Looks like my first build is finished. Let’s take a deeper look at the results.

The build group overview shows my active and completed builds at a glance, and clicking the first entry opens up the overview page for our build.

This overview shows me brief details about the build such as durations and environment configurations, with the lower section showing me the status of all actions and post-actions involved.

Also, the top-right has helpful buttons to rebuild the run again, and check out this revision in my local environment.

Leaving the overview and expanding an action node, such as the passing “Archive-iOS” one shows the summary of this specific action.

And within the view, I can find logs and artifacts produced by this run.

The logs page neatly organizes all the tasks within this action, with filters available at the top to focus on areas that need attention.

I also have easy access to binaries, log files, and other artifacts produced by my build in the artifacts page.

This all makes for a very convenient way for my teammates and I to access our CI content right here in Xcode. Now let’s investigate why the Mac archive action failed by visiting the action summary.

Similar to the logs view, I can filter these issues by type for efficient triage.

Looks like our first CI build caught an import issue I previously missed for our Mac app, and since I’m triaging my results in Xcode, I can use this jump button within an issue to navigate directly to the code I need to fix.

I’ll make a quick code change to clean things up.

And I want our CI builds to get off to a good start, so I’ll go ahead and commit and push it to my remote repository.

And right after I push my change, I see Xcode Cloud has started a new build for me.

And I can continue to follow along with all my changes live.

I’m pretty excited with my quick progress. By running our CI builds on Apple’s Cloud Infrastructure, our team will collaborate on our project more efficiently than ever. Now, back to Holly to join in on the fun. Thanks, Geoff, for getting Xcode Cloud set up and running for our project Fruta. As a member of the same team, I can open the Fruta Xcode project on my Mac and see all of the workflows and builds that Geoff and the rest of our team have been working on.

Here in the report navigator on the Cloud tab when I click on my project name, because workflows are shared within teams, I can see the default workflow that Geoff just created.

It looks like Build 2 that Geoff started when he fixed the import error has completed successfully. Now that we have a passing build, let’s edit the workflow to see what it does, and find out what improvements we can make to get additional coverage for Fruta. I can right-click on the workflow name and select Edit Workflow.

Let’s start by giving the workflow a more descriptive name. Let’s call this workflow “Releases” since we’re gonna be building and testing a couple of branches we use for our releases.

Now, let’s edit the start condition. I’ll select the start condition section from the sidebar to bring up the configuration.

Remember, the start condition defines what needs to happen to cause the workflow to run. The default is set to start when a code change is pushed to your main branch.

My team also uses a release branch, so let’s go ahead and add that here too. I just click on the plus button in the custom branches section and type my branch name in the table row.

That looks good for the start condition. Now let’s move on to actions. The default workflow automatically creates archive actions for all platforms that my project runs on. This is a great foundation to build upon, but to add some additional coverage, I’d like to add some tests here.

I click the plus button to the right of the Actions header in the sidebar and select the Test action type.

For the Test action, I can select the platform-- let’s do iOS-- then select the correct scheme, Fruta iOS in our case.

In the sidebar, there’s still a red X next to our new Test action because we haven’t yet filled out everything that’s required. The last setting I need to configure is adding some devices for these tests to run on. Clicking the plus button below the Destination table automatically adds recommended iPhone simulators...

And clicking one more time adds recommended iPads.

I can also change these to pick a specific device simulator. Let’s choose the latest iPhone to make sure my app works great on iPhone 12.

Notice that all of the destinations I’ve added are automatically set to use the latest OS version.

I can review my workflow in the sidebar, and everything looks good to me, so let’s save the changes by clicking the Save button in the bottom right-hand corner.

Now that we’ve made changes to the workflow, I want to make sure it works without having to make a code change to start it. I can do that manually by right-clicking on the workflow in the report navigator and selecting Start Build.

Next, I’m prompted to choose which branch I want to run. Let’s try it with “release/v1” since we’ve just added that branch to the workflow.

And from here, I click Start Build to kick it off. Great, it looks like our new build is running. Now, in the build group overview, there’s a new section for our release/v1 branch, and the new build I just started, Build 3, appears here with a running status. After this completes, I’ll have a good idea of how our release branch is doing. Then I can continue to add to the release workflow or create new ones to support how my team works.

Xcode Cloud made it really simple to adopt a continuous integration practice for our app. With just a few clicks, Geoff got us set up and fixed an issue that the workflow found. Then I was able to easily see everything he had already done, and make our workflow more robust. Your team’s ability to iterate on both code and feedback productively is essential to creating a high-quality app or framework. With Xcode Cloud, you can easily setup CI, and whether this is a totally new practice or makes your process seamless, you can be more productive and feel more confident that your users will have a great experience with your product.

We hope this session helped you get acquainted with Xcode Cloud and Continuous Integration. From our team in Vancouver, Canada, and on behalf of Geoff and myself, thank you and enjoy the rest of WWDC 2021. [upbeat music]