Fatbobman's Swift Weekly #142
SPI Joins Apple, and Swift Moves Toward Self-Hosting
SPI Joins Apple, and Swift Moves Toward Self-Hosting
A few days ago, Swift Package Index (SPI) announced that it had joined Apple. The two sides will work together to build a comprehensive package registry for Swift developers. At the same time, SPI’s existing capabilities, including package discovery, compatibility checking, and documentation hosting, will continue to be provided, and package authors will not need to adjust their current publishing workflows in the short term.
This also adds a new footnote to the observation I made in #135 that “SwiftPM has only just reached its second chapter”: the retreat of CocoaPods merely pushed SPM into the default position, while SPI joining Apple truly opens the next act of Swift package ecosystem infrastructure.
If SwiftPM answered the question of “whether packages can be conveniently depended on,” and SPI answered “whether packages can be found and evaluated,” then joining Apple moves the conversation further toward “whether packages can be published, identified, and distributed in a trustworthy way.” Looking at the medium term, three points are especially worth watching:
SPI will evolve from a third-party indexing service into an important entry point for the official package registry;
The Swift package ecosystem may gradually reduce its implicit dependence on GitHub as a source of hosting, distribution, and identity;
Xcode may establish closer integration with SPI’s search, compatibility checking, and documentation capabilities.
Another exciting development for Swift developers last week was Erik Eckstein’s announcement on the Swift forums that the Swift project will drop the requirement that the compiler “must be buildable using only a C++ host toolchain.” In other words, starting from the main branch, building the Swift compiler will require an existing Swift toolchain. This also means that mandatory compiler paths that previously had to remain implemented in C++ can now gradually be written in Swift. The officially mentioned scope includes core components such as the Parser, AST, Type Checker, and mandatory SIL passes.
This does not mean that the Swift compiler has already been completely rewritten in Swift, nor does it mean that the C++ parser will disappear immediately. More precisely, this is an important threshold for the Swift compiler as it moves toward bootstrapping and self-hosting: Swift is no longer limited to peripheral tools, optional features, or individual optimization passes, but can now enter the compiler’s core paths.
Bootstrapping itself does not simply prove the strength or weakness of a language, but it does represent a form of engineering maturity: whether the language, compiler, standard library, package manager, and cross-platform build system are strong enough to support their own continued evolution. For a language that hopes to expand its influence beyond Apple platforms, this step carries both symbolic significance and practical value.
Looking at SPI joining Apple alongside the Swift compiler moving toward self-hosting, it becomes clear that they point to the same thing: Swift is filling in its ecosystem infrastructure. The former concerns package discovery, identity, signing, and trusted distribution, while the latter improves the maintainability and evolution capacity of the language toolchain itself. Whether Swift can truly break out depends not only on how much influence Apple has over it, but on whether Apple and the Swift community can continue to show an open and enterprising attitude, and whether they can make the toolchain, package ecosystem, and cross-platform experience complete enough. On these two developments, I am willing to remain optimistic.
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 ☕️
Recent Recommendations
Bring Swift to The APPLE II
The Apple II was one of Apple’s most important early products and continues to influence many developers today. Many people once used BASIC or Apple Pascal on it, but what would it feel like to write Swift on this machine? Yeo Kheng Meng created SwiftII, a Swift-like mini development environment that allows an old machine with a 1 MHz 6502 CPU and around 64 KB of memory to write and run Swift-like programs.
What makes the article fascinating is not only “getting a Swift-like language running on the Apple II,” but also the many engineering trade-offs imposed by hardware limitations: limited memory space, conflicts between the language card and ProDOS, keyboard and display differences across Apple II models, and why the project ultimately had to be distributed as multiple disk images. The author also candidly shares the process of AI-assisted development. Even with the help of Claude Code and Codex, key architectural trade-offs, scope control, and hardware testing strategies still had to be handled by the author. This article offers both retro-computing engineering details and the compromises involved in bringing modern language design into an extremely constrained environment.
Building an over-the-air update system for native Swift with WebAssembly, from scratch
Building an OTA update mechanism for native Swift iOS apps is a controversial but valuable direction. In this article, Jack Solomon demonstrates a WebAssembly-based approach: compile Swift functions into WASM, load and execute them inside an iOS app through WasmKit, and then download new WASM modules from a server, allowing the app to change its runtime behavior without rebuilding or replacing the signed binary.
The article breaks down the Swift-to-WASM toolchain, WASI, @_cdecl exports, reactor modules, passing parameters through linear memory, and why hot-updating SwiftUI views requires dynamic replacement and a serializable view description tree. Jack also packaged this approach into a Swift SDK: patch-swift.
It should be noted that this type of solution touches the boundaries of App Store Review rules around downloading and executing code, so actual usage still requires careful evaluation of the scenario and compliance risks.
SwiftUI Is One Graph
Mihaela Mihaljević Jakić published two long articles about SwiftUI’s underlying mechanisms over the past week, and they are worth reading together. The first, SwiftUI Is One Graph, starts from observed behavior and Apple patents to explain that SwiftUI is not simply doing View Tree diffing, but is more like a demand-driven attribute graph: View structs themselves are disposable descriptions, while what truly persists is the attribute graph and the state, dependencies, layout, and animation propagation within it.
The second article, “The SwiftUI Oracle: Measuring a Clean Room Against the Real Thing,” goes further by showing how to validate this understanding. The author implements a clean-room engine called PureView that does not depend on SwiftUI, then treats real SwiftUI as an oracle and uses differential testing of layout, animation, pixel rendering, and more to validate the model.
Mihaela’s workflow is highly inspiring for AI agents. Agents do not need to rely solely on language models to guess whether SwiftUI behavior is correct; they can generate or modify an implementation, run tests, and let real SwiftUI provide comparable results. This kind of “unit test”-like feedback loop can turn the understanding of a black-box framework into engineering signals that can be continuously verified and iterated on.
SwiftUI: Intercept-able Picker / Menu / Context Menu
In many scenarios, developers want to perform some synchronous operation before components such as Menu, Picker, or contextMenu are presented, such as recording how many times a menu is opened, updating state, or temporarily deciding whether presentation should be allowed. SwiftUI, however, does not provide a corresponding callback. In this article, Itsuki shares an implementation approach: bridge to a native View that hosts SwiftUI content, execute menuWillOpen when the corresponding gesture is triggered, and then decide whether to actively present the menu using AppKit APIs such as NSMenu.popUpContextMenu.
This article once again highlights a practical issue with SwiftUI: many seemingly simple interaction controls, once they go beyond what the system modifiers expose, still require understanding the underlying AppKit / UIKit layer to truly solve.
_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects
Artem Mirzabekian shared an interesting private UIKit component, _UIPortalView. Backed by CAPortalLayer, it can project the rendered result of a sourceView to another location on the screen in real time, without duplicating the View hierarchy or repeatedly generating snapshots. Compared with static snapshots, Portal is more like a “live window” at the compositing layer: the source view remains the single source of state, while changes to text, animations, layout, or subviews can be reflected synchronously elsewhere.
The article also connects _UIPortalView with Liquid Glass-style effects: through matchesPosition, clipping, offsets, and 3D transforms, it can achieve real-time mirroring, reflections, lenses, shared backgrounds, edge distortion, and other effects.
Taking control of toolbar items in SwiftUI
The new SwiftUI Toolbar APIs introduced at WWDC 26 strike a better balance between system adaptivity and explicit developer control. In this article, Majid Jabrayilov introduces several new control capabilities: using visibilityPriority to specify the display priority of toolbar items, explicitly creating collapsed menus with ToolbarOverflowMenu, pinning important actions to the trailing edge of the top bar with .topBarPinnedTrailing, and using toolbarMinimizeBehavior to control how the navigation bar, tab bar, bottom bar, and others minimize during scrolling.
The same set of toolbar items may be presented differently on iOS, iPadOS, and macOS. The value of the new APIs is that they do not undermine the original cross-platform adaptive nature of SwiftUI Toolbar, while still allowing developers to express more clearly which actions should be shown first, which actions can be intentionally placed into overflow, and how toolbars should respond to scrolling.
Tools
iOS-Simulator-Camera-Extend: Adding a “Truly Usable Camera” to iOS Simulator
iOS Simulator has long lacked real camera capabilities. Features involving QR code scanning, OCR, faces, video calls, or AVCaptureSession often require a physical device or mocked logic. Developed by Shuyu Guo, iOS-Simulator-Camera-Extend recreates the core idea of SimCam: through a macOS-side frame source, DYLD_INSERT_LIBRARIES hooks inside Simulator, and AVFoundation swizzling, the app under test can access the Mac camera, desktop, images, videos, and QR code feeds in the simulator without code changes or a different bundle id.
Even more interestingly, it also provides another path based on a CMIO System Extension, allowing macOS apps such as QuickTime, FaceTime, Zoom, and OBS to see a SimCam Virtual Camera. In other words, the same frame source can be fed both to an app running inside iOS Simulator and used as a macOS virtual camera, making it very useful for debugging, demonstrations, and automated testing of camera-related features.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
SPI 加入 Apple，Swift 迈向自举
几天前，Swift Package Index（SPI）宣布已加入 Apple。双方将共同建设一个面向 Swift 开发者的综合 package registry；与此同时，SPI 现有的包发现、兼容性检查、文档托管等能力仍会继续提供，包作者在短期内也无需调整现有的发布流程。
这也让 #135 中“SwiftPM 才刚到第二章”的判断得到了新的注脚：CocoaPods 的退场只是把 SPM 推上了默认位置，而 SPI 加入 Apple，才真正揭开了 Swift 包生态基础设施建设的下一幕。
如果说 SwiftPM 解决的是“能不能方便地依赖包”，SPI 解决的是“能不能找到并评估包”，那么这次加入 Apple 则把问题进一步推进到了“能不能可信地发布、识别和分发包”。从中期来看，有三点尤其值得观察：
SPI 将从第三方索引服务，演进为官方 package registry 的重要入口；
Swift 包生态可能逐步降低对 GitHub 作为托管、分发与身份来源的隐性依赖；
Xcode 有机会与 SPI 的搜索、兼容性检查和文档能力建立更紧密的集成。
上周，另一件让 Swift 开发者振奋的事情是，Erik Eckstein 在 Swift 论坛上宣布，Swift 项目将取消“必须能够仅使用 C++ 宿主工具链构建编译器”的要求。换句话说，从 main 分支开始，构建 Swift 编译器将需要已有的 Swift 工具链参与；这也使得编译器中那些过去必须保持 C++ 实现的强制路径，现在可以逐步用 Swift 编写。官方提到的范围包括 Parser、AST、Type Checker，以及 mandatory SIL passes 等核心部分。
这并不意味着 Swift 编译器已经完全用 Swift 重写，也不意味着 C++ parser 会马上消失。更准确地说，这是 Swift 编译器迈向自举和自托管的重要门槛：Swift 不再只是用于外围工具、可选功能或个别优化 pass，而是可以进入编译器的核心路径。
自举本身并不能简单证明一门语言能力的高低，但它代表了一种工程成熟度：语言、编译器、标准库、包管理器和跨平台构建系统，是否已经强大到足以支撑自身的持续演进。对于一个希望在 Apple 平台之外继续扩展影响力的语言来说，这一步的象征意义和实际价值都不小。
把 SPI 加入 Apple 与 Swift 编译器迈向自托管放在一起看，会发现它们指向的是同一件事：Swift 正在补齐生态基础设施。前者关乎包的发现、身份、签名和可信分发，后者则提升了语言工具链自身的可维护性与演进能力。Swift 能否真正破圈，关键并不只在于 Apple 在其中拥有多大的影响力，而在于 Apple 与 Swift 社区是否能持续展现开放、进取的态度，并把工具链、包生态和跨平台体验打磨到足够完整。就这两件事而言，我愿意保持乐观。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。
近期推荐
在 Apple II 上跑 Swift (Bring Swift to The APPLE II)
Apple II 是苹果早期最重要的产品之一，至今仍影响着许多开发者。很多人都曾在它上面使用 BASIC 或 Apple Pascal，但如果在这台机器上写 Swift，又会是什么体验？Yeo Kheng Meng 实现了一个 Swift 风格的迷你开发环境 SwiftII，让一台搭载 1 MHz 6502 CPU、64 KB 级别内存的老机器也能编写和运行类似 Swift 的程序。
文章精彩的地方不只是“让 Apple II 跑上类 Swift 语言”，还包括大量围绕硬件限制的工程取舍：有限的内存空间、语言卡和 ProDOS 的冲突、不同 Apple II 机型的键盘与显示差异，以及为什么最终要拆成多张磁盘镜像发布。作者也坦诚分享了 AI 辅助开发的过程。即便有 Claude Code 和 Codex 的帮助，关键的架构取舍、范围控制和硬件测试策略仍然需要作者自己把关。本文既有复古计算机的工程细节，也有现代语言设计在极小环境中的取舍。
基于 WebAssembly 实现 Swift App 热更新 (Building an over-the-air update system for native Swift with WebAssembly, from scratch)
为原生 Swift iOS App 构建 OTA 更新机制，是一个有争议但也很有价值的方向。Jack Solomon 在这篇文章中展示了基于 WebAssembly 的实现思路：将 Swift 函数编译成 WASM，再通过 WasmKit 在 iOS App 内加载执行，随后从服务器下载新的 WASM 模块，让 App 在不重新构建、不替换已签名二进制的情况下改变运行结果。
文章拆解了 Swift to WASM 的工具链、WASI、@_cdecl 导出、reactor module、线性内存传参，以及 SwiftUI 视图热更新为什么需要 dynamic replacement 和可序列化的视图描述树。Jack 也将这套思路包装成了 Swift SDK：patch-swift。
需要注意的是，这类方案触及 App Store 审核规则中关于下载和执行代码的边界，实际使用时仍需要谨慎评估场景和合规风险。
理解 SwiftUI 的底层核心：属性图 (SwiftUI Is One Graph)
Mihaela Mihaljević Jakić 在过去一周连续发表了两篇关于 SwiftUI 底层机制的长文，值得放在一起阅读。第一篇 SwiftUI Is One Graph 从实际行为和 Apple 专利出发，解释 SwiftUI 并不是简单的 View Tree diff，而更像是一个 demand-driven attribute graph：View struct 本身只是可丢弃的描述，真正持续存在的是属性图，以及其中的状态、依赖、布局和动画传播。
第二篇 《The SwiftUI Oracle: Measuring a Clean Room Against the Real Thing》则进一步展示了如何验证这种理解。作者实现了一个不依赖 SwiftUI 的 clean-room 引擎 PureView，再把真实 SwiftUI 当作 oracle，通过布局、动画、像素渲染等 differential testing 去验证自己的模型。
Mihaela 的工作流对 AI agent 很有启发。Agent 不需要只靠语言模型去猜 SwiftUI 行为是否正确，而是可以生成或修改实现，然后运行测试，让真实 SwiftUI 给出可比较的结果。这种类似“单元测试”的反馈闭环，能把对黑盒框架的理解变成可以持续验证和迭代的工程信号。
在 SwiftUI 中实现可拦截回调的菜单与选择器 (SwiftUI: Intercept-able Picker / Menu / Context Menu)
很多场景下，开发者都希望能在 Menu、Picker、contextMenu 等组件弹出前执行一些同步操作，比如统计打开次数、更新状态，或者临时决定是否允许展示。但 SwiftUI 并没有提供对应的回调。Itsuki 在这篇文章中分享了自己的实现思路：通过桥接一个承载 SwiftUI 内容的原生 View，在对应手势触发时先执行 menuWillOpen，再决定是否使用 NSMenu.popUpContextMenu 等 AppKit API 主动展示菜单。
本文再次体现了 SwiftUI 的一个现实问题：很多看似简单的交互控制，一旦超出系统 modifier 暴露的能力，仍然需要理解底层 AppKit / UIKit 才能真正解决。
解析 UIPortalView：从视图实时投影到流体玻璃特效 (_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects)
Artem Mirzabekian 分享了 UIKit 中一个有趣的私有组件 _UIPortalView。它由 CAPortalLayer 支持，可以把某个 sourceView 的渲染结果实时投射到屏幕上的另一个位置，而不需要复制一份 View 层级，也不需要反复生成 snapshot。相比静态快照，Portal 更像是合成层上的“实时窗口”：源视图仍然是唯一状态来源，而文本、动画、布局或子视图变化都可以同步反映到另一处显示。
文章还把 _UIPortalView 和 Liquid Glass 效果联系起来：通过 matchesPosition、裁剪、偏移和 3D transform，可以实现实时镜像、反射、镜头、共享背景和边缘扭曲等效果。
掌控 SwiftUI 工具栏新 API (Taking control of toolbar items in SwiftUI)
WWDC 26 带来的新 SwiftUI Toolbar API，让系统自适应和开发者显式控制之间取得了更好的平衡。Majid Jabrayilov 在这篇文章中介绍了几项新的控制能力：通过 visibilityPriority 指定 toolbar item 的显示优先级，用 ToolbarOverflowMenu 明确创建折叠菜单，借助 .topBarPinnedTrailing 将重要操作固定在顶部栏尾部，以及使用 toolbarMinimizeBehavior 控制导航栏、标签栏、底部栏等在滚动时的最小化行为。
同一组 toolbar items 在 iOS、iPadOS 和 macOS 上可能会有不同的展示方式。新 API 的价值在于，它们没有破坏 SwiftUI Toolbar 原本的跨平台自适应能力，却让开发者可以更明确地表达哪些操作应该优先显示、哪些操作可以主动放进 overflow，以及工具栏应该如何响应滚动。
工具
iOS-Simulator-Camera-Extend：给 iOS Simulator 补上“真实可用的相机”
iOS Simulator 一直没有真正的相机能力，涉及扫码、OCR、人脸、视频通话、AVCaptureSession 的功能，往往只能上真机或写模拟逻辑。由 Shuyu Guo 开发的 iOS-Simulator-Camera-Extend 复刻了 SimCam 的核心思路，通过 macOS 端帧源、Simulator 内 DYLD_INSERT_LIBRARIES hook 与 AVFoundation swizzle，让被测 App 无需改代码、无需换 bundle id，就能在模拟器里拿到 Mac 摄像头、桌面、图片、视频和二维码画面。
更有意思的是，它还提供了另一条 CMIO System Extension 链路，让 QuickTime、FaceTime、Zoom、OBS 等 macOS 应用也能看到一台 SimCam Virtual Camera。也就是说，同一份帧源既可以喂给 iOS Simulator 里的 App，也可以作为 macOS 虚拟摄像头使用，对相机相关功能的调试、演示和自动化测试都很实用。