Those Who Swift - Issue 280

This week’s articles share a common thread: frameworks can change significantly beneath APIs that look exactly the same.

SwiftUI’s compiler performance is improving, @State has a new underlying implementation, and developers are still debating whether the framework’s long-standing limitations are acceptable. Together, these pieces show why understanding the mechanism—not just the API—often leads to faster debugging and better engineering decisions.

Have you ever had to investigate a SwiftUI or UIKit behavior that the documentation couldn’t explain? Hit reply—I’d love to hear what you found.

with Divya Ravi — Technical Editor, iOS engineer

Seven years after its introduction, SwiftUI still asks developers to trust a considerable amount of hidden machinery. This week’s reading made a strong case for looking beneath that abstraction.

Start with ContentBuilder. Apple introduced it at WWDC26 as a way to improve SwiftUI type-checking performance. But as Fatbobman explains, the improvement does not come from adding another builder type. It comes from restructuring the shared builder APIs used by containers such as Group and ForEach.

By relying on TupleContent and deferred conditional conformance, SwiftUI gives the type checker less work to perform. The code developers write remains largely unchanged, while the compiler does substantially less work behind the scenes.

That distinction matters. When build performance improves without an obvious source change, it is easy to treat it as compiler magic. Understanding the implementation gives us something more useful: a clearer mental model for why certain view structures are expensive and why newer APIs may compile faster.

A similar change is happening with @State.

Stewart Lynch found that in Xcode 27, @State is implemented as a macro rather than a property wrapper. The syntax remains familiar, but the initialization behavior changes in an important way.

Previously, the initializer expression could be evaluated during every view recreation, even when SwiftUI ultimately preserved the existing state value. With the macro implementation, that expression is evaluated lazily.

For a simple integer or Boolean, the difference is unlikely to matter. For state initialized through a database lookup, file operation, or expensive computation, it can eliminate work that developers may not have realized was happening.

These two changes approach the same problem from different directions. ContentBuilder improves compiler behavior beneath a stable API, while the new @State implementation changes the underlying mechanism without changing how the declaration looks. Both improvements are nearly invisible unless someone profiles the behavior, examines the generated code, or asks why the result changed.

That brings us to Yakov Manshin’s “SwiftUI After 7 Years: A Story of Mediocrity,” a deliberately sharp retrospective that generated more than 300 comments on Hacker News.

His central argument is difficult to dismiss completely: after seven years, “it is still a young framework” becomes a less convincing explanation for persistent problems. Focus management, drag-and-drop, platform inconsistencies, and difficult edge cases have survived several release cycles.

I do not agree with every conclusion in the article, but the larger tension is real. SwiftUI’s internals continue to improve, while some visible limitations remain stubbornly familiar.

Those are separate measures of maturity. Compiler performance can improve dramatically while developers still struggle with basic interactions. A framework can gain powerful new APIs without resolving gaps in older ones. When we say SwiftUI has come a long way, it is worth being precise about which part of SwiftUI we mean.

Chang-Jui Lin’s article on building an EPUB reader with CoreText offers a practical counterpoint. Instead of adapting a WebView or relying on a higher-level text component, Lin built directly on CoreText to support reflowable content, fixed layouts, media overlays, and bidirectional text.

It is a much lower level of abstraction—and a much larger engineering commitment. But it also provides the control required for a problem that higher-level frameworks do not solve cleanly.

That is not an argument for rebuilding every framework primitive. Most abstractions are valuable precisely because they prevent us from owning that complexity. But when an abstraction becomes the constraint, understanding the layer below it can reveal options that are otherwise easy to miss.

The broader lesson from this week is not that SwiftUI is good or bad. It is that no framework should remain a complete black box.

The engineers who diagnose difficult problems fastest are often the ones willing to inspect the generated code, profile the rebuild, trace the macro expansion, or move down the stack when the current abstraction stops being useful.

Frameworks will continue to improve while retaining frustrating gaps—sometimes within the same release. The durable skill is learning how to investigate what the framework is actually doing. That understanding makes debugging faster, design decisions clearer, and point-release surprises far less surprising.

What is the last SwiftUI, UIKit, or Swift behavior you had to reverse-engineer because the documentation did not explain enough?

An investigation into how Apple improved SwiftUI type-checking performance through TupleContent, shared builder APIs, and deferred conditional conformance. A useful read if you want to understand what changed beneath the WWDC26 performance claims.

📍Level: Advanced

A focused demonstration of @State becoming a macro in Xcode 27. The new implementation lazily evaluates its initializer, avoiding unnecessary work when SwiftUI recreates a view.

📍Level: Intermediate

A critical assessment of SwiftUI’s maturity and the framework limitations that remain after seven years. You may not agree with every argument, but it is a useful prompt to reconsider which rough edges we have started treating as normal.

📍Level: Advanced

A detailed look at implementing EPUB 3 rendering directly with CoreText, including reflowable text, fixed layouts, media overlays, and bidirectional content. It shows both the control and the complexity involved in owning a native text-rendering pipeline.

📍Level: Advanced

A real-time debugging log of SwiftUI buttons that quietly stop responding inside a horizontal ScrollView — fixed, but still without a clear answer for why. A fitting closer for this week's theme: sometimes going under the hood just leaves you with a better mystery.

📍Level: Intermediate

A first-person debugging story showing why a button’s label and background can animate independently — and how ZStack, drawingGroup, compositingGroup, and geometryGroup each solve (or half-solve) the problem for different reasons. A concrete companion to this week’s “nothing is as simple as it looks” theme.

📍Level: Intermediate

The latest across Swift, Apple, AI, and the community.

Researchers document a WebKit issue that can expose a user’s real IP address and DNS queries while using proxy-based browsers or iCloud Private Relay. Important context for teams making privacy guarantees around WebKit-based experiences.

📍Level: Intermediate

A practical implementation of Server-Sent Events using URLSession.bytes(for:), along with a small test server. Particularly useful for apps consuming AI responses or other incrementally delivered data.

📍Level: Intermediate

StructuredQueries 0.35 introduces schema-checked support for JSON and JSONB data in SQLite. The article shows how to retain type safety while working with semi-structured local data.

📍Level: Advanced

A concise guide to the Top Functions view in Xcode 26.4’s profiling instruments. Sorting by self-weight and inspecting flame graphs can make it much easier to identify where execution time is actually being spent.

📍Level: Intermediate

Command-line steps for installing simulator runtimes when Xcode 27 beta remains stuck on “fetching download information.” A useful workaround to keep nearby when the graphical installer fails.

📍Level: Intermediate

A clear explanation of Sendable types and @Sendable closures, with examples showing how values move safely across concurrency boundaries. A solid reference when working through Swift 6 strict-concurrency warnings.

📍Level: Intermediate

Explores SwiftUI toolbar placement, customization, and platform-specific behavior. Helpful for interfaces where the default toolbar layout does not provide enough control or consistency.

📍Level: Intermediate

Apple previews new creative and marketing asset options for App Store product pages. Worth reviewing before planning your next product-page update or launch campaign.

The latest TestFlight release notes, covering recent changes to Apple’s beta-distribution workflow. A quick check before your next external-testing cycle may save some surprises.

A hands-on guide to connecting Cursor to Xcode 27 through Agent Client Protocol support. It offers an early look at how external coding agents can participate directly in an Xcode-based workflow.

📍Level: Intermediate

A practical fix for tracking token usage across Codex/Claude coding-agent sessions without hitting replay errors — useful if AI agents are part of your build pipeline, even outside the Swift/iOS-specific tooling this newsletter usually covers.

📍Level: Intermediate

A practical guide to capturing VoiceOver audio for accessibility testing, bug reports, and demos. iOS supports the workflow through screen recording, while macOS requires a virtual-audio device.

📍Level: Intermediate

Makes the case that open-sourcing SwiftUI could help developers diagnose and address long-standing issues such as keyboard focus and drag-and-drop. Even if the proposal feels unlikely, the argument raises useful questions about framework transparency and community participation.

📍Level: Intermediate

Thanks for reading Those Who Swift!

Subscribe for free to receive new posts. 👇