在 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 中控制孤行：挖掘未公开的 avoidsOrphans
SwiftUI 的 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 的语言范式。