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.
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.