Fatbobman's Swift Weekly #141
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 WeeklyPromote your product to Swift & iOS developers across: - Blog: 50,000+ monthly visitors Perfect for developer tools, courses, and services. Enjoyed this issue? Buy me a coffee ☕️ OriginalFrom 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 Recent RecommendationsSwift 6.4: What’s New in ConcurrencyIn this article, Antoine van der Lee reviews a series of improvements Swift 6.4 brings to concurrency, including support for asynchronous cleanup in 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 KernelSwift 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 iOSWhat 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 SwiftUIImagine 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 SwiftUI SensoryFeedback Cache Key Pitfall: Do Not Store Continuous ValuesCan 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 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
Architecting a Conversion Engine in SwiftWhen 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 ToolsSwiftOS: Building a Real Operating System with Embedded SwiftSwiftOS 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.
Loupe: Giving AI Agents Runtime Evidence for Native Apple UIsLoupe, 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 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，例如 近期推荐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 的私有子标签，将这项偏好编码进 SwiftUI SensoryFeedback Cache Key 经验教训：不要存储连续值在 SwiftUI 中用 Slider 动态调整触觉反馈强度，竟然可能导致内存快速增长？听起来不可思议，但这个问题确实存在于 iOS 17 至 iOS 26 中。Kyle Ye 发现，这些版本的内部实现将 Kyle 在去年年底提交了 FB，并于今年 6 月收到问题已修复的通知。iOS 27 的解决方案并不是增加一个缓存专用 Key 来打补丁，而是重新划分模型边界：将代表“稳定身份”的
Swift 构建文档转换引擎的架构设计 (Architecting a Conversion Engine in Swift)当应用需要在 Markdown、HTML、富文本、PDF 等多种格式之间互相转换时，如何避免转换逻辑随着格式数量呈平方级增长？Arthur Van Siclen 介绍了他在 Minimal 中的解决方案：设计一套中间表示 IR，让每种格式只需分别实现 Parser 和 Renderer，从而将六种格式之间的 30 条转换关系减少为 12 条。 其中，对“有损转换”的处理尤其值得借鉴。不同格式的表达能力并不对等，Minimal 通过 工具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 自己托管的。
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 属性和约束进行运行时探针式修改，快速验证调整是否有效，再回到源码完成真正的修正。这让“看起来对不对、点起来通不通、布局有没有漂移”不再只依赖截图与猜测，而是成为一条能够复查和留痕的证据链。 Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
