Fatbobman's Swift Weekly #142
SPI Joins Apple, and Swift Moves Toward Self-HostingA 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:
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 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 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 ☕️ Recent RecommendationsBring Swift to The APPLE IIThe 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 scratchBuilding 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,
SwiftUI Is One GraphMihaela 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.
SwiftUI: Intercept-able Picker / Menu / Context MenuIn many scenarios, developers want to perform some synchronous operation before components such as
_UIPortalView: From Live Mirroring to Liquid Glass-Style EffectsArtem Mirzabekian shared an interesting private UIKit component, The article also connects Taking control of toolbar items in SwiftUIThe 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 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. ToolsiOS-Simulator-Camera-Extend: Adding a “Truly Usable Camera” to iOS SimulatoriOS Simulator has long lacked real camera capabilities. Features involving QR code scanning, OCR, faces, video calls, or 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 则把问题进一步推进到了“能不能可信地发布、识别和分发包”。从中期来看，有三点尤其值得观察：
上周，另一件让 Swift 开发者振奋的事情是，Erik Eckstein 在 Swift 论坛上宣布，Swift 项目将取消“必须能够仅使用 C++ 宿主工具链构建编译器”的要求。换句话说，从 这并不意味着 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、
理解 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 去验证自己的模型。
在 SwiftUI 中实现可拦截回调的菜单与选择器 (SwiftUI: Intercept-able Picker / Menu / Context Menu)很多场景下，开发者都希望能在
解析 UIPortalView：从视图实时投影到流体玻璃特效 (_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects)Artem Mirzabekian 分享了 UIKit 中一个有趣的私有组件 文章还把 掌控 SwiftUI 工具栏新 API (Taking control of toolbar items in SwiftUI)WWDC 26 带来的新 SwiftUI Toolbar API，让系统自适应和开发者显式控制之间取得了更好的平衡。Majid Jabrayilov 在这篇文章中介绍了几项新的控制能力：通过 同一组 toolbar items 在 iOS、iPadOS 和 macOS 上可能会有不同的展示方式。新 API 的价值在于，它们没有破坏 SwiftUI Toolbar 原本的跨平台自适应能力，却让开发者可以更明确地表达哪些操作应该优先显示、哪些操作可以主动放进 overflow，以及工具栏应该如何响应滚动。 工具iOS-Simulator-Camera-Extend：给 iOS Simulator 补上“真实可用的相机”iOS Simulator 一直没有真正的相机能力，涉及扫码、OCR、人脸、视频通话、 更有意思的是，它还提供了另一条 CMIO System Extension 链路，让 QuickTime、FaceTime、Zoom、OBS 等 macOS 应用也能看到一台 SimCam Virtual Camera。也就是说，同一份帧源既可以喂给 iOS Simulator 里的 App，也可以作为 macOS 虚拟摄像头使用，对相机相关功能的调试、演示和自动化测试都很实用。 Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
