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.
Original
From 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 horizontalSizeClass, are no longer suitable as the primary indicator of window width. So, is this change a sudden shift in direction, or the inevitable result of Apple’s years-long evolution of its layout system? This article explores that question.
Recent Recommendations
Swift 6.4: What’s New in Concurrency
In this article, Antoine van der Lee reviews a series of improvements Swift 6.4 brings to concurrency, including support for asynchronous cleanup in defer, cancellation shields that ensure critical cleanup or rollback operations can finish, warnings for ignored throwing Task instances, and typed error support for Task. In addition, Result can now directly wrap asynchronous throwing operations, while ~Sendable and the weak let introduced in Swift 6.3 make the modeling of Sendable types more precise.
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 Kernel
Swift 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 iOS
What 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 SwiftUI
Imagine 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 Locale, then reading it through a custom FormatStyle when Text is actually rendered. This approach works around SwiftUI’s lack of a dynamic Text initializer and turns logic that could easily be forgotten at individual call sites into application-wide default behavior.
SwiftUI SensoryFeedback Cache Key Pitfall: Do Not Store Continuous Values
Can 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 intensity in the feedback generator’s cache key. Every tiny change in intensity could therefore correspond to a new UIImpactFeedbackGenerator instance, causing the cache to grow continuously.
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 FeedbackType from the per-play dynamic parameters stored in the new Payload. The public API remains unchanged, but the cache behavior is corrected at the data-model level.
What makes this fix worth studying is not merely that it resolves the memory-growth issue, but that it demonstrates an important principle of API design: stable information describing an object’s identity should not be mixed with dynamic parameters that affect only a single operation. It also reminds us that simply conforming to
Hashabledoes not make a type inherently suitable for use as a cache key. Rather than repeatedly excluding exceptional fields at the point of use, drawing clear semantic boundaries in the data model is usually the more reliable design.
Architecting a Conversion Engine in Swift
When 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 Concession to explicitly record formatting that was downgraded, content that was dropped, or data that was truncated during conversion, rather than pretending that every conversion can be lossless.
Tools
SwiftOS: Building a Real Operating System with Embedded Swift
SwiftOS 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.
We may still need more time before Swift is widely used within Apple’s operating system kernels. But SwiftOS proves at least one thing: Embedded Swift is no longer limited to firmware and bare-metal examples. It is capable of supporting an operating system with process isolation, user-space programs, a network stack, and real service workloads.
Loupe: Giving AI Agents Runtime Evidence for Native Apple UIs
Loupe, 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 tap, swipe, drag, and type, and record before-and-after snapshots, diffs, and traces. It can also make probe-like runtime changes to selected UIKit properties and constraints, quickly verify whether an adjustment works, and then return to the source code to implement the actual fix. This turns questions such as “Does it look right?”, “Does the interaction work?”, and “Has the layout drifted?” from screenshot-driven guesswork into a reviewable and reproducible chain of evidence.