SwiftUI Group Lab

Transcript

Engineers from the SwiftUI team introduce themselves and set up a session covering large collections and ForEach performance, navigation transitions, adaptive layout across screen sizes, data flow, conditional views, AnyView cost, custom controls and overlays, and building views with Liquid Glass.

The team is aware of this and looking into it — traversing the entire collection on updates shouldn't be necessary, and they acknowledged it as a real limitation for very large reorderable collections. File a Feedback with your use case; for now, extremely large datasets may still need careful structuring to avoid full-collection traversal on every change.

NavigationTransition is a protocol SwiftUI uses to expose conforming, framework-provided transitions rather than one you fill in yourself in beta 1. Use the built-in transitions the API vends; if you need a specific custom transition, file Feedback describing it, since the surface may expand in later betas.

The new skills shipping with Xcode give the coding agent accurate insight into current APIs like Liquid Glass and work with the model of your choice, so they're worth enabling — and you can export them for use in other agentic systems. On glass itself: avoid Liquid Glass in the content area of a view, since with nothing scrolling underneath there's nothing for it to refract and the simpler flat design is usually better; glass is for controls hugging the content layer. For a glass button, reach for the glassButtonStyle (or glassProminent) rather than applying a raw glassEffect — glassEffect on a button gives you a button sitting on glass, which won't look right — and pair it with buttonBorderShape to get the shape you want. Toolbar and navigation-bar buttons already get the right glass treatment automatically, so you don't need to add it there; new this year, sharedBackgroundVisibility(.hidden) and a content-margin-removal API let you drop the glass (or just its padding) for cases like a profile photo in the toolbar.

Don't hard-code specific window sizes — that's a losing battle. Design layouts that work at any size and adapt fluidly. Use size classes (compact vs. regular, vertically/horizontally) to make layout decisions, and lean on adaptive containers so your UI responds to the full continuum of window and screen sizes rather than targeting fixed dimensions.

At its core, SwiftUI data management is about identifying pieces of information and choosing where they should live and how they flow. Learn the tools — @State for view-owned state, bindings to share mutable access, and @Observable/Environment for passing data down — by building small apps that force you to move data between screens, rather than studying the wrappers in isolation.

An if that swaps views changes the view's identity and structure, which can cost more than necessary for simple show/hide. Prefer keeping the element in the hierarchy and controlling its visibility — for example with opacity or the hidden modifier, or conditional content that preserves identity — so SwiftUI can animate and update efficiently instead of inserting/removing the view.

AnyView erases the type SwiftUI would otherwise use to diff efficiently, so it adds overhead and reduces the framework's ability to optimize updates — most impactful in deeply nested or frequently updating views. It's fine where you genuinely can't know the view type at compile time; just avoid it on hot paths where a concrete type or @ViewBuilder would let SwiftUI update more efficiently.

Use the resizable previews to exercise your layout across sizes as you build. Design for flexibility — avoid fixed frames, use size classes and adaptive containers, and let content drive layout — so your UI holds up across the full range of window sizes the resizable preview now lets you check quickly.

There may be no clean way to do this purely in SwiftUI today. A full-screen cover works when you present it from the right point in the hierarchy, but getting something reliably above other modal presentations is genuinely hard. The pragmatic approach is interop: drop down to UIKit and create a new UIWindow (with a UIHostingController root) for a HUD or a login-over-the-app case, positioning it above everything. But be careful — with multiple windows it's last-UIWindow-wins, which is a bug waiting to happen once something else also needs to be always on top. So question the design brief first: a less disruptive flow (for example rewinding the navigation stack to a base view and restoring it after login) is often better than forcing a global overlay. File feedback with your use case so the gaps can be closed.

First ask whether it needs to be fully custom — an existing UIKit/AppKit control may already do it. If custom, present the expanding portion as an overlay so it draws above sibling views without participating in their layout, and manage its own interaction/state, rather than inserting it inline where it would push other elements around.

Size isn't the real goal — isolating independently-updating data is. Split a view when its parts update from different data (e.g. a header, content, and footer that each change on their own), so a change to one doesn't invalidate and re-run the body of the whole. If the dependencies are shared across the whole view, splitting buys you nothing — you do the same work either way. Crucially, extracting into a @ViewBuilder computed property gives no performance benefit, because it's still one view body with all the same dependencies; only a separate view type creates an initialization boundary where SwiftUI can compare inputs and skip work. An @Observable reference helps here too, since its stable pointer lets a small subview redraw without re-running the parent. And don't be afraid of many small views — they're value-type structs and cheap.