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 的设计权衡
随着 Swift 并发模型不断演进,一些过去被视为理所当然的工程取舍,也开始因语言能力增强而发生变化。本文并未停留在讨论"@MainActor 应该放在 protocol 上还是方法上",而是借此进一步探讨了 Swift 并发时代的 API 设计思路:隔离是一种约束,应当源于真实需求,而非沿袭既有习惯。
Tuist 每周动态第一期
随着 AI Agent 越来越深入开发流程,Tuist 这类工程管理工具的重要性也在不断提升,对独立开发者同样如此。一位长期活跃于 Tuist 社区的开发者推出了专门追踪 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 中单独查看每一种状态。文章分享了作者的组织思路:arguments 应描述业务状态(State),而非环境(Environment)——即使 API 继续演进,这种将业务状态与运行环境分离的设计理念依然有长期参考价值。
用 iOS 27 新 API 实现 SwiftUI 同心圆角按钮
WWDC 26 中苹果给 SwiftUI 新增了 GeometryProxy.concentricCornerRadii,让开发者能获取容器的同心圆角信息。不过 ButtonBorderShape 仍是封闭类型,无法直接实现真正的自定义按钮边框。有开发者利用这一新 API,结合 onGeometryChange、自定义 ViewModifier 与方法重载,实现了一套使用方式几乎与系统 API 无异的同心按钮方案。文章更侧重于分享实际使用中的注意事项,以及值得尝试的应用场景。
Swift、AI 与软件开发的未来展望
AI 已成为许多开发者工作流中不可或缺的一部分,但在提升效率的同时,也悄然改变着开发者与代码之间的关系。有文章真诚分享了这一年来的困惑:一方面享受 AI 带来的高效率,另一方面又怀念亲手写代码、深入理解问题的过程;既相信 AI 会持续改变软件开发,也希望它始终只是帮助开发者思考与创造的工具,而不是取代思考本身。
对很多人而言,AI 带来的困惑很相似。尽管它让一些乐趣消失了,对代码和产品产生了某种疏离感,但仍应不懈尝试建立对 AI 的更强掌控力,让它更好为己所用,成为外脑,而不是让自己沦为它的辅助。
工具
Gitwyn:围绕 Xcode 工作流设计的 Git 客户端
尽管近几个版本 Xcode 的 Git 功能已有明显改善,但在使用体验和功能完整性上,仍难以满足部分开发者在不同场景下的需求。一款名为 Gitwyn 的原生 Git 客户端围绕 Xcode 工作流设计,在任意 Xcode 项目中按下 ⌘⇧E,即可查看改动、整理暂存内容、生成提交信息并推送代码,全程无需切换到终端或其他 Git 工具。
Gitwyn 的一项特色功能是利用设备端 Apple Intelligence,根据已暂存的代码自动生成提交信息——无需联网,也不会上传源码。它希望将查看差异、组织提交、生成说明和推送代码整合为一段连续的开发流程,让 Git 操作尽可能留在 Xcode 的工作上下文中。
VersionedDocC:为 Swift-DocC 补上版本管理
过去几年,每逢 WWDC 召开,开发者通常会第一时间打开苹果开发者文档,通过"API 变化(API Changes)"功能比较不同 Xcode 与 SDK 版本,查看 API 的新增、修改与弃用。这项实用功能在 2025 年文档网站改版后消失了,原有差异查询地址虽仍可访问,却已无法呈现完整的 API 变化。
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 的语言范式。