SwiftUI 小组实验室

Engineers from the SwiftUI team introduce themselves and set up a session covering SwiftUI architecture, view identity and updates, performance and view invalidation, the ContentBuilder change, navigation and scroll APIs, lazy layouts, and concurrency with @Observable and @State.

SwiftUI doesn't prescribe an architecture — it's designed to be architecture-agnostic, so use whatever pattern fits your app. @Observable helps here: it can model your data in AppKit/UIKit today and eases the transition to SwiftUI, and it's plain Swift not tied to any UI framework. If your chosen architecture integrates poorly or feels awkward passing data around, file feedback so the team can improve the ergonomics.

Both are valid; the choice is about clarity more than raw performance. Breaking a large body into smaller pieces makes views easier to reason about — a separate view struct gives SwiftUI a distinct identity and its own dependency tracking, so it can update independently, while a @ViewBuilder computed property is inlined into the parent and re-evaluates with it. Prefer separate view types when a subsection has its own state or should update on its own.

A frequently cited one is overusing GeometryReader — audit where you use it and prefer the Layout protocol (introduced a few years ago) where possible. More broadly, watch for patterns that cause excessive view invalidation. The framing the team prefers is less "anti-pattern" and more knowing the idiomatic right way to express layout and state.

The hidden part is how SwiftUI updates via an internal graph — nodes represent views and edges represent their inputs (dependencies). SwiftUI uses that structure to determine which parts of your hierarchy need to update when data changes. Understanding that your view's inputs define its update behavior is the mental model that unlocks most performance and correctness questions.

UIKit relied on cell reuse mainly because views are reference types allocated on the heap, so every row carried a fixed allocation cost plus the overhead of inserting and removing it from the hierarchy. SwiftUI doesn't have that same problem, so you generally don't need to reach for a hosted UICollectionView. Lazy stacks and grids also bring real advantages: implicit prefetching starts evaluating the view bodies of cells about to scroll on screen, and because the view graph is made of individual nodes, SwiftUI can partially evaluate the next cell in the time left after rendering the current frame, then pause right before the next frame. One performance caveat: reconfiguring a cell's state in onAppear can change its size and force it to lay out again, throwing away that prefetched work — so do that setup in the initializer rather than in body or onAppear. As with onChange, prefer letting your data model drive changes, since both onChange and onAppear live in the view body and force it to recompute.

See the What's New in SwiftUI talk for a visual walkthrough. The change reworks how the result builder is structured so the compiler type-checks builder content more efficiently, reducing the combinatorial type-checking cost that could make large view bodies slow to compile — without changing how you write your views.

The recommended path is the SwiftUI Instrument, which visualizes updates and shows which views are re-evaluating and why. Self._printChanges remains a handy quick check for what caused a view to update; the underscore signals it's a debugging aid rather than stable API. Use the Instrument for systematic investigation of over-updating.

ContentBuilder and ViewBuilder are effectively the same — ContentBuilder is a type alias — so existing @ViewBuilder code keeps working unchanged. The one meaningful difference is reach: ContentBuilder can be used outside of views, so you can build your own SwiftUI-like DSLs and result-builder-based building blocks that aren't SwiftUI views. If you don't need that, there's nothing you have to change.

SwiftUI runs your view updates on the main actor, so @State and view body evaluation happen on the main thread by default — that's the anchor. Concurrency is about moving work off the main actor and bringing results back. You don't need to master @State's internal storage; the model is: UI state lives on the main actor, do async work elsewhere, and update that state back on the main actor.

It depends on your app's needs, but iOS 27 adds a new SwiftUI API for customizing navigation transitions, with built-in support for cross-fades and other custom transitions. If those cover your case, stay in SwiftUI; only reach for UIKit interop when you need a transition the new API doesn't support.

There are a few APIs depending on what you need: the onGeometryChange modifier, scroll effects (which offload work and are more efficient in some cases), and the scrollPosition modifier to know which item is currently on screen. Treat the raw content offset as an implementation detail — with lazy stacks it's only estimated from off-screen view heights and has no reliable semantic meaning — and instead trigger changes relative to the views actually on screen. There's also an API (covered in Rens' talk) for tracking what percentage of a view is visible, which is ideal for analytics or impression tracking. And a common way to build infinite scrolling is to put a view at the bottom of the list whose onAppear tells your networking layer to fetch more data.

Not today — there's no protocol for describing a custom lazy layout; the Layout protocol is eager. If this matters for your use case, file a Feedback request with details, since developer demand helps prioritize adding it.

Too much invalidation cascading from the top. A frequent cause is putting something high in the environment that many downstream views read — when it changes, everything observing it re-evaluates. Scope state so changes invalidate only the views that actually depend on them, rather than triggering wide downstream updates.

SwiftUI operates on the main actor, so state that views read is exercised on the main thread. Rather than annotating every property, let UI-facing state live on the main actor by default and only move computation off it deliberately. Decide where state lives based on who uses it: keep view-driving @Observable state main-actor-aligned, and isolate background work separately.

Prefer keeping type information over erasing it with AnyView. Use @ViewBuilder and an associated type (some View) on your protocol, or opaque return types, so the concrete view type stays hidden across module boundaries without paying AnyView's cost. Reserve AnyView for cases where you genuinely need heterogeneous, type-erased views.

They serve different purposes. compositingGroup isn't primarily a performance tool — it flattens a subtree so visual effects apply to it as a whole. drawingGroup rasterizes content off-screen (via Metal), which can help with complex static visuals but costs memory and isn't free, so measure before using. geometryGroup isolates geometry changes so animations resolve correctly. Choose based on the effect you need, and profile rather than applying them speculatively.