上周，Reddit 上一篇题为《Is anyone else excited by Swift progress as the language?》的帖子引发了不少讨论。WWDC 2026 上，Apple 明确表示，Swift 已被用于 WebKit 关键组件、QUIC 网络栈、字体渲染、驱动与固件。发帖者据此认为，Swift 正在向核心操作系统内核迈进，并将这一幕视为 2014 年”高级系统编程语言”承诺的兑现。评论区的讨论则很快从“是否兑现了承诺”，延伸到跨平台支持、语言治理、工具链体验，以及 Swift 是否正在变得过于庞大等话题。
尽管问题依然不少，我仍然很欣赏 Swift 这些年的进展。本期推荐的内容也恰好提供了几个不同的观察切面：Swift 6.4 继续补齐并发模型中的工程细节，KernelKit 展示了 Apple 为内核 Swift 铺设的基础设施，SwiftOS 则让 Embedded Swift 承担起一个完整操作系统与真实服务负载。Swift 的进步已不只体现为语言特性越来越多，更体现在它能够胜任的工作种类不断增加，而且其中不少已经走出了实验阶段。
就我个人而言，从 Swift 6 开始，我几乎都在尽可能地使用新的语言能力。在新项目中，我已经将 Swift 编译器的最低版本要求设置为 6.2；随着理解不断深入，未来可能还会继续提高。一些涉及并发、所有权和隔离的特性，初看时确实有些拗口，但真正理解其设计目标后往往会发现：它们不是在增加心智负担，而是在把过去依赖约定、注释和经验维持的正确性，转变为编译器可以检查的约束。代码因此更容易推理，意图也更加清楚，许多安全问题则在运行之前就被挡了下来。
在 AI 时代，一门语言的人体工学优势，或许不再像过去那样单独决定开发者是否愿意采用它——生成代码的成本下降后，真正拉开差距的更可能是生态、工具链、可部署的平台，以及编译器能否持续提供可靠反馈。但语言设计的重要性并未因此减弱，反而换了一种方式体现：当越来越多代码由 AI 参与生成时，强类型系统、明确的所有权语义和严格的并发检查，都会成为可机器验证的护栏。AI 可以更快地产生代码，而语言和编译器负责告诉我们，哪些代码值得信任。
Swift 的处境也始终带着一种矛盾。Apple 生态为它提供了稳定且庞大的应用场景，却也长期让外界将其视为一门“只属于 Apple”的语言。这个生态既是 Swift 向外扩张时最难跨越的边界，也是它能够得到长期投入、稳步演进，不至于轻易被时代淘汰的坚实后盾。如今，官方 Android SDK、WebAssembly SDK 和 Windows 工作组等进展表明，这条边界正在逐渐向外移动；当然，非 Apple 平台上的工具链、包生态和开发体验仍有很长的路要走。
要说 Swift 现在是否仍让我感到 Excited，倒也未必；但我确实很 Enjoy 它当前的状态。相比十年前的宏大愿景，我更喜欢今天这种把承诺一点点变成工程现实的节奏。
原创
从 Size Class 到可用空间，horizontalSizeClass 还可靠吗？
从 WWDC 26 开始，iPhone 应用在 iPhone Mirroring 到 Mac 时，其窗口尺寸将支持自由调整。与此同时，iPhone-only 应用在 iPad 上运行时，也会进入可变尺寸环境。这次更新带来的影响远不止“iPhone 应用可以调整尺寸”这么简单。它正在改变许多开发者长期以来对布局系统的理解。一些过去常被用作布局依据的 trait，例如 horizontalSizeClass 已不再适合作为窗口宽度的主要判断依据。那么，这种变化究竟是一次突然出现的转向，还是 Apple 多年布局下的必然演进？本文将对此进行探讨。
近期推荐
Swift 6.4 并发新特性 (Swift 6.4: What’s New in Concurrency)
Antoine van der Lee 在本文中梳理了 Swift 6.4 为并发编程带来的一系列改进，包括支持在 defer 中执行异步清理、通过取消屏蔽确保关键的清理或回滚操作得以完成、为被忽略的可抛错 Task 增加警告，以及为 Task 引入类型化错误支持。此外，Result 现在可以直接封装异步可抛出操作，~Sendable 和 Swift 6.3 引入的 weak let 也让 Sendable 类型的表达更加准确。
相较于 Swift 6.2 之前对并发模型较为大刀阔斧的调整，这些变化不会带来太多新的心智负担，更多是在现有模型之上补齐细节，解决实际工程中清理、取消、错误处理和类型建模等方面的问题。
探索苹果系统内核中的 Swift (Apple Internals: Swift in the Kernel)
Swift 已经诞生十余年。作为这门语言的创造者，苹果是否已经开始将它用于操作系统内核的开发？来自 Calif 的 Josh Maine 通过分析 macOS 27、iOS 27 的 kernelcache 与 Xcode 27 Beta 工具链发现，Apple 新增了名为 KernelKit 的内部 SDK、对应不同系统的 Mach-O 平台标识，以及一套静态链接在 macOS 内核扩展中的 Embedded Swift 运行时。
不过，这并不意味着 XNU 正在被 Swift 重写。目前，Swift 只出现在内核扩展层；macOS 中的运行时尚未被其他组件实际调用，而 iOS 现阶段也只是完成了平台和工具链层面的准备。整套基础设施更像是 Apple 在正式引入 Swift 内核组件之前，先行铺设工具链、运行时与链接环境。无论如何，这意味着距离真正使用 Swift 编写内核组件又近了一步。
从触摸到像素：iOS 渲染管线底层探秘 (Touch to Pixels: UI Pipeline Internals on iOS)
当手指点击 iOS 界面后，到屏幕上的像素发生变化之前，系统内部究竟经历了什么？Jacob Bartlett 从一次触摸事件出发，沿着触摸屏硬件、XNU、IOKit、backboardd、应用 Run Loop、UIKit 与 Core Animation，一路追踪事件如何抵达我们的代码，以及界面更新如何经过 Render Server、GPU 和帧缓冲区，最终转化为屏幕上的像素。了解这条从 Touch 到 Pixels 的完整链路，不仅能帮助我们建立对 iOS UI 系统的整体认识，也有助于分析主线程阻塞、动画卡顿和掉帧等常见的界面性能问题。
SwiftUI 动态文本渲染 (Dynamic Text in SwiftUI)
设想一个场景：应用里有一个全局开关，决定所有界面显示用户的全名还是昵称。最直接的做法，是在每一处显示用户名的地方都加上判断，但只要有一个新功能忘记处理，这个开关就会失效。Robb Böhnke 的解法是借用 BCP 47 的私有子标签，将这项偏好编码进 Locale，再通过自定义 FormatStyle，在 Text 真正渲染时读取并选择对应的名称。这种做法绕过了 SwiftUI 缺少动态 Text 初始化 API 的限制，也把容易遗漏的调用端逻辑变成了应用范围内的默认行为。
SwiftUI SensoryFeedback Cache Key 经验教训：不要存储连续值
在 SwiftUI 中用 Slider 动态调整触觉反馈强度，竟然可能导致内存快速增长？听起来不可思议，但这个问题确实存在于 iOS 17 至 iOS 26 中。Kyle Ye 发现，这些版本的内部实现将 intensity 这样的连续值纳入了反馈生成器的缓存键。强度值的每一次细微变化，都可能对应一个新的 UIImpactFeedbackGenerator 实例，最终导致缓存不断膨胀。
Kyle 在去年年底提交了 FB，并于今年 6 月收到问题已修复的通知。iOS 27 的解决方案并不是增加一个缓存专用 Key 来打补丁，而是重新划分模型边界：将代表“稳定身份”的 FeedbackType，与每次播放使用的动态参数 Payload 彻底拆开。公开 API 保持不变，缓存逻辑却从数据模型层面得到了修正。
这次修复值得关注的地方，不只是解决了内存增长问题，更体现了 API 设计中的一个重要原则：描述“对象身份”的稳定信息，不应与只影响单次操作的动态参数混在一起。它也提醒我们，一个类型即使满足
Hashable，也不代表它天然适合作为缓存键。相比在使用处不断排除特殊字段，从数据模型层面划清语义边界，通常是更可靠的设计。
Swift 构建文档转换引擎的架构设计 (Architecting a Conversion Engine in Swift)
当应用需要在 Markdown、HTML、富文本、PDF 等多种格式之间互相转换时，如何避免转换逻辑随着格式数量呈平方级增长？Arthur Van Siclen 介绍了他在 Minimal 中的解决方案：设计一套中间表示 IR，让每种格式只需分别实现 Parser 和 Renderer，从而将六种格式之间的 30 条转换关系减少为 12 条。
其中，对“有损转换”的处理尤其值得借鉴。不同格式的表达能力并不对等，Minimal 通过 Concession 显式记录转换过程中发生的格式降级、内容丢弃或截断，而不是假设所有格式之间都能无损转换。
工具
SwiftOS：用 Embedded Swift 写一个真正的操作系统
SwiftOS 是一个几乎完全使用 Embedded Swift 从零编写的 64 位 ARM 操作系统。作者 Andrey Sapunov 的出发点很朴素：与其只从书本上理解操作系统，不如亲手实现一个，真正弄清内核、内存、进程与设备如何协作。选择 Swift 也不只是出于语言偏好，而是希望在保持代码生成可预测和底层控制能力的同时，借助 Swift 的类型系统、所有权模型和现代工程工具，让系统代码更安全、更容易表达。
SwiftOS 选择了一条颇为现代的系统路线：AArch64、基于 MMU 的进程地址空间隔离、自定义 syscall ABI、能力导向的授权模型、静态链接、签名只读基础镜像，以及原生 Swift userland。它已经实现了内核态 TCP/IP 栈，能够运行 nginx 和 Node.js，并运行在真实的 Hetzner Cloud ARM 实例上——项目官网就是由 SwiftOS 自己托管的。
或许，我们还需要更多时间，才能看到 Swift 被大规模用于苹果的系统内核。但 SwiftOS 至少证明了一件事：Embedded Swift 已经不只能够编写固件和裸机示例，它也足以支撑一个拥有进程隔离、用户态程序、网络栈和真实服务负载的操作系统。
Loupe：为 AI Agent 补上 Apple 原生 UI 的运行时证据
Loupe 是由 Won Heo 发起的 Apple 平台运行时诊断与 E2E 验证工具，尤其适合 Codex、Claude Code 这类 AI Coding Agent 参与原生界面开发时使用。它并不替代 xcodebuild、XCTest 或其他负责构建和测试的工具，而是通过向调试中的 App 注入或链接运行时，补上其后的 UI 证据层：从真正运行的 App 中采集 UIKit/AppKit 视图结构、可访问性信息、截图、日志、URLSession 网络活动，以及 Defaults、Feature Flags 等状态，再通过 CLI 提供查询与审计能力
Agent 可以先获取紧凑的 UI 观察结果，再按需深入检查具体节点，执行 tap、swipe、drag、type 等模拟器可见操作，并记录操作前后的快照、差异与 trace；它还可以对部分 UIKit 属性和约束进行运行时探针式修改，快速验证调整是否有效，再回到源码完成真正的修正。这让“看起来对不对、点起来通不通、布局有没有漂移”不再只依赖截图与猜测，而是成为一条能够复查和留痕的证据链。