Apple Intelligence 已通过审核即将在中国提供服务在 WWDC 26 上苹果公布了新的 Apple Intelligence 架构不仅在云端引入 Gemini第三代 Apple Foundation Models 也确认由苹果与 Google 合作构建。这一度让我以为Apple Intelligence 进入中国市场的难度反而进一步增加了。但事情的发展比预想中更快。7 月Apple Intelligence 已经出现在中国国家互联网信息办公室CAC公布的最新一批生成式 AI 服务备案名单中。而就在两天前苹果又确认阿里巴巴 Qwen 将参与中国版 Apple Intelligence并一度出现在苹果的官方文档中。虽然该文档在 8 月 8 日短暂上线后于次日被暂时撤回但其中详细的操作指引和隐私说明已经向外界揭示了相当完整的集成方式。这意味着Apple Intelligence 在中国正式提供服务已经进入倒计时。除了阿里巴巴的 Qwen备案信息还披露百度也将作为合作伙伴深度参与中国版 Apple Intelligence 的 AI 搜索与视觉搜索。这意味着苹果不仅可以根据地区调整底层模型和服务提供商而且这样的合作关系也并非只能由一家厂商承担。随着各个国家和地区对隐私、数据以及 AI 服务监管要求的不断加强区域化差异几乎已经不可避免。苹果正在中国率先实践一种新的方式在保持 Apple Intelligence 整体产品体验和开发接口相对统一的同时根据不同地区的法规与生态选择不同的底层模型。未来这种模式很可能还会出现在更多市场并成为 Apple Intelligence 全球化过程中相当重要的一部分。对于使用 Apple Intelligence API 的开发者来说这同样是一个好消息。如果苹果能够继续维持 API 层的一致性开发者理论上无需为了不同市场维护完全不同的实现方案也意味着那些以 Apple Intelligence 能力为重要特色的应用将有机会触达更广泛的用户。Gemini 和 Qwen 或许并不是我日常 Agent 使用场景中最耀眼的两个名字但它们在世界知识、语言理解等方面都有相当不错的表现。考虑到 Apple Intelligence 当前更偏向系统级辅助能力而这些合作伙伴又拥有成熟的模型基础设施和云服务经验苹果这样的选择其实相当合理。Apple Intelligence 已经成为苹果在 AI 时代最重要的入口之一。它目前的能力距离我的个人期待仍有一些距离但至少从 2026 年开始它正在真正覆盖全球更多用户。相比于今天它究竟能完成多少任务我更期待 WWDC 2027 上苹果会如何进一步让 AI 深入融入自己的硬件、系统与服务生态。本期内容 | 前一期内容 | 全部周报列表原创在 SwiftUI Text 中控制孤行挖掘未公开的 avoidsOrphansSwiftUI 的Text有一项默认行为当段落末行只剩一个孤词或孤字时它会主动把上一行的完整词组一并推到末行避免“落单”。这份体贴多数时候是对的但代价是上一行可能留下一大片空白——在窄容器或中英混排的场景中反而破坏了段落的均衡。麻烦在于UIKit 允许开发者通过NSParagraphStyle关掉这项策略SwiftUI 却没有提供任何公开接口。本文将挖掘 SwiftUI 中一个早已存在、却始终未曾公开的 API ——avoidsOrphans让开发者重新拿回这项控制权。近期推荐再谈协议与全局 Actor 的设计权衡 (An Even Closer Look at Protocols and Global Actors)随着 Swift 并发模型不断演进一些过去被视为理所当然的工程取舍也开始因语言能力的增强而发生变化。在本文中Matt Massicotte 并没有停留在讨论“MainActor应该放在 protocol 上还是方法上”而是借此进一步探讨了 Swift 并发时代的 API 设计思路。相比给出一种所谓的“最佳实践”Matt 更强调一种设计思路隔离是一种约束应当源于真实需求而不是沿袭既有习惯。Tuist 每周动态第一期 (Weekly Tuist News #1)随着 AI Agent 越来越深入开发流程Tuist 这类工程管理工具的重要性也在不断提升对于独立开发者而言同样如此。作为长期活跃于 Tuist 社区的开发者Lee YoungJun 推出了一个专门追踪 Tuist 生态的新系列 Weekly Tuist News。与单纯汇总 release notes 不同这个系列还会结合社区动态以及作者在实际项目中的使用体验。在创刊号中他介绍了 SwifterPM 成为默认依赖恢复方式、Target 缓存失效条件的新控制能力以及 Tuist 面向 Coding Agent 的auth.md支持并结合实际使用分享了自己的验证过程与观察。使用 #Preview(arguments:) 轻松预览 SwiftUI 视图的多状态大多数 SwiftUI 组件都不只有一种状态空数据、加载中、错误、权限受限等。开发过程中我们通常会维护一组重复的#Preview或将所有状态放进一个VStack中统一展示。Xcode 27 新增的#Preview(arguments:)正是为这一场景而设计它能够根据一组状态数据自动生成多个独立的 Preview并支持在 Canvas 中单独查看每一种状态。Artem Novichkov 在文中也分享了他组织 Preview 的思路arguments应该描述业务状态State而不是环境Environment。即使未来 API 继续演进这种将业务状态与运行环境分离的设计理念依然具有长期参考价值。用 iOS 27 新 API 实现 SwiftUI 同心圆角按钮 (Concentric Buttons with OS 27’s SwiftUI APIs)WWDC 26 中苹果给 SwiftUI 新增了GeometryProxy.concentricCornerRadii让开发者能够获取容器的同心圆角信息。不过ButtonBorderShape仍然是一个封闭类型无法直接实现真正的自定义按钮边框。Alexander Weiß 利用这一新 API结合onGeometryChange、自定义ViewModifier与方法重载实现了一套使用方式几乎与系统 API 无异的同心按钮方案。对于GeometryProxy.concentricCornerRadii这类新增 API我们往往只需几秒钟就能知道它的作用但真正应用到项目中时才会发现还有不少实现细节和框架限制需要考虑。与其说这是一篇 API 介绍不如说 Alexander 分享了它在实际使用中的注意事项以及值得尝试的应用场景。Swift、AI 与软件开发的未来展望 (Swift, AI, and the future of software development)AI 已经成为许多开发者工作流中不可或缺的一部分但它在提升效率的同时也悄然改变着开发者与代码之间的关系。Tibor Bödecs 在这篇文章中真诚分享了自己这一年来的困惑一方面享受 AI 带来的高效率另一方面又怀念亲手写代码、深入理解问题的过程既相信 AI 会持续改变软件开发也希望它始终只是帮助开发者思考与创造的工具而不是取代思考本身。在过去一段时间中AI 给我带来的困惑与 Tibor Bödecs 很相似。尽管它让我失去了一些乐趣对代码、对产品产生了某种疏离感但我也一直不懈地尝试对 AI 建立更强的掌控力让它更好地为我所用成为我的外脑而不是让我沦为它的辅助。工具Gitwyn围绕 Xcode 工作流设计的 Git 客户端尽管近几个版本中 Xcode 的 Git 功能已经有了明显改善但无论是使用体验还是功能完整性仍难以满足部分开发者的在不同场景下的需求。由 Karthik K 开发的 Gitwyn是一款围绕 Xcode 工作流设计的原生 Git 客户端。在任意 Xcode 项目中按下 ⌘⇧E即可查看改动、整理暂存内容、生成提交信息并推送代码全程无需切换到终端或其他 Git 工具。Gitwyn 的一项特色功能是利用设备端 Apple Intelligence根据已暂存的代码自动生成提交信息。无需联网也不会上传源码。相比单纯减少一次输入它更希望将查看差异、组织提交、生成说明和推送代码整合为一段连续的开发流程让 Git 操作尽可能留在 Xcode 的工作上下文中。VersionedDocC为 Swift-DocC 补上版本管理过去几年每逢 WWDC 召开我通常都会第一时间打开苹果开发者文档通过“API 变化API Changes”功能比较不同 Xcode 与 SDK 版本查看 API 的新增、修改与弃用。遗憾的是这项颇为实用的功能在 2025 年的文档网站改版后消失了。原有的差异查询地址虽然仍可访问却已无法呈现完整的 API 变化。Kyle Ye 开发的 VersionedDocC恰好为 DocC 补上了这一能力。它在原有 Swift 工具链之上增加了一层发布编排为不同版本生成稳定地址提供版本选择器依据符号图展示相邻版本的公开 API 变化并通过不可变缓存避免反复构建历史文档。项目同时提供 SwiftPM 插件、GitHub Action 和 GitHub Pages 工作流也支持多平台符号图、外部模块及独立 DocC 目录。Swift Subprocess 1.0历经一年迭代Swift 官方项目 swift-subprocess 本周发布 1.0 正式版。它是一套基于 Swift Concurrency 的跨平台子进程库可以在 macOS、Linux、Windows、Android 与 BSD 系统上以统一方式启动命令、提供输入、流式读取输出并管理进程的退出与取消。它尤其适合 Swift CLI、构建工具、服务器程序、开发者工具与 macOS 自动化。需要注意的是1.0 要求 Swift 6.2不面向普通 iOS App也未提供沙箱、命令授权或伪终端PTY等更高层能力。swift-subprocess 也补上了 Swift 构建本地 Agent 所需的一块重要拼图可靠执行工具、持续接收运行结果并妥善管理子进程生命周期。模型决定“做什么”Subprocess 则让“如何执行”变得更可控、更可观测也更符合 Swift 的语言范式。往期内容热茶还是冰咖啡 - #147不是模型变慢了是任务变大了 - #146当灵感跑在了结果前面 - #145当每一次写入都有了新价格 - #144 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践 Apple Intelligence 已通过审核，即将在中国提供服务 -- 肘子的 Swift 周报 #148
Apple Intelligence 已通过审核即将在中国提供服务在 WWDC 26 上苹果公布了新的 Apple Intelligence 架构不仅在云端引入 Gemini第三代 Apple Foundation Models 也确认由苹果与 Google 合作构建。这一度让我以为Apple Intelligence 进入中国市场的难度反而进一步增加了。但事情的发展比预想中更快。7 月Apple Intelligence 已经出现在中国国家互联网信息办公室CAC公布的最新一批生成式 AI 服务备案名单中。而就在两天前苹果又确认阿里巴巴 Qwen 将参与中国版 Apple Intelligence并一度出现在苹果的官方文档中。虽然该文档在 8 月 8 日短暂上线后于次日被暂时撤回但其中详细的操作指引和隐私说明已经向外界揭示了相当完整的集成方式。这意味着Apple Intelligence 在中国正式提供服务已经进入倒计时。除了阿里巴巴的 Qwen备案信息还披露百度也将作为合作伙伴深度参与中国版 Apple Intelligence 的 AI 搜索与视觉搜索。这意味着苹果不仅可以根据地区调整底层模型和服务提供商而且这样的合作关系也并非只能由一家厂商承担。随着各个国家和地区对隐私、数据以及 AI 服务监管要求的不断加强区域化差异几乎已经不可避免。苹果正在中国率先实践一种新的方式在保持 Apple Intelligence 整体产品体验和开发接口相对统一的同时根据不同地区的法规与生态选择不同的底层模型。未来这种模式很可能还会出现在更多市场并成为 Apple Intelligence 全球化过程中相当重要的一部分。对于使用 Apple Intelligence API 的开发者来说这同样是一个好消息。如果苹果能够继续维持 API 层的一致性开发者理论上无需为了不同市场维护完全不同的实现方案也意味着那些以 Apple Intelligence 能力为重要特色的应用将有机会触达更广泛的用户。Gemini 和 Qwen 或许并不是我日常 Agent 使用场景中最耀眼的两个名字但它们在世界知识、语言理解等方面都有相当不错的表现。考虑到 Apple Intelligence 当前更偏向系统级辅助能力而这些合作伙伴又拥有成熟的模型基础设施和云服务经验苹果这样的选择其实相当合理。Apple Intelligence 已经成为苹果在 AI 时代最重要的入口之一。它目前的能力距离我的个人期待仍有一些距离但至少从 2026 年开始它正在真正覆盖全球更多用户。相比于今天它究竟能完成多少任务我更期待 WWDC 2027 上苹果会如何进一步让 AI 深入融入自己的硬件、系统与服务生态。本期内容 | 前一期内容 | 全部周报列表原创在 SwiftUI Text 中控制孤行挖掘未公开的 avoidsOrphansSwiftUI 的Text有一项默认行为当段落末行只剩一个孤词或孤字时它会主动把上一行的完整词组一并推到末行避免“落单”。这份体贴多数时候是对的但代价是上一行可能留下一大片空白——在窄容器或中英混排的场景中反而破坏了段落的均衡。麻烦在于UIKit 允许开发者通过NSParagraphStyle关掉这项策略SwiftUI 却没有提供任何公开接口。本文将挖掘 SwiftUI 中一个早已存在、却始终未曾公开的 API ——avoidsOrphans让开发者重新拿回这项控制权。近期推荐再谈协议与全局 Actor 的设计权衡 (An Even Closer Look at Protocols and Global Actors)随着 Swift 并发模型不断演进一些过去被视为理所当然的工程取舍也开始因语言能力的增强而发生变化。在本文中Matt Massicotte 并没有停留在讨论“MainActor应该放在 protocol 上还是方法上”而是借此进一步探讨了 Swift 并发时代的 API 设计思路。相比给出一种所谓的“最佳实践”Matt 更强调一种设计思路隔离是一种约束应当源于真实需求而不是沿袭既有习惯。Tuist 每周动态第一期 (Weekly Tuist News #1)随着 AI Agent 越来越深入开发流程Tuist 这类工程管理工具的重要性也在不断提升对于独立开发者而言同样如此。作为长期活跃于 Tuist 社区的开发者Lee YoungJun 推出了一个专门追踪 Tuist 生态的新系列 Weekly Tuist News。与单纯汇总 release notes 不同这个系列还会结合社区动态以及作者在实际项目中的使用体验。在创刊号中他介绍了 SwifterPM 成为默认依赖恢复方式、Target 缓存失效条件的新控制能力以及 Tuist 面向 Coding Agent 的auth.md支持并结合实际使用分享了自己的验证过程与观察。使用 #Preview(arguments:) 轻松预览 SwiftUI 视图的多状态大多数 SwiftUI 组件都不只有一种状态空数据、加载中、错误、权限受限等。开发过程中我们通常会维护一组重复的#Preview或将所有状态放进一个VStack中统一展示。Xcode 27 新增的#Preview(arguments:)正是为这一场景而设计它能够根据一组状态数据自动生成多个独立的 Preview并支持在 Canvas 中单独查看每一种状态。Artem Novichkov 在文中也分享了他组织 Preview 的思路arguments应该描述业务状态State而不是环境Environment。即使未来 API 继续演进这种将业务状态与运行环境分离的设计理念依然具有长期参考价值。用 iOS 27 新 API 实现 SwiftUI 同心圆角按钮 (Concentric Buttons with OS 27’s SwiftUI APIs)WWDC 26 中苹果给 SwiftUI 新增了GeometryProxy.concentricCornerRadii让开发者能够获取容器的同心圆角信息。不过ButtonBorderShape仍然是一个封闭类型无法直接实现真正的自定义按钮边框。Alexander Weiß 利用这一新 API结合onGeometryChange、自定义ViewModifier与方法重载实现了一套使用方式几乎与系统 API 无异的同心按钮方案。对于GeometryProxy.concentricCornerRadii这类新增 API我们往往只需几秒钟就能知道它的作用但真正应用到项目中时才会发现还有不少实现细节和框架限制需要考虑。与其说这是一篇 API 介绍不如说 Alexander 分享了它在实际使用中的注意事项以及值得尝试的应用场景。Swift、AI 与软件开发的未来展望 (Swift, AI, and the future of software development)AI 已经成为许多开发者工作流中不可或缺的一部分但它在提升效率的同时也悄然改变着开发者与代码之间的关系。Tibor Bödecs 在这篇文章中真诚分享了自己这一年来的困惑一方面享受 AI 带来的高效率另一方面又怀念亲手写代码、深入理解问题的过程既相信 AI 会持续改变软件开发也希望它始终只是帮助开发者思考与创造的工具而不是取代思考本身。在过去一段时间中AI 给我带来的困惑与 Tibor Bödecs 很相似。尽管它让我失去了一些乐趣对代码、对产品产生了某种疏离感但我也一直不懈地尝试对 AI 建立更强的掌控力让它更好地为我所用成为我的外脑而不是让我沦为它的辅助。工具Gitwyn围绕 Xcode 工作流设计的 Git 客户端尽管近几个版本中 Xcode 的 Git 功能已经有了明显改善但无论是使用体验还是功能完整性仍难以满足部分开发者的在不同场景下的需求。由 Karthik K 开发的 Gitwyn是一款围绕 Xcode 工作流设计的原生 Git 客户端。在任意 Xcode 项目中按下 ⌘⇧E即可查看改动、整理暂存内容、生成提交信息并推送代码全程无需切换到终端或其他 Git 工具。Gitwyn 的一项特色功能是利用设备端 Apple Intelligence根据已暂存的代码自动生成提交信息。无需联网也不会上传源码。相比单纯减少一次输入它更希望将查看差异、组织提交、生成说明和推送代码整合为一段连续的开发流程让 Git 操作尽可能留在 Xcode 的工作上下文中。VersionedDocC为 Swift-DocC 补上版本管理过去几年每逢 WWDC 召开我通常都会第一时间打开苹果开发者文档通过“API 变化API Changes”功能比较不同 Xcode 与 SDK 版本查看 API 的新增、修改与弃用。遗憾的是这项颇为实用的功能在 2025 年的文档网站改版后消失了。原有的差异查询地址虽然仍可访问却已无法呈现完整的 API 变化。Kyle Ye 开发的 VersionedDocC恰好为 DocC 补上了这一能力。它在原有 Swift 工具链之上增加了一层发布编排为不同版本生成稳定地址提供版本选择器依据符号图展示相邻版本的公开 API 变化并通过不可变缓存避免反复构建历史文档。项目同时提供 SwiftPM 插件、GitHub Action 和 GitHub Pages 工作流也支持多平台符号图、外部模块及独立 DocC 目录。Swift Subprocess 1.0历经一年迭代Swift 官方项目 swift-subprocess 本周发布 1.0 正式版。它是一套基于 Swift Concurrency 的跨平台子进程库可以在 macOS、Linux、Windows、Android 与 BSD 系统上以统一方式启动命令、提供输入、流式读取输出并管理进程的退出与取消。它尤其适合 Swift CLI、构建工具、服务器程序、开发者工具与 macOS 自动化。需要注意的是1.0 要求 Swift 6.2不面向普通 iOS App也未提供沙箱、命令授权或伪终端PTY等更高层能力。swift-subprocess 也补上了 Swift 构建本地 Agent 所需的一块重要拼图可靠执行工具、持续接收运行结果并妥善管理子进程生命周期。模型决定“做什么”Subprocess 则让“如何执行”变得更可控、更可观测也更符合 Swift 的语言范式。往期内容热茶还是冰咖啡 - #147不是模型变慢了是任务变大了 - #146当灵感跑在了结果前面 - #145当每一次写入都有了新价格 - #144 支持与反馈如果本期周报对你有帮助请点赞- 让更多开发者看到评论- 分享你的看法或问题转发- 帮助同行共同成长拓展 Swift 视野 邮件订阅| weekly.fatbobman.com 获取独家技术洞察 开发者社区| Discord 实时交流开发经验 原创教程| fatbobman.com 学习 Swift/SwiftUI 最佳实践