iPhone Duo 留给开发者的一个月 - 肘子的 Swift 周报 #155
内容提要
Xcode 27.1 beta 已包含 iPhone Duo 模拟器，但适配窗口仅约一个月。开发者应区分“够用”与“好用”，先确保应用稳定运行，真正适配可待设备到手后展开。文章还介绍了 ArrangementView 的定位与取舍、Swift 6.4 新特性、后台任务可靠性、Xcode 自研 MCP 栈，以及 Duo 适配、PaintKit、SwiftFairy 等工具与实践。
延伸解读
适配窗口紧迫，但不必过度设计
Xcode 27.1 beta 于 9 月 18 日发布，距离 iPhone Duo 10 月 23 日正式发售仅五周，且不含 Duo 支持的 Xcode 27.2 beta 先行推出，导致开发者适配窗口被压缩到一个月左右。文章指出，模拟器能还原几何形态与姿态，却无法还原真实物理交互，因此开发者容易陷入两个极端：要么不敢行动，要么凭空构想出在真实握持下别扭的交互。更务实的做法是分清“够用”与“好用”：先确保应用稳定运行，真正适配可待设备到手后展开。
ArrangementView 的定位与使用前提
文章作者对 ArrangementView 的 API 感到别扭，部分源于对其定位不够清楚，部分则来自 API 本身。想用好它，需要在使用前多想一步：内容之间究竟是什么关系？哪些结果可以交给容器，哪些取舍仍须由应用承担？这种“谋而后定”的思路，要求开发者在采用该容器前先理清布局逻辑，而非直接套用。
Swift 6.4 的并发调整与取消屏蔽
Swift 6.4 引入 withTaskCancellationShield（SE-0504），让一段代码不受所属任务已有取消状态的影响，适合必须完成的收尾和清理逻辑。它不会撤销取消本身，只是让屏蔽范围内的代码暂时“看不到”取消状态，离开后取消状态重新可见。该 API 依赖随系统分发的并发运行时，只能在 27 系列系统上使用，无法向下部署。过渡方案是创建非结构化任务并 await 其 value，但存在额外开销且要求捕获值满足 Sendable。
后台任务可靠性的组合思路
针对 BGTaskScheduler 在用户长期不打开 App 时执行机会衰减的问题，文章介绍了一种组合方案：利用系统不依据 App 使用频率限制静默推送的特性，让 Cloudflare Worker 每小时向 CloudKit 公共数据库写入 WakePing 记录，再通过 CKQuerySubscription 触发静默推送唤醒 App。整个过程无需维护设备令牌，也不触及用户数据。经过数月运行，即使连续三周未打开 App，同步仍能近乎准点按小时触发。这并非让 iOS 后台执行变成真正的 cron，而是示范了如何
Q&A
iPhone Duo 的开发者适配窗口为什么只有一个月？
包含 iPhone Duo 模拟器的 Xcode 27.1 beta 于 9 月 18 日发布，而设备 10 月 23 日正式发售，间隔仅五周。同时，不含 Duo 支持的 Xcode 27.2 beta 已先行推出，导致想适配新设备反而要用版本号更低的 Xcode。这种“双轨 Beta”可能源于 Duo 独立的系统版本与发布前保密需要，代价是开发者的准备窗口被压缩到约一个月。
在 iPhone Duo 上市前，开发者应该优先做哪些适配工作？
更务实的做法是先划定理性的适配边界，分清“够用”与“好用”。Apple 已明确现有应用即使不重新构建也能在 Duo 上运行，但“能够运行”不等于“已经适配”。上市前的及格线是确保应用在新设备上自然、稳定地呈现；真正属于折叠设备的“好用”体验，可等设备到手后再展开。
Swift 6.4 的 withTaskCancellationShield 有什么作用？
withTaskCancellationShield（SE-0504）可以让一段代码不受所属任务已有取消状态的影响，适合必须完成的收尾和清理逻辑。它不会撤销取消本身，只是让屏蔽范围内的代码（包括其中创建的子任务）暂时“看不到”取消状态；离开屏蔽区域后，原有取消状态会重新可见。该 API 依赖随系统分发的并发运行时，只能在 27 系列系统上使用，无法向下部署。
如何提高 iOS 后台任务（BGTaskScheduler）的可靠性？
Irving Popovetsky 发现系统不会依据 App 使用频率限制静默推送，于是让 Cloudflare Worker 每小时向 CloudKit 公共数据库写入一条 WakePing 记录，再借助 CKQuerySubscription 触发静默推送唤醒 App。整个过程无需维护设备令牌，也不触及用户数据。经过数月运行，即使连续三周未打开 App，同步依然能近乎准点地按小时触发。这示范了如何组合 BGTaskScheduler、CloudKit 与后台通知来提升可靠性。
Xcode 27 的 MCP 实现为什么选择自研而不是用 swift-sdk？
尽管 Apple 也参与维护官方 Swift MCP SDK，但 Xcode 27 的 MCP 实现却另辟蹊径。Snow Wu 通过导出并核对符号表发现，从 JSON-RPC、MCP 语义层到命令行参数解析，Xcode 几乎全部采用自研实现。mcpbridge 本身不包含任何工具定义，只负责在外部 Agent 与 Xcode 之间完成协议转换与路由，真正的工具能力仍由 Xcode 提供。结合三进程架构、XPC 通信与三层权限闸门，可以看出 Apple 将 MCP 视为一个系统架构问题：如何让不可信的外部 Agent 安全地接入一个状态复杂的 GUI 应用。
SwiftFairy 如何帮助 Agent 进行 SwiftUI 代码审查？
SwiftFairy 是一款 macOS 工具，通过本地 MCP 服务器为编码 Agent 提供 Swift 与 SwiftUI 代码审查。它不把大量规则写进 Skill 或 AGENTS.md，而是将“发现问题”交给确定性的静态分析：把代码解析为局部图，与声明式的问题模式匹配，将发现精确定位到代码行，再把解释和修复示例交给 Agent。知识只在真正命中问题时才进入上下文，既避免 Agent“读过就忘”，也减少 Token 消耗。其规则以“卷轴”形式组织，首批包括 Proper SwiftUI、Performant Swift Charts 与 Modern Swift。
