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

Build, deliver, and automate with Xcode Cloud

Xcode CloudCI/CDTestFlightWebhooksSPM
观看原视频

Highlight

Xcode Cloud 新增原生多仓库支持与引导助手，让 iOS 团队无需自建 CI/CD 基础设施即可完成构建、测试和 TestFlight 分发。

核心内容

以前的问题

iOS 团队做持续集成，常见路径是：买 Mac mini 组农场，配证书，写 GitHub Actions 或 Jenkins 脚本。Xcode Cloud 出来后简化了流程，但多仓库项目仍然头疼。

具体痛点有两个。一是私有依赖。项目把 UI 组件库或网络层拆成独立 Git 仓库，通过 Swift Package Manager（SPM）引入。Xcode Cloud 以前只能拉主仓库，私有 SPM 依赖经常拉取失败。开发者被迫在 ci_post_clone.sh 里注入 SSH key、手动 clone，脚本丑陋且权限问题导致构建随机失败。

二是分发配置繁琐。TestFlight 分发需要跳转到 App Store Connect 网页端操作，和 Xcode 里的开发流程割裂。

Apple 做了什么

今年 Apple 没有发布全新的 CI 工具，而是在 Xcode Cloud 里做了三个针对性改进。

引导助手（Onboarding Assistant）。Xcode 的 Report Navigator 里新增可视化向导，点几下就能把 iOS 和 macOS App 接入云端构建。不再需要手动去 App Store Connect 创建项目和配置工作流。

额外仓库（Additional repositories）原生支持。Xcode Cloud 的 Workflow 设置里可以直接挂载多个 Git 仓库。私有组件库、内部工具库都能在 UI 里配置访问权限，构建时自动拉取。ci_post_clone.sh 回归处理简单环境变量的本职。

Webhook 事件推送。Xcode Cloud 支持向外部 URL 发送构建状态事件。Payload 是标准 JSON，包含构建号、工作流名称、状态和 TestFlight 链接。企业团队可以接入内部系统，无需学习 Apple 特有的 CI 语法。

这些改进解决了什么

中小团队（50 人以下）不再需要维护 Jenkins 或 GitHub Actions。多仓库项目的私有依赖配置从脚本 hack 变成 UI 勾选。构建状态可以自动推送到 Slack、飞书或内部发布系统。

Apple 用”免运维”体验把开发者留在生态内。对独立开发者来说，这意味着零基础设施成本就能拥有完整的 CI/CD 流水线。

详细内容

额外仓库配置与瘦身后的 post-clone 脚本

（03:15）

在 Xcode Cloud 的 Workflow 设置中，“Additional repositories” 区域可以添加多个 Git 仓库。每个仓库独立配置访问权限，支持分支匹配策略。

配置完成后，ci_post_clone.sh 不再需要处理复杂的 SSH 密钥和 git clone 逻辑：

#!/bin/sh

# 设置 SPM 缓存目录，加速后续构建
export SPM_CACHE_DIR="$CI_WORKSPACE/.spm_cache"
mkdir -p "$SPM_CACHE_DIR"

# Release 构建注入编译宏
if [[ "$CI_WORKFLOW" == "Release" ]]; then
    export SWIFT_ACTIVE_COMPILATION_CONDITIONS="RELEASE_BUILD"
fi

关键点：

  • CI_WORKSPACE 是 Xcode Cloud 注入的环境变量，指向构建工作目录
  • CI_WORKFLOW 标识当前执行的工作流名称，用于条件判断
  • 脚本必须具有执行权限（chmod +x ci_post_clone.sh），否则构建静默失败
  • 额外仓库在 UI 中配置后，Xcode Cloud 自动处理拉取，无需脚本介入

分支匹配策略需要注意。Xcode Cloud 默认尝试拉取与主仓库同名的分支。如果主仓库在 feature/login 分支，而组件库只有 main 分支，构建会失败。必须在 Workflow 设置中为额外仓库显式指定 Fallback 分支。

Webhook 事件接收与处理

（12:40）

Xcode Cloud 的 Webhook 在构建生命周期各阶段触发：Started、Building、Testing、Finished。Payload 结构如下：

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 // 忽略中间状态，避免消息轰炸
    }

    let emoji = payload.status == "SUCCEEDED" ? "✅" : "❌"
    let message = """
    \(emoji) Xcode Cloud 构建通知
    工作流: \(payload.workflowName)
    版本号: \(payload.buildNumber)
    状态: \(payload.status)
    TestFlight: \(payload.testflightUrl ?? "暂无")
    """

    try await sendMessageToChatApp(message)
}

关键点：

  • 必须过滤中间状态，只处理最终成功或失败事件
  • testflightUrl 仅在构建成功且配置了分发时存在
  • 接收端需要做好幂等性处理，同一构建可能触发多次 Webhook
  • 任何能接收 HTTP POST 和标准 JSON 的后端都能集成，无需专用 SDK

TestFlight 分发直连

（08:20）

Xcode 27 支持直接在 IDE 内配置分发 Workflow 并创建 App Store Connect 记录。流程是：选择目标 App -> 配置构建工作流 -> 添加分发步骤 -> 选择内部测试组或外部测试员。整个过程不需要打开浏览器访问 App Store Connect 网站。

macOS App 的无缝接入

（05:50）

同一个 Xcode Workspace 中的 iOS 和 macOS target 可以分别建立独立的 Workflow。跨平台团队不再需要为不同平台维护独立的 CI 配置。

核心启发

1. 做一个构建状态通知机器人

做什么：用 Vapor 或 Hummingbird 搭一个轻量服务端，接收 Xcode Cloud Webhook，把构建结果推送到团队聊天工具。

为什么值得做：Xcode Cloud 的 Webhook 在构建完成时推送标准 JSON，包含构建号、状态、TestFlight 链接。团队能实时知道构建成败，不需要盯着 Xcode 或 App Store Connect。

怎么开始：在 Xcode Cloud Workflow 设置页配置 Webhook URL，指向你的服务端。服务端解析 status 字段，配合 CI_WORKFLOW 环境变量把不同分支的通知发到不同频道。注意过滤中间状态，只处理 SUCCEEDED 和 FAILED。

2. 把内部组件库迁移到 Xcode Cloud 原生依赖

做什么：清点 ci_post_clone.sh 里手动 clone 的私有仓库，逐个迁移到 Xcode Cloud 的 Additional repositories。

为什么值得做：以前私有 SPM 依赖需要脚本注入 SSH key，权限问题导致构建随机失败。原生支持后，仓库访问在 UI 里配置，post-clone 脚本回归处理环境变量的本职，构建稳定性大幅提升。

怎么开始：打开 Xcode -> Report Navigator -> 选中 Workflow -> Edit -> Additional repositories，逐个添加依赖仓库并配置访问权限。注意为每个仓库设置 Fallback 分支，避免主仓库在 feature 分支时组件库拉取失败。

3. 为独立开发者配置全自动发布流水线

做什么：从代码推送到 TestFlight 分发全程无人干预，一个人也能拥有完整的 CI/CD。

为什么值得做：Xcode Cloud 的 Onboarding Assistant 让零运维经验的开发者也能在几分钟内配好构建工作流。配合 TestFlight 直连分发，独立开发者不需要买 Mac mini 农场或写 GitHub Actions 脚本。

怎么开始：用 Onboarding Assistant 创建 Workflow，配置代码推送触发 -> 跑单元测试 -> Archive -> 自动上传到 TestFlight 内部测试组。再加一个 Webhook 把构建结果推送到个人通知渠道。

4. 利用 ephemeral VM 做安全合规审计

做什么：把 Apple 构建虚拟机的安全特性写进团队的安全审计文档。

为什么值得做：金融、医疗类 App 的源码和证书极其敏感。Apple 承诺 Xcode Cloud 的构建虚拟机用完即销毁，源码不落盘，这比自建 Jenkins 或第三方 CI 更容易通过安全审计。

怎么开始：在 Xcode Cloud 文档的 Security 章节找到相关承诺条款，摘录进团队的合规文档。对比自建 CI 的运维成本和安全风险，量化使用 Xcode Cloud 的合规收益。

5. 为跨平台 App 配置统一构建矩阵

做什么：在同一个 Xcode Workspace 中为 iOS 和 macOS target 分别建立独立的 Workflow，共用一套构建配置。

为什么值得做：跨平台团队以前需要为不同平台维护独立的 CI 配置，变更时容易遗漏。Xcode Cloud 支持同一 Workspace 中的多 target 分别建 Workflow，配置集中管理，维护成本减半。

怎么开始：在 Xcode Cloud 中为 iOS target 创建一个 Workflow，再为 macOS target 创建另一个。两个 Workflow 可以共用相同的 post-clone 脚本和测试配置，只在 Archive 和分发步骤区分平台。入口：Xcode -> Report Navigator -> 选中项目 -> Create New Workflow。

关联 Session

  • 262 Swift — Swift 语言新特性，配合 Xcode Cloud 构建 Swift 项目
  • 258 Xcode 27 — Xcode 27 新功能，包含 Xcode Cloud 集成改进
  • 259 Xcode agents — Xcode 智能体辅助开发，与 Xcode Cloud 自动化互补
  • 267 Swift Testing — 测试框架更新，Xcode Cloud 构建流程中的测试执行
  • 278 UIKit modernization — UIKit 现代化，Xcode Cloud 构建的 App 可应用的新 UI 能力

评论

GitHub Issues · utterances