Fatbobman's Swift Weekly #141
Is Anyone Else Excited by Swift’s Progress as a Language?
Is Anyone Else Excited by Swift’s Progress as a Language?
Last week, a Reddit post titled “Is anyone else excited by Swift progress as the language?” sparked a lively discussion. At WWDC 2026, Apple made it clear that Swift is now being used in key WebKit components, the QUIC networking stack, font rendering, drivers, and firmware—and, as the original poster claimed, it has started making its way into the core operating system kernel beginning with the 27 releases. The original poster saw this as Apple finally delivering on the promise it made in 2014 when it introduced Swift as a “high-level systems programming language.” The discussion soon expanded beyond whether that promise had been fulfilled to topics such as cross-platform support, language governance, the tooling experience, and whether Swift is becoming too large and ambitious.
Despite its remaining shortcomings, I still appreciate the progress Swift has made over the years. This week’s recommendations happen to offer several different perspectives on that progress: Swift 6.4 continues to fill in practical gaps in the concurrency model; KernelKit reveals the infrastructure Apple is laying for Swift in the kernel; and SwiftOS demonstrates Embedded Swift taking on an entire operating system and real-world service workloads. Swift’s progress is no longer measured only by the number of language features it has gained, but also by the growing range of work it can handle—and many of those use cases are no longer merely experimental.
Personally, since Swift 6, I have tried to adopt new language features wherever possible. For new projects, I have already raised the minimum required Swift compiler version to 6.2, and as my understanding deepens, I may raise it further. Some features involving concurrency, ownership, and isolation can feel awkward at first. Once their design goals become clear, however, they often turn out not to increase cognitive load, but to reduce it: correctness that once depended on conventions, comments, and developer experience can now be expressed as constraints the compiler is able to verify. The result is code that is easier to reason about, clearer in intent, and able to prevent many safety issues before it ever runs.
In the age of AI, a language’s ergonomic advantages may no longer determine adoption as decisively as they once did. As the cost of generating code falls, the real differentiators are more likely to be the ecosystem, tooling, available deployment targets, and whether the compiler can provide consistently reliable feedback. But that does not make language design less important—it simply changes how its value appears. As AI participates in writing more of our code, strong type systems, explicit ownership semantics, and strict concurrency checking become machine-verifiable guardrails. AI can produce code faster; the language and compiler help us determine which of that code deserves to be trusted.
Swift has always occupied a somewhat contradictory position. The Apple ecosystem gives it a large, stable field of application, yet it has also caused the language to be seen for years as something that “belongs only to Apple.” That ecosystem is both the hardest boundary for Swift to cross as it expands outward and the solid foundation that ensures continued investment, steady evolution, and protection from fading into irrelevance. Today, developments such as the official Android SDK, the WebAssembly SDK, and the Windows Working Group suggest that this boundary is gradually moving outward. Of course, tooling, package ecosystems, and the overall developer experience on non-Apple platforms still have a long way to go.
Does Swift still make me feel excited? Perhaps not exactly. But I genuinely enjoy where the language is today. Compared with the grand vision of a decade ago, I prefer the current pace: turning those promises into engineering reality, one step at a time.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate
Perfect for developer tools, courses, and services.
Enjoyed this issue? Buy me a coffee ☕️
Original
From Size Class to Available Space: Is horizontalSizeClass Still Reliable?
Starting with WWDC 26, iPhone apps mirrored to a Mac through iPhone Mirroring will support freely resizable windows. At the same time, iPhone-only apps running on iPad will also enter a variable-size environment. The impact of this update goes far beyond simply allowing iPhone apps to resize. It is changing how many developers have long understood the layout system. Traits that were once commonly used as the basis for layout decisions, such as horizontalSizeClass, are no longer suitable as the primary indicator of window width. So, is this change a sudden shift in direction, or the inevitable result of Apple’s years-long evolution of its layout system? This article explores that question.
Recent Recommendations
Swift 6.4: What’s New in Concurrency
In this article, Antoine van der Lee reviews a series of improvements Swift 6.4 brings to concurrency, including support for asynchronous cleanup in defer, cancellation shields that ensure critical cleanup or rollback operations can finish, warnings for ignored throwing Task instances, and typed error support for Task. In addition, Result can now directly wrap asynchronous throwing operations, while ~Sendable and the weak let introduced in Swift 6.3 make the modeling of Sendable types more precise.
Compared with the more sweeping changes made to the concurrency model before Swift 6.2, these additions introduce relatively little new cognitive overhead. Instead, they refine the existing model and address practical engineering concerns involving cleanup, cancellation, error handling, and type modeling.
Apple Internals: Swift in the Kernel
Swift has now been around for more than a decade. As the creator of the language, has Apple begun using it to develop operating system kernels? Josh Maine of Calif analyzed the macOS 27 and iOS 27 kernelcaches, along with the Xcode 27 Beta toolchain, and discovered that Apple has added an internal SDK called KernelKit, separate Mach-O platform identifiers for different operating systems, and an Embedded Swift runtime statically linked into a macOS kernel extension.
However, this does not mean that XNU is being rewritten in Swift. At present, Swift appears only at the kernel-extension layer. The runtime included in macOS is not yet referenced by any other component, while iOS has so far completed only the platform and toolchain groundwork. The infrastructure looks more like Apple laying down the toolchain, runtime, and linking environment before introducing actual Swift kernel components. In any case, it brings us one step closer to seeing real kernel components written in Swift.
Touch to Pixels: UI Pipeline Internals on iOS
What exactly happens inside the system after you tap an iOS interface but before the pixels on the screen change? Starting with a single touch event, Jacob Bartlett follows the entire journey through the touchscreen hardware, XNU, IOKit, backboardd, the app’s Run Loop, UIKit, and Core Animation. He traces how the event reaches our code, and how the resulting UI update passes through the Render Server, GPU, and frame buffer before finally becoming pixels on the display. Understanding this complete journey from Touch to Pixels not only gives us a clearer mental model of the iOS UI system, but also helps when diagnosing common performance issues such as main-thread blocking, stuttering animations, and dropped frames.
Dynamic Text in SwiftUI
Imagine an app with a global preference that determines whether every screen displays a user’s full name or nickname. The most direct approach is to add a conditional check everywhere a username appears, but the entire preference breaks down as soon as one new feature forgets to handle it. Robb Böhnke solves this by using a BCP 47 private-use subtag to encode the preference into Locale, then reading it through a custom FormatStyle when Text is actually rendered. This approach works around SwiftUI’s lack of a dynamic Text initializer and turns logic that could easily be forgotten at individual call sites into application-wide default behavior.
SwiftUI SensoryFeedback Cache Key Pitfall: Do Not Store Continuous Values
Can dynamically adjusting haptic feedback intensity with a Slider in SwiftUI really cause memory usage to grow rapidly? It sounds surprising, but the issue genuinely exists from iOS 17 through iOS 26. Kyle Ye discovered that the internal implementation in these versions included continuous values such as intensity in the feedback generator’s cache key. Every tiny change in intensity could therefore correspond to a new UIImpactFeedbackGenerator instance, causing the cache to grow continuously.
Kyle filed an FB late last year and was notified this June that the issue had been fixed. Rather than patching the problem by introducing a cache-specific key, iOS 27 redraws the model boundary: it completely separates the “stable identity” represented by FeedbackType from the per-play dynamic parameters stored in the new Payload. The public API remains unchanged, but the cache behavior is corrected at the data-model level.
What makes this fix worth studying is not merely that it resolves the memory-growth issue, but that it demonstrates an important principle of API design: stable information describing an object’s identity should not be mixed with dynamic parameters that affect only a single operation. It also reminds us that simply conforming to
Hashabledoes not make a type inherently suitable for use as a cache key. Rather than repeatedly excluding exceptional fields at the point of use, drawing clear semantic boundaries in the data model is usually the more reliable design.
Architecting a Conversion Engine in Swift
When an application needs to convert among formats such as Markdown, HTML, rich text, and PDF, how can it prevent conversion logic from growing quadratically as more formats are added? Arthur Van Siclen explains the solution he developed for Minimal: introduce an Intermediate Representation, or IR, so that each format only needs its own Parser and Renderer. With six formats, this reduces the number of conversion relationships from 30 to 12.
Its treatment of lossy conversion is particularly worth learning from. Different formats do not have equivalent expressive capabilities, so Minimal uses Concession to explicitly record formatting that was downgraded, content that was dropped, or data that was truncated during conversion, rather than pretending that every conversion can be lossless.
Tools
SwiftOS: Building a Real Operating System with Embedded Swift
SwiftOS is a 64-bit ARM operating system written almost entirely from scratch in Embedded Swift. Its author, Andrey Sapunov, began with a straightforward idea: rather than learning operating-system concepts only from books, why not build one and truly understand how kernels, memory, processes, and devices work together? His choice of Swift was not merely a matter of language preference. He wanted to preserve predictable code generation and low-level control while using Swift’s type system, ownership model, and modern engineering tools to make systems code safer and easier to express.
SwiftOS follows a distinctly modern systems architecture: AArch64, MMU-based process address-space isolation, a custom syscall ABI, a capability-oriented authorization model, static linking, a signed read-only base image, and a native Swift userland. It already includes an in-kernel TCP/IP stack, can run nginx and Node.js, and is deployed on a real Hetzner Cloud ARM instance—the project’s website is hosted by SwiftOS itself.
We may still need more time before Swift is widely used within Apple’s operating system kernels. But SwiftOS proves at least one thing: Embedded Swift is no longer limited to firmware and bare-metal examples. It is capable of supporting an operating system with process isolation, user-space programs, a network stack, and real service workloads.
Loupe: Giving AI Agents Runtime Evidence for Native Apple UIs
Loupe, created by Won Heo, is a runtime diagnostics and E2E verification tool for Apple platforms. It is particularly useful when AI coding agents such as Codex and Claude Code participate in native UI development. Loupe does not replace xcodebuild, XCTest, or other tools responsible for building and testing an application. Instead, by injecting or linking a runtime into a debug build, it adds a runtime UI evidence layer on top of them. From the app that is actually running, it can collect UIKit and AppKit view structures, accessibility information, screenshots, logs, URLSession network activity, and state such as Defaults and Feature Flags, then expose querying and auditing capabilities through its CLI.
An agent can begin with a compact observation of the UI, inspect specific nodes in greater detail as needed, perform simulator-visible actions such as tap, swipe, drag, and type, and record before-and-after snapshots, diffs, and traces. It can also make probe-like runtime changes to selected UIKit properties and constraints, quickly verify whether an adjustment works, and then return to the source code to implement the actual fix. This turns questions such as “Does it look right?”, “Does the interaction work?”, and “Has the layout drifted?” from screenshot-driven guesswork into a reviewable and reproducible chain of evidence.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
Swift 还让你 Excited 吗？
上周，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 它当前的状态。相比十年前的宏大愿景，我更喜欢今天这种把承诺一点点变成工程现实的节奏。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。
原创
从 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 属性和约束进行运行时探针式修改，快速验证调整是否有效，再回到源码完成真正的修正。这让“看起来对不对、点起来通不通、布局有没有漂移”不再只依赖截图与猜测，而是成为一条能够复查和留痕的证据链。