If you were developing for Apple platforms a decade ago, you probably remember the WWDC era in San Francisco. The massive scale, the live sessions, the sheer energy of thousands of developers packed into the Moscone Center—it was an incredible spectacle. But let’s be honest about the reality of the labs back then: you reserved a time slot, waited around while others got their questions answered, and grabbed whatever brief 1:1 time you could. It was grandiose, and information was largely being fed to you. It was rarely ever “intimate.”

Today, WWDC has evolved into a polished, pre-recorded cinematic event. While you can still go to Apple Park to meet with engineers, the loss of the week-long, in-person conference makes it a tough sell. For many companies and developers, it is incredibly hard to justify the investment of flying out just for a brief lab session.

But Apple has quietly built something else—something much more valuable for day-to-day engineering.

Recently, I had the privilege of attending the “Let’s talk Liquid Glass: New design workshop” at Apple’s offices in NYC. For three days, from 9 AM to 5 PM, I sat in a highly intimate room with Apple’s Developer Relations and Design Evangelists team. These were the folks tasked with knowing everything about Liquid Glass so they can travel the globe and help developers and designers actually use it (including one framework engineer in the room who specifically worked on SwiftUI).

They were incredibly accessible. I asked every question I could think of, got immediate feedback on lots of ideas and decisions, and worked through real-world implementation challenges for hours on end. It was the peak developer experience I had always hoped the old WWDC labs would be.

While I was there representing my team and can’t discuss the specific project details we worked on, there were certain philosophies and strategic insights I walked away with that absolutely apply to every single one of us.

Here are the universal lessons I learned from Apple’s Liquid Glass vanguard.

Universal Lesson 1: The Ship Has Sailed (Liquid Glass is Permanent)

Let’s address the elephant in the room. If you read the comments on my articles or browse the iOS subreddits, there is a vocal contingent of developers betting that Apple is going to roll back Liquid Glass.

The rationale usually points to the initial community backlash, the slower adoption rate of iOS 26, and the news that Alan Dye left Apple for Meta. The prevailing theory has been: “Just wait it out. They’ll revert to flat design.”

I shared this exact sentiment with the Apple team.

Their reaction? Genuine shock. They were actually concerned that developers were holding onto this position. They made it emphatically clear that Liquid Glass is absolutely moving forward, evolving, and expanding across the ecosystem.

Their exact warning to me was that those who don’t adopt it now “are gonna find themselves in a tough position later.”

During the workshop, they admitted they have seen teams who are only interested in doing the bare minimum—just enough to keep their app from breaking when the new system is forced on. While that is technically allowed, it is a dangerous game of technical debt.

We had them confirm the hard truth: Xcode 27 will absolutely not have the deferral flag, and it will not respect it if you leave it there, anyway. When Q1 2027 rolls around and Xcode 27 becomes the mandatory minimum for compiling to the App Store, glass will be enabled globally, period.

If you are waiting for a rollback, you are charting a course for a shipwreck. It’s time to accept and get into the new system.

Universal Lesson 2: Hierarchy is the Anchor (Content is King, Controls are Servants)

If you read my previous article, The Northern Stars of Liquid Glass, you know the Apple HIG dictates three core design principles for this new era: hierarchy, harmony, and consistency.

But if you want to know what Apple really cares about people focusing on? It’s hierarchy.

Hierarchy wasn’t just a bullet point; it was the absolute anchor for the entire three-day session. The Apple designers relentlessly emphasized the need to strictly break every screen down into two distinct dimensions: the content layer and the control layer.

Here is the harsh truth that many developers (and designers) struggle to accept: nobody opens your app to admire your custom buttons. They open it for the content. Because the content is the ultimate destination, it should be given as much screen real-estate as physically possible.

To achieve this, your control layer needs to get out of the way. Apple stressed pushing controls to “prime real-estate” locations—specifically the vertical extremes of the screen, like the top navigation bar and/or the bottom toolbar and TabView.

The rule of thumb they drove home applies across every single Apple platform: Controls serve the content.

If a UI element sits in one of those prime locations, its sole purpose must be to facilitate the user’s interaction with the bedrock content in the center of the screen. If it doesn’t serve the content, it’s just visual clutter taking up valuable space.

I plan to share an article soon where I break down the exact physics, z-axis rules, and “Barbell Layouts” of this hierarchy. But the high-level takeaway from the NYC labs is crystal clear: maximize your content, push your controls to the poles, and never let the interface compete with the information.

Universal Lesson 3: The Great Reset (and the Promise of WWDC26)

I have seen the comments on my posts, and I’ve read the threads on Reddit and developer forums. There is a lot of frustration out there about the loss of customizable properties and missing sub-elements in some of the new Liquid Glass components. You feel like your toolkit shrank overnight.

I brought this up directly with the Apple team. The good news? They are completely aware of it.

They explained that what we are experiencing right now is the exact same phenomenon that happened during the last massive design shift: the move to iOS 7. We just spent over a decade building on a design system that had time to fully evolve and mature from iOS 7 all the way through iOS 18. We had every modifier and customization hook we could ever want.

Now, we are living through a reset. We are back at Version 1.0.

The Apple engineers explained that a massive part of the initial Liquid Glass rollout was simply ensuring the foundation was solid. It had to be functional, it had to meet incredibly strict styling guidelines across every single Apple platform, and most importantly, it just had to work. When you are rebuilding the visual physics of an entire OS ecosystem, deep component customization takes a back seat to foundational stability.

But here is where it gets exciting.

The team was visibly enthusiastic about what is in store for WWDC26 and Xcode 27. While they wouldn’t drop any specific spoilers, they gave the very strong impression that this upcoming cycle is where Liquid Glass takes its first massive step into maturity.

Seeing their level of historical awareness regarding the iOS 7 transition—and their genuine excitement for what’s next—left me incredibly optimistic. The foundation is poured; now, they are getting ready to decorate the house.

Universal Lesson 4: Stop Fighting the Framework (SwiftUI Best Practices)

Beyond the overarching design principles of Liquid Glass, the Apple engineers dropped some incredibly practical, day-to-day SwiftUI advice. If you want to build robust, modern apps, here are three architectural course corrections straight from the source:

1. The List vs. ScrollView Reality Check - Many of us have been defaulting to List the second we need a scrolling column of data. The team made a point to clarify that List should really be reserved for highly specific, uniform data structures, or when you absolutely need built-in swipe actions. For almost everything else? You should be reaching for a ScrollView paired with a LazyVStack or LazyHStack. Between the massive improvements to ScrollView over the last few years and the inherent flexibility and performance of Lazy Stacks, rolling your own scrolling layout gives you far greater control over your styling—which is helpful when trying to nail the Liquid Glass look.

2. The Untapped Power of Custom Containers - They gently reminded us that we have the API to create our own custom containers in SwiftUI. Honestly, this felt like a massive missed opportunity for the community. It is a topic I rarely see covered by other iOS writers or utilized in the open-source repos I review. Instead of hacking a generic VStack with a dozen modifiers to act like a specific container, take the time to build a custom one. It makes your call sites significantly cleaner and your intent much clearer.

3. Ride the Native Wave (and Style It) - Especially now, while the maturity of the design system has been “reset,” the absolute best thing you can do is stick to native components. If you build a completely custom button or toggle from scratch using raw shapes, your app could get stuck in the past when Apple inevitably rolls out the next waves of Liquid Glass enhancements. Sticking with native components ensures your app naturally rides along with the OS’s evolution.

They took it a step further: when you need varying forms of a component, do not rebuild it. That is exactly what Styles are for. I touched on this heavily in my recent article on FULL DISCLOSUREgroup, and hearing Apple echo this sentiment validated that approach. Keep the native structural integrity and functional purpose, and use the Style protocols to paint the glass.

The Call to Action: Get in the Room

Attending WWDC 2016 in San Francisco was a milestone in my career, but spending three days in a quiet room with Apple’s design evangelists and framework engineers was entirely different. It wasn’t a spectacle; it was about the craft.

It is incredibly easy to sit behind our keyboards, read documentation, and complain online when an API doesn’t work exactly the way we want it to. But when you have 9-to-5 access to the team whose entire job is to know this system inside and out, you realize they are deeply passionate about this platform, they hear our feedback, and they are building for a multi-year horizon.

If you ever get the opportunity to attend one of these Liquid Glass or similar sessions—whether it’s in NYC, Cupertino, London, Tokyo, or elsewhere—go.

With the traditional week-long WWDC conference gone, these localized workshops are the absolute best way to get face-to-face time with Apple. Keep a close eye on the Apple Developer app and website for upcoming design labs. Pitch your company on the ROI of sending you to attend these sessions. The ability to bring your actual codebase, sit down with Apple for three full days, and get unscripted, immediate feedback is unparalleled. It will make you a better engineer, and it will give you a profound understanding of where the wind is blowing in the ecosystem.

And just in case you need to read it one more time: Liquid Glass is here. It’s time to learn how to sail it.

Navigate the Liquid Glass Transition with The Captain

The Xcode 27 deadline is approaching, and as the Apple engineers confirmed, there is no deferral flag. You don’t have to figure out this design reset alone. I have spent most of the last year leading Liquid Glass adoptions, and after my recent three-day intensive at the Apple Developer Center in NYC, I am offering expert-level, 1-on-1 consulting to get your app’s architecture ready for the new era.

Whether you need a UI/UX conflict teardown, custom container strategies, or a session to fix your control/content hierarchy, we can map it out.

Submit an Inquiry!

Let’s be honest: the Observation Framework and @Observable macro isn’t brand new. It has been navigating our waters for a few years now, offering a concurrency-safe upgrade to the older, more mysterious ObservableObject. But while many of us have been slowly adopting it, others have clung to the familiar comforts of Combine and @Published.

However, the recent release of Xcode 26.3 made the situation crystal clear.

With the new update, Apple introduced built-in “Agentic Coding” and an exposed Model Context Protocol (MCP) to drive it. Curious developers quickly cracked open the internal system prompts that guide Apple’s own AI assistant. Hidden inside the AgentSystemPromptAddition was this directive:

“- Architecture: Follow SwiftUI patterns with clear separation of concerns. Avoid using the Combine framework and instead prefer to use Swift’s async and await versions of APIs instead.”

There is no ambiguity left. Apple is explicitly instructing its own intelligence to “Avoid the Combine framework.” The era of Combine in SwiftUI is officially coming to a close. We are even seeing the Observation framework mature further with recent enhancements like the Observations type, giving us even more granular control.

But here is the catch: If you treat Observation like a simple find-and-replace for Combine, you are going to crash.

You delete your @Published wrappers, the compiler applauds, but then you tap a button and the UI doesn’t flinch. You aren’t crazy, and the API isn’t broken. You are just experiencing the friction of a fundamental paradigm shift.

We have moved from a Push model (where objects shout “I changed!” to anyone listening) to a Pull model (where Views quietly and efficiently track only what they touch). It is a smarter, leaner way to build apps, but it requires us to embrace a new mental model.

So, let’s clear the fog. Here are a few tips and tricks to help navigate the transition, avoid the common traps, and fully unlock the power of the new observation engine.

1. The “Lazy Init” Trap: Your View is Leaking Performance

In the “Old World,” @StateObject was our magic shield. It used an @autoclosure to ensure your ViewModel was only instantiated once, effectively acting lazily.

In the “New World,” Apple tells us to use @State to hold our reference types.

// The New Way (Potential Trap)
@State private var viewModel = HeavyViewModel()

Here lies the trap. Because State does not use an autoclosure for its initial value, the Swift runtime executes HeavyViewModel() every single time the parent view’s body is recomputed.

Yes, SwiftUI is smart enough to discard the new instance and keep using the old one. But the damage is done:

1. CPU Waste: You are allocating and deallocating a class instance on every frame refresh.

2. Side Effect Hazards: If your init() fires off a network request or heavy setup, your app will stutter or trigger duplicate logic.

The Fix: Defer Creation with .task

Since we don’t have a State(lazy:) option, Apple’s official guidance is to make the state optional and hydrate it using the .task modifier.

struct ContentView: View {
    @State private var viewModel: HeavyViewModel?

    var body: some View {
        HomeView(model: viewModel)
            .task {
                // Only runs once when the view first appears
                if viewModel == nil {
                    viewModel = HeavyViewModel()
                }
            }
    }
}

Why .task? It runs immediately before the view appears and, unlike onAppear, automatically handles the lifecycle of any async work if you decide to load data during initialization.

2. The “Nested Observable” Dead Zone

This is where 90% of developers get stuck. They migrate their code, the compiler is happy, but the UI simply stops updating.

The Pitfall:

You have a parent model containing a child model, both marked with @Observable.

@Observable class User {
    var settings = Settings() 
}

@Observable class Settings {
    var isDarkMode = false
}

If you access user.settings.isDarkMode inside a view that only explicitly observes user, you might miss updates. If you pass user to a child view, and that child view only reads user.settings (the reference), the parent view has no idea that the internal properties of settings changed.

The Fix: Granular Access or @Bindable

You must ensure that the specific View that needs to update is the one reading the specific property.

The Trap (Lazy Observation)

struct UserProfile: View {
    @State var user = User()

    var body: some View {
        VStack {
            // Potential Issue: We are digging deep into the graph.
            // If 'isDarkMode' changes, does UserProfile need to redraw? 
            // It relies on implicit tracking that can be fragile in complex views.
            Toggle("Dark Mode", isOn: Bindable(user.settings).isDarkMode) 
        }
    }
}

The Solution (Granular Passing)

Pass the specific node of the graph to the view that needs it. This ensures the “Spotlight” is shining exactly where the data changes.

struct UserProfile: View {
    @State var user = User()

    var body: some View {
        VStack {
            Text("User: \(user.name)")
            // FIX: Pass ONLY the child object to a dedicated view.
            SettingsEditor(settings: user.settings)
        }
    }
}

struct SettingsEditor: View {
    // 1. We accept the Observable class instance directly
    @Bindable var settings: Settings

    var body: some View {
        // 2. We bind directly to the property on this scoped object.
        // When 'isDarkMode' changes, ONLY 'SettingsEditor' redraws.
        Toggle("Dark Mode", isOn: $settings.isDarkMode)
    }
}

3. The “Array Mutation” Ghost

You have a list of items, you toggle a property on one of them, and… nothing happens.

The “Old World” Habit:

We used to rely on List($viewModel.items) to get bindings. In the @Observable world, if you try to iterate and bind, you hit a syntax wall because the iterator gives you a let constant, not a binding.

List(viewModel.items) { item in
    // ERROR: Cannot find '$item' in scope
    Toggle(item.title, isOn: $item.isDone) 
}

The Fix: Shadowing with @Bindable

This is the new “magic spell” you need to memorize. You must create a @Bindable shadow variable inside the scope where you need the binding.

List(viewModel.items) { item in
    // 1. Create a bindable shadow copy
    @Bindable var item = item
    
    // 2. Now you can access the projected value ($)
    Toggle(item.title, isOn: $item.isDone)
}

The @Bindable property wrapper creates a bridge. It tells SwiftUI: “I know this object (item) is @Observable. Please create dynamic bindings for its properties right here, right now.”

This isn't just a hack; it is the official pattern prescribed by Apple. As noted in the documentation for Bindable, you must create a bindable value within the view's scope to generate bindings for an observable object that you don't own (like one passed into a closure).

4. The “Computed Property” Compiler Error

You have a favorite property wrapper—maybe @AppStorage—and you drop it into your new @Observable class.

@Observable class GameScore {
    // ERROR: Property wrapper cannot be applied to a computed property
    @AppStorage("highScore") var score: Int = 0
}

This fails because @Observable converts all stored properties into computed properties behind the scenes to inject its tracking logic. Property wrappers generally don’t like wrapping computed properties.

The Captain’s Advice: The Service Pattern

You can fix this by writing complex boilerplate involving @ObservationIgnored (check out this solution by David Steppenbeck and how it works inside). But if you find yourself fighting the compiler to keep @AppStorage inside your observable class, pause for a moment.

Perhaps it’s worth considering that you may need to let go of the wrapper convenience and go back to more traditional means (e.g. using UserDefaults). Plus, the @Observable era is the perfect time to separate Data from Persistence.

Instead of coupling your data model tightly to UserDefaults, consider moving that responsibility to a dedicated Service or Manager.

• The Service: Handles the saving/loading logic.

• The Observable Model: Simply holds the current source of truth in a standard Swift type.

This keeps your observation logic clean (no manual wiring required!) and your persistence logic isolated where it belongs.

Conclusion: Finding Your Sea Legs

Migrating to @Observable is a bit like upgrading your ship’s engine from diesel to nuclear fusion. The potential for power and efficiency is incredible, but if you wire it up using the old schematics, you’re going to have a meltdown.

The most important thing to remember is the “Spotlight Rule”: The new observation system is lazy. It only updates a view if that view is currently “shining a spotlight” on the specific property that changed. If your view stops looking—even for a second, or because of a nested object—the updates stop coming.

Once you master the lazy .task initialization, strict granular access for child objects, and the @Bindable shadow syntax, you’ll find that the new system isn’t just “Objectively Better”—it’s actually fun to use.

Until then, keep your eye on the graph, and trust your bindings.

Did you know that zero had to be “invented”? For many ancient civilizations, numbers were exclusively for tangible things. There was no need to count nothing. Eventually, scholars recognized that “nothing” isn’t just an absence—it’s a value. It’s a placeholder, a starting point, and a critical bridge between positive and negative.

In SwiftUI, the empty state is our zero.

There will always be scenarios where there is no data to display, no modifier to apply, or no content to render. Yet, the software must still communicate this state of “nothingness” to the user—or to the compiler.

SwiftUI provides us with three distinct tools to handle emptiness, each serving a different purpose:

1. EmptyView: For the view hierarchy (Layout).

2. EmptyModifier: For the type system (Compiler).

3. ContentUnavailableView: For the user (Experience).

Let’s explore how to design for nothingness.

EmptyView: The Layout of Nothing

EmptyView is one of SwiftUI’s most deceptively simple types. On the surface, it feels like a placeholder you drop in when you don’t want to render anything. But its role is deeper: EmptyView is SwiftUI’s canonical representation of nothingness.

What EmptyView Actually Is

EmptyView is a zero-sized, non-rendering view. It draws nothing, takes up no space, has no layout implications, and participates minimally in the view tree. If SwiftUI were a standard programming language, EmptyView would be Void—a way to say, “There is a concept of a view here, but it is empty.”

Under the hood, SwiftUI uses EmptyView as the default return type for conditional branches that don’t produce UI and for erased view builders.

Common Use Cases

1. Handling Optional Content

if let user = model.user {
    UserProfileView(user: user)
} else {
    EmptyView()
}

This is the simplest case: you conditionally include a view, and use EmptyView() when there’s nothing to show.

2. Satisfying ViewBuilders

SwiftUI’s @ViewBuilder cannot return nil. It must return a View. In complex generic contexts or manual ViewBuilder implementations, EmptyView is the correct return type when you need to bail out of rendering.

How EmptyView Differs From .hidden()

This is where many developers trip up.

Using .hidden() does not remove your view—it’s closer to setting visibility: hidden in CSS. The view stays in the layout calculation, reserves its frame size, and affects the positioning of neighbors.

Text("Hidden")
   .hidden() // Invisible, but still takes up space

Using EmptyView removes the view entirely from the layout pass:

EmptyView() // No space, no layout, no impact

Captain’s Tip

EmptyView is the silence between notes—essential to the rhythm, but never the melody. Use it to create space, not confusion.

This article would like to promote Jacob’s Tech Tavern:

Jacob’s blog was one of the few that inspired me to get back into writing articles and on Substack. His topics are always interesting, in-depth, and full of good humor. And now that he’s gone full-time indie, we get to enjoy more of his great work! Check him out and consider subscribing to Jacob’s Tech Tavern, today!

Jacob's Tech Tavern

EmptyModifier: The Compiler’s Nothing

If EmptyView represents “no view,” then EmptyModifier represents “no transformation.”

The official documentation notes that this modifier is useful “at compile time.” This is a crucial distinction. EmptyModifier isn’t usually meant for runtime logic (like toggling opacity on and off); it is the Identity element of the modifier world. It exists to satisfy the type checker when a modifier is required, but you don’t actually want to do anything.

The Power of Type Aliases

The most powerful use case for EmptyModifier is combining it with Conditional Compilation.

Imagine you want a specific debug overlay—a red border or a tap gesture—but you want that code completely stripped out of your Release builds. You don’t want to wrap every call site in #if DEBUG.

Instead, you can define a modifier that changes based on the build configuration:

#if DEBUG
struct DebugBorder: ViewModifier {
    func body(content: Content) -> some View {
        content.overlay(
            RoundedRectangle(cornerRadius: 4)
                .stroke(.red, lineWidth: 1)
        )
    }
}
#else
// In Release builds, this becomes the "Identity" modifier
typealias DebugBorder = EmptyModifier
#endif

Now, your call site remains clean and consistent:

Text("Hello World")
    .modifier(DebugBorder())

In a Debug build, the compiler sees a ViewModifier that draws a border.

In a Release build, the compiler sees EmptyModifier. Because EmptyModifier’s body just returns the content exactly as is, the compiler can optimize it away entirely. There is no runtime cost, no branching logic, and no leftover code artifacts.

Why not use it for Runtime Logic?

You might be tempted to write code like this:

view.modifier(isEnabled ? MyEffect() : EmptyModifier())

While this compiles, it usually results in the creation of a _ConditionalContent wrapper. For simple runtime toggling, it is often cleaner to put the logic inside a custom modifier or use standard view extensions.

EmptyModifier shines when you need to provide a default value to a generic system. If you are building a reusable component that accepts a generic VM: ViewModifier, you can set the default to EmptyModifier:

struct MyContainer<VM: ViewModifier>: View {
    var modifier: VM = EmptyModifier() // Default is "do nothing"
    // ...
}

Captain’s Tip

EmptyModifier is the invisible rigging of your UI—unseen in release builds, but essential when you’re tuning the ship. Use it to debug boldly and deploy cleanly.

The Paradox of Empty State

“Empty” is one of the most misleading words in UI design.

In software, an empty state is never truly empty—it’s a moment of uncertainty. It’s the space where users ask: What should I do next? Did something break? Is there supposed to be something here?

Left untreated, emptiness feels like failure. Treated well, it becomes guidance.

While EmptyView solves the technical problem of rendering nothing, it fails the user experience problem. An empty screen requires intention, clarity, and often a visible invitation to act.

ContentUnavailableView: Designing for Absence

This is precisely why SwiftUI introduced ContentUnavailableView.

Rather than treating empty states as an edge case or a blank canvas, ContentUnavailableView formalizes them. It gives emptiness a standard structure that feels “at home” on Apple platforms.

Here, we have a really basic implementation that still manages to not leave the user hanging:

ContentUnavailableView("Emptiness!", systemImage: "bathtub", description: Text("Wow, such empty!"))

This next example provides a bit more information that answers three simple questions considering “nothingness”:

1. What’s missing? (The Title)

2. Why is it missing? (The Description)

3. What can I do next? (The Action)

ContentUnavailableView {
    Label("No Favorites", systemImage: "star.slash")
} description: {
    Text("Mark items as favorites to see them here.")
} actions: {
    Button("Browse Items") {
        // Navigate to items
    }
}

Instead of a blank list or a silent screen, the UI acknowledges the state. It reassures the user that the app isn’t broken—it’s just waiting.

In many cases, ContentUnavailableView is the right answer where developers used to reach for EmptyView. If a list is empty, don’t show an EmptyView (which shows nothing); show a ContentUnavailableView (which explains why there is nothing).

Captain’s Tip

An empty state isn’t a failure of your UI—it’s a moment of guidance. When there’s nothing to show, your job shifts from displaying content to setting expectations. If users feel lost in an empty screen, the problem isn’t the data—it’s the design.

Conclusion

Emptiness in SwiftUI is a spectrum.

At the lowest level, we have EmptyView: the structural, silent void used by the layout system to reserve no space.

At the compiler level, we have EmptyModifier: the identity type used to strip behaviors out of release builds or satisfy generic requirements without incurring runtime cost.

And at the human level, we have ContentUnavailableView: the loud, helpful interface that turns a lack of data into a call to action.

As you build your apps, remember that “nothing” is a valid state that deserves just as much care as your “happy paths.” Use EmptyView to hide, EmptyModifier to optimize, and ContentUnavailableView to guide.

There’s been ongoing—yet significant—evolution in how sheets and modals are used. The era of full-screen takeovers and heavy modals has been fading, replaced by lightweight, flexible, and fluid overlays that feel right at home in the new Liquid Glass design system.

Apple’s been steadily modernizing the way we present content—most notably through presentation detents, component roles, and a refreshed set of presentation modifiers that give developers real control over look, feel, and motion. Even the elusive and slightly odd TabView/sheet pattern from “Find My” has been cleaned up, aligning with the system’s new aesthetic.

In this article, I wanted to take a break from the broader, high-level topics and just have some fun playing with sheet—exploring what’s new, what’s changing, and how you can adopt Apple’s updated presentation model in SwiftUI without losing your sense of flow.

Sheet Fundamentals and Modern Presentation

For years, a “sheet” in SwiftUI meant one thing: a full-screen takeover that slid up from the bottom, blocked everything behind it, and waited for the user to tap a “Done” button before giving control back. It got the job done — but it also froze the rest of the experience.

That era has long sailed away.

Today, sheets are far more flexible. They’re not just interruptions — they can be the moment, or complement it. A sheet can act as a full-screen view, a compact accessory, a sliding control panel, or a lightweight status overlay. What used to be a rigid, single-purpose UI element has evolved into one of the most dynamic tools in the developer’s toolkit.

Apple’s presentation modifiers — like .presentationDetents, .presentationCornerRadius, and .presentationBackgroundInteraction — capture that evolution. These aren’t just cosmetic flourishes; they represent a philosophical shift: a sheet no longer removes users from context — it expands it.

Here’s a simple example that captures that spirit:

.sheet(isPresented: $showSettings) {
    SettingsView()
        .presentationDetents([.medium, .large])
        .presentationBackgroundInteraction(.enabled)
        .presentationCornerRadius(32)
}

What used to be a hard stop is now a conversation between layers. The user decides how much space they need; you decide how immersive it should feel.

That’s the foundation of modern sheet design: adaptive, responsive, and gracefully contextual.

Captain’s Tip

If it feels like you’re breaking flow, you probably are. In the Liquid Glass era, sheets should move like water — flowing with the user’s intent, not against it.

Understanding Detents — Designing in Depth

When sheets first landed in SwiftUI, they were pretty basic — useful, but blunt. You could show a modal that covered most of the screen or one that hovered partway up, and that was about it.

With presentation detents, Apple has turned sheets into a flexible, fluid part of the user experience. They can live anywhere between a full takeover and a subtle overlay — floating, snapping, or expanding based on user intent and your app’s design.

Think of detents as waypoints for your sheet — positions that define how much space the sheet occupies, how it behaves when dragged, and how the user transitions between states.

The Built-Ins: Medium and Large

The simplest detents are built right in: .medium and .large. These match Apple’s own design language — you’ll find them everywhere from Maps to Stocks.

A .medium detent is great for contextual views — showing filters, lists, or a now-playing interface. A .large detent, meanwhile, is perfect for tasks that need focus but don’t necessarily deserve a new screen.

Going Custom — Height and Fraction

Sometimes your sheet doesn’t fit neatly into Apple’s presets. That’s where custom detents come in:

.presentationDetents([
    .fraction(0.25),
    .medium,
    .height(500)
])

Here, you’re defining specific heights or proportional space allocations, giving your sheet a feel that matches your content.

Fractional heights like .fraction(0.25) are particularly useful when you want consistency across devices, while .height() gives you fine-grained control for precise layouts.

For custom, reusable, and labeled detents, you can also take advantage of CustomPresentationDetent to define and set your own detents:

private struct ScoreOnly: CustomPresentationDetent {
    static func height(in context: Context) -> CGFloat? {
        max(48, context.maxDetentValue * 0.1)
    }
}

extension PresentationDetent {
    static let scoreOnly = Self.custom(ScoreOnly.self)
    static let smallHeight = Self.height(100)
    static let extraLargeFraction = Self.fraction(0.75)
}

Here, we’ve added a detent for when we just want to show the score of the game:

Selecting and Tracking Detents

You can even track the user’s chosen detent or programmatically adjust it with a binding:

.presentationDetents([.medium, .large],
                     selection: $currentDetent)

This lets you adapt your UI as interaction unfolds — imagine expanding your sheet when the user taps “Show Details”, or collapsing it after a confirmation. It also opens the door for subtle motion design: a medium sheet can transition seamlessly into a large one as more content loads or becomes available.

In Apple’s Stocks app, we see how tracking the selected detent actually determines the state of the content being shown. For instance, when it’s “closed”, the title says Business News, then changes the title to Top Stories in when set to the medium detent. And on large, the navigation bar transforms into a scrolling ticker.

This enables detents to be more than just a determination of how much/little of the background content is being shown, but also all the subtle states in and around it, as well.

Captain’s Tip

Think of detents like depth markers on a ship’s hull. Each one tells you how far your UI dives beneath the surface — a careful balance between immersion and intrusion. Use them to give your users buoyancy, not ballast.

Roles & Interactivity — Customizing Sheet Behavior

With detents you decide where a sheet lives. Now we’ll talk about how it behaves—how it interacts, how it dismisses, how it feels to tap, scroll, drag, or ignore the background behind it. These interactive modifiers turn sheets into living panels, not just pop-ups.

Background Interaction — The Layer Lives On

One of the biggest shifts in sheet behavior is what happens behind it. With .presentationBackgroundInteraction(_:), you decide whether the user can still interact with the view underneath.

.presentationBackgroundInteraction(.enabled(upThrough: .medium))

Use this pattern when your sheet is part of a fluid interaction (e.g., a map panel). It lets users still tap and pan the map while the sheet sits at a lower detent. When the sheet expands, background interaction disables automatically—shifting focus naturally.

Appearance & Feel — Beyond Just Covering the Screen

Customization features like .presentationBackground(_:), .presentationCornerRadius(_:), and .presentationContentInteraction(_:) let you refine how the sheet looks and acts.

.sheet(isPresented: $showMenu) {
    MenuView()
        .presentationDetents([.height(250), .medium])
        .presentationBackground(.ultraThinMaterial)
        .presentationCornerRadius(24)
        .presentationContentInteraction(.scrolls)
}

• .presentationBackground(.ultraThinMaterial) gives that translucent glass feel.

• .presentationCornerRadius(24) softens the sheet for modern presentation.

• .presentationContentInteraction(.scrolls) helps where you have a ScrollView within your sheet, and you either want the scroll effect to have precedent or the drag-to-resize.

Dismissal Options — Different Ways of Letting Go

For when it’s time for sheet to sail off screen, we have a number of options to trigger and handle dismissing:

• You can provide a more explicit control to dismiss a sheet by adding Button(role: .close) to it’s toolbar.

• Use .interactiveDismissDisabled(_:) to prevent the user from swiping away if your sheet requires completion (e.g., a payment flow).

• Use @Environment(\.dismiss) inside the sheet content to dismiss programmatically.

• Provide an onDismiss closure in the .sheet(...) to handle any logic that needs to happen once the sheet goes away (e.g. apply the settings the user chose on the sheet)

.sheet(isPresented: $showForm, onDismiss: { cleanUpForm() }) {
    FormView()
        .interactiveDismissDisabled(isProcessing)
}

This blend of intent, role, and behavior ensures the sheet aligns with your functional flow—whether it’s a quick glance, a control panel, or a committed task.

Captain’s Tip

Think of interactivity as sea state. A calm panel lets the waves (background) move; a deep dive sheet anchors the ship. Use these modifiers to control when the sea moves and when the ship settles.

Give Sheet a Try

Sheets used to be stop signs. Now, they’re flow points — a place where users can pause, peek, act, or dive deeper without ever leaving context. Sheet’s evolution to include detents, modifiers, and style controls turn what used to be a rigid pattern into something expressive and adaptive — a tool that matches the rhythm of your app, not break it’s vibe.

The real trick isn’t memorizing every modifier — it’s learning to feel when a sheet should expand, retract, scroll, or stay anchored. That’s what Apple’s evolving design language is all about: fluid layers that live together instead of on top of each other.

So experiment. Play. Let the sheet breathe with your design instead of boxing it in. Because in this new Liquid Glass era we’re all headed for, presentation isn’t interruption — it’s motion.

With the release of [your platform here]OS 26, Liquid Glass is officially here. And with it comes a new era under Apple’s new design system. It’s been a fun summer exploring LG alongside the community — especially as each beta changed this, that, and everything in between. But now, with the official release, we can expect things to (mostly) settle into place for a while.

This also means the era of “we’ll wait because they keep changing things” is officially over. Sure, we get a pass for Xcode 26, but starting with Xcode 27+ Liquid Glass becomes the default system in every build.

That makes now the perfect time to understand the three principles at the heart of Liquid Glass. According to Apple’s updated Human Interface Guidelines, they are Hierarchy, Harmony, and Consistency:

While Apple introduces these principles in the HIG and touched on them during the Platforms State of the Union, there’s no single, in-depth guide from Apple that shows how to apply them in practice. So let’s fill that gap — breaking down what each principle means for modern UX and how it translates into real-world SwiftUI.

Hierarchy — The Lighthouse of User Attention

When Apple talks about Hierarchy in Liquid Glass, it’s not about vertical order (top vs. bottom of a screen). It’s about layering — which elements float above your content to guide interaction and which stay embedded in content.

Liquid Glass is optimized for UI elements that sit above the main canvas: navigation bars, tab bars, toolbars, sidebars, and menus. Apple’s new design language turns these controls into translucent, weightless surfaces that make the content beneath feel present and alive — instead of suffocating it.

The result:

• Foreground layers = guidance and controls

• Background layers = immersive content

• Clear, immediate hierarchy for the user’s eyes and fingers

Some examples of how Liquid Glass already aids the hierarchy principle can be found in toolbars and tabview:

We see how core points of interaction, navigation, and functionality do not hinder the main content, but are also elevated into prominence.

How to apply it in SwiftUI:
In many cases (like with toolbars and tabviews), the LG system already sets us up for great hierarchy. But, if we were creating a more custom experience, we should consider the layers of the experience we’re presenting to our users:

VStack(alignment: .leading, spacing: 8) {
    Text("Button")
        .font(.largeTitle)
        
    Text("...")
        .font(.body)
    
    HStack {
        Spacer()

        Button {
            // something
        } label: {
            Text("Accept")
        }
            .buttonStyle(.glass)

        Spacer()
    }
}
.padding()
.background(.green.opacity(0.3))

The result when repeating in different button styles shows:

Without glass, the button blends into the (very basic) UI, remaining relatively flat even with the bordered style. But with glass, the button stands out from the content beneath, making it clear that this is a point of interaction and, potentially, state change.

Glass effects already promote hierarchy and naturally produce layering—even on the same literal Z-layer. Think of it as raising user attention to the surface where you need it, instead of piling on more stacks. In Liquid Glass, you don’t fight for hierarchy — you reveal it.

Captain’s Tip: When it comes to hierarchy, think “layers”. The top-most layers (nav bars, toolbars, tab bars) should guide interaction and feel lighter. The bottom layers (content views) should be primary and immersive.

Harmony — Keeping the Currents Smooth

If Hierarchy is about which elements rise to the surface, Harmony ensures those elements move together as one current. It’s not just visual polish — Harmony is spacing, rhythm, and consistency that prevent your layered UI from feeling like a sticker book of floating widgets.

Think of Harmony as composition:

• The translucency of glass means elements share visual “DNA” with the content beneath.

• Spacing and padding must be tuned so floating elements don’t feel like they’re crashing into each other.

• Motion, blur, and tint should echo across layers so the UI feels orchestrated, not random.

One of the best and coolest examples of harmony is in the new backgroundExtensionEffect. We’ve already seen how toolbars and tabviews hover over content. But the extension modifier lets you add context where the system can’t, maintaining visual continuity and harmony.

Harmony also depends on grouping related elements together within clear, recognizable boundaries. In Liquid Glass, this is reinforced through Concentricity—rounded, nested shapes that echo each other—eliminating harsh edges that could feel jarring against content. You can see this in the sidebar from the extension screenshot above. You’ll also find it in the highlighted screenshot of the Maps app below. Notice the way areas of focus are grouped in concentric “containers”, reducing visual noise while reinforcing relationships between actions.

Note: Apple has made it a point that concentric design is so helpful in distinguishing features harmoniously that it’s used throughout Apple hardware design, as well.

How to apply it in SwiftUI:
Much of what keeps harmony is provided for us through many of the components already found in SwiftUI under the new design system. In the following screenshot, concentricity, grouping, spacing, and overlapping (without inteference) is all handled simply by adding components like TabView, tabViewBottomAccessory, and ToolbarItem. Even the rows were given concentricity when applying row spacing:

When you need to introduce harmony where there is more custom/unique UI, there’s help in tools like ConcentricRectangle and backgroundExtensionEffect.

Captain’s Tip: Harmony is your current — it is the tide that quietly carries your users attention from one destination on screen to the next. If one element splashes too loudly, the whole current feels off.

Consistency — Building Trust Across the Voyage

If Hierarchy is about what rises above and Harmony is about how everything moves together, Consistency is about predictability. It’s making sure your UI behaves, looks, and feels familiar — not just across screens, but across Apple’s entire platform fleet.

Consistency isn’t about sameness or stifling creativity. It’s about creating a dependable mental model so users can instantly understand and navigate your experience. In the Liquid Glass era, that extends across:

• Apps on the same platform: Shared navigation gestures, familiar placements of toolbars/tabviews, coherent typography.

• Across Apple platforms: iOS, iPadOS, macOS, visionOS, watchOS, and tvOS — each with its own scale but unified materials, controls, and motion principles.

• Across states of your own app: Light/Dark Mode, compact/expanded, windowed/fullscreen, folded/unfolded devices.

How to apply it in SwiftUI:
By using system components, environment-driven layout, and shared modifiers (rather than reinventing the wheel per screen), maintaining consistency could be as simple as:

var body: some View {
    ViewThatFits {
        NavigationSplitView {
            List(games) { game in
                GameRow(game)
            }
            .listRowSpacing(8)
            .navigationTitle("MLB Scores")
        } detail: {
            GameDetailSheetView()
        }
        
        NavigationStack {
            List(games) { game in
                GameRow(game)
            }
            .listRowSpacing(8)
            .navigationTitle("MLB Scores")
        }
    }
}

Here, we simply rely on ViewThatFits to determine whether we use a SplitView (with a defined detail view) for iPadOS/macOS or a Stack for iOS. Everything else stays the same. This may be a tad over-simplistic, but it highlights how consistency can be achieved with very little. Just look at how the experience changes at various sizes:

Captain’s Tip: Consistency is your compass, letting users sail confidently between your screens and across Apple’s platforms. It isn’t just a guideline — and it doesn’t mean cloning your UI everywhere. It’s about letting users feel at home no matter where they sail. Consistency is the glue holding the entire experience together as windows float, fold, or fade.

Navigating by the Northern Stars

We’ve charted three distinct “stars” of Liquid Glass — Hierarchy, Harmony, and Consistency — but in practice, they’re never separate. They’re constellations, working together to guide your users through a seamless experience.

Hierarchy gives users a clear beacon of interaction. Harmony ensures those interactions flow naturally and feel connected. Consistency builds the trust that lets them navigate confidently across your app and Apple’s platforms.

When you apply all three, you’re not just following Apple’s design principles — you’re creating experiences that feel effortless, resilient, and future-ready.

As Liquid Glass becomes the standard, these principles aren’t checkboxes. They’re habits — ways of thinking about layers, balance, and predictability from the start of your design process. By adopting them now, you’ll spend less time “retro-fitting” later and more time innovating.

This summer has really felt like a busy one as an Apple Developer. I feel I've spent much of it jumping from topic to topic, trying to piece together just how projects may (or may not) be impacted (either now or in the future).

Of course, diving deep into Liquid Glass was an obvious whale of a topic to wade through. There was also iPadOS Windowing and the foldable iPhone production news that began to introduce new sizing and perspective considerations, adding UX design complexity. And, as I continued to convert some of my projects over to Swift 6, working through concurrency issues became a past time.

Absorbing these and a slew of other topics felt more taxing than normal. You can tell based off my writing (or lack, thereof). There were pre-WWDC indications that there would be large changes coming (and I did attempt to brace myself and others for them). As developers, we sign on to a career of constantly learning and adapting as technology evolves and emerges.

But I decided to take a step back, breathe in the salty air, and reflect on all these changes.

During my reflections, it finally hit me: we’ve now entered a new era of Apple Development, and we’re currently smack dab in the middle of The Great Shift (at least, that’s what I’m calling it).

Let me explain…

Swift 6 Is A New Way of Coding

When Swift 6 was declared to be a large, concurrency-pushing, thread-safety enforcing update, developers rejoiced! As we were slowly introduced in later Swift 5 versions to some of the core features (such as Actors, async/await, and Tasks) there was growing excitement for what was to come!

I do think, however, that the vast majority of developers underestimated what concepts like “strict-concurrency” would actually entail. For anyone who has undergone a migration to Swift 6, you may have said to yourself at one point “was my code really that unsafe?”. And the answer is yes, it really was.

For years, even slightly experienced Swift developers had some awareness of threading and concurrency (probably through Grand Central Dispatch). I’ve seen many Juniors first encounter Dispatch.main when their UI was failing to react to data changes that were happening on another thread, unbeknownst to them.

This new era of Swift will change all of that. Knowing concurrency concepts and the tools/frameworks supporting them will no longer be just a distinguishing factor between career levels and sets of interview questions: it is now universally required understanding.

Thank goodness for that. Once you get over the initial panic and fear of a gazillion concurrency warnings and errors, you begin to understand the actual healing taking place in your code. That rich reward, itself, allows you to slowly embrace how you need to code in Swift from now on.

Liquid Glass Enables Fluid Designs

Liquid Glass embodies a host of liquid puns. Clearly, the “material” part of the design is quite transparent. The minimizing of components (such as TabView and Toolbars) creates less of a splash atop app content. The transitions, interactions, and presentations provide a fluid experience that allows users to feel they’re floating from feature to feature.

However, Liquid Glass is not just material facelift. As Apple has stated, Liquid Glass is a “new design system”. This means there is a new vision and direction for how Apple wants us to design applications on its platforms. The HIG reflects this as it prominently displays the new core design principles: Hierarchy, Harmony, and Consistency.

As I dove into Liquid Glass this summer, I began to better understand how these principles guide apps into the next era of software and mobile. That the glimpses at some of the new features (and rumored features) to lead us to a vast sea of possibilities ahead. At the same time, failing to adopt Liquid Glass could leave your app feeling dated, behind-the-curve, or worse: broken.

Windowing and Foldables Shatter Size Class Conventions

If you’re a web/desktop-app developer, you’re laughing at all the mobile developers befuddled at Windowing on iPadOS. Accounting for dynamic sizing and displaying of applications is par-the-course. But for Mobile, that static rigidity of size classes has been a solid staple of design and requirements.

Even with Split View on iPad, there has always been some way of planning ahead for how your app looked in a seemingly fixed set of scenarios. Through the years, I’ve even seen designs get updates when a new iPhone’s dimensions were announced. iPhone X was a shocker with the screen going (seemingly) edge to edge (sans notch).

Now, however, we have to concern ourselves with more dynamic scenarios, including a minimum size that beats out the iPhone SE.

To make things even more complicated, we know that a foldable iPhone is just about a year away. We can start to guess how it will look, but until we actually see it we have no idea what new dimensions iPhone apps will now have to take into account.

Harkening back to Liquid Glass, this idea of having a more fluid and dynamic design for apps seems to fit right in. Maybe the flattening of component design and focus on core functionality are key to these “next steps”, after all. As the principle of Consistency states: “Adopt platform conventions to maintain a consistent design that continuously adapts across window sizes and displays.” If we don’t adhere to this principle, our apps may literally not fit the devices of tomorrow.

Snippets, Widgets, Intents: Oh My!

Apple is pushing for an ecosystem where the features of your app are not confined by your apps instance: they want your features to be open, accessible, and available to the platform, at-large.

Widgets are not new, but they have consistently seen some kind of update at every WWDC since they arrived. Their inclusion in CarPlay is a huge barrier-busting announcement.

The push for snippets was also interesting to see this year. They are not widgets, but are of the class of mini-features, complete with UI. Think of when you ask Siri what the weather is and it shows a thin rectangle from the Weather app.

Lastly, App Intents have always been promoted as ways to expose your app features, particularly through non-UI methods. They influence Siri prompts, could work with Shortcuts, and are promised to have a significant role in Apple Intelligence.

Which is why I view these three “channels” as part of The Great Shift. I believe they are a part of an app-less, more-platform future for software. A world where users may end up using your features and content more from the platform than from your actual app.

An App-less What-If…

Picture this: a user wants to know the wait time for a ride at an amusement park. They could open the park’s app, navigate to the rides section, scroll to the ride, tap to look at it’s details, and see the wait time. Or, the user asks the (eventual) Apple Intelligent Siri for the wait time, and Siri pulls up a snippet that displays the ride name, wait time, and other minor details (requirements, “fun-level”, etc), all in the UI style of the park and ride.

This Thing Called AI

Without a doubt, AI has become a seismic force in software development (for good, bad, and everything in between). While a great deal of the AI revolution is happening beyond Apple, they’ve clearly begun to bring it into the Apple ecosystem. Whether Apple is doing enough is a debate I’ll happily leave to pundits and hot-take artists.

But consider these points:

• We already need to consider how Apple Intelligence interacts with our app (or, perhaps, doesn’t)

• With Foundation Models, we can begin to consider introducing basic AI capabilities into our app at no cost (just limitations)

• Xcode 26 comes with a built-in AI assistant geared towards Apple Development

With AI influencing so much of Apple’s platforms and frameworks, it’s absolutely a large part of The Great Shift. We must adopt thinking through how AI can impact a project as it could make a world of difference to your users (and, potentially, your competition).

A Worthy Measure of The Great Shift

Besides all the evidence above, there’s another way I’ve taken notice of The Great Shift.

Let’s say you were to new to iOS development and wanted to start a File → New Project with Swift 6 and Liquid Glass enabled. The majority of books, resources, and tutorials will fail to properly prepare you for those two (completely game-changing) concepts, alone.

Heck (my publisher is gonna kill me for this) the book I co-authored just a year ago (Swift Cookbook: Third Edition) is already outdated! Yes, a lot of resources begin to become outdated almost the moment they hit shelves. But usually section by section, chapter by chapter, and over time.

This past year, Apple changed the game in tons of spaces. How we code, how we build UI, and even how our app will exist on the platforms they run on. When a vast collection of resources all of a sudden become (or are about to become) outdated, that feels like solid confirmation of a large shift.

There are other ways of confirming The Great Shift. There’s the impact to your team’s backlog, your app becoming unusable in Liquid Glass, the inability to use a new Swift 6.2 feature in your code because you haven’t migrated out of sheer panic.

But, I digress. The fact of the matter is, there’s enough evidence to say that, if you were an Apple developer even just 2 years ago, you have felt The Great Shift happen in some capacity.

Rolling With The Tide

How do we account for The Great Shift? We do what developers have done at every great wave of change that comes their way: brace themselves as they sail right into it, with strong determination and a hunger for exploration and adventure in their belly.

We are entering uncharted waters, for sure, as we don’t even have the final versions of Xcode and OS’s. But know that you won’t be alone. As a writer in this community, I’ve learned more and more about how awesome the Apple developer community really is. And not just my fellow writers, but the developers who share comments, findings, and suggestions. Who ping me or others with support, encouragement, and gists.

As the Captain, I’m proud to be a part of this with you all. So let’s raise anchor, roll down the sails, and set course for what’s next as we venture into The Great Shift, together.

Another WWDC, another step closer to macOS and iPadOS merging. This year, it’s official: windowing has arrived on iPad — with resizable windows, top-left traffic lights, and full menu bar support.

For iPad users, this is certainly a welcomed change and brings about hope that, one day, the two platforms will truly become one (Where’s Xcode on iPad already?).

On the developer front, if you thought Liquid Glass was the biggest hit to your teams backlog this year, wait until you run your app through the Windowing system. If your app has multitasking enabled, your app is open to a number of potential new states to account for.

• For pure iPad experiences, you may need to account for iPhone-sized scenarios (even if you’ve accounted for side-by-side)

• For cross-platform apps, you could bring your iPhone experience to iPad

• States could exist that are between iPad and iPhone (iPhone feel with iPad components) and could be previews of phone form factors to come

• A new micro-state now exists

Turning MLB Tracker into an iPad App (Kinda)

To quickly convert MLB Tracker (my WWDC Demo app) to have an iPad Variant, I took advantage of ViewThatFits. This allowed me to do a few things:

• Be able to switch between NavigationSplitView and NavigationStack

• Watch how and when iPadOS would decide to switch between split and stack

• See if there were any in-between states

MLB Tracker on Github

For both the Scores and Standings experiences, I used something like the following:

ViewThatFits {
    NavigationSplitView {
        SummaryTemplateView(
            ...
        )
    } detail: {
        GameDetailSheetView()
    }
    
    NavigationStack {
        SummaryTemplateView(
            ...
        )
    }
}

Simple, but enough to experiment with.

A Chronicle of Changes at Different Window Sizes

Overall, this is how MLB Tracker looks at various windowing states:

You’ll notice that there’s actually a few states as we scale the window size down. Unfortunately, scaling the size back up doesn’t automatically restore the larger state, either.

Here’s a breakdown of the various states.

Portrait Full

Landscape Full: iPad TabView / Split

Resized: iPad TabView / Switched to Stack

Resized More: iPhone TabView / Still Stack

Minimum Size: Smaller than iPhone SE

A New Micro-State

With window resizing comes the ability for users to create tiny windows with micro states. It’s something that isn’t quite a widget, but certainly goes smaller than your typical iPhone experience. The minimum size I found (running the iPad A16 simulator) was 375 x 486.

This could work for many experiences, but I would imagine there are some that already find it difficult to work on iPhone SE screens (568 x 320). That kind of micro-state might already break UI on an iPhone SE — and shrinking below that risks hiding essential UI or causing accessibility breakdowns.

Unfortunately, setting a minimum frame for a view does not seem to be respected. Here, I set a minimum height and width on my Content View and resizing completely breaks the experience:

And defaultSize and windowResizability don't really do anything.

Possible Micro-State Solution: Cover Page

If your experience really cannot work in certain frames, you could consider using a Cover Page to block access to the experience. Here, I state that whenever the window goes below a certain size (the SE dimensions), show a Text instead:

ViewThatFits {
    ContentView()
        .frame(minWidth: 320, maxWidth: .infinity, minHeight: 568, maxHeight: .infinity)
        
    Text("Please resize the window")
        .font(.headline)
}

The result gets the job done, but if your app allows for it then a more robust cover experience would certainly work, as well:

Prepare for Foldable iPhone Through Window Testing

Apple seems to be full steam ahead with releasing a foldable iPhone next year (production on the display for it has begun). The obvious scenario is that your app may exist on double the normal screen width. Using iPad's Windowing, we could probably emulate what this experience could look like (repost from above, but for contextual emphasis):

There's a chance split view could appear on the foldable (think landscape on a Pro Max), or perhaps a unique split view with a sidebar more appropriate for a foldable phone factor.

Embrace the Windows of Opportunity

Windowing for iPadOS really is the natural next step in the evolution of the platform. While it could certainly mean your development team has its work cut out for it to account for the new system, users will certainly appreciate it.

You can also look at windowing as fitting in with the new Liquid Glass design system. Think about how windows “fluidly” resize and how Apple would love for your experiences to “fluidly” adjust. In the updated Human Interface Guidelines, there are three new design principles: Hierarchy, Harmony, and Consistency. The latter states:

“Adopt platform conventions to maintain a consistent design that continuously adapts across window sizes and displays.” - Apple’s Human Interface Guidelines

That’s as straight-forward as it can get. We’re in the Liquid Glass era now: the sooner we embrace its principles, the better we can modernize our apps for our users!

Need help with Liquid Glass? Consider a Consultation with the Captain!

Learn About Liquid Glass Consultations

Search: one of the biggest features of all technology, as well as one of the most significant quests in life. Think about it: searching for (in no particular order) the right opportunity, the right someone, the right information, the right plumber, and (occasionally) Spock.

As we enter deeper into the Age of AI, search remains a core component of yet another technological era. Digital search expectations have gone beyond expecting a list of SEO-optimized websites and/or a wikipedia article. We expect interactive, collaborative, and expansive responses. In short, we're not just looking for answers anymore, but discoveries.

Where Liquid Glass (LG) takes search fits with what (I believe) is the true goal of Apple's new design system: ushering apps into the new age. I've talked about how Apple can passive aggressively push devs into a more modern (if not opinionated) direction (see my article on Translation. LG is all about that in many different doses, and search just happens to be one of the most glaring ones of all.

The Two Pattern That Have Shifted, At Large

Apple shared in Build a SwiftUI app with the new design that two main patterns have shifted in LG. First:

"Search in the toolbar (on iOS) places the field at the bottom of the screen, within easy reach.
And on iPad and Mac, it appears in the top-trailing position of the toolbar."

- Build a SwiftUI app with the new design

Simple change here, but a good one to note. In both scenarios, search gets its due by being placed in the expected, optimal utility location on screen.

The second change is narrowed to iOS, but is no doubt one of the biggest navigational shifts in LG:

"The second pattern is to treat it as a dedicated page in a multi-tab app."

- Build a SwiftUI app with the new design

This single statement doesn't quite capture the impact of what's changed, so let's unpack a bit.

The Brilliant Audacity of iOS's TabView Search

The TabView in LG has already caused quite a stir. If you've read my initial exploration of the new TabView in my MLB Tracker POC, then you know how excited I've been by the potential it unlocks (particularly if starting a fresh app). In review:

• Hovers over content, affording more visibility of the content behind it

• Can have minimizing behavior set to provide even more real estate to the TabItem being displayed

• Allows for a bottom accessory that can reside above or inline with TabView

Calling for search to be a dedicated page adds to LG's opinionated design system while also scaling with the idea that search goes beyond answer seeking and into discovery. This new space is a central spot where users can specify what they initially were looking for as well as explore the wealth of other information and experiences your app offers.

As developers, the question we’re answering is “What do I need to show the user before they even search?”.

Apple’s Guiding API

The way Apple drives this discoverable search concept is through the API, itself. When it comes to adding a TabItem with the search role, it actually requires you to provide 3 other things in order to actually appear in the new LG fashion:

1. The searchable modifier - ensuring that search is still the key feature

2. Contents of the TabItem wrapped in a NavigationStack - insinuating that search should lead users on paths, not just destinations

3. Make it the last "fitting" tab without triggering the "More" tab - if you have more destinations for your users to navigate to than can fit in the TabView, you'll need to relinquish "auto-collating" them into the "More" tab and, instead, assume the responsibility of making them explorable from the dedicated page (we'll see an example of this in a bit)

In code, this looks something like this:

@State private var searchText: String = ""
...
TabView {
    Tab("Scores", systemImage: "baseball.diamond.bases") {
        GameListView()
    }    
    Tab("Standings", systemImage: "figure.baseball") {
        StandingsView()
    }
    Tab("Scout", systemImage: "magnifyingglass", role: .search) {
        NavigationStack {
            ScoutView()
        }
    }
}
.searchable(text: $searchText)

In a sense, Apple would love for you to adopt the new search, but forces you to make it a conscious decision. The reward is the foundation is laid out and ready for exploring.

Exploring Examples from Apple

Apple has already implemented the new dedicated search page in a few of their iOS 26 apps, namely News and Health. In both of the iOS 18 version of the apps, there was already a dedicated tab providing a traditional implementation of the search/discoverability pattern:

In iOS 26, those pages call for special attention with tabs that stand out:

And when we enter those pages, the underlying views look very similar, but search is given better access from the bottom of the screen while also giving back screen real estate (instead of TabView and the search bar being present, the two are combined floating over the content).

Scouting Out Search in MLB Tracker

To see what it would look like in the MLB Tracker, I added the necessary components I listed earlier and asked Xcode's AI Assistant to create a demo "ScoutView" (sticking with baseball terms). The result fit right in with the app's theme and even begun to inspire future features that could be added to the tracker:

What To Look For In The Future

This "spotlighting" Apple is providing for search in Liquid Glass intuitively elevates its role in UI to match where search and discovery is headed. With Apple slowly prepping more AI features while also calling for more Intents, Snippets and Widgets, I believe that “discoveries” are to lead us to “enriched”results.

In the MLB Tracker, searching a player could navigate me to the “Players” feature in the app, but maybe it also shows a snippet of the player as I’m continuing to type. Something that highlights that it’s a player result alongside the information and highlights I was hoping to see, with the option to dig deeper upon interacting with the snippet.

And then maybe this sets up my app data and “micro-experiences” to be discoverable beyond my app. Perhaps by Siri, other apps, AI models… who knows.

But for now, at least, it starts in your app. All in the form of a tab that represents that the treasures you’ve prepared for your users are ready to be used and explored.

If you would like to join the next session of Office Hours, consider subscribing!

Subscribe now

After WWDC25, I kept building on my mocked-out MLB Tracker app — this time exploring Apple’s new AI tools: Foundation Models and Xcode 26’s built-in assistant. I also took the new #Playground macro for a spin. This post is part dev log, part proof of concept, and full of baseball energy.

To follow along, check out the latest code on Github.

Foundation Models is a Game Changer

Since the app already has 2 main screens (one for game scores and another for team standings) complete with mock data, the simplest generative AI feature I could think of was a summarizer. Yes, both screens are served visually well through Lists. But what if I was driving or out for a run and preferred hearing an up-to-date summary of where things stood in the MLB?

Starting with game scores first, I first created a function to print the game data neatly to a String and created my first Playground to see the result:

#Playground {
    print(printBaseballGamesDetails(generateMockGames()))
}

Tremendously impressed already, but more on that later...

Then, I created a new class called ScoresSummarizer. In there, I added a static base prompt that would make the request with detailed instructions for what I wanted. To help me write the prompt, I got real meta with it and asked ChatGPT in my browser to make me a perfect prompt (see full prompt on Github).

Then I added a static function that would combine the printed data with the prompt, generate the model session, trigger the combined prompt, and return the response:

static func summarizeGameScores(_ games: [BaseballGame]) async throws -> String {
    let gameData = await printBaseballGamesDetails(games)
    let combinedPrompt = basePrompt + gameData
    let session = LanguageModelSession()
    let response = try await session.respond(to: combinedPrompt).content
    return response
}

To test it out, I created another Playground closure and checked the results. Already I can foresee my future code bases riddled with Playgrounds:

#Playground {
    print(try! await ScoresSummarizer.summarizeGameScores(generateMockGames()))
}

While not instantaneous (I run a Mac Mini M4 w/ 16 GB RAM. Come at me, bro) I was pleasantly surprised by the response generated:

Meanwhile:
Bottom of the 8th in Atlanta — Braves trailing 8-3 against the Diamondbacks!
Over in:
Bottom of the 8th in Cincinnati — Reds clinging to a 4-3 lead over the Blue Jays!
Also tonight:
Top of the 7th in Oakland — Athletics take an early 9-7 lead over the Cubs!
Meanwhile:
Bottom of the 9th in Milwaukee — Guardians edge out Brewers 1-0!
Also tonight:
Bottom of the 9th in San Francisco — Giants bounce back with an 8-1 victory over the Dodgers!
...

Ground-breaking sports journalism? No. But it's taken my data and turned it into something more readable and, in particular, easy to listen to. And all this without using Generable, Guide, or Tool. Just a basic prompt and response.

Displaying the Results

To show off the summary in the app, I first added a task to my Scores view that triggers generating the summary. I also set a new @State property to collect the response and another to track that the summary has been generated.

@State private var summaryReady = false
@State private var generatedSummary: String?

...

.task {
    do {
        generatedSummary = try await StandingsSummarizer.summarizeStandings()
        summaryReady = true
    } catch {
        // Handle error if needed
    }
}

Once generated, a button with a baseball SF Symbol appears in the top toolbar (Liquid Glass style, of course). Once tapped, a sheet appears displaying the response:

Speaking the Results

In the GIF above, you'll see I also added a "Read Summary Aloud" button. When tapped, I trigger a read out of the summary using AVSpeechUtterance and AVSpeechSynthesizer:

private func readSummary() {
    guard let summary = generatedSummary else { return }
    let utterance = AVSpeechUtterance(string: summary)
    utterance.rate = 0.57
    utterance.pitchMultiplier = 0.8
    utterance.postUtteranceDelay = 0.2
    utterance.volume = 0.8
    let voice = AVSpeechSynthesisVoice(language: "en-GB")
    utterance.voice = voice
    let synthesizer = AVSpeechSynthesizer()
    synthesizer.speak(utterance)
}

This was a new feature, but it highlights how easily we can generate content that can power other features in iOS. Combining summaries and speech can really change the "hands-free" game!

Cleaning Things Up with Xcode AI

I took all the code added for the Scores Summarizing (model code and UI additions) and copied it over for the Standings feature. The only difference (besides changing some names) was generating a different prompt for the Standings summary. But beyond that, the structure between the Game Score and Standings screens are almost identical.

Which led me to an idea. I asked Xcode AI to look at the similarities between the two Screens and create a new base Template View for reuse purposes. The result was detailed steps listed out on how it would approach the task, then the generation of the Template View, and a refactoring of the feature views to utilize the new template.

I hit run and, predictably (though still amazingly) the app was functionally the same. It was really satisfying to not only watch my POC code undergo some healthy gut rearranging, but for it to work on the first go.

Stealing Bases with Xcode AI

While impressed, I wasn't done experimenting with AI just yet. During the opening sessions, they showed off drawing a UI by hand, uploading it to the chat, and having it spit out impressively matching SwiftUI.

This felt like the big one to test out. And so, I imagined that, when a user taps on the live score in the tabview bottom accessory, a sheet would appear with a more detailed overview of a game's current status. Breaking out the ancient tools known as paper and pen, I drew a fantastic rendering of my vision:

I snapped a pic, AirDropped to my machine, and dropped it into the chat with the prompt "when a user taps the tabview bottom accessory, a sheet should appear with the current games details displayed using the attached drawn UI. Create this view and attach it to the tabview bottom accessory". Within seconds, it delivered something that, in all honesty, beat my expectations:

It's far from perfect, for sure. But in terms of translating a drawing I made in under a 30 seconds (see squiggles in the game summary section), I was particularly impressed that:

• It added relevant mock text to the summary section instead of the squiggles

• It nailed the three dots for the outs

• It suggested and implemented medium and large detents

• It built a baseball diamond (albeit 45 degrees off)

With some small UI fixes (diamond angle and padding on top in medium detent), I have a UI that I can begin to hook up to data in no time (probably seconds with just another prompt).

AI for MVP?

This time around I got to mess with AI features on-device and off. For all the speculation around AI, Apple Intelligence, and WWDC, at the very least developers won big this year.

On-device

Foundation Models are gonna help Apple developers usher in a new era of AI powered apps (mind you, I did a basic prompt without even getting into Generable, Guide, or Tool). Yes, we've already seen quite a bit of AI-powered apps already, for sure. But on-device generation brings with it privacy, security, immediacy, unlimited uses (seemingly), and network-less access.

Sure it's capabilities are limited compared to server-driven solutions. We're still at the dawn of this new era, one where individuals and organizations are becoming more aware and concerned about the loss of privacy and control of the information. As on-device models become increasingly better alongside ever-evolving supporting hardware, I guarantee its value will scale with it exponentially.

Off-device

As for Xcode's AI features, in spite of the concerns I just mentioned about server-driven solutions, it's really fun and a huge game changer for Apple developers. Having worked with other solutions like Cursor, Claude, and Copilot (just realized they all start with C's), I'm positive there are pros and cons to each.

Apple has the advantage of providing a baked in solution that could integrate with their IDE in ways no other solution could. With what I saw during sessions and experienced on my machine (so far), I believe they proved that point really well on the first shot. That makes me hopeful that we could potentially see really incredible stuff over the next few WWDC's. Just imagine bringing that power over to Instruments and supercharging app optimization and performance.

Seventh-inning Stretch

As for my exploration into WWDC goodies, this has only been a taste so far. I've been digging deep into Liquid Glass, understanding more about what's changed, and letting it sync in that Apple means it when they say it's a new design system.

As the summer continues, I'll be sharing more expansions to this little MLB Tracker app as well as focused articles on specific topics. So stand up, stretch those legs, grab some cracker jacks, and stay tuned!

This year's WWDC has really got me thinking about what's next for Apple development. Liquid Glass ushers in a new era of mobile design and, with it, some really radical UX perspective shifts. SwiftUI has matured to a point where (alongside a redesign) the primary focus feels like its shifted in supporting and improving performance. And then there's Foundational Models, introducing on-device intelligence to both the consumer and developer masses.

While I've been enjoying watching the sessions... I needed to get my hands dirty. So I downloaded Xcode 26, (accidentally) installed macOS Tahoe on my personal machine, and got to work creating a base iOS app that will be my testing grounds of sorts. Probably for the next few articles.

For this starter article, we'll try using Xcode 26's new AI tools and Liquid Glass's new TabView. And let me tell you... I think Apple knocked it out of the park with these.

Starting Line-up: Creating a Demo MLB App

To test things out, I built a simple (mocked out) baseball scores app. A TabView will drive out two main pages: scores and standings. Scores will simple list out games and there scores while standings will list out team standings based on League and Division.

This will give us an opportunity to experiment with the new Liquid Glass TabView. I'm extremely curious about how much real-estate we're really gaining by the glass look and floating design, plus the new minimizing behaviors we can apply. To make it even more worthwhile, there'll also be the new bottom accessory to the TabView that will show the score of a "live" game.

Play ball!

That's already a tall order and I didn't want to take up too much time away from watching sessions. Therefore, I enlisted the new intelligence features in Xcode 26 to help build the base of the app.

Source Code on Github

I opened the chat window and explained the two main views and asked for the data models I would need. I then asked it to create basic UI's for both based on the descriptions I gave earlier. The results were not too shabby:

You can see that the TabView is no longer a bar but the floating dock we’ve seen in visionOS. You also can tell that, while you can see the List behind the tabs, there’s a frosted look obscuring the details.

For the sake of focusing this article on the new things, I'm not gonna post the snippets for the stuff up to this point. But, if you are curious, you can view the code on Github.

Scouter's Eye: Creating a Live Score Accessory

Imagine your checking the days scores and standings but there's a game going on right now and you wanna stay on top of it's progress. The new TabView Bottom Accessory honestly feels like a perfect use of this feature.

Now, remember, I'm just playing with mock/static data, but I created a super simple View that has a baseball indicator symbol, the abbreviations and scores for both teams, and what inning it is. Enough to track what's going on.

.tabViewBottomAccessory {
    HStack {
        Image(systemName: "baseball.diamond.bases.outs.indicator")
        Text("\(MLBTeam.yankees.abbreviation) 4 - 3 \(MLBTeam.redSox.abbreviation)")
            .bold()
        Image(systemName: "arrow.up")
            .font(.caption)
        Text("7")
    }
}

The result looked great:

Then I took it a step further by adding .tabBarMinimizeBehavior(.onScrollDown). And boy did I really, really like the results:

I love this new accessory plus minimize behavior! That is just one of the coolest things I've seen this year from WWDC. The accessory, itself, is minimalist, yet informative while persisting across tabs (notice in the GIF that I switch tabs and the accessory stays in place). It can easily be swapped out for different views (either by user choice or based on some context) and can be made tappable by placing a button or gesture.

To me, it sets a hopeful tone about what Liquid Glass could be trying to achieve. Let me explain.

Approaching the Mound

Think about it: The TabView literally eats up a portion of your screen's real estate displaying the same icons and text almost permanently. When you think about it, it's such an incredibly dead waste of space just to ensure a basic navigation. Yes, we could have added Badges, but the View has remained mostly unaltered for ages.

Just enabling the new minimizing behavior (without an accessory) is nice as it neatly folds and packs the tabs to the bottom corner, though it leaves a frosty covering in it's wake:

What takes this to a whole new level is that by enabling minimizing with an accessory, the tabs fold into that corner and the accessory then glides in to the now open space. Not only does this return back the space the accessory took above the TabView, but it makes the TabView space actually useful for more than just Tab Navigation!

On Deck: Summaries with Foundation Models

The next feature I want to test out is Foundation Models. I'd like to see how quickly I can get prompts and responses setup, so in my next article I'll create features that will summarize the list of scores and the current standings. Simple, but enough to lightly test how quickly we can add basic on-device AI features into our app (no networking, accounts, or web API's necessary). I also hope to use the new #Playground macro to test out my prompts in the IDE instead of re-running every time.

Looking forward to taking this demo app to the Big Leagues with you all!

Source code for this article can be found on Github.

Looking to Talk More WWDC? Join Office Hours on June 19th!

Looking to talk more about WWDC25 and all the other goodies we got this year? Ready to vent about and/or praise Liquid Glass? Wanna ask how I tested some of these things? We’ll talk about it all!

Join as a Paid Subscriber on July 19th at 11:00 am EDT! If you aren’t a member already, consider joining with a special discounted rate!

Get 10% off for 1 year

WWDC25 is here and both the Keynote and Platform State of the Union are officially behind us. The time for (most) speculation is over as we enter a time of processing and (as we go through the week) digging deeper into all the new goodies.

Here's a rundown of some of things I took away from the sessions, with a promise to share more of my thoughts as the week progresses...

Rumors Were On Point

Majority of rumors I had seen circulating proved to be true. In fact, it was almost too many things that proved to be true. It almost makes me wonder if they were leaked on purpose or, at the very least, guarded with lax security. But the things we now know were true leaks were:

• All OS versions (and Xcode) will adopt an annual-based versioning system (e.g. iOS 26 for 2026)

• The UI re-design is official and dubbed Liquid Glass (see below for more details)

• Apple Intelligence was discussed at length, but (as expected) Apple punted most new features until "later this year"

• Conversely, Apple did announce the new Foundation Models Framework and significant App Intents improvements, exposing apps to more AI services and tools both on-device and off (see below for more details)

• The gap between iPadOS and macOS narrowed significantly more than in past years with new Windowing and File systems

While rumors gave us possible insight, it was interesting to see these come to life during the talks.

Liquid Glass

It wasn't much of a surprise that the new UI design system would be glass-based. Seeing it in it's glory, however, was pretty awesome. Keeping it high-level for now, what I'll say is that almost every native component has been altered. And there are a ton of navigation and micro-interactions changed or added.

Apple shared that the guiding design principles at the core of the redesign were Hierarchy, Harmony, and Consistency (you know, HHC). At first glance, they seem to have achieved that very well and in intuitive ways.

What is abundantly clear is that every development team will have its work cut out for it this year. While it all looks very cool and impressive, it will certainly send many teams into a frenzy trying to figure out if it breaks any existing UX.

Apple offered an approach that the developers should consider when tackling the redesign:

• Recompile: the re-design will automatically take affect once recompiled

• Refine and Tailor: in other words, refactor and adjust accordingly to restore UX flow and harmony

• Liquid Glass Effects: once stable, consider diving deeper into Liquid Glasses new features and applying them to your app

Documentation on Adopting Liquid Glass is already posted and is a must-read.

SwiftUI: No Longer The New Kid on the Block

When you look at the SwiftUI Update page and compare the June 2025 list to June 2024, it is significantly smaller. I'm sure this is disappointing for many devs who had specific SwiftUI items on their wishlists this year.

Given the scope of Liquid Glass, I'm really not that surprised. Apple made it abundantly clear that a lot has changed with the redesign and given that we still have a week of sessions ahead of us, I don't think we should underestimate how that may alter our wishlists, as well. I mean, just look at this "subset" of areas Apple said was altered:

For better or worse, we will need to reexamine majority of components, modifiers, interactions, and customizations to understand what problems still exist, have been solved, or have emerged.

Performance and Instrument Gains

Apple stated that SwiftUI performance has improved, specifically for macOS which has now adopted idle pre-fetching. It was specifically called out that Lists and Tables (note: not Scrollviews or other containers) have been optimized, with macOS claiming Lists with 100K items loading 6 times faster and updating 16 times faster.

While briefly mentioned, one of the most exciting new things to me was a new SwiftUI Performance Instrument which promises to dig into specific/suspected views that could be hindering performance. This is a tremendous win for SwiftUI as majority of performance issues I've come across are really the result of unoptimized code.

Xcode: Pleasant Surprises

In my pre-game article, I expressed that I didn't mind if no new AI tools or fancy features made it into Xcode this year, I just wanted more stability. I still want the stability, but I'd be lying if I said I wasn't excited about some of the new things they showed today.

The new AI Chat is not only an built-in solution to Copilot's extension, it takes it much further by having better interaction with the IDE, itself. Some key highlights were:

• Swapping generated snippets in and out

• History Slider so you can revert or cherry pick generated changes you made over time

• Automatic bug fixing (not that I believe it will work every time, but gets you a head start)

• Sketch-to-SwiftUI

• Ability to choose LLM Model/Service

I also cannot wait to use the new Playground macro. Think SwiftUI Preview but for your logical Swift code.

This could be a more direct way of testing your code and inspiring better unit tests.

Foundation Models Framework

The introduction of the new Foundation Models Framework was very exciting. It promises private, on-device generative capabilities for your apps (and Shortcuts). The framework looks really simple, yet powerful to adopt in your app.

Getting a model spun up and testable with the Playground macro takes only a few lines:

Preparing structs to receive generated data is as simple as using the @Generable macro. Guiding responses is also made easy using the @Guide macro:

I really can't wait to play with this new framework more. I'm sure there will be limitations, but on-device and privacy make this very appealing as a dev.

And Many More...

There were a number of other goodies that were announced that I look forward to diving into throughout the week (and, really, the rest of the summer). And I can't wait to write more articles and code exploring these topics beyond WWDC!

For now, the Sessions page provides a list of our daily dose of introductions and walkthroughs. And new this year is a Guides page. This collates the topics and sessions very neatly with great little summaries and list of related links. The best part is for categories such as Swift and SwiftUI, they also link to their respective update pages that list out their new associated documentation pages.

As promised, I will be posting a few more articles this week as sessions release and goods are digested more. And don't forget that next week will be a very special Office Hours where we'll discuss WWDC at-length!

Not long ago, I took part in a healthy debate: Should an experience use SwiftUI’s built-in Form, or roll its own custom-styled container?

One camp argued in favor of Form, emphasizing that it follows Apple’s Human Interface Guidelines (HIG) by default. They believed that even if Apple updated its appearance in the future, sticking with Form would help us stay aligned with native platform conventions. Others weren’t so convinced — they wanted full control over styling, worried that relying on Form might lock us into a brittle or inflexible design path.

As we explored both sides, something became clear: this wasn’t just a styling choice. It was an architectural and design philosophy decision. So in this article, we’re going to explore what Form actually does, why you might (or might not) want to use it, and what it really means to build a “form” in SwiftUI.

What Form Actually Does

At its core, Form is just a container view— a specialized type of stylized List that Apple maintains and updates.

Wrapping your views in a Form applies platform-specific styling:

• On iOS, you get grouped rows, padding, and label alignment.

• On macOS or visionOS, Form adapts to each platform’s standard form behavior.

• In many cases, it will also group toggles, pickers, and text fields with proper accessibility behavior and spacing.

Form follows the Human Interface Guidelines (HIG) out of the box, making it easy to build views that "look right" without customizing spacing or alignment manually.

Wait — what about FormStyle?

SwiftUI does allow you to define a custom FormStyle. But after exploring that path, I found that creating a custom FormStyle feels nearly identical to just building your own container with a VStack, ScrollView, or even a custom Layout. You might gain some semantic clarity — e.g. denoting that “this block of UI is a form” — but in practice, you still need to handle layout and appearance yourself.

Experiment: Comparing a Custom FormStyle vs Custom Container

I created a quick little experiment. I made a ridiculous custom FormStyle:

struct CustomFormStyle: FormStyle {
    @MainActor @preconcurrency public func makeBody(configuration: CustomFormStyle.Configuration) -> some View {
        ForEach(sections: configuration.content) { section in
            VStack {
                section.header
                    .font(.title)
                    .foregroundStyle(.purple)
                ForEach(subviews: section.content) { subview in
                    subview
                        .foregroundStyle(.pink)
                }
                section.footer
            }
            .background(Color.red)
        }
    }
}

extension FormStyle where Self == CustomFormStyle {
    @MainActor @preconcurrency internal static var custom: CustomFormStyle {
        .init()
    }
}

I then created a custom container… with essentially the same code:

struct CustomContainer<Content: View>: View {
    var content: Content
    
    var body: some View {
        ForEach(sections: content) { section in
            VStack {
                section.header
                    .font(.title)
                    .foregroundStyle(.purple)
                ForEach(subviews: section.content) { subview in
                    subview
                        .foregroundStyle(.pink)
                }
                section.footer
            }
            .background(Color.red)
        }
    }
}

The result was that both custom implementations looked exactly the same, while using Grouped or Columns styles looked as expected:

In short: Form is a pre-styled container. Nothing more. If you don’t like Apple’s design decisions for forms, you may be better off just making your own.

Join us June 19 @ 11am EDT for a special Office Hours: Post-WWDC Edition!

We’ll be talking all about the WWDC goodies Apple brings this year and what they could mean for us devs! Join the Captain’s Crew as a Paid Subscriber to get access!

Get 10% off for 1 year

The Case For Using Form

There’s a reason Apple made Form in the first place: it streamlines a lot of common UI work and keeps your app aligned with system conventions.

Here are some good reasons to use it:

• ✅ Adheres to HIG automatically
  You get consistent spacing, font sizes, and affordances with almost no effort.

• ✅ Future-proofing
  If Apple updates Form’s design in a future OS version, your views adapt for free — no manual restyling required.

• ✅ Less UI boilerplate
  You don’t need to micromanage padding or alignment across multiple sections and controls.

• ✅ Accessibility baked in
  Screen readers understand how to navigate grouped controls in a Form, and focus behavior is handled for you.

• ✅ Easy integration with system controls
  Pickers, toggles, and steppers drop in with ideal spacing and behavior.

For many apps — especially settings pages or profile screens — these defaults are exactly what you want.

The Case Against Using Form

Despite its convenience, Form also comes with tradeoffs — especially for teams with strong design systems or highly customized layouts.

Some common drawbacks:

• ❌ Limited styling flexibility
  If you want custom fonts, backgrounds, insets, or separators, you’ll find yourself fighting against Form’s default styling.

• ❌ Inconsistent behavior across platforms and OS versions
  What looks great on iOS 17 may feel odd on macOS or completely different on visionOS.

• ❌ Difficult to theme or brand
  Customizing Form to match your app’s unique look often involves painful workarounds.

• ❌ Hidden structure
  Because Form is backed by List, things like section spacing and background bleed may be controlled behind the scenes.

• ❌ You're locked into Apple’s opinion
  If you don’t agree with the HIG’s take on forms, you're essentially styling against the current.

And, as I found while exploring FormStyle, the moment you start trying to "override" too much, you’re essentially re-implementing a container. At that point, it may be simpler — and more sustainable — to just write your own.

A Middle Path?

Here’s the good news: this isn’t an either/or situation.

You can — and maybe should — use both approaches depending on context:

• Use Form for data entry views where HIG compliance is a benefit (e.g. settings, registration, feedback).

• Use custom containers for marketing-heavy or brand-driven forms that require pixel-perfect control.

• Consider wrapping fields in your own styled components like FormSection, FormField, or FormGroup, which provide the structure of a form without relying on Form itself.

Ultimately, this is a design system decision, not just a SwiftUI one. If your team values native alignment, Form is a gift. If you’re chasing precision and consistency across platforms, rolling your own container might be the better path.

Final Thoughts

SwiftUI’s Form isn’t magic — it’s just a container Apple maintains and styles for what it considers “form-like” interactions. And that’s not a bad thing. But it also means that if you disagree with Apple’s styling, you’re probably not looking to tweak Form — you’re looking to replace it.

My advice? Don’t fear the Form. But don’t treat it as sacred either. Know what it gives you, and what it costs.Then decide what’s best for your team and your users.

Happy forming.

Container Views are the steel beams of SwiftUI. They provide the structure that holds all of its contents up, as well as for everything that gets built around it. Whether List, Stack, Group… all of these are core to declaratively composing experiences.

The concept of being able to actually create a custom container has been tossed around since SwiftUI was released. However, you could only go so far until you, most likely, needed to just rely on one of the given containers.

That is, seemingly, until WWDC24's session called Demystify SwiftUI Containers, where they introduced new API's (ForEach(subviews:) and Group(subviews:)) to finally gain access to the finer points of a container. All seemed exciting and well in the SwiftUI universe.

I decided to give this API a whirl and, at first, I was amazed at how simple and powerful it was to spin up a container in no time. I then decided to take it a step further and add some basic interactions. And that's when things took a turn...

Ease at the Cost of Performance?

As easy as these “container constructors” are, it was heartbreaking to hit a tremendous catch: I couldn’t make them reactive. At least, not in a performant manner.

Let me explain.

I experimented with Apple’s own sample from Demystify SwiftUI Containers. When you download the sample code, there’s a v2 (just uses the ForEach) and a v5 (fully featured with Group and Sections). With both, I converted one of the sets of data into a State variable and created a tapGesture to add an item to that State.

My expectation was to see the new item appear, and I did.

However… I also expected that, when monitoring with the SwiftUI Instrument, there would be evidence that only a new item was being drawn.

What I Tried (And The Sad Results)

I tested extensively. Meaning, I tried:

• Trying as-is

• Adding .id(...) to each subview

• Wrapping each subview in EquatableView

• Creating a custom ContainerValue to create unique id’s within the ForEach

None of these techniques reduced the redraw count. SwiftUI still diffed the subviews collection seemingly from scratch every time (meaning that despite any identifiable or equatable help I gave it, it was as if they didn’t exist). This resulted in a ton of draws per tap. Worse, with every tap, it consistently grew by 2 draws. This meant we were experiencing a linear growth in performance loss.

I really wanted to see better results. I wanted to believe there were better results. And so I tried another experiment. One that involved breaking into one of the worst kept secrets in the SwiftUI API.

Worst Kept Secret: VariadicView

One of the coolest discoveries in SwiftUI was its secret API. Chris Eidhof shares a bit about this as a footer in one of his articles where he quickly shares how we can go "spelunking into the .swiftinterface".

In the same article, we’re introduced to VariadicView. Before the ForEach and Group options, THIS was how custom containers were being built at the expert level.

And so, I had a thought: what if the worst kept secret was the best solution?

Testing the Theory

To test the theory, I took a trusted example of VariadicView from a trusted source: Jacob from Jacob’s Tech Tavern. He wrote a great article on VariadicView that you should pause right now and go read (and then come right back). It seemed only right that I pull his repo as a base, attempt creating a converted version of his example, and then compare their performance using Instruments.

Implementation Comparison

What I did was pinpoint his Variadic implementation:

struct ChatList<Content: View>: View {
    
    var content: Content

    init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }
    
    var body: some View {
        _VariadicView.Tree(ChatLayout()) {
            content
        }
    }
}

struct ChatLayout: _VariadicView_MultiViewRoot {
    
    func body(children: _VariadicView.Children) -> some View {
        List {
            ForEach(children) { child in
                child
                    .inverted()
                    .listRowSeparator(.hidden)
            }
        }
        .listStyle(.plain)
        .inverted()
    }
}

Then, I created what should represent the ForEach approach:

struct ChatContainer<Content: View>: View {
    
    var content: Content

    init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }
    
    var body: some View {
        List {
            ForEach(subviews: content) { subview in
                subview
                    .inverted()
                    .listRowSeparator(.hidden)
            }
        }
        .listStyle(.plain)
        .inverted()
    }
}

Comparing the code, it eliminates a few lines of code, making for a tighter implementation. It would have been great if the results matched.

However, when using ForEach (again, trying all the various ways), not only was it less performant (42 draws on tap as opposed to only 13 with Variadic)… the UX was negatively affected. Using Variadic, a new message would appear with a bit of an animation. Now, no animation.

Resolution is the Problem?

In the WWDC session on custom layouts, Apple clearly distinguishes between Declared Subviews and Resolved Subviews. The newer APIs, including subviews in layout and container contexts, work with the resolved version — that is, a system-generated representation after the SwiftUI engine computes the view hierarchy.

But here’s the catch: by calling them “resolved,” Apple hints at something deeper — any change to the underlying set of views requires a re-resolution. That includes adding or removing just a single item. And when resolution resets, the identity of each subview is essentially re-evaluated, leading to widespread redraws, even if most views are unchanged.

Key Takeaway

When building custom containers in SwiftUI, ForEach(subviews:) may look like the right tool — but it doesn’t diff how you would expect. This leads to massive redraws as children are added or removed. Surprisingly, VariadicView is the only API I found that eliminates those redraws and scales cleanly with dynamic content.

Spread the Word: VariadicView is still the Custom (Dynamic) Container Solution

This article was to be a victory lap for Custom Containers when added to my Trello board of topics. And, to be fair, it is a win if you are creating static container in your experience.

The fact of the matter is that there is a fundamental limitation to ForEach(subviews:) that is not immediately clear in the docs. Therefore, if you anticipate any interactive/dynamic aspects of your container, then perhaps turn to the secret ways of the shadows... er... VariadicView.

VariadicView might not be the headline API in this story, but it’s still the hero behind the scenes.

Clip is from the first Office Hours on May 7. To join future sessions, upgrade to a paid subscription and join the crew!

Ahoy there! Tomorrow morning (June 19 @ 11am EDT) will be the second session of Office Hours! I cannot wait to discuss all the WWDC goodies and where we see things headed for SwiftUI!

If you are a paid subscriber, thank you for your support and I look forward to chatting with you! If you are not yet a paid subscriber, then consider joining and you will get access to tomorrow’s Office Hours, as well!

Subscribe now

We’ll start with brief introductions and a quick review of the events last week at WWDC. From there, I’ll open the floor to any questions or topics from the crew. Lastly, depending on time, I’ll dive into some topics I think are really interesting and kick start some conversation for the group.

Read more

We're roughly a month away from the most wonderful time of an Apple Dev's year: World Wide Developer Conference 2025. Every year we are bestowed goodies from Cupertino (and beyond) that often give us insight on where Apple is hoping to take the platforms and app development (ranging from glimpses to full-blown fire hose).

Some of my fellow writers have already shared their thoughts on and wishes for WWDC (shout out to Majid). I'm always trying to read the SwiftUI Sea, myself, and so here are some of my thoughts for this year.

The Mood Going In

This year feels... odd. There's already been strong rumors of things to come, doubts casted on what we'll see, and questions about where Apple actually envisions things are headed towards. That's awkward to say about the company that introduced the world to affordable PC's, revolutionized the music industry, radically changed the world with smart mobile devices, and so on.

But with Vision Pro production being halted (albeit possibly to prepare for a Vision Pro 2) and Apple Intelligence delays, it's caused some concerns about Apple's ability to pivot to "the next big thing".

I don't believe this threatens the ecosystem Apple has built and, therefore, those already a partaker in it will most likely remain faithful (did that sound cult-of-mac like or what?). However, FOMO (fear of missing out) has already begun to creep in. And especially as a developer who uses Xcode daily.

A Word on AI and Xcode

I want to see more Apple Intelligence features across all platforms.

I want to see more Apple Intelligence in Xcode.

I want a more stable and improved Xc…

In all sincerity, I would of course love for many of the AI goodies we see with IDE’s like VS Code and Cursor make it’s way (natively) into Xcode. Having Apple provide the goods could give Xcode users more fine-tuned and relevant features. I’m already a fan of the auto-complete model, a step in the right direction.

Having said that, I’ve grown to use AI in one IDE, and then switch to Xcode to run/debug. If better AI in Xcode didn’t happen this year, I’d be fine with that.

Instead, I rather see Xcode become more stable and more robust, in general. Xcode really does provide some awesome features when you stop and take stock. But there are enough annoyances with Xcode that produce some of the negative/meh feelings I read and see in the community.

If I had to choose an MVP, I’d go with making Xcode as solid as possible.

What We Can Strongly Expect

Without a doubt, SwiftUI will continue to be the primary UI framework in majority of demos and announcements, just like we saw in WWDC 24. I also expect more frameworks to provide better interfacing with SwiftUI (similar to Translation and MapKit in prior years).

But beyond those strong speculations, here are a few strong rumors worth keeping an eye out for...

Overall Design Changes

A strong rumor is that that iOS 19 will bring about some of the biggest design changes in over a decade. The goal is being reasoned that this will bring cross-platform cohesiveness much closer together, which is certainly a win. The inspiration seems to be many of the design decisions already found in VisionOS.

This rumor feels solid because we already saw some VisionOS concepts creep into iPadOS 18 through the tab bar. That particular change was a bit of an upheaval, so a more wide-scale makeover could enhance UX, but it may hurt developer backlogs this summer/fall.

UIApplicationDelegate Deprecation

According to Jeff Johnson's analysis, he presents compelling evidence that UIApplicationDelegate will be deprecated in iOS19. While deprecation does not mean mandatory change, this would still be a tremendous shift in iOS development. The app delegate has been the core for what feels like ages, so this news almost seems baffling.

The alternative Apple would push for is switching to UISceneDelegate (in fact, Apple already suggests this for apps targeting iOS 13 onwards). The full strategy has not been revealed (pending this rumor being true), but it may be worth exploring the (current) differences and possible meanings this will have on development.

UPDATE: CONFIRMED!

Hours after this article was published (coincidence? I think not), Apple released a Tech Note confirming the move from UIApplicationDelegate to UISceneDelegate.

The most intense quote came towards the beginning where they state: “Soon, all UIKit based apps will be required to adopt the scene-based life-cycle, after which your app won’t launch if you don’t.”

This is striking because man believed the rumor would mean more ceremonial deprecation, not something mandatory. But the wording here is strong and clear: migrate or your app won’t launch…

Closing the Combine vs Observation Gap

There is a swift evolution proposal currently wrapping up review (seemingly just in time for WWDC) called SE-0475: Transactional Observation of Values. When Observation was announced two years ago, it was exciting because it really embraced the concurrency/task-based/thread-safe future we all saw coming in Swift 6. Plus, it was shared that SwiftUI was already optimized to use Observation under the hood with more basic property wrappers.

One thing that felt awkward, though, was that programmatic tracking was primarily done using withObservationTracking

func printFlowers() { 
    withObservationTracking { 
        print(flower.name) 
    } onChange: { 
        print("Schedule printing.") 
    }
}

The proposal would essentially create an asynchronous sequence (note: not an AsyncSequence, which we'll come back to) using a new closure-initialized Observed type as well as "just-the-right-amount-of-magic" (their words, not mine).

let flowerNames = Observed { flower.name }

Which would allow us to then write something more familiar like:

for await name in flowerNames {
    print(name)
}

This also helps to better close the gap that Observation attempts to close between a Combine Publisher and AsyncSequence: the former supports broadcasting to multiple subscribers while the latter does not.

So now, when we attempt to do the following, all of the tasks will receive the same values from the same event that bore them:

Task.detached {
  for await name in flowerNames {
    print("Task1: \(name)")
  }
}

Task.detached {
  for await name in flowerNames {
    print("Task2: \(name)")
  }
}

For those looking to move away from Combine and over to something more concurrency-based, this bolsters the argument for Observation.

Want to talk more about this year’s upcoming WWDC? Join me live at Office Hours!

Open to all paid subscribers! Join at the button below and take advantage of a special promo discount!

Get 10% off for 1 year

What I'd Like to See

Just like I the one I write for Santa every December, it's now time for my WWDC wishlist. See, The Captain has been good all year and would love to see a few of these items under the OutlineGroup tree (note: even I rolled my eyes at how corny this paragraph turned out to be).

Default Theming/Styling of Components

Let's say I have a particular vision for how I want Button to look across my app. I could:

• Create a ButtonStyle, but that requires adding .style to each Button or surrounding Container

• Create my own Button that wraps Button with my styling, but I might not be able to anticipate what initializers I need to account for (did you know there are 15 initializers for Button?)

• Write a macro that automatically adds the modifiers I want to a specific component when recognized, but at the risk of blocking additional styling

What would be great is for a way to simply declare style overrides in a centralized manner that could even be swappable.

Recycling

Considering all of Apple's green initiatives, it's surprising that SwiftUI doesn't offer more recycling (badum-tish). I want to echo one of Majid's wishes, as its one that so many SwiftUI devs have wanted (or have yet to realize they wanted): container views that allow for recycling.

There are custom built solutions out there, everything from wrapped UICollectionViews to more calculated, yet pure-SwiftUI solutions like this one by Nil Coalescing.

But, it would be great to see more native offerings. List was changed under the hood by Apple a few years ago to use UICollectionView, and it’s been a game changer. If Apple wants to continue to encourage prioritizing SwiftUI, this would be a great boost.

Let The Hype Begin

As we count down to the lights dimming on June 9th, I find myself riding that familiar mix of excitement and curiosity. Whether Apple delivers long-rumored hardware, surprises us with (actual) AI integrations, or simply refines what’s already great, WWDC always finds a way to mark a turning point—for our tools, our workflows, and our ambitions as developers.

I’m not just watching as an engineer—I’m watching as someone who still gets pumped when Craig takes the stage. And I know many of you feel the same. So what are you hoping for? What’s your boldest prediction? I’d love to hear it.

There I was, staring at my beautiful new experience written entirely in SwiftUI, months ahead of schedule as I promised (and gambled on). Feeling proud of myself, I went to show one of my teammates. They praised the work… and then asked how it looked in different dynamic sizes.

Uh oh…

Much of the UI began to shrink and grow as we scaled from small to large. But the sub-containers that made up such a large part of the experience were set to a fixed height and width.

I quickly scrambled to find a solution, worrying that it would take another sprint to custom write something. But then, what’s this? @ScaledMetric you say? I quickly add it to my code.

That sense of aw and magic I had when I first used SwiftUI quickly washed over me as I watched these containers scale along with the overall experience. The fear of a lost sprint was squashed with a simple, mysterious property wrapper.

Wrappers: Unsung Heroes of SwiftUI

SwiftUI developers lean heavily on the classic property wrappers: @State, @Binding, @ObservedObject. But SwiftUI ships with a powerful cast of other property wrappers and wrapped values — some that solve complex problems with a single line of code.

This article is your curated guide to 10 wrappers and values that are often overlooked but deserve a spot in your toolkit.

Note: What do I mean by wrapped values? Towards the end of this list, you’ll see values that can be found in Environment. They are not wrappers, themselves. However, they felt at home on this list because of the similar help they offer experiences as well as to highlight some of the powerful values being kept “under wraps”.

What Are Property Wrappers?

Property wrappers in Swift are a powerful language feature that let you define reusable behaviors for how values are stored, computed, or observed. In SwiftUI, they’re everywhere: @State, @Binding, @Environment, and others all rely on this system.

At a high level, a property wrapper:

• Encapsulates a value (like a Bool or String)

• Adds logic to how that value is read or written

• Can expose additional projected values (like $binding)

For example, @State var isOn = false actually wraps the value inside a State<Bool> struct, managing updates and triggering view re-renders when the value changes.

Want to Make Your Own?

If you’re curious about how custom wrappers are built, Apple has a concise guide here: Swift Documentation – Property Wrappers

Come join The Captain and the rest of the Captain’s Crew at Office Hours!

Open to all paid subscribers! Join at the button below and take advantage of a special promo discount!

Get 10% off for 1 year

The Main Event

And now it’s time to reveal some of the best Wrappers in the SwiftUI Game…

1. @ScaledMetric – Auto-Scale UI for Dynamic Type

What it does:
Automatically scales a numeric value (padding, size, etc.) based on the user's preferred text size.

@ScaledMetric var size: CGFloat = 64

Image("avatar")
    .resizable()
    .frame(width: size, height: size)

Why it matters:

• Adapts automatically to accessibility settings without manual recalculation.

• Great for spacing, frames, and icons that need to feel "right" across small and large text settings.

• Helps you avoid hardcoding fixed dimensions that break UX for accessibility users.

When to use it:
When sizing UI elements that should grow naturally with Dynamic Type — like buttons, avatars, cards, or tap targets.

📚 Learn more about @ScaledMetric

2. @Namespace – Enable Matched Geometry Transitions

What it does:
Creates a transition context to morph views between states.

@Namespace var animation

matchedGeometryEffect(id: "avatar", in: animation)

Why it matters:

• Enables beautiful hero transitions where views fluidly animate across different screens.

• Helps maintain spatial continuity for users (which improves UX dramatically).

• Way less boilerplate than doing custom animations manually.

When to use it:
Any time you're animating between screens or states — like photo galleries, card swipes, onboarding flows, or navigation transitions.

📚 Learn more about @Namespace

3. @FocusedValue – Share Values Across Focused Views

What it does:
Exposes values based on the currently focused view. Perfect for input coordination.

@FocusedValue(\.username) var username

Why it matters:

• Great for building forms where data flows between fields without tightly coupling the views.

• Lets you create smarter, context-aware toolbars or keyboards that change depending on focus.

When to use it:
When multiple fields or child views need to share or react to information based on the current focus — like dynamic toolbars or editing panels.

📚 Learn more about @FocusedValue

4. @GestureState – Track Gesture Values

What it does:
Tracks temporary state during a gesture and resets automatically after it ends.

@GestureState private var isPressed = false

Circle()
    .scaleEffect(isPressed ? 1.2 : 1.0)
    .gesture(
        LongPressGesture()
            .updating($isPressed) { value, state, _ in state = value }
    )

Why it matters:

• No need to manually reset gesture state — SwiftUI cleans it up for you.

• Makes it easy to animate elements during gestures like drags, long-presses, or swipes.

When to use it:
Anytime you want temporary visual feedback during a user interaction — like highlighting, scaling, or revealing hidden options while dragging.

📚 Learn more about @GestureState

5. @FocusState – Control Input Focus Declaratively

What it does:
Manage keyboard focus between multiple fields using simple state binding.

@FocusState private var focusedField: Field?

TextField("Username", text: $username)
    .focused($focusedField, equals: .username)

Why it matters:

• Cleaner and safer than UIKit’s messy becomeFirstResponder()/resignFirstResponder().

• Crucial for building great, intuitive SwiftUI forms, especially for keyboard users.

When to use it:
Whenever you want to control or track which field is active — like auto-advancing fields, validating on focus loss, or dismissing keyboards cleanly.

📚 Learn more about @FocusState

6. @AppStorage – Persist User Defaults with Zero Boilerplate

What it does:
Binds directly to UserDefaults with reactive updates.

@AppStorage("isDarkMode") var isDarkMode = false

Why it matters:

• You get persistence and view updates automatically.

• No more manually syncing between UI state and stored settings.

When to use it:
For lightweight user preferences — like theme modes, onboarding completion, toggle switches, or any user-specific flags.

📚 Learn more about @AppStorage

7. @SceneStorage – Persist View State Across Sessions

What it does:
Restores view state like scroll position, tab selection, or input text.

@SceneStorage("draftText") var text: String = ""

Why it matters:

• Keeps your app feeling seamless even when a scene or window is closed and reopened.

• Essential for iPad multitasking and Stage Manager where apps frequently suspend and resume.

When to use it:
For view-local state that should survive temporary app interruptions — like scroll positions, selected tabs, or form drafts.

📚 Learn more about @SceneStorage

8. @Environment(\.dynamicTypeSize) – Read Current Type Size

What it does:
Gives you access to the current Dynamic Type size setting (like .large, .accessibility5).

@Environment(\.dynamicTypeSize) var typeSize

if typeSize.isAccessibilitySize {
    CompactLayout()
} else {
    RegularLayout()
}

Why it matters:

• Lets you adapt layouts, not just text size, for accessibility.

• You can build UIs that totally rethink structure at large text sizes.

When to use it:
When you need major layout shifts for users with accessibility text sizes — like stacking content vertically or increasing tap target spacing.

📚 Learn more about EnvironmentValues/dynamicTypeSize

9. @Environment(\.horizontalSizeClass) – Build Responsive Layouts

What it does:
Lets you respond to size class changes (compact vs regular).

@Environment(\.horizontalSizeClass) var sizeClass

if sizeClass == .compact {
    VerticalLayout()
} else {
    HorizontalLayout()
}

Why it matters:

• Helps you create adaptive interfaces that work on iPhone, iPad, and Mac seamlessly.

• Vital for Split View, Stage Manager, and dynamic resizing scenarios.

When to use it:
Whenever you want a view to layout differently based on device, orientation, or window size.

📚 Learn more about EnvironmentValues/horizontalSizeClass

10. @Environment(\.isEnabled) – Respect System Interactivity

What it does:
Check whether your view or container is enabled or disabled.

@Environment(\.isEnabled) var isEnabled

Text("Label")
    .opacity(isEnabled ? 1 : 0.5)

Why it matters:

• Lets you customize how views behave when .disabled() is applied upstream.

• You can build better, more consistent disabled states beyond just graying out a button.

When to use it:
When creating custom components that need to respect (or override) enabled/disabled state from parent views.

📚 Learn more about EnvironmentValues/isEnabled

Wrap Up: These Wrappers Pull Serious Weight

If you’re building modern, accessible, adaptive SwiftUI interfaces — don’t stop at @State. The wrappers above help you:

• Write cleaner code

• Support accessibility out of the box

• Handle persistence, focus, gestures, layout, and more

Button. The classic and (arguably) most basic interactive component of modern interfaces.

Yet, in the age of Swift 6 and concurrency, it can be baffling that Button’s evolution into an AsyncButton remains an open topic. When Googled, there are numerous implementations demo’d and written about.

“But Captain,” you may be asking. “Is it worth sailing these seas if they’ve already been explored?”

“Aye,” said The Captain. “I do.”

Charting Course

In this article, we will explore three basic implementations of AsyncButton:

1. AsyncGoogledButton - based on your typical Google answer

2. AsyncStructuredButton - an attempt to fix the Googled answer with some structure

3. AsyncTaskButton - an exploration into a more SwiftUI-based solution

To test these out, I’ve created a simple macOS App (found on Github) that allows me to trigger an async (throwing) function that counts from 1 to 10, printing the current value every second.

for i in 1...10 {
    try await Task.sleep(nanoseconds: 1000000000)
    print("Task Count: \(i)")
}

The app looks like this:

It’s worth noting that for each type of AsyncButton, the buttons Task1 and Task2 switch the detail view on the right. This will be important to remember shortly.

Github Repo

The (Potentially) Unstructured Problem With A Googled AsyncButton

The typical answer on Google (or ChatGPT, if we want to be cheeky) is usually something like:

Button(
    action: {
        Task {
            try await action()
        }
    },
    label: {
        label()
    }
)

Perhaps, at a baseline, this is enough for many folks out there. However, what happens if the task is long running and the user decides they want to navigate away from the action?

In our testing app, I mentioned that for each implementation, we can switch between two detail views. If we start our task in the first view, and then switch to our second view:

We see that Task 1 continues to count. Even as we trigger Task 2, we see that Task 1 doesn’t stop until it hits 10. This is because we’ve triggered an unstructured task.

Disclaimer: maybe it’s an ok scenario to have an unstructured task for your use case. If the task was to trigger a save operation, maybe we want to allow that to continue even after the user navigates away. To read more, about when you may want to use an unstructured task, check out this article.

However, there are certainly cases where we would want a continuous task to stop (e.g. we’re awaiting values that are only relevant to the screen where the task was triggered). Simply starting a Task from a synchronous context immediately releases control over the Task, itself, leaving you at the mercy of it’s own ability to manage its own lifespan.

Come join The Captain and the rest of the Captain’s Crew at Office Hours!

Open to all paid subscribers! Join at the button below and take advantage of a special promo discount!

Get 10% off for 1 year

Adding Structure to AsyncButton’s Wild Nature

Fortunately, adding view-dismissal-safety (or structure) to our AsyncButton is rather simple:

@State var holdTask: Task<Void, Error>? = nil

...

Button(
    action: {
        holdTask = Task {
            try await action()
        }
    },
    label: {
        label()
    }
)
.onDisappear {
    holdTask?.cancel()
}

We store the Task into a State property so that we can then reference it within onDisappear and cancel the task. This manually ties the life of the task to the appearance of the Button view.

Note: This leads to possible enhancements where we expose the task outside of AsnycButton, possibly to expand our structured handling to other views or objects. For the sake of simplicity in this article, I’ll leave it to you to explore those options.

One Step Further Using .task

It’s great that we were able to add structure to AsyncButton by having it be tied to the appearance of it’s calling view. However, as Captain SwiftUI, I have to ask: what about using the .task modifier? After all, it promises to automatically tie the life of a task to the life of the calling view.

Let’s give this a go.

@State private var isRunning = false

...

Button(action: {
    isRunning = true
}) {
    label()
}
.task(id: isRunning) {
    guard isRunning else { return }
    try? await action()
    isRunning = false
}

Three less lines of code, no holding of a task property, and automatically tied to the life of a view. If this structured approach fits your use-case, then this seems like the ultimate answer.

A Cautionary Tale of The Sneaky Error

You might have noticed in the task implementation I used an optional try?. Because we’re passing in an async throwable closure, the task modifier actually complains about the throw not being handled. We didn’t get this complaint with the other implementations, but, out of curiosity… what happens if we to swap “?” for a “!”…

🚨 MAYDAY! MAYDAY! 🚨

We get… a crash?!

Fatal error: 'try!' expression unexpectedly raised an error: Swift.CancellationError()

What the heck is a CancellationError and why are we getting this? As it turns out, CancellationError is thrown automatically when a task is cancelled. Which means if we add an “!” in our structured implementation, we get the same crash over there, too.

This might not seem entirely relevant to our goals here, but it’s worth mentioning this because it’s one of the most overlooked Task-related errors. Your use-case may accept using a try? to simply handle this error. However, if you need more granular control, we can handle with a do-catch block:

@State private var isRunning = false

...

Button(action: {
    isRunning = true
}) {
    label()
}
.task(id: isRunning) {
    guard isRunning else { return }
    do {
        try await action()
    } catch is CancellationError {
        print("Task was cancelled")
    } catch {
        if Task.isCancelled {
            print("Task was cancelled")
        } else {
            print(error.localizedDescription)
        }
    }
    isRunning = false
}

This works for both the task modifier and structured approaches. It’s pointless for the unstructured approach because, well, there’s nothing to trigger a cancellation.

Conclusion: We Can Build a Better Button (and A Better One, and A Better One…)

We’ve explored previously traversed seas and pushed a little beyond, proving we can provide structure and better handling to AsyncButtons… if we need it.

That’s really at the crux of the AsyncButton topic, and probably why there is no native offering. There’s no few async contexts that can be easily managed by just one component.

I love the attempts, including this extensive and impressive one by Thomas Durance (which he goes through in this article). But ultimately, you may need to opt for building the AsyncButton that fits your needs best.

Ahoy there! This is your Captain speaking…

I’ve been loving the community that’s been growing here and the positive feedback you all have been giving! That’s why I’m excited to announce expanded offerings and ways for the community to support those offerings.

Note: To be clear, my articles will remain free. I’m exploring ways that folks can choose to support my writing and some of these new offerings. If you are one of those folks interested, thank you and read on to learn more…

With over 20 years of coding experience, more than a decade specializing in iOS and mobile development, and a track record of helping launch successful apps, I’m excited to offer office hours and consulting services to help developers and teams level up their iOS development skills.

Leading, teaching, and mentoring are passions of mine. It’s why I love being a Lead Software Engineer and why I take on side-projects such as co-authoring of The Swift Cookbook, Third Edition and, of course, running Captain SwiftUI.

Whether you're an individual looking for career guidance or a team refining your mobile architecture, I’m here to help.

Office Hours for Crew Members (Paid Subscribers)

For those who have joined the Captain’s Crew as paid subscribers, I now host monthly office hours. Crew members can drop in with questions, discuss challenges, or get feedback on their projects.

What You Get

• Access to a monthly one-hour Q&A session

• Direct insights from an experienced iOS engineer

• Community-driven discussions on Swift, SwiftUI, and app architecture

How to Join

• Subscribe as a Paid Subscriber to Captain SwiftUI

• Join the first live session on Wednesday, May 7 @ 8 pm EST

• Regular schedule to be announced (recordings available for paid subscribers)

Get 10% off for 1 year

Consulting Services

Apart from paid subscriptions, I also provide tailored consulting sessions designed to solve your most pressing mobile development challenges. These sessions are ideal for:

• Code reviews and architecture guidance

• Modularization and scalable iOS app structures

• SwiftUI best practices and UI design principles

• Performance optimization and debugging

• Career advice and navigating the iOS job market

How It Works

• Inquiry Form: Fill out the Inquiry Form to provide details about your needs

• Personalized Follow-Up: I will review your request and reach out with pricing and next steps

• Scheduling & Payment: Once aligned, I’ll provide a scheduling link and payment details

Need ongoing support? I also offer retainer packages for teams looking for continuous mentorship.

Consult With The Captain!

Admiral’s Club

For those who want to take their support for Captain SwiftUI to the next level and take advantage of some special offers, I’m also offering a new Founder’s Tier called Admiral’s Club.

What You Get

• Access to Office Hours with higher priority given to your questions

• Special 10% discount for Consulting Services

How to Join

• Subscribe as an Admiral’s Club Member to Captain SwiftUI

Subscribe now

Sponsored Ads

Lastly, I plan to feature sponsored ads in future articles. This will help support keeping articles free at a baseline level. Substack, as a platform, doesn’t provide an ad template/component/embed option, which I think is great for readers as it means us writers can’t do anything super elaborate and intrusive.

You’re here to read and (hopefully) learn. I want to respect that.

To give you an idea of what these ads will look like, the following is an ad for an app a connection of mine recently released. Because I also happen to think it’s an awesome app that aims to give back and “leave this world a better place than we found it”, I asked if I could use promote it for the demo, free-of-charge. Please check it out!

This article is brought to you by Omilía:

Discover Omilía — the speech and language app designed for individuals recovering from a stroke or traumatic brain injury. Explore interactive games to boost communication and cognitive skills in a fun, engaging and intuitive way!

View Omilía in App Store

Interested in Sponsoring?

• Email me at captainswiftui@gmail.com

Get Started

• Become a paid subscriber with access to live office hours on May 7: Subscribe Here

• Schedule a personalized Consultation with The Captain: Inquiry Form

• Join the Admiral’s Club and get all the paid subscriber perks plus:

  • Priority at Office Hours

  • 10% off consulting services

• Sponsor this blog with an ad by emailing captainswiftui@gmail.com

Question? Send me an e-mail!

Get 10% off for 1 year