iPhone Duo 留给开发者的一个月包含 iPhone Duo 模拟器的 Xcode 27.1 beta 于 9 月 18 日发布距离 10 月 23 日正式发售仅五周。颇为微妙的是彼时不含 Duo 支持的 Xcode 27.2 beta 已先行推出——想适配苹果最新的设备反而要使用版本号更低的 Xcode。这种“双轨 Beta”或源于 Duo 独立的系统版本与发布前的保密需要代价则是开发者的准备窗口被压缩到了一个月左右。开发者可以在 Device Hub 中开合、旋转、折叠这台虚拟设备。但任何有经验的工程师都清楚模拟器能够还原几何形态与姿态却无法还原可供性与真实的物理交互。在缺乏实体反馈的这段真空期开发者很容易滑向两个极端要么无所适从不敢越雷池一步要么对着虚拟窗口凭空构想出许多看似精巧、在真实握持下却别扭难用的专属交互。面对紧迫的倒计时更务实的做法是先为“适配”划定理性的边界分清什么是“够用”什么是“好用”。Apple 已明确表示现有应用即使不重新构建也可以在 Duo 上运行但“能够运行”显然不等于“已经适配”。确保应用在新设备上自然、稳定地呈现是上市前“够用”的及格线至于什么才是真正属于折叠设备的“好用”体验恐怕要等设备来到开发者手中后才会逐渐浮现答案。10 月 23 日或许才是 Duo 适配真正开始的那一天。本期内容 | 前一期内容 | 全部周报列表原创ArrangementView谋而后定第一次看到ArrangementView的 API 时我有一种说不出的别扭感。直到在 Xcode 27.1 beta 中实际使用后这种感觉才逐渐清晰。查阅更多的苹果资料再把它放回 iPhone Duo 的使用场景我发现这份别扭其实来自两个方面一部分源于我对它的定位不够清楚理解之后便释然了另一部分则来自 API 本身即便想明白了依然存在。因此想用好ArrangementView需要在使用前多想一步内容之间究竟是什么关系哪些结果可以交给容器哪些取舍仍须由应用承担谋而后定。近期推荐What’s new in Swift 6.4’s from Apple’s engineersXiangyu 以 WWDC26 Swift Group Lab 上 Apple 工程师的现场答疑为线索逐一对照 Evolution 提案、编译器源码与官方文档厘清了哪些能力已经落地、哪些仍处于过渡阶段并订正了现场回答中若干版本与实现细节上的出入。其中最耐人寻味的是“如果重来一次”这个话题早期的 Swift Concurrency 会让nonisolated async函数自动离开调用者所在的 actor转到全局并发执行器Global Concurrent Executor上运行经过数年的实践Swift 团队认为让它默认留在调用者的 actor 上才更为合理——若能从头设计他们希望一开始便是如此。尽管这一行为在 Swift 6.4 中仍需显式启用却清晰地展现了 Swift Concurrency 如何依据真实的迁移经验不断校准自身的默认选择。withTaskCancellationShield: Swift 6.4 new featureSwift 6.4 引入的withTaskCancellationShieldSE-0504可以让一段代码不受所属任务已有取消状态的影响非常适合必须完成的收尾和清理逻辑。它并不会撤销取消本身只是让屏蔽范围内的代码包括其中创建的子任务暂时“看不到”取消状态离开屏蔽区域后原有取消状态会重新可见。由于该 API 依赖随系统分发的并发运行时Concurrency Runtime因此只能在 27 系列系统上使用很遗憾无法向下部署。Omar Elsayed 在文中给出了一个过渡方案创建一个非结构化任务Unstructured Task并await其value。由于取消状态不会自动传播到这个新任务而等待value又能让当前任务等到清理结束后再继续因此可以实现近似的效果。Omar 也强调这只是权宜之计不仅存在额外开销还要求捕获的值满足Sendable待最低部署版本提升后仍应改用正式 API。Running iOS Background Tasks Reliably, Part 2在 Part 1 中Irving Popovetsky 通过长期的真机观察总结出一套提升BGTaskScheduler可靠性的实践但有一个问题始终无解当用户较长时间不打开 App后台任务获得的执行机会便会逐渐衰减。这一次他从 WWDC20 的一句提示中找到了突破口——系统不会依据 App 的使用频率来限制静默推送Silent Push。于是他让 Cloudflare Worker 每小时向 CloudKit 公共数据库Public Database写入一条WakePing记录再借助CKQuerySubscription触发静默推送唤醒 App。整个过程无需维护设备令牌Device Token也不触及任何用户数据。经过数月的实际运行即便连续三周未打开 App同步依然能近乎准点地按小时触发。这当然无法让 iOS 的后台执行变成真正的 cron却很好地示范了如何将BGTaskScheduler、CloudKit 与后台通知Background Notification组合起来切实提升后台任务的可靠性。拆解 Xcode 27 mcpbridgeApple 没有用 swift-sdk而是自研了一整套 MCP 栈尽管 Apple 也参与了维护官方的 Swift MCP SDK但 Xcode 27 自身的 MCP 实现却另辟蹊径。Snow Wu 导出并核对了mcpbridge、mcp-server及相关私有框架的符号表发现从 JSON-RPC、MCP 语义层到命令行参数解析Xcode 几乎全部采用自研实现。这种“另起炉灶”并不只是为了规避第三方依赖。mcpbridge本身甚至不包含任何工具定义只负责在外部 Agent 与 Xcode 之间完成协议转换与路由真正的工具能力仍由 Xcode 提供。再结合三进程架构、XPC 通信与三层权限闸门可以看出 Apple 并不只是在 Xcode 里嵌入一个 MCP Server而是将 MCP 视为一个系统架构问题如何让不可信的外部 Agent 安全地接入一个状态复杂的 GUI 应用。Apple Watch brings distributed system headaches to your app当 iPhone 与 Apple Watch 都能读取并修改同一份状态时你面对的其实已是一个小型分布式系统两个独立节点随时可能失联各自继续修改数据并在数小时甚至数天后才重新连接。Jacob Bartlett 从这一视角重新审视 Watch Connectivity借 CAP 理论剖析各个WCSessionAPI 背后的取舍sendMessage要求对端即时可达以牺牲分区时的可用性换取实时、可确认的交互updateApplicationContext与transferUserInfo则容忍短暂的不一致优先保证可用性前者只保留最新状态后者按序投递每一次变更。这种视角也让“该选择哪个 Watch Connectivity API”从接口能力问题变成了产品语义问题登录状态、设置同步、录音控制等数据对一致性和可用性的要求并不相同同一个 App 的不同功能完全可以做出不同选择。iPhone Duo 和 AnyOS 27 适配codelaby 介绍了 iOS 27.1 新增的 Reserved Regions API以及如何通过GeometryProxy获取折痕division和摄像头遮挡occlusion区域。对于系统容器无法自动处理的自定义布局它提供了一种避免重要内容落入折痕或摄像头区域的可靠方式。Antoine van der Lee 从实际适配出发系统梳理了 iPhone Duo Simulator、可调整布局、ArrangementView、Reserved Regions、铰链状态和垂直工具栏等新能力。核心思路并不是为 Duo 单独设计一套界面而是先让应用真正适应可变空间再用 Duo 专属 API 对特殊场景进行增强。Ronnie W. 发现 macOS 27 会重新决定 SwiftUI Toolbar 的分组即使使用ToolbarSpacer原本希望分开的项目仍可能被合并进同一个 navigation island。文章给出的解决方案相当直接在需要精确控制分组时让 AppKit 的NSToolbarItemGroup接管 macOS 工具栏结构。Anton Gubarenko 整理了两场 iPhone Duo Group Lab 中 Apple 工程师对开发者问题的回答第二部分涵盖自适应布局、折叠姿态、垂直工具栏、多窗口、摄像头、无障碍以及 Simulator 等大量实际问题。贯穿其中的建议十分一致把 Duo 当作拥有更多可变空间的 iPhone优先依赖系统容器和自适应布局只有确有需要时再介入折痕、铰链和特定姿态。Sarunw 解释了 iPhone Duo 上系统如何决定 Toolbar Item 应进入水平还是垂直工具栏为项目同时提供图标和标题让系统根据空间选择表现形式只有在默认判断不合适时才通过axisBehavior明确指定.horizontalOnly或.verticalPreferred。工具PaintKitSwift 栅格绘图与图像处理引擎Josh Lin 开发的 PaintKit是 ItsPaint 项目中一套可以独立使用的 Swift 栅格绘图引擎涵盖像素存储与混合、光栅化、画笔与形状、选区、撤销、文字渲染以及图片和 PDF 编解码等能力。引擎以预乘 Alpha 的 RGBA8 像素为基础每次编辑都会返回实际发生变化的区域使画面刷新和撤销记录都只需处理必要的像素撤销历史也不是简单限制操作次数而是通过局部像素补丁按实际内存占用管理。PaintKit 不依赖 AppKit、SwiftUI 或第三方库采用 Swift 6 严格并发模式大部分功能无需启动应用或 Xcode 工程即可通过 swift test 验证。ItsPaint 则是 PaintKit 的完整应用与实践验证。它是一款面向 macOS 的轻量级原生绘图及截图标注工具提供铅笔、画笔、形状、文字、选区、像素化和聚光灯等 13 种工具支持 15 种形状、九种导出格式和 PDF 标注在不使用机器学习模型与网络服务的情况下移除简单背景。ItsPaint 同样开源并可在 App Store 免费下载。SwiftFairy让 Agent 不再“读过就忘”的 SwiftUI 审查工具由 Natalia Panferova 与 Matthaus Woolard 打造的 macOS 工具通过本地 MCP 服务器为编码 Agent 提供 Swift 与 SwiftUI 代码审查。与把大量规则写进 Skill 或AGENTS.md、再期待 Agent 在正确的时候想起它们不同SwiftFairy 将“发现问题”交给确定性的静态分析它把代码解析为局部图与声明式的问题模式进行匹配将发现精确定位到代码行再把对应的解释和修复示例交给 Agent。知识只在真正命中问题时才进入上下文既避免了 Agent “读过就忘”也减少了 Token 消耗。SwiftFairy 的价值也很大程度来自规则本身。目前这些知识以“卷轴”Scrolls的形式组织首批包括 Proper SwiftUI、Performant Swift Charts 与 Modern Swift内容来自两位作者多年积累的书籍与文章以及 Natalia 曾参与 Apple SwiftUI 核心团队工作的经验。与让另一个 LLM 来 Review 相比SwiftFairy 更像是在 Agent 工作流中加入了一层具有领域知识、结果可重复的静态审查。往期内容一场关于 SwiftUI 动画的“原生”之争 - #154iPhone Duo 带来的机遇与挑战 - #153当 Mac mini 的价格不再 mini - #152热茶还是冰咖啡 - #151 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践 iPhone Duo 留给开发者的一个月 -- 肘子的 Swift 周报 #155
iPhone Duo 留给开发者的一个月包含 iPhone Duo 模拟器的 Xcode 27.1 beta 于 9 月 18 日发布距离 10 月 23 日正式发售仅五周。颇为微妙的是彼时不含 Duo 支持的 Xcode 27.2 beta 已先行推出——想适配苹果最新的设备反而要使用版本号更低的 Xcode。这种“双轨 Beta”或源于 Duo 独立的系统版本与发布前的保密需要代价则是开发者的准备窗口被压缩到了一个月左右。开发者可以在 Device Hub 中开合、旋转、折叠这台虚拟设备。但任何有经验的工程师都清楚模拟器能够还原几何形态与姿态却无法还原可供性与真实的物理交互。在缺乏实体反馈的这段真空期开发者很容易滑向两个极端要么无所适从不敢越雷池一步要么对着虚拟窗口凭空构想出许多看似精巧、在真实握持下却别扭难用的专属交互。面对紧迫的倒计时更务实的做法是先为“适配”划定理性的边界分清什么是“够用”什么是“好用”。Apple 已明确表示现有应用即使不重新构建也可以在 Duo 上运行但“能够运行”显然不等于“已经适配”。确保应用在新设备上自然、稳定地呈现是上市前“够用”的及格线至于什么才是真正属于折叠设备的“好用”体验恐怕要等设备来到开发者手中后才会逐渐浮现答案。10 月 23 日或许才是 Duo 适配真正开始的那一天。本期内容 | 前一期内容 | 全部周报列表原创ArrangementView谋而后定第一次看到ArrangementView的 API 时我有一种说不出的别扭感。直到在 Xcode 27.1 beta 中实际使用后这种感觉才逐渐清晰。查阅更多的苹果资料再把它放回 iPhone Duo 的使用场景我发现这份别扭其实来自两个方面一部分源于我对它的定位不够清楚理解之后便释然了另一部分则来自 API 本身即便想明白了依然存在。因此想用好ArrangementView需要在使用前多想一步内容之间究竟是什么关系哪些结果可以交给容器哪些取舍仍须由应用承担谋而后定。近期推荐What’s new in Swift 6.4’s from Apple’s engineersXiangyu 以 WWDC26 Swift Group Lab 上 Apple 工程师的现场答疑为线索逐一对照 Evolution 提案、编译器源码与官方文档厘清了哪些能力已经落地、哪些仍处于过渡阶段并订正了现场回答中若干版本与实现细节上的出入。其中最耐人寻味的是“如果重来一次”这个话题早期的 Swift Concurrency 会让nonisolated async函数自动离开调用者所在的 actor转到全局并发执行器Global Concurrent Executor上运行经过数年的实践Swift 团队认为让它默认留在调用者的 actor 上才更为合理——若能从头设计他们希望一开始便是如此。尽管这一行为在 Swift 6.4 中仍需显式启用却清晰地展现了 Swift Concurrency 如何依据真实的迁移经验不断校准自身的默认选择。withTaskCancellationShield: Swift 6.4 new featureSwift 6.4 引入的withTaskCancellationShieldSE-0504可以让一段代码不受所属任务已有取消状态的影响非常适合必须完成的收尾和清理逻辑。它并不会撤销取消本身只是让屏蔽范围内的代码包括其中创建的子任务暂时“看不到”取消状态离开屏蔽区域后原有取消状态会重新可见。由于该 API 依赖随系统分发的并发运行时Concurrency Runtime因此只能在 27 系列系统上使用很遗憾无法向下部署。Omar Elsayed 在文中给出了一个过渡方案创建一个非结构化任务Unstructured Task并await其value。由于取消状态不会自动传播到这个新任务而等待value又能让当前任务等到清理结束后再继续因此可以实现近似的效果。Omar 也强调这只是权宜之计不仅存在额外开销还要求捕获的值满足Sendable待最低部署版本提升后仍应改用正式 API。Running iOS Background Tasks Reliably, Part 2在 Part 1 中Irving Popovetsky 通过长期的真机观察总结出一套提升BGTaskScheduler可靠性的实践但有一个问题始终无解当用户较长时间不打开 App后台任务获得的执行机会便会逐渐衰减。这一次他从 WWDC20 的一句提示中找到了突破口——系统不会依据 App 的使用频率来限制静默推送Silent Push。于是他让 Cloudflare Worker 每小时向 CloudKit 公共数据库Public Database写入一条WakePing记录再借助CKQuerySubscription触发静默推送唤醒 App。整个过程无需维护设备令牌Device Token也不触及任何用户数据。经过数月的实际运行即便连续三周未打开 App同步依然能近乎准点地按小时触发。这当然无法让 iOS 的后台执行变成真正的 cron却很好地示范了如何将BGTaskScheduler、CloudKit 与后台通知Background Notification组合起来切实提升后台任务的可靠性。拆解 Xcode 27 mcpbridgeApple 没有用 swift-sdk而是自研了一整套 MCP 栈尽管 Apple 也参与了维护官方的 Swift MCP SDK但 Xcode 27 自身的 MCP 实现却另辟蹊径。Snow Wu 导出并核对了mcpbridge、mcp-server及相关私有框架的符号表发现从 JSON-RPC、MCP 语义层到命令行参数解析Xcode 几乎全部采用自研实现。这种“另起炉灶”并不只是为了规避第三方依赖。mcpbridge本身甚至不包含任何工具定义只负责在外部 Agent 与 Xcode 之间完成协议转换与路由真正的工具能力仍由 Xcode 提供。再结合三进程架构、XPC 通信与三层权限闸门可以看出 Apple 并不只是在 Xcode 里嵌入一个 MCP Server而是将 MCP 视为一个系统架构问题如何让不可信的外部 Agent 安全地接入一个状态复杂的 GUI 应用。Apple Watch brings distributed system headaches to your app当 iPhone 与 Apple Watch 都能读取并修改同一份状态时你面对的其实已是一个小型分布式系统两个独立节点随时可能失联各自继续修改数据并在数小时甚至数天后才重新连接。Jacob Bartlett 从这一视角重新审视 Watch Connectivity借 CAP 理论剖析各个WCSessionAPI 背后的取舍sendMessage要求对端即时可达以牺牲分区时的可用性换取实时、可确认的交互updateApplicationContext与transferUserInfo则容忍短暂的不一致优先保证可用性前者只保留最新状态后者按序投递每一次变更。这种视角也让“该选择哪个 Watch Connectivity API”从接口能力问题变成了产品语义问题登录状态、设置同步、录音控制等数据对一致性和可用性的要求并不相同同一个 App 的不同功能完全可以做出不同选择。iPhone Duo 和 AnyOS 27 适配codelaby 介绍了 iOS 27.1 新增的 Reserved Regions API以及如何通过GeometryProxy获取折痕division和摄像头遮挡occlusion区域。对于系统容器无法自动处理的自定义布局它提供了一种避免重要内容落入折痕或摄像头区域的可靠方式。Antoine van der Lee 从实际适配出发系统梳理了 iPhone Duo Simulator、可调整布局、ArrangementView、Reserved Regions、铰链状态和垂直工具栏等新能力。核心思路并不是为 Duo 单独设计一套界面而是先让应用真正适应可变空间再用 Duo 专属 API 对特殊场景进行增强。Ronnie W. 发现 macOS 27 会重新决定 SwiftUI Toolbar 的分组即使使用ToolbarSpacer原本希望分开的项目仍可能被合并进同一个 navigation island。文章给出的解决方案相当直接在需要精确控制分组时让 AppKit 的NSToolbarItemGroup接管 macOS 工具栏结构。Anton Gubarenko 整理了两场 iPhone Duo Group Lab 中 Apple 工程师对开发者问题的回答第二部分涵盖自适应布局、折叠姿态、垂直工具栏、多窗口、摄像头、无障碍以及 Simulator 等大量实际问题。贯穿其中的建议十分一致把 Duo 当作拥有更多可变空间的 iPhone优先依赖系统容器和自适应布局只有确有需要时再介入折痕、铰链和特定姿态。Sarunw 解释了 iPhone Duo 上系统如何决定 Toolbar Item 应进入水平还是垂直工具栏为项目同时提供图标和标题让系统根据空间选择表现形式只有在默认判断不合适时才通过axisBehavior明确指定.horizontalOnly或.verticalPreferred。工具PaintKitSwift 栅格绘图与图像处理引擎Josh Lin 开发的 PaintKit是 ItsPaint 项目中一套可以独立使用的 Swift 栅格绘图引擎涵盖像素存储与混合、光栅化、画笔与形状、选区、撤销、文字渲染以及图片和 PDF 编解码等能力。引擎以预乘 Alpha 的 RGBA8 像素为基础每次编辑都会返回实际发生变化的区域使画面刷新和撤销记录都只需处理必要的像素撤销历史也不是简单限制操作次数而是通过局部像素补丁按实际内存占用管理。PaintKit 不依赖 AppKit、SwiftUI 或第三方库采用 Swift 6 严格并发模式大部分功能无需启动应用或 Xcode 工程即可通过 swift test 验证。ItsPaint 则是 PaintKit 的完整应用与实践验证。它是一款面向 macOS 的轻量级原生绘图及截图标注工具提供铅笔、画笔、形状、文字、选区、像素化和聚光灯等 13 种工具支持 15 种形状、九种导出格式和 PDF 标注在不使用机器学习模型与网络服务的情况下移除简单背景。ItsPaint 同样开源并可在 App Store 免费下载。SwiftFairy让 Agent 不再“读过就忘”的 SwiftUI 审查工具由 Natalia Panferova 与 Matthaus Woolard 打造的 macOS 工具通过本地 MCP 服务器为编码 Agent 提供 Swift 与 SwiftUI 代码审查。与把大量规则写进 Skill 或AGENTS.md、再期待 Agent 在正确的时候想起它们不同SwiftFairy 将“发现问题”交给确定性的静态分析它把代码解析为局部图与声明式的问题模式进行匹配将发现精确定位到代码行再把对应的解释和修复示例交给 Agent。知识只在真正命中问题时才进入上下文既避免了 Agent “读过就忘”也减少了 Token 消耗。SwiftFairy 的价值也很大程度来自规则本身。目前这些知识以“卷轴”Scrolls的形式组织首批包括 Proper SwiftUI、Performant Swift Charts 与 Modern Swift内容来自两位作者多年积累的书籍与文章以及 Natalia 曾参与 Apple SwiftUI 核心团队工作的经验。与让另一个 LLM 来 Review 相比SwiftFairy 更像是在 Agent 工作流中加入了一层具有领域知识、结果可重复的静态审查。往期内容一场关于 SwiftUI 动画的“原生”之争 - #154iPhone Duo 带来的机遇与挑战 - #153当 Mac mini 的价格不再 mini - #152热茶还是冰咖啡 - #151 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践