WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Create practical workflows in Xcode Cloud

Create practical workflows in Xcode Cloud

Xcode CloudCI/CDDeveloper ToolsWorkflow
Watch original video

Highlight

Xcode Cloud uses a three-dimensional configuration model of “when to trigger (Start Conditions) + what to execute (Actions) + what environment to run in (Environment)”, allowing individual developers to use a single workflow to achieve automatic build and distribution, allowing medium-sized teams to use three workflows (PR verification/Beta internal testing/Release release) to cover the complete development process, allowing large teams to smoothly migrate legacy tests to the cloud through the “Not Required To Pass” test mode.

Core Content

Individual developers: one workflow to handle everything

One person maintains the iOS + macOS dual-platform application, uses CocoaPods to manage dependencies, and tests it with relatives and friends through TestFlight. Manual building and distribution take up a lot of time.

Xcode Cloud’s solution is to create a CI Workflow:

  • Trigger condition: Code push of any branch (Any Branch)
  • Build Action: iOS and macOS dual platform Archive, select “TestFlight and App Store” deployment preparation
  • Post Action: Automatically upload to TestFlight’s “Friends and Family” test group

CocoaPods dependencies are handled through post-clone custom scripts. Xcode Cloud natively supports Swift Package Manager, other dependency managers only need toci_scripts/post_clone.shJust install it.

（02:28）

Medium-sized team: three workflows for division of labor and collaboration

A cross-time zone team of developers, project managers and QA. Working mode: Developers develop in their own branches, merge them into the beta branch through PR, and merge into the release branch after QA testing for tagging and release.

PR Workflow:

  • Trigger condition: Pull Request whose target branch is beta
  • Action: Run the test on four devices: iPhone 13, iPhone 14 Pro Max, iPad mini, and iPad Pro
  • Purpose: Ensure code quality before merging

Beta Release Workflow:

  • Trigger condition: code push of beta branch
  • Action: Run test first, then Archive (select TestFlight Internal Testing)
  • Post-action: distribute to “QA Team” test group
  • Custom script: Replace the app icon with the Beta version icon in the pre-build phase

Release Workflow：

  • Trigger condition: push whose tag name starts with “release/”
  • Action: Archive (select TestFlight and App Store)
  • Post-action: first distributed to internal “Executive Stakeholders”, and then distributed to external “Early Adopters”
  • Notification: Send a Slack message to the “Releases Feed” channel after the build is completed

（07:30）

Large Teams: Gradual Migration Strategy

Large teams with complex code bases and extensive legacy testing are already using home-built CI/CD systems. Migrating everything directly is too risky.

It is recommended to proceed in three steps:

  1. Build the Release Workflow first: Move the App Store archive build to Xcode Cloud and use the built-in Cloud Code Signing to eliminate the need for certificate and description file management.
  2. Remigration Test: Create a PR workflow and mark all tests as “Not Required To Pass”. Test failures do not block merging, but test reliability data can be collected. After running for a period of time, move the stable and passing tests into the “Reliable Tests” Test Plan, and then create a new Required test action to run only these stable tests. Unstable tests will continue to be fixed and gradually migrated
  3. Finally complete other workflows: Use webhook and Xcode Cloud Public API to integrate with existing project management tools and Dashboard

（19:12）

Detailed Content

Core concepts of Workflow

Xcode Cloud’s workflow is defined by three dimensions:

  • What: Build, Test, Archive, Analyze and other Actions
  • Where (in what environment): Xcode version, macOS version, environment variables
  • When (when triggered): Branch Changes, Pull Request Changes, Tag Changes, Schedule

Custom build script

Xcode Cloud provides hook scripts at different stages of the build, which are placed in the project root directoryci_scripts/In the folder:

Script nameExecution timePurpose
ci_post_clone.shAfter the code cloning is completedInstall dependencies (such as CocoaPods)
ci_pre_xcodebuild.shBefore the Xcode build startsModify the build configuration (such as replacing the icon)
ci_post_xcodebuild.shAfter the Xcode build is completedUpload additional products and send notifications

Beta icon replacement script example

（14:38）

#!/bin/sh
# ci_pre_xcodebuild.sh

if [[ "$CI_XCODEBUILD_ACTION" == "archive" && "$CI_WORKFLOW" == "Beta" ]]; then
    echo "Replacing app icon with beta icon"
    mv BetaAppIcon.appiconset ../App/Assets.xcassets/AppIcon.appiconset
fi

Key points:

  • CI_XCODEBUILD_ACTIONEnvironment variables identify the currently executed action (archive/build/test, etc.) -CI_WORKFLOWEnvironment variable identifies the name of the current workflow
  • Replace icons only in the Archive stage of Beta workflow through conditional judgment
  • The script is placed inci_scripts/ci_pre_xcodebuild.sh, Xcode Cloud will automatically identify and execute

”Not Required To Pass” Test migration mode

（23:21）

The core pain point when migrating tests for large teams: tests run stably in the old CI environment, but may fail in the new environment due to differences in timing, resources, etc. If set directly to Required, normal development will be blocked.

Xcode Cloud allows setting the Requirement of the test Action to “Not Required To Pass”:

  • Test failures will not cause the build to fail
  • PR can still be merged
  • The team can observe the stability of the test in the new environment

After running for a period of time, move the tests that pass stably into the new Test Plan, and then create a Required test action to specifically run these tests. Unstable tests are fixed one by one and gradually migrated to Required.

Webhook integration with Public API

（26:44）

Xcode Cloud supports two external integration methods:

Webhook: After the build is completed, send an HTTP request to the specified URL, including build status, workflow information, submission information, etc. You can create work orders and update Dashboard after receiving them on your own server.

Public API: Query build history, obtain build details, and download build products through the App Store Connect API. Suitable for displaying build data on internal Dashboard or status page.

Workflow reuse skills

（16:16）

Xcode Cloud supports right-click copy workflow. Release workflow and Beta workflow are usually very similar and can be directly copied and modified:

  • Change trigger conditions (Branch Changes → Tag Changes)
  • Change deployment preparation options (Internal Testing → TestFlight and App Store)
  • Change the test team (QA Team → Executive Stakeholders + Early Adopters)
  • Add notification channels (Slack/Email)

Core Takeaways

1. Automatically switch application configurations for different branches

What to do: Automatically switch Bundle ID, application icon, and API endpoint according to the build target (Debug / Beta / Release).

Why it’s worth doing: Avoid manually maintaining multiple targets or schemes and reduce configuration errors. Xcode Cloud’s custom scripts + environment variables make this completely automated.

How ​​to start: Inci_pre_xcodebuild.shmedium basisCI_WORKFLOWandCI_BRANCHenvironment variables, useplutilModify the API endpoint in Info.plist withmvReplace AppIcon.

2. Automatically create a Jira/Linear work order if the build fails

What: When an Xcode Cloud build fails, automatically create a repair ticket in the project management tool and assign it to the relevant developer.

Why it’s worth doing: Build failures are easily overlooked in large teams. Receive build status via webhooks and automatically create tickets to ensure issues are tracked and fixed.

How ​​to start: Configure the Xcode Cloud webhook to point to your own server, parse the build failure information, and call the Jira/Linear API to create a work order. The commit author can be retrieved from the webhook payloadscmCommit.authorField acquisition.

3. Test stability Dashboard

What to do: Use the Xcode Cloud Public API to pull historical build data and generate a test pass rate trend chart.

Why it’s worth doing: Test data in “Not Required To Pass” mode can quantify which tests are unstable and help the team prioritize fixing flaky tests.

How ​​to get started: Using the App Store Connect API/ciBuildRunsThe endpoint obtains the build history, counts the failure rate and failure reasons of each test case, and displays it using Grafana or a self-built page.

4. PR build time optimization

What to do: Based on the file path modified by the PR, only run the relevant subset of tests.

Why it’s worth doing: Test suites for large projects may run for tens of minutes. By analyzing the modified files in git diff and only triggering tests of relevant modules, PR feedback time can be greatly shortened.

How ​​to start: Use it in the pre-build script of PR workflowgit diffAnalyze the modified file and combine it with the test mapping table (such asModels/Directory modification only runs Model tests), dynamically generate Test Plan and pass it inxcodebuild。

Comments

GitHub Issues · utterances