跪拜 Guibai
← Back to the summary

SPI Joins Apple and Swift Drops Its C++ Bootstrapping Requirement

SPI Joins Apple, Swift Moves Toward Bootstrapping

A few days ago, the Swift Package Index (SPI) announced it has joined Apple. The two parties will jointly build a comprehensive package registry for Swift developers; at the same time, SPI's existing capabilities for package discovery, compatibility checking, and documentation hosting will continue to be provided, and package authors will not need to adjust their existing publishing workflows in the short term.

This also adds a new footnote to the judgment in #135 that "SwiftPM has only just reached Chapter Two": the exit of CocoaPods merely pushed SPM into the default position, while SPI joining Apple truly opens the next act in building the infrastructure of the Swift package ecosystem.

If SwiftPM solves the problem of "can we conveniently depend on packages," and SPI solves the problem of "can we find and evaluate packages," then this move to join Apple pushes the question further to "can we trustworthily publish, identify, and distribute packages." In the medium term, three points are particularly worth observing:

Last week, another piece of news that excited Swift developers was Erik Eckstein's announcement on the Swift forums that the Swift project will drop the requirement of "must be able to build the compiler using only a C++ host toolchain." In other words, starting from the main branch, building the Swift compiler will require an existing Swift toolchain to participate; this also means that those mandatory paths in the compiler that previously had to remain implemented in C++ can now gradually be written in Swift. The scope mentioned by the officials includes core parts such as the Parser, AST, Type Checker, and mandatory SIL passes.

This does not mean the Swift compiler has been completely rewritten in Swift, nor does it mean the C++ parser will disappear immediately. More accurately, this is an important threshold for the Swift compiler moving toward bootstrapping and self-hosting: Swift is no longer just for peripheral tools, optional features, or individual optimization passes, but can enter the core paths of the compiler.

Bootstrapping itself cannot simply prove the capability of a language, but it represents a kind of engineering maturity: whether the language, compiler, standard library, package manager, and cross-platform build system are powerful enough to support their own continuous evolution. For a language that hopes to expand its influence beyond the Apple platform, the symbolic significance and practical value of this step are considerable.

Looking at SPI joining Apple and the Swift compiler moving toward self-hosting together, it becomes clear they point to the same thing: Swift is completing its ecosystem infrastructure. The former concerns the discovery, identity, signing, and trusted distribution of packages, while the latter enhances the maintainability and evolution capability of the language toolchain itself. Whether Swift can truly break out of its circle depends not only on how much influence Apple holds within it, but on whether Apple and the Swift community can continuously demonstrate an open and enterprising attitude, and polish the toolchain, package ecosystem, and cross-platform experience to a sufficiently complete state. Regarding these two matters, I am willing to remain optimistic.

This Issue | Previous Issue | All Weekly Issues

Recent Recommendations

Running Swift on an Apple II (Bring Swift to The APPLE II)

The Apple II is one of Apple's most important early products and still influences many developers today. Many people have used BASIC or Apple Pascal on it, but what would the experience be like to write Swift on this machine? Yeo Kheng Meng implemented a Swift-style mini development environment called SwiftII, allowing an old machine with a 1 MHz 6502 CPU and 64 KB-level memory to write and run Swift-like programs.

The brilliance of the article is not just "getting an Apple II to run a Swift-like language," but also includes a large number of engineering trade-offs around hardware limitations: limited memory space, conflicts between the language card and ProDOS, keyboard and display differences across different Apple II models, and why it ultimately had to be split across multiple disk images for release. 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 required the author's own oversight. This article contains both the engineering details of retro computing and the trade-offs of modern language design in an extremely constrained environment.

Building an OTA Update System for Native Swift with WebAssembly (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 also very valuable direction. Jack Solomon demonstrates an implementation approach based on WebAssembly in this article: compile Swift functions into WASM, load and execute them within an iOS App via 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 dissects the Swift to WASM toolchain, WASI, @_cdecl exports, reactor modules, linear memory parameter passing, and why dynamic replacement and a serializable view description tree are needed for SwiftUI view hot updates. Jack has 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 regarding downloading and executing code, and the specific scenarios and compliance risks still need to be carefully evaluated in actual use.

Understanding the Core of SwiftUI: The Attribute Graph (SwiftUI Is One Graph)

Mihaela Mihaljević Jakić published two long articles on the underlying mechanisms of SwiftUI over the past week, which are worth reading together. The first, SwiftUI Is One Graph, starts from actual behavior and Apple patents to explain that SwiftUI is not a simple View Tree diff, but more like a demand-driven attribute graph: the View struct itself is just a discardable description, and what truly persists is the attribute graph, along with the state, dependencies, layout, and animation propagation within it.

The second article, "The SwiftUI Oracle: Measuring a Clean Room Against the Real Thing," further demonstrates how to verify this understanding. The author implemented a clean-room engine called PureView that does not depend on SwiftUI, and then used real SwiftUI as an oracle to validate her model through differential testing of layout, animation, pixel rendering, etc.

Mihaela's workflow is very inspiring for AI agents. An agent does not need to rely solely on a language model to guess whether SwiftUI behavior is correct; instead, it can generate or modify an implementation, then run tests, allowing the real SwiftUI to provide comparable results. This feedback loop, similar to "unit testing," can turn the understanding of a black-box framework into an engineering signal that can be continuously verified and iterated upon.

Implementing Interceptable Callbacks for Menus and Pickers in SwiftUI (SwiftUI: Intercept-able Picker / Menu / Context Menu)

In many scenarios, developers wish to execute some synchronous operations before components like Menu, Picker, or contextMenu pop up, such as counting opens, updating state, or temporarily deciding whether to allow display. But SwiftUI does not provide corresponding callbacks. Itsuki shares her implementation approach in this article: by bridging a native View that hosts SwiftUI content, executing menuWillOpen first when the corresponding gesture is triggered, and then deciding whether to use AppKit APIs like NSMenu.popUpContextMenu to actively display the menu.

This article once again reflects a practical problem with SwiftUI: many seemingly simple interaction controls, once they exceed the capabilities exposed by system modifiers, still require understanding the underlying AppKit/UIKit to truly solve.

Analyzing UIPortalView: From Live View Mirroring to Liquid Glass Effects (_UIPortalView: From Live Mirroring to Liquid Glass-Style Effects)

Artem Mirzabekian shares an interesting private component in UIKit called _UIPortalView. Backed by CAPortalLayer, it can project the rendering result of a sourceView to another location on the screen in real-time, without needing to duplicate a View hierarchy or repeatedly generate snapshots. Compared to static snapshots, Portal is more like a "live window" on the compositing layer: the source view remains the sole source of truth, and text, animation, layout, or subview changes can be synchronously reflected in another display location.

The article also connects _UIPortalView with Liquid Glass effects: through matchesPosition, clipping, offset, and 3D transforms, effects like live mirroring, reflections, lenses, shared backgrounds, and edge warping can be achieved.

Mastering the New SwiftUI Toolbar API (Taking control of toolbar items in SwiftUI)

The new SwiftUI Toolbar API brought by WWDC 26 achieves a better balance between system adaptation and explicit developer control. Majid Jabrayilov introduces several new control capabilities in this article: specifying the display priority of toolbar items via visibilityPriority, explicitly creating overflow menus with ToolbarOverflowMenu, pinning important actions to the trailing edge of the top bar using .topBarPinnedTrailing, and controlling the minimization behavior of navigation bars, tab bars, bottom bars, etc., during scrolling using toolbarMinimizeBehavior.

The same set of toolbar items may display differently on iOS, iPadOS, and macOS. The value of the new APIs lies in the fact that they do not break the original cross-platform adaptive capabilities of the SwiftUI Toolbar, yet allow developers to more explicitly express which actions should be displayed with priority, which actions can be proactively placed into overflow, and how the toolbar should respond to scrolling.

Tools

iOS-Simulator-Camera-Extend: Giving the iOS Simulator a "Truly Usable Camera"

The iOS Simulator has never had real camera capabilities; features involving barcode scanning, OCR, face recognition, video calls, and AVCaptureSession often require a real device or writing simulation logic. iOS-Simulator-Camera-Extend, developed by Shuyu Guo, replicates the core idea of SimCam. Through a macOS-side frame source, DYLD_INSERT_LIBRARIES hook inside the Simulator, and AVFoundation swizzling, it allows the app under test to access the Mac camera, desktop, images, videos, and QR code feeds within the simulator without modifying code or changing the bundle ID.

Even more interestingly, it also provides another CMIO System Extension path, allowing macOS applications like QuickTime, FaceTime, Zoom, and OBS to see a SimCam Virtual Camera. That is to say, the same frame source can be fed to both the app inside the iOS Simulator and used as a macOS virtual camera, which is very practical for debugging, demonstration, and automated testing of camera-related functions.

Previous Issues

💝 Support and Feedback

If this weekly issue was helpful to you, please:

🚀 Expand Your Swift Horizons

  • 📮 Email Subscription | weekly.fatbobman.com Get exclusive technical insights
  • 👥 Developer Community | Discord Real-time exchange of development experience
  • 📚 Original Tutorials | fatbobman.com Learn Swift/SwiftUI best practices