WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Build, deliver, and automate with Xcode Cloud

Build, deliver, and automate with Xcode Cloud

Xcode CloudCI/CDTestFlightWebhooksSPM
Watch original video

Highlight

Xcode Cloud adds native multi-repository support and an onboarding assistant, letting iOS teams build, test, and distribute through TestFlight without maintaining their own CI/CD infrastructure.

Core Ideas

The old problem

For iOS teams, continuous integration often used to mean buying a rack of Mac minis, configuring certificates, and writing GitHub Actions or Jenkins scripts. Xcode Cloud simplified that workflow, but multi-repository projects were still painful.

There were two specific pain points. The first was private dependencies. Teams often split UI component libraries or networking layers into separate Git repositories and bring them in through Swift Package Manager (SPM). Previously, Xcode Cloud could only pull the main repository, so private SPM dependencies often failed to fetch. Developers had to inject SSH keys and manually clone repositories in ci_post_clone.sh, producing brittle scripts and permission issues that caused random build failures.

The second was distribution setup. TestFlight distribution required switching to the App Store Connect website, breaking the flow from the development work already happening in Xcode.

What Apple changed

This year Apple did not introduce a brand-new CI system. Instead, it made three targeted improvements inside Xcode Cloud.

Onboarding Assistant. Xcode’s Report Navigator now includes a visual guide that connects iOS and macOS apps to cloud builds in a few clicks. You no longer need to manually create projects and configure workflows in App Store Connect.

Native support for additional repositories. Xcode Cloud workflow settings can now attach multiple Git repositories directly. Private component libraries and internal tool repositories can be configured in the UI with their access permissions, then fetched automatically during builds. ci_post_clone.sh can go back to its real job: handling simple environment variables.

Webhook event delivery. Xcode Cloud can send build-status events to external URLs. The payload is standard JSON and includes the build number, workflow name, status, and TestFlight link. Enterprise teams can connect it to internal systems without learning Apple-specific CI syntax.

What these improvements solve

Small and midsize teams with fewer than about 50 people no longer need to maintain Jenkins or GitHub Actions for many common app workflows. Private dependency setup in multi-repository projects moves from script hacks to UI configuration. Build status can be pushed automatically to Slack, Lark, or internal release systems.

Apple is using a “no operations” experience to keep developers inside its ecosystem. For independent developers, that means a complete CI/CD pipeline with zero infrastructure cost.

Details

Additional repositories and a thinner post-clone script

(03:15)

In Xcode Cloud workflow settings, the “Additional repositories” section can add multiple Git repositories. Each repository gets its own access permissions and supports branch-matching policies.

Once that is configured, ci_post_clone.sh no longer needs to handle complex SSH keys or git clone logic:

#!/bin/sh

# Set the SPM cache directory to speed up later builds
export SPM_CACHE_DIR="$CI_WORKSPACE/.spm_cache"
mkdir -p "$SPM_CACHE_DIR"

# Inject a compilation flag for Release builds
if [[ "$CI_WORKFLOW" == "Release" ]]; then
    export SWIFT_ACTIVE_COMPILATION_CONDITIONS="RELEASE_BUILD"
fi

Key points:

  • CI_WORKSPACE is an environment variable injected by Xcode Cloud that points to the build working directory
  • CI_WORKFLOW identifies the current workflow name and is useful for conditional logic
  • The script must have execute permission (chmod +x ci_post_clone.sh), otherwise the build can fail silently
  • After additional repositories are configured in the UI, Xcode Cloud fetches them automatically without script involvement

Branch matching needs attention. By default, Xcode Cloud tries to fetch a branch with the same name as the main repository. If the main repository is on feature/login but the component library only has main, the build fails. You need to explicitly set a fallback branch for each additional repository in the workflow settings.

Receiving and handling webhook events

(12:40)

Xcode Cloud webhooks trigger at different stages of the build lifecycle: Started, Building, Testing, and Finished. The payload looks like this:

struct XcodeCloudPayload: Decodable {
    let buildNumber: String
    let workflowName: String
    let status: String // "SUCCEEDED", "FAILED", "STARTED"
    let testflightUrl: String?
}

func handleWebhook(_ payload: XcodeCloudPayload) async throws {
    guard payload.status == "SUCCEEDED" || payload.status == "FAILED" else {
        return // Ignore intermediate states to avoid notification spam
    }

    let emoji = payload.status == "SUCCEEDED" ? "✅" : "❌"
    let message = """
    \(emoji) Xcode Cloud build notification
    Workflow: \(payload.workflowName)
    Build number: \(payload.buildNumber)
    Status: \(payload.status)
    TestFlight: \(payload.testflightUrl ?? "Not available")
    """

    try await sendMessageToChatApp(message)
}

Key points:

  • Filter intermediate states and handle only final success or failure events
  • testflightUrl exists only when the build succeeds and distribution is configured
  • Receivers should be idempotent because the same build may trigger multiple webhook deliveries
  • Any backend that accepts HTTP POST and standard JSON can integrate without a dedicated SDK

Direct TestFlight distribution

(08:20)

Xcode 27 can configure distribution workflows and create App Store Connect records directly inside the IDE. The flow is: choose the target app, configure the build workflow, add a distribution step, then choose internal testing groups or external testers. The whole process no longer requires opening App Store Connect in a browser.

Seamless onboarding for macOS apps

(05:50)

iOS and macOS targets in the same Xcode workspace can each have their own workflow. Cross-platform teams no longer need to maintain separate CI configurations for each platform.

Key Takeaways

1. Build a bot for build-status notifications

What to do: Build a lightweight server with Vapor or Hummingbird that receives Xcode Cloud webhooks and pushes build results to your team’s chat tool.

Why it is worth doing: Xcode Cloud webhooks send standard JSON when builds finish, including the build number, status, and TestFlight link. The team can know immediately whether a build passed or failed without watching Xcode or App Store Connect.

How to start: Configure a webhook URL in the Xcode Cloud workflow settings and point it to your server. Parse the status field and combine it with the CI_WORKFLOW environment variable to send different branch notifications to different channels. Filter intermediate states and handle only SUCCEEDED and FAILED.

2. Move internal component libraries to native Xcode Cloud dependencies

What to do: Audit private repositories that are manually cloned in ci_post_clone.sh, then migrate them one by one to Xcode Cloud’s Additional repositories.

Why it is worth doing: Private SPM dependencies previously required scripts that injected SSH keys, and permission issues caused random build failures. With native support, repository access is configured in the UI, the post-clone script returns to environment setup, and build stability improves significantly.

How to start: Open Xcode -> Report Navigator -> select the workflow -> Edit -> Additional repositories, then add dependency repositories and configure access permissions one by one. Set a fallback branch for each repository so component libraries still fetch correctly when the main repository is on a feature branch.

3. Configure a fully automated release pipeline for independent developers

What to do: Automate everything from code push to TestFlight distribution, so a solo developer can still have a complete CI/CD pipeline.

Why it is worth doing: Xcode Cloud’s Onboarding Assistant lets developers with no operations experience configure build workflows in minutes. With direct TestFlight distribution, independent developers do not need a Mac mini farm or GitHub Actions scripts.

How to start: Use Onboarding Assistant to create a workflow: trigger on code push, run unit tests, archive, and automatically upload to the internal TestFlight group. Add a webhook to push build results to your personal notification channel.

4. Use ephemeral VMs for security and compliance audits

What to do: Document the security properties of Apple’s build virtual machines in your team’s security-audit materials.

Why it is worth doing: Source code and certificates for finance and healthcare apps are extremely sensitive. Apple states that Xcode Cloud build virtual machines are destroyed after use and do not persist source code, which can make security review easier than self-hosted Jenkins or a third-party CI service.

How to start: Find the relevant commitments in the Security section of the Xcode Cloud documentation and quote them in your team’s compliance docs. Compare the operational cost and security risks of self-hosted CI against the compliance benefits of Xcode Cloud.

5. Configure a unified build matrix for cross-platform apps

What to do: Create separate workflows for iOS and macOS targets in the same Xcode workspace while sharing one build setup.

Why it is worth doing: Cross-platform teams previously had to maintain independent CI configurations for each platform, which made changes easy to miss. Xcode Cloud supports separate workflows for multiple targets in one workspace, keeping configuration centralized and cutting maintenance work.

How to start: Create one workflow for the iOS target in Xcode Cloud, then another for the macOS target. Both workflows can share the same post-clone script and test configuration, with only archive and distribution steps differing by platform. Entry point: Xcode -> Report Navigator -> select the project -> Create New Workflow.

  • 262 Swift — New Swift language features that pair well with building Swift projects in Xcode Cloud
  • 258 Xcode 27 — New Xcode 27 features, including improvements to Xcode Cloud integration
  • 259 Xcode agents — Agent-assisted development in Xcode, complementing Xcode Cloud automation
  • 267 Swift Testing — Testing framework updates for test execution in Xcode Cloud build workflows
  • 278 UIKit modernization — UIKit modernization features that apps built with Xcode Cloud can adopt

Comments

GitHub Issues · utterances