Meet Xcode Cloud

Highlight

Apple 发布 Xcode Cloud，把持续集成和持续交付服务接入 Xcode 与 App Store Connect，让团队在 Apple 托管环境中自动构建、测试、归档、分发应用，并从构建报告直接定位问题。

核心内容

一个团队开发 App，麻烦通常出现在代码合并之后。

你在 Xcode 里修 bug、加功能。队友在 pull request 里给反馈。测试者在 TestFlight 里试新版。每一次反馈都会带来一次代码改动。改动合进去之后，还要确认 iOS 能不能编译，macOS 能不能归档，测试有没有失败，构建能不能发给测试者。

以前，这些事情经常靠本地机器和人工检查串起来。谁有空，谁跑一次测试。谁负责发包，谁处理证书、构建产物和上传流程。问题是，团队越大，分支越多，遗漏越容易发生。

Xcode Cloud 解决的是这条链路。它把持续集成（Continuous Integration，简称 CI）放进 Apple 的开发工具。开发者推送代码后，工作流会在 Apple 托管的云环境中运行。它可以构建、测试、归档，也可以把结果交给后续分发流程。

这场演讲用 Fruta 这个跨 iOS 和 macOS 的示例应用演示整个流程。开发者先在 Xcode 里创建工作流，授权 Xcode Cloud 访问代码仓库，启动第一次构建。构建失败后，报告指出 Mac 归档动作遇到导入错误。开发者点一下问题，就能跳到源码修复，再提交并推送。

团队协作的变化也很直接。工作流属于团队共享配置。一个成员创建并运行构建后，另一个成员打开同一个项目，也能在 Xcode 的 Cloud tab 里看到工作流、构建历史和结果。接着，她可以编辑工作流，把 release 分支加入触发条件，再给 iOS 增加测试动作。

这就是 Xcode Cloud 的定位：它不只跑一台远程构建机。它把 Xcode、App Store Connect、TestFlight、代码托管服务和团队通知连成一条发布前流水线。

详细内容

CI 的最小模型：推送代码后自动跑一组动作

（00:45）演讲先定义持续集成。CI 是定期集成代码改动的实践，目的是尽早发现并修复问题。一个典型 CI 工作流，会在你或队友向仓库推送代码时运行自动步骤。

这些步骤可以是构建、测试，或者团队要求的其他质量检查。Xcode Cloud 把这些步骤包装成 workflow（工作流）。

Workflow
- Start condition: 当代码推送到仓库时启动
- Actions: build, test, archive
- Result: build report

关键点：

Workflow 是配置，决定 Xcode Cloud 在什么时机做什么事。
Start condition 是触发条件，演讲中的默认值是推送到 main 分支。
Actions 是要执行的动作，演讲提到 build、test、archive。
build report 是一次工作流运行后的结果入口，用来查看测试报告、日志和问题。

工作流跑在 Apple 托管环境里

（02:34）Xcode Cloud 的一次工作流运行叫 build（构建）。这些构建运行在 Apple managed Cloud infrastructure（Apple 托管云基础设施）里。

演讲明确提到三件事：云环境提供代码签名，提供多个操作系统版本，提供不同的 Xcode 版本。开发者不用为每台构建机单独准备这些能力。

Xcode Cloud Build Environment
- Code signing
- Multiple operating system versions
- Xcode releases

关键点：

Code signing 由云端构建环境支持，减少本地构建机上的证书管理负担。
Multiple operating system versions 让团队能在不同系统版本上验证 App。
Xcode releases 让构建环境和 Xcode 版本相关配置进入工作流。
构建结果在 Xcode 的 Report navigator 的 Cloud tab 中查看。

第一次创建工作流：从 Xcode 菜单开始

（06:04）演示从 Xcode 的 Product menu 进入 Xcode Cloud 区域，选择 Create Workflow。Xcode 会检测本地项目中的应用，并生成默认的第一个工作流。

Fruta 支持 iOS 和 macOS。Xcode Cloud 检查本地项目后，自动把两个平台一起纳入默认配置。

Product > Xcode Cloud > Create Workflow

Detected app: Fruta
Platforms: iOS, macOS
Default workflow:
- Start condition: every push to main
- Environment: latest released Xcode
- Actions: archive iOS, archive macOS

关键点：

Create Workflow 是演讲中的入口。
Detected app 来自 Xcode 对本地项目的检查。
every push to main 是默认触发条件。
latest released Xcode 是默认环境选择。
archive iOS 和 archive macOS 来自 Fruta 的平台支持情况。

授权代码仓库：私有仓库需要显式权限

（07:24）Xcode Cloud 要构建项目，必须读取源码。演讲中的授权是一次性操作，覆盖构建项目所需的所有源码仓库，包括主仓库、submodules（子模块）和 private Swift packages（私有 Swift 包）。

公开仓库不需要额外授权。私有仓库需要按代码托管服务完成授权。演示中，Fruta 有两个私有仓库，源码托管在 GitHub，因此需要在 App Store Connect 的网页流程里授权 GitHub。

Source access
- Primary repository
- Submodules
- Private Swift packages

Public repositories: no additional authorization
Private repositories: grant provider access

关键点：

Primary repository 是项目主仓库。
Submodules 和 Private Swift packages 也会被纳入授权范围。
grant provider access 发生在代码托管服务的原生认证流程中。
演讲提到开发者可以随时撤销访问权限。

构建报告：从失败动作跳到出错代码

（09:18）第一次构建结束后，Build group overview 会显示活跃构建和已完成构建。进入单次构建页面后，可以看到构建时长、环境配置，以及所有 actions 和 post-actions 的状态。

如果某个 action 失败，可以展开 action summary。演讲中的 Mac archive action 失败，Xcode Cloud 抓到了一个导入问题。开发者在 Xcode 的问题列表里点击 jump button，直接跳到需要修改的源码。

Build report
- Overview: duration, environment configuration
- Action summary: status, logs, artifacts
- Issues: filter by type, jump to source

关键点：

Overview 展示一次构建的基本信息。
Action summary 展示某个动作的执行情况。
logs 按任务组织，并提供筛选。
artifacts 包含二进制文件、日志文件和其他构建产物。
jump to source 让开发者从 CI 问题回到本地源码。

一个真实修复：UIKit 只在非 macOS 平台导入

（11:04）Fruta 同时构建 iOS 和 macOS。第一次 CI 构建发现 Mac app 的归档动作失败，原因是源码里有不适合 macOS 的导入。演讲给出的修复是条件编译：在非 macOS 平台才导入 UIKit。

import SwiftUI
#if !os(macOS)
import UIKit
#endif

关键点：

import SwiftUI 导入 SwiftUI，供跨平台界面代码使用。
#if !os(macOS) 开始一个编译条件，含义是当前目标系统为 iOS 等非 macOS 平台时才编译下面的代码。
import UIKit 只在 iOS 等非 macOS 平台导入，避免 Mac 归档动作遇到不匹配的框架导入。
#endif 结束条件编译块。

这段代码展示了 CI 的价值。问题并没有等到发布前才出现。一次云端归档动作让跨平台差异立刻暴露出来，开发者修复后提交并推送，新 build 自动开始运行。

团队共享工作流：一个人创建，其他人继续编辑

（11:43）Geoff 创建并修复工作流后，Holly 作为同一团队成员打开 Fruta 项目，也能看到默认工作流和构建历史。演讲强调 workflow 在团队内共享。

她接着把默认工作流改名为 Releases，并编辑 start condition，把 release 分支加入构建范围。

Workflow: Releases
Start condition:
- main
- release/v1

关键点：

Releases 是演示中给工作流设置的新名称。
main 是默认分支触发条件。
release/v1 是团队用于发布的分支。
增加分支后，同一个工作流可以分别显示不同分支的构建结果。

增加测试动作：给 iOS 选择 scheme 和设备

（13:18）默认工作流为 Fruta 的所有平台创建 archive actions。为了增加覆盖率，演示中又添加了一个 Test action。

这个测试动作选择 iOS 平台，选择 Fruta iOS scheme，然后添加测试设备。Xcode Cloud 会推荐 iPhone 模拟器，再点击一次会添加推荐 iPad。演示里还把设备改成最新的 iPhone，确保 App 在 iPhone 12 上表现正常。

Action: Test
Platform: iOS
Scheme: Fruta iOS
Destinations:
- Recommended iPhone simulators
- Recommended iPads
- iPhone 12
OS version: latest

关键点：

Test 是工作流里的动作类型。
Platform: iOS 指定测试运行的平台。
Scheme: Fruta iOS 指定 Xcode 用哪个 scheme 执行测试。
Destinations 指定测试设备或模拟器。
OS version: latest 来自演讲中提到的默认设备系统版本设置。

手动启动构建：不改代码也能验证工作流

（14:41）修改工作流后，Holly 想验证它能否运行，但不想为了触发 CI 再提交一行代码。Xcode Cloud 支持从 Report navigator 中右键 workflow，选择 Start Build 手动启动。

启动时可以选择分支。演示选择刚加入工作流的 release/v1，然后点击 Start Build。

Report navigator > Workflow > Start Build
Branch: release/v1
Result: Build 3 starts under release/v1 section

关键点：

Start Build 让开发者手动运行工作流。
Branch: release/v1 用于验证刚添加的发布分支。
Build 3 出现在 build group overview 的 release/v1 分区下。
这一步用来检查工作流配置，不需要额外代码改动。

隐私设计：临时环境、隔离负载、不保存源码

（04:59）Xcode Cloud 需要访问源码，所以演讲单独说明了隐私设计。

构建环境是临时的。工作负载相互隔离。每次构建之间，环境会被销毁并重新创建。源码不会被存储，Xcode Cloud 只会在临时构建环境中获取代码。构建数据会加密静态存储，并存放在专用 CloudKit 数据库中。开发者可以删除自己的数据。

Privacy model
- Temporary build environments
- Isolated workloads
- Source code is never stored
- Build data encrypted at rest
- Dedicated CloudKit database
- User-controlled deletion

关键点：

Temporary build environments 降低构建环境残留状态带来的风险。
Isolated workloads 让不同构建负载相互隔离。
Source code is never stored 是演讲中的明确表述。
encrypted at rest 描述构建数据的静态加密。
User-controlled deletion 让团队可以自行删除数据。

核心启发

做什么：为主分支建立最小 CI 工作流。 为什么值得做：演讲中的默认工作流会在 push 到 main 后运行 archive actions，能尽早发现构建问题。 怎么开始：在 Xcode 里打开 Product > Xcode Cloud > Create Workflow，接受默认的 main 分支触发条件，先让 iOS 和 macOS 归档动作跑起来。
做什么：给发布分支单独增加构建视图。 为什么值得做：Build group overview 会按分支组织结果，一个 workflow 可以覆盖多条分支，同时保留独立状态。 怎么开始：编辑 workflow 的 start condition，在 custom branches 中加入 release/v1 这类发布分支，然后手动 Start Build 验证。
做什么：把跨平台导入问题交给 CI 捕获。 为什么值得做：Fruta 的 Mac archive action 抓到了 UIKit 导入问题，说明多平台项目很适合用云端归档动作持续验证。 怎么开始：让工作流同时 archive iOS 和 macOS。遇到平台差异时，用 #if !os(macOS) 这类条件编译限制平台专属 import。
做什么：给 iOS App 增加设备矩阵测试。 为什么值得做：演讲中 Test action 可以选择 scheme 和多个 destination，覆盖 iPhone、iPad 与最新系统版本。 怎么开始：在 workflow 的 Actions 中添加 Test，选择 iOS 平台和项目 scheme，再用推荐模拟器作为 destination。
做什么：把失败构建通知接入团队协作工具。 为什么值得做：演讲提到团队成员可以在 App Store Connect 中设置自己的通知，例如失败构建的 Slack 通知。 怎么开始：先让构建报告稳定产生结果，再到 App Store Connect 配置个人通知，优先订阅 failing builds。

关联 Session

Explore Xcode Cloud workflows — 继续讲工作流的 start condition、environment、actions 和 post-actions，适合配置正式 CI 流水线前阅读。
Customize your advanced Xcode Cloud workflows — 讲环境变量、自定义脚本、额外仓库和 webhook，适合已有基础工作流的团队。
Meet TestFlight on Mac — 讲 Mac beta 测试分发，并介绍它和 Xcode Cloud 的构建分发连接。
Faster and simpler notarization for Mac apps — 讲 Mac app 公证工具 notarytool，适合处理 Xcode Cloud 之外的 Mac 分发步骤。

Highlight

核心内容

详细内容

CI 的最小模型：推送代码后自动跑一组动作

工作流跑在 Apple 托管环境里

第一次创建工作流：从 Xcode 菜单开始

授权代码仓库：私有仓库需要显式权限

构建报告：从失败动作跳到出错代码

一个真实修复：UIKit 只在非 macOS 平台导入

团队共享工作流：一个人创建，其他人继续编辑

增加测试动作：给 iOS 选择 scheme 和设备

手动启动构建：不改代码也能验证工作流

隐私设计：临时环境、隔离负载、不保存源码

核心启发

关联 Session

评论