Hi. Welcome to another SwiftUI group lab, or as we like to call it, SwiftUI After Dark. My name’s Kurt and I’m part of the Worldwide Developer Relations team here at Apple. I’m joined by engineers and leaders from the UI frameworks team, Anna Stephen, Nick, Russell, and Sam. In addition to those on screen, there’s a team behind the scenes helping with the triage of all your inbound questions. We’re excited to answer your questions tonight about all things SwiftUI and UI frameworks. If you have a code specific question or somehow we can’t get to your question today, please bring your questions to the developer forum at developer.apple.com/forums where we can continue the discussion.

If you have a bug or a feature request, go to feedback.apple.com. We’ll focus on questions tonight that will help the broadest audience. So without further ado, let’s get to questions. And I’d like to start things off by, by just hearing from each of you about what parts of SwiftUI you work on.

Maybe, Sam, you can get us started. Sure. So my, before this world, I did a lot of work in programing languages. And so as a sort of natural consequence of that, I work on things that are like at the intersection of Swift and SwiftUI, because that’s sort of where my interests lie. So if you’ve seen like some of the type checking performance work that we announced this year, I’m very involved in that and anything else where we’re thinking about like, how do we use Swift in really interesting ways?

I worked, I actually worked on UIKit for most of my time here. So I worked on animations there in the interop between that and SwiftUI and like the bridging parts of SwiftUI a little bit. Nice. Nick I too, I did a stint in Appkit. I did a little bit of work in UIKit and now I’m a manager on SwiftUI. So when I do get to write code, I’m sometimes in presentations with sheet and some of the containers, like inspector navigation and controls.

And then this year spent a little bit of time in dataflow. Oh, nice. Stephen. So before SwiftUI, I was an engineer on the Apple Music team doing SwiftUI development on the app side. And now my focus is on SwiftUI performance and also the, the Agentic coding skills that we introduced this year.

Nice. And Anna. Yeah, I work on mostly navigation bars tabs effectively, if it’s touching the way that someone in in is navigating your app, that’s something that I work on and I get to work on it with Nick. Nice. Excellent. And before I became part of the Worldwide Developer Relations team, I also worked on presentations and navigation. In fact, Russell and I shared an office, which was great.

So let’s go to some questions from the forum. So the first question is, with over a million re orderable items for each doesn’t render every view, but still traverses the whole collection on first display in every count or order change causing slowdowns UIKits. Diffabledatasource has the same issue. Only a classic data source helps. What can we do about this in SwiftUI?

You want to take a stab at it, Steven? Yeah. So this is actually an issue that that we’re looking into and that we’re aware of. It definitely shouldn’t be working in that way. And the best thing to do is to file a feedback in order for us to keep track of it.

And it’s, I should, I should say, when, when we’re asking for feedback, it’s not so much that we need to be aware of the issue. Like we we know there are issues, as Steven said, but we want to know your particular use case. So why do you need to display that many items in a the list.

What’s the nature of your data that causes that to be sort of the the structure that you’re building up? So that’s, that’s the sort of thing we look for in feedback reports is tell us what you’re trying to accomplish so we can make sure the APIs support your use cases.

And bravo to this developer for downloading the betas and testing them out like we are every day. I get to work right now, and I come in and see what feedbacks are coming in from developers. They’re very visible to us. We take a look at them. We’ve already gotten a couple on state macro as well. And so we’re fixing the bugs. And when you get them in early, we get to look at them pretty quickly. Yeah, yeah, totally. The best time to file feedback that will influence the next release is right now.

So so our next question and let’s see, and I think I’ll let you take a crack at this one first. So in iOS 27, at least beta one, it’s not possible to create a custom transition. The protocol navigation transition is publicly empty. What what is the purpose of of this protocol? And is there anything we can do to make our own?

Yeah. So that is effectively like a way for SwiftUI to expose things that, you know, conform to the protocol. So they can be like navigation, transitioning, like this is something that, you know, in SwiftUI sometimes you will see like either like protocols or like also styles that will give you the pieces to be able to do your own, like, for example, like a button style. But there are other ones that maybe expose concrete members. So like you can make a zoom, you know, navigation transition, but they may not necessarily, at least right now, expose a way to do it to create your own custom one.

So kind of unfortunately, going back to the last one, but if you’re able to file a feedback with your use case, we’d be really curious about the kinds of things you’re trying to build because it helps us know also, you know, what are the pieces that you might need in order to be able to build your own custom navigation transition? Yeah. So we’ve got crossfade transition and zoom Transition and automatic as the sort of the trifecta today.

But one of the ones that I’m actually quite excited about this year, which is a very sleeper, but any navigation transition, which means you can switch between the two of them, which is something that you weren’t able to do before. So like having that dynamism is nice, cool. And that crossfade one applies to sheets too. So you can do some pretty cool things with.

Zoom as well. Oh yeah. Yeah. Nice. Yeah. So the API is composed right. So when you say navigation transition, we name that specifically because there was a lot of back and forth on what that should be called presentation navigation. Transition. Transition transition. But we named it navigation transition because navigation was kind of the unifying concept like sheets or navigation.

So another fun thing, just when you’re making these transitions, there’s no like SwiftUI first class API for custom transitions in the sense that the UIKit one exists, but it’s also quite fun and easy to build up, Like custom transitions for your own SwiftUI views if they’re not on top of a navigation stack. So you can drive the animation yourself, and SwiftUI gives you all sorts of modifiers to flex the shape. And you can, you can even use shaders.

And so if it doesn’t strictly have to be pushing onto a navigation stack, it’s quite a lot of fun to build your own kind of transitions. Yeah. So if your animations are really powerful, like especially with Animatable and you can have like keyframe based animations, there’s some, some crazy stuff you can do. Yeah, it’s a lot of fun.

So Steven, I’m going to send this next question, your direction with coding intelligence and genetic models in Xcode. What are some ways we can implement it in building views with Liquid Glass, for example? So I guess let’s let’s talk about that more generally instead of diving into the specifics about it. And then we can maybe double back to the specifics. Yeah. So the new skills that are shipping with Xcode are a really good way to get some additional insight, especially into new APIs and best practices.

And we would definitely like to get feedback on the skills as well. The the tools that are built into Xcode are really good for rendering previews of Liquid Glass also. So iterating on the various pieces of the design. To kind of get things looking the way that you want them to look is a really good way to sort of work your way towards the, the outcome that you’re trying to get.

And the skills are usable with the model of your choice as well, which is great. So, you know, if the results vary from model to model, you know, there’s an opportunity there to, to experiment with kind of trying to iterate with that. Right. As a reminder also about these, all these skills are built into xcode’s agentic workflows and they work really great there. But if you use something outside of that, like some other agentic system, whatever it is, you can always export all of these skills. There’s a command, I forget exactly what it is, but it’s in listed in what’s new in Watson.

And modernizing your UIKit app. Yeah, yeah. So you can grab those skills and use them elsewhere. And also they’re fun to read through. There’s a lot of really cool tidbits in there for humans too, and like obviously targeted at LLMs, but that doesn’t mean like people can’t learn from them also.

So the second part of this question is about using the glass effect modifier on, on buttons to, to apply a glass effect. And I want to, I want to take a second to talk a little bit about what’s in the human interface guidelines and what we’ve seen in the various workshops we’ve done around the world about adoption of the new design.

When you put buttons in, in toolbars, in the navigation bar, the top toolbar, they’ll they’ll take on the appropriate glass appearance automatically. And so the, the glass effect is really for stuff that is not appearing in those locations. And in general, we would encourage people to not use Liquid Glass inside the content area of the view you think. Think of the the glass control layer sort of hugging the content layer and the content layer underneath is is flat.

Because if there’s not any content scrolling underneath the glass, the glass effect really isn’t providing any benefit. There’s nothing for it to refract. It’s just static. And so think about whether you actually need glass effect in some of these cases. Often the simpler design is actually better in the content area.

I’m going to take a dangerous venture down trying to describe controls. I don’t work too frequently in controls. So Frank, please correct me if you’re watching, but if you’re trying to put glass on a button specifically, there is API for that, I’m pretty sure. So there’s a glass button style. Yeah. You want glass button style or glass prominent? I think FaceTime uses glass prominent where they’ve got that green button in there that’s like, this is this is the button. This is the magic one.

So yeah, you can use it to good effect there. And one error I see people making because it’s very natural to do is to reach for a glass effect. You’re like, oh, button glass effect. And that alluding to the question that that will get you a button on glass, but it won’t look exactly right. So you probably want button glass effect. And then on top of that, you want button border shape. A lot of times you want button border shape to like make it a circle or a triangle. Triangle. Yeah. And the other thing I will say is like.

A triangle. Time Capsule. Yeah, there we go. Button warnings. We’re going to hear about this one. And you had something useful to add. The other thing I will add though, on top of like when to use Liquid Glass is reminder that if you put like a button in the toolbar item like that will already have a glass background. So like you don’t need to add one on top of that. And if you want it to take on a color like a prominent glass button might, you can just use a tint.

Can you put content not on glass in the toolbar. Yes you can. So you use I believe it’s the. Oh goodness. It’s shared. Shared background. Yes. Hidden. Shared. Shared. Background. Hidden. True. A lot of debate went into that one as well. Yes. We think a lot about names of things.

And the the main case for the hiding the glass background. For example. You can see this in the in the books app. It shows a profile photo of the current person who’s logged in and putting glass around and behind a photo of a person actually doesn’t look great. And so this causes that to be B flat and not have the glass treatment over the top.

But we have a we have something for that now, don’t we? Yeah, we do have something that makes it a little bit easier to make, kind of like the padding and other things. Good in that case. So because one thing that can look kind of cool is if you have like a little glass refraction around the edge, like you don’t have a huge piece of glass, but you have like just enough to kind of reflect, but it’s mostly the profile photo. And we’ve added API this year so that you can remove that content margin.

That normally toolbar buttons will add around the edge. So the refractions right at the edge. Yeah. Super cool. Because removing the background used to be the only way to remove that padding. It removed both. And then your view could take up the whole space. And so it would look the same size as like the other buttons.

But now you can remove just the padding and leave the background and keep your image inside. And even if it fills, then it can fill it. And then you get the rim and it’s like still made of glass, which then also means it mitosis better when you like push and pop like it because the, the mitosis like looks more natural if everything is glass.

So it’s like, like it just, it all looks much better. Now. I want all of the avatars to. Have like mitosis for, for those who haven’t had a biology class recently is when the shape sort of blob together or blob apart. It’s like they have this sort of liquid really cool effect. Yes, it’s called slurp slurp. Yes. Also called. Slurp.

I believe slerp is the technical term, which is why we tend to stick with mitosis, which is a lot easier to remember. Yes, it’s so easy. So the the next question, I think I’ll I’ll start with you, Russell. And then you might be interested in jumping in also or.

Nick. There’s lots of us who have interests here, but we’ll start with Russell. So what’s the best way to manage screen sizes now in our apps with vertical and resizable and split views and all the different sizes that screens can take? Now, the resizable simulator, like what API should we think about using as Windows 10 to windows resizing?

Definitely. So one, if you’re hard coding for specific window sizes, don’t do that. That that’s been a losing battle for a long time. Really just if you can lay out at any size, you should be able to do that. And then look at size classes. I think we’re, we’re leaning like even more into them than we were before to. And I think of them as kind of defining different experiences.

So at regular size classes, you get kind of your full like, like iPad or Mac, like Multi-column experience. And in compact sizes either vertically compact or horizontally compact, then you get a more like you’re, you’re constrained in that environment. So you just want to display less. And sometimes that means just changing your number of columns. And sometimes it’s much more dramatically changing your app.

Right. But if you lean into size classes, you’ll, you should be okay. Yeah. But remember that just supporting size classes isn’t fully sufficient, right? Like, you know, windows can be many different sizes that go in between where you’d want those size class transitions. So make sure that you’re dealing with true flexibility, right? Yeah. In addition to doing like different UI looks and feels per size class.

Yeah. I mean, I will also say like using system containers, if that’s like an option for your app can be really nice because then we’re the ones doing the work for you to have to support that. Yeah. But the other thing I will plug is something that I don’t know, it’s I feel like it’s just layouts and SwiftUI are also really cool and really powerful. There’s a good WWDC talk from 22. Yeah, from 22 on that. Using custom custom layouts. Yeah. We’re all like, oh yeah, that’s Paul’s talk. You know, internally we all think of who gave the talk because we know these people. And it turns out that’s not very helpful to those of you who are trying to find them.

Yeah. But it is the session on building custom layouts in SwiftUI. Yeah. Because like one thing that people, I think is something that you will, people will reach for is like doing an if statement off of size class. And the thing that can be like not great about doing that is when it changes, it’ll tear down the view on the other side. So you lose all your state, or you have to do a ton of work to make it so that the state is like synced on either side. And that can just be hard to manage.

So like the nice thing about a layout is like, if you’re genuinely like changing, like the position of the views and their flexibly resizing, then you don’t have to like throw away that state. Also a plug for while we’re here, custom containers like the combination of custom layouts and custom containers is a really great way to make super flexible, reusable controls that can like have all of these adaptations to different size classes, different layouts, like all sorts of different things. And I demystify SwiftUI containers from WWE for Matt’s talk is a, is a good one to go to for, for that.

I think we’re all, we’re all talking about like different ways to maintain structural view identity. And the one, the one that we almost hit was like the any layout as well. So if you’re really doing something custom, but you want a custom layout and compact, and then you want a different layout in regular, you can use any layout. And all of those views will maintain their structural identity. And any layout wraps each of those other its any layout, right?

Is it called any layout? I think it is. So yeah, it wraps, it can switch between those two layouts and so. It can animate between them too. It’s very, very cool. That’s all the structure is. And you can use the system ones too. Yeah. Yeah. The another couple of things to, to think about in this space view that fits is is handy.

You want to not use view that fits in a whole bunch of views at once because it has to, you know, measure some subsequent or successive views to find. Got to figure out which. One fits one that fits. And literally like tries them all and says, which of you fits in this container. And but it can be at a, at a higher level.

It can be super handy for that. The other thing that that I would plug is I think, I think tab views are great for this, you know, two releases ago to be iOS, A18 and aligned releases. We Anna really built tab views that are along with others tab views that are adaptive and can have a sidebar at at regular size classes, and that’s optionally collapsible. And they have all kinds of configuration options.

And that’s a really nice container that adapts nicely to narrow, compact size classes like on the phone with just the tabs or to larger ones. And so I think that’s a great container view that’s maybe less appreciated than, than it should be on larger devices. Definitely. One question though, I like a lot of people will, you know, you think, okay, I need to respond to sizes. I want to use a geometry reader.

I was wondering like, Stephen, can you talk a little bit more about like when to think about using a geometry reader or like what the performance implications are and like how, you know, if an app is thinking, I need to do something a little more precise, like what they might want to think about when they’re doing that.

Yeah. So I’m actually a big fan of geometry change specifically because I feel like most of the use cases where people are trying to, you know, react to size changes for things like resizing grid items, for instance, what they really want is like breakpoints for their various sizes, you know, like if the, if the view is like wider than 320, then I want to have like this particular layout for my cell.

And if it’s like in this range, then I want to have another kind of layout. And the nice thing about an geometry change is that it actually has two closures. The first one is the one that actually gets the real time geometry information that fires on every frame, but then whatever you return from that is the thing that actually determines whether the action gets called.

So basically, like if you had a range where you’re saying like 320 to 480, like I want to use this size, then you can specify that logic and then like only need to relayout or change things when you actually cross over those various thresholds. So you take something that’s running at frame rate and suddenly it just fires twice as you cross the threshold, right?

Like typically, if I, if I were, you know, on an older release using a geometry reader, I would really only do it in a background view for the most part, because putting things inside of a geometry reader, it ends up being really expensive for the views that are like subviews of the closure for, for that geometry reader in general on geometry, change is going to be a better tool to, to reach for.

Yeah. Basically, you don’t want your views to be invalidating on every single frame, right? And for things that you’re trying to do, like more complex stuff where you have like the bounds and then want to do like very specific placements. And I mentioned custom layouts. That’s the tool I would go to there. So like the combination of on geometry change and custom layouts is going to get you so far. And there’s a super cool thing in the talk on advanced graphics in SwiftUI this year.

Hawkins talk. He has this such, such a good explanation of alignment guides and has this really neat example where he uses alignment guides to do something that that I would have thought you could only do with a custom layout, but his explanation of it is just so neat what you can achieve with that. And that is super efficient, like layout once and it’s done. I mean, guys are so powerful and so underused. Yeah, yeah.

It’s like that layout once thing that just kind of made me think of something that the with on geometry change, it’s still even like the couple times that it fires. Like even if your condition mostly means it doesn’t fire very much. But the second closure, the only thing you can really do in there is still set another set some state or something. So this whole system will take at a minimum of two passes to lay out. It’s like one initial one and then one additional one. Once you change that state, it needs to like run again. Whereas with like a custom layout, you can really lay everything out in one, one pass.

So the next question, I think we’ll we’ll start with you on this one, Sam. The developer asks any tips on how to properly learn data management and passing data between views and SwiftUI. Are there good projects that would help us strengthen our skills in that, or how should we increase our knowledge there? It’s a really good question.

Like the at its core, at least in my mind, data management and SwiftUI is really like making pieces of information and then trying to make your views as lightweight as possible, such that they map that information to view data. So honestly, my, my biggest recommendations in terms of like getting good at structuring that is like, even just like building like self-contained, like state machines and logical components that you can use all throughout your app to, to drive things.

And then anytime you see that, like your view code is getting messy, trying to sort of bridge things back and forth, try to see if that means you can pare down that, that like model or logic layer data so that it only has the things that it needs.

And I hope a lot on like the fact that SwiftUI is like very architecture agnostic. And the reason for that isn’t like, you know, there’s no, like, we don’t want to like make a choice. It’s that we think like there isn’t one correct choice. And it really depends on the shape of the data for your specific app.

So as far as learning goes, I’d say just like build a lot of things that are trying to model very different kinds of data and you’ll quickly find you’ll need like very different patterns for, for each one of those cases to map them nicely onto these. Yeah. I mean, the thing, the thing I think about there is.

It’s helpful to build sample apps in a domain that you’re familiar with, right? So build an app for something that you care about. Maybe it’s keeping track of your watercolor paints or you know, how often you have to feed your fish or whatever it is that you really care about. Because then you’re solving a problem that you have, so you’re motivated to work on it and you understand the data. And so you’re not spending brain cycles trying to figure out what the data is about.

You’re just spending it on trying to solve the problem. I think one of the challenges of like going through a canned tutorial that is about something someone else is excited about is you have to learn what they’re excited about and what you’re doing in your tutorial. I run into all the time. Yeah, it turns out people don’t want to look at my apps about like floor tiles.

I try to It’s just not good. Sample code to look through different terrazzo patterns. People aren’t into that. Just need to find someone who like, has your same interest in floor tiles. I will say. Looking. Still looking. I’m also a big fan of of using instruments for this.

You know, not necessarily like people typically use instruments for debugging performance, but the SwiftUI instrument is actually really powerful because it shows you a timeline of all of the things that are being updated. So you can actually understand how the places that you’re updating your data are affecting which view bodies are running.

And sort of it can kind of show you how the data is flowing through your app in that way as well. And you can also see the work that SwiftUI is doing as a result of, of the changes that you’re making to your data. And that can kind of help you understand how things work and how stuff flows. Yeah.

I’ve also been pedaling dynamic property to all who will listen this year. Because. I finally learned the power of dynamic property, and it’s hard to explain on a panel, but a lot of the times on change is very helpful in a pinch. But as your views grow and you have lots and lots of on changes.

A good rule of thumb that I like any on change, can probably be replaced by a good usage of dynamic property. And then going back to Russell’s point, that also saves you an extra render cycle because on chain or dynamic properties, their update method is called right before body.

And so you take what was an update of the on change updating state and then rerendering the view. And you move that into the dynamic property updates and the view renders and you’re done. Yeah. Yeah. Anytime you have like any kind of on change or like action based closure and some extra state you’re incurring, I mean, both like extra memory to store that state, but then like extra time to process that. Yeah, that’s a great point.

Like we had a question in the previous SwiftUI lab, which is, was about sort of anti-patterns and on change isn’t always the wrong move, but sometimes I’ll be like looking at code in a workshop or something and a developer will be using on change in order to do a bunch of calculations and then update some piece of state. And, and it’s sort of like trying to get back to imperative code and do the work there.

And ideally you’d have a data model that’s doing that work and it’s just vending the new value as the other values of that data model change. And you make it observable, it updates efficiently. So there are cases where on change makes sense because you have to broadcast to some external system or whatever. But if you’re using on change to mutate the state of the view, that’s almost always not the right move.

Yeah. There are, you know, I see a lot of people in various forums saying like, oh, you know, X API is bad or whatever it is. Like you shouldn’t use it. Generally, if we shipped an API, it’s because we think like it is useful in like, you know, yeah, like, you know, on change any view or things that I hear a lot of people saying like, oh, they’re, you know, spooky. You don’t touch them. But I wouldn’t so much put it that way. I would say when you see uses of APIs like that, it’s a sign that you should look critically and make sure that the usage is justified.

Like for any of you, are you actually erasing the type of the view or are you using like a heterogeneous collection? Or are you just like, you know, wanting to make it easy instead of thinking through the generics and for unchanged, like, are you actually doing some react, something reactive and that needs to be in like an imperative breakout point?

Or are you just using this to like plumb things through that you otherwise could use the environment or a dynamic property or something else to, to better? We haven’t mentioned on a pier and I feel like that’s even more, it’s even more common than, than on change actually.

And this is my favorite use case for dynamic property, which is that, you know, commonly if you’re loading something like an image, there’s the possibility that you’ll already have it in your cache. And in that case, you don’t want to wait until onAppear to load your image because you’re basically going to be guaranteed to have a full rerender of your view, even if the image was already available. And so because the update method of a dynamic property fires before the body renders. You can actually turn a dynamic property into a property wrapper and vend the cache to value if you have it, and then it’s available to the body on its first run.

And then you don’t have to do that round trip. And that can make a really big difference. And there’s a great example of that in the the talk this year at Dub Dub on Lazy Stacks. So Rens talks about how you can actually it’s this exact example, how you can move that loading earlier in the process.

And SwiftUI is smart enough that like it can instantiate a view, it can process the layout, and then it can do the rendering in separate frames. And so as you’re scrolling and views about to come on screen, if we can have it all laid out before it gets there, can render super fast and avoid glitching when you scroll.

It’s super cool. And I the talk is so good. I just love it. It is a really good talk, a lot of lot of depth in that talk. While we’re here in on a pier. My favorite feature of the year. Well that rhymed. The poet. Nick is dropping some rhymes on. This is.

It’s really subtle, but it was a lot of attention to detail, paid by one of the engineers on the team to take advantage of new swift concurrency features to make task and on a peer have the same timing. So there was this really subtle behavioral difference where if you stack like a task and on a peer on a view, so you have view dot task dot on a peer, the on a peer would fire first because the task incurred in isolation hop. And now that doesn’t happen with the latest swift concurrency features. And so they’ll they’ll execute top down nice. Which is a nice like ordering improvement. Awesome. So the the next one. Oh, who should I throw this at?

I think we’ll start with Russell because he raised his eyebrows at me. No. Let’s go and feel free to bounce it to someone else if you don’t want it. So developer asks. I’ve heard in multiple places, including the last two SwiftUI Group labs this week, that I shouldn’t be using if to conditionally hide elements.

So what’s Apple’s recommendation? And part of why I love this question is the example that was provided. So for example, only at 9:41 should I show that it’s 9:41. Otherwise I shouldn’t show show something. It’s always somebody pays attention to their Apple demos. Yeah, it’s always 941 somewhere in Apple. Park in Apple. Park. Yeah.

If you wanted to show 941 only at 941, then the best thing would be to do is add like an opacity modifier and or whatever transition you wanted. Which is part of why I love animations is like one of the things I’ve worked on for so many years because the, the animations often inform much more than just what happens when it moves. They can inform the structure of the whole, the whole thing you’re building.

Anyway, back to 941. If you wanted to fade in and out at that time, just use an opacity with a conditional in that modifier and have it be one at 941 and zero at any other time so that it’s always there. But it doesn’t. It disappears at the other times. Now, if you need to like actually remove it from your layout so that it doesn’t take up space, I might Pop to see who else has a good suggestion for how to handle that.

If you’re, if you’re doing something like that, then it is fine to, to analyze it, right? Like if it actually, if you’re actually removing the view and putting it back in, right, then you’re going to have to do new layout and all these things. The reason to avoid doing that is we don’t want to like, you know, have to reflow layout and like, you know, reinitialize state and things like that. If the view is not actually going away and reappearing, it’s just like visually changing, like with opacity.

But if it, if it really is being removed from the hierarchy and not just hidden, then yeah, that’s that’s the time to. But what about in Viewmodifiers like conditionals for for the content of a Viewmodifier, for instance, like where people like if you had a. 941 Viewmodifier and like inside it was like, you know, like if. 941 content dot overlay your text. Otherwise just content.

What are the, what are the implications of that? So I mean, for conditional viewmodifiers. Right. Generally you want to make sure the viewmodifiers take arguments such that like you can pass in an argument that will do nothing. And that’s you see that with a lot of our, hopefully most of our modifiers where like, there’ll be like a value that we consider inert as then it will do nothing. Just like one was for opacity. Yeah, exactly. Right.

Like if you call opacity one on something, it doesn’t modify the content at all. And you want to be putting like the conditional expression, not like an if statement inside of the arguments to. And one of the challenges that we see it all the time is if a conditional is inside the body of a view modifier. Then that view modifier gets applied all over the place, and you just made those views relay out. And as the person applying the modifier, you don’t really know that you’re doing that. It’s it’s like.

And if it happens upstream, you’re very confused. Yeah. If you, if. You ever see the pattern of like making an if modifier that like basically is just a modifier around a conditional branch, it’s really dangerous for exactly that reason. You can end up with like all sorts of conditionals and places you don’t expect them. And that can cause like state to get reset, switch a conditional branch, you lose state because it’s a new view. So you want to be very careful with that kind of stuff. Just please.

Just like an interesting pattern when you’re designing modifier API’s is sometimes you have the inert one because it makes sense. And then there are other SwiftUI modifiers that won’t have an inert version. And that’s not an oversight. It’s more so in the spirit of that particular API. So like certain styles are static and that you pass a type to them that’s generic and that binds to that modifier.

And so you can’t change that. And that’s kind of intentional because SwiftUI uses that static information to render more efficiently. And so switching styles like that on the fly is something that you might want to do. Like if you really need to do that, that’s more of an if else type of thing.

Yeah. The, I think the, the place where it came up earlier in the week about avoiding, if in particular, was an if statement at the top level of a view that’s in like a lazy stack or a for each. Because in that case, SwiftUI is counting the number of of views.

It’s identifying the views and position based on how many there are. And if a view is scrolled out of the screen. But it had a conditional at the top level of it, we don’t know whether that view should be there or not. And so we have to keep it around so that we can tell whether the conditional state Changed.

And so again Renz talks about that in the in the Lazy Stacks video this year. But that’s a case where if you really do need that conditional, you should maybe wrap the whole thing in a stack so that there’s always a view there and it’s empty sometimes. Yeah.

To, to provide a little additional clarity on that, since it can be hard to get a mental model for these things. The problem case for lazy containers like list and lazy stack is when you have a view that could resolve to multiple subviews. So if you just wrote like a Viewbuilder text text text.

If instead you wrap that whole thing in a Vstack right now, that vstack is one resolved view. So you’re always going to get one view out of it. And the same advice applies for things like any view, any view conceptually can have any type under the hood. So it could produce one view. It could produce ten views.

Custom layout is the same. Yeah, exactly. So if you have any of those things, if you wrap them in a unary container like a vstack or some layout, you’ll be guaranteed to always produce one view. And then you’ll get the fast path for those lazy containers. But if you just make your own view type, that doesn’t do that, right? If you return something from body. No, not that is. Yeah, you can return multiple views from body. Exactly right.

And that’s still multiple views. That’s still multiple. Views, still multiple views. Right. And like group is like that as well. It doesn’t flatten. And there’s a reason for that, right? Like you could imagine you’d make a custom view that you want to be able to pass to a list and have it expand out to multiple list rows instead of just like one list row that’s surrounded in like a stack or something like. That, right? So that’s, that’s important functionality and it’s very intentional, but you have to be careful about it when working with lazy containers. Yeah. Well, the other like dataflow thing that I think not as like people.

If you’ve, you know, been developing in SwiftUI, I think most people have heard of the environment, but I think something that people have sometimes heard about less are preferences and traits which can flow upward. And the other thing is traits are accessible to kind of like your surrounding container. And so if. You mean container values. Yes. Container values. Sorry. Thank you.

More naming. Naming. Yeah. Container values. So they’re accessible accessible to your surrounding containers. So the one thing to know is if you’re, you know, wrapping something in a container like a vstack, that will mean that like a container outside of it can’t read those container values. So that might be desirable or that might not be. But that is one thing to like, take a look at when you’re debugging.

And that, that actually both of these last two things, the counting the number of views that a view actually expands to, and the container values API are covered in that demystify containers session from 24, which is just, it’s super cool. It’s also karaoke themed. So it is. We love. Karaoke. Yeah.

The next one I’m going to throw to throw to you, Sam. And this is a bit, a bit of a segue. You mentioned any, any of you in that conversation. We moved on from it. But let’s go back to it. What’s the what’s the concrete cost of type erasing with any view if it’s in a deeply nested or frequently updating view, like when should I worry about it? When should I not? So. You know, I mentioned with like the if else case, right?

Like it’s sometimes you need to like switch the view that you’re showing and then that’s okay. With any view in general, there are places where you need to type erase views, right? It could just be that, you know, at compile time, you don’t know what the type of view is going to be.

And in cases like that, any of you is a fine thing to reach for the case to look out for is when the underlying type would change. Because when, if the underlying type were to change, like, let’s say it starts out as a text and then you change it to a, you know, my special view when that change happens, just like if else you have to, you have to sort of tear down the view hierarchy and then rebuild it. And that is not super efficient.

So if you can try to avoid changing the underlying type as much as possible, and that’ll get you in good performance cases. And then the other one is exactly the thing which I was just mentioning, which is if you’re in a lazy container, you need to be careful because it won’t be able to tell the surrounding lazy container how many views it resolves to. As mentioned, you can. You can resolve that by wrapping it in a stack. All right.

So I’m going to throw this one to you, Nick, and you can throw it to someone else if you’d like. So the the question is, are there any tips for making SwiftUI layouts more adaptable now that Xcode previews are resizable? We talked about this a little bit, but but like, is there anything with with custom layouts that maybe we should think about differently?

Anything along these lines? I’m going to need some time to think about this one. This is like an abstract question. It’s kind of one of those like, give me a little more about kind of what you’re doing. But yeah, it’s. Tough to say without like specifics here, but yeah, sorry. Go ahead. Oh go ahead. I think you have more to say about this than I do. So I’ll let you start.

I mean, I feel like when you’re writing layouts, so sometimes in your app, you may be writing like a really bespoke layout and you may have been thinking like, okay, this is going to be a particular size. Like, I know maybe I hard coded some things. It happens. We’ve done it, but it’s what not me.

Okay, perfect. And only writes amazing code. But like the size is an input parameter. So if you’ve set up your layout such that you’re kind of prepared to accept any size and do something that is reasonable in any of these sizes, then like you’re really already well on the way. And I would probably, you know, test that like you have, you know, now a way to test that I would kind of tested all the different sizes. See. Do you like the results that you’re getting?

If not, then maybe, you know, evaluate what you’re doing. But honestly, you’re probably in a pretty good place if you’re writing a custom layout, right? And that, that actually, I think is, you know, a brilliant way to think about this is like, actually the question is kind of backwards.

Now that you’ve got resizable previews, resize your app and see what happens. Find out where you made assumptions, find out where the layout breaks, and then go in and find where you put that magic number that causes this to break and figure out how you need to react to it.

And also, just like use your app in context where it is resizable, like on an iPad and you know it, you really quickly find out when you’re trying. Yeah. iPhone mirroring, you really quickly find out when you’re like trying to resize your app and use it, like when it doesn’t quite work in certain situations. And then it’s much easier to patch that stuff. And use other people’s apps.

I like to like apps and apps and websites. Just resize them and see how different people deal with this. It’s one of my most favorite parts of like, looking at a lot of indie apps is indie developers in particular. They get to do their own, you know, they’re not bound to a product team or a design team. And so they get to be really creative with how their app adapts.

And so there are a lot of apps out there that do something really special and compact, and then you wind them up and you’re like, oh, this is a very creative use of space. So cop out answer. Yeah. Figure out what your app should do by looking at other apps and figuring out what you like. Inspiration. Take inspiration from other apps.

All right. This is this is a challenging one. We’ll start with you on this. And you might choose to throw it to you might choose to throw it to Russell because this is a topic all three of us have discussed, I think. But the question is, what’s your advice for presenting full screen SwiftUI overlays on top of everything else in the app, including sheets? Is there any way to do this that doesn’t interfere with modal presentation? Look at the wheels turning.

This is a hard question. All three of them go into like loading spinner mode. Well, I can elaborate more because this has come up in, in, in our workshops, sometimes a, a common case where people face this problem is they’ll want to present a login interface over the app. And so if you’re happen to to get locked out because of a network disconnect or something like that? Sure. Teams will want to bring up a UI over the top of the existing UI, and I’m not actually sure there’s a way to accomplish that in SwiftUI.

Or I think you would have to be probably pretty coordinated about your navigation model and your data model. Like if you’re able to guarantee like, because a full screen cover, once you’ve presented it, that will take up the whole screen provided, like kind of, if you think of it as like a little like hierarchy, like if you’re at zero and you want to present something on top of zero, and that’s like a full screen cover, you’re good to go.

But if you have like this question said another modal presentation, and maybe you have another modal presentation presented, like that’s going to be trickier. So I think at least if you want to be using like SwiftUI with like the APIs currently as is, I would probably try to track the presentations and see, but we’d also probably welcome a feedback for like your use case so we can make this better. Yeah for sure.

I mean, this is like, I mean, if we’re, I know it’s a SwiftUI lab. It’s a I love interop. We love frameworks, being friends. We love frameworks. Drop some UI window on us. I thank you for the the invitation. I feel like I. Feel safe saying that now.

Yeah. I mean, because even in in UIKit, if you even if you’re a UIKit SwiftUI at all, it’s difficult to present something or to get something on top of other presentations in your app, especially if you don’t have a central way to manage all your presentations and don’t know if there’s anything there.

And so the easiest way maybe to drop down to UIKit and you could make a new UI window if you’re using like UI kits scene lifecycle, and then you have access to the scene and you can edit it with a scene and you can position it on top of things. And so if you have like a HUD or like a very specific use case that really needs to be over something, then like you can drop down and do that and you can put SwiftUI in there.

So you could make it root view controller, a UI hosting controller, and then do anything you want. Yeah. And it probably wouldn’t be so bad. It should work. Yeah, there’s plenty of times I’ve. Hacked. It together. Yeah, for years and years and years. It does then kind of lead you into another area where what if, what if something wants to draw on top of that? I do find this way of thinking can sometimes feel like, well, I’m, I’m the number one thing.

Of course, this thing should. Always be on top of everything, which is true until you think of something else that needs to be on top of everything, and you. Have to think, or a. Person on your team who didn’t know that you thought your view needed to be on top comes along. Right? And then and if you don’t, I think it’ll like it’ll be last last UI window wins. So if if you have two teammates making UI windows. Then. Whichever one is last wins. And that’s the whole thing. SwiftUI is trying to solve. And I think that. Actually.

Gets at a really interesting way of thinking about problems like this sometimes. It’s it’s kind of a reductio ad absurdum. It’s like, oh, actually, we Can’t have a distributed decision making process about which windows on top right. There has to be some source of truth for what layering we’re doing there.

And if it’s just all the different pieces of code can say no, now it’s me. That’s that’s a bug waiting to happen. Yeah. And so think about whether the design brief is right here. Maybe that’s not the right way to design the app. Maybe, you know, whatever you would present the full screen cover for should actually be a more elegant, more elegant flow, right?

You know, maybe it is rewinding the navigation stack to, to some base view and then restoring that navigation when they log in. There’s other ways to approach that, that problem. I’m not saying it’s always wrong to present a full screen cover, but you know. It feels very. Disruptive to the. User. Yeah, yeah.

Yeah. And in general, like for any of these things where you do need to drop down to UIKit for these sort of things, that is not like a bad thing. We build our frameworks with real interop in mind for exactly this reason, right? There are cases that will work better in one framework better than the other. But if you find things that you really want to accomplish in SwiftUI and you need to drop down to UIKit for them, all feedbacks about that we want to hear like where you’re running into those corners so we can ship some APIs to make them better. Yeah.

Excellent. So this question is along a similar line. I think I’ll start with you on this one, Anna. So the question is what’s the best way of building a pure SwiftUI custom control. And I think we’ll come back to pure SwiftUI before we’re done with this. But for now. Let’s. Take it at face value, a pure SwiftUI custom control, like a drop down that can expand on top of other elements and be interacted with, but doesn’t impact the layout of those other elements.

So how can I go about building a custom control like that? Yeah, I mean, definitely. So I think first, like I would think about, does this need to be custom? Does this not need to be custom? Kind of like going back to what we were talking about, you know, if there’s a control that exists in like UIKit or exists in Appkit and SwiftUI doesn’t have it, and you’re considering building your own custom one in SwiftUI, I would probably think about using the framework interop and just using that UIKit or Appkit control, because then, you know, you don’t like if things change in the framework, like, you know, like this year we made some tweaks to the new design.

You just get that for free and you don’t have to then go and make updates in your app. But if you want to do that, that’s definitely a very fun question. SwiftUI is definitely pretty compositional, and so you can kind of compose a lot of those building blocks to build really powerful things.

I think one principle I would say that is like good to think about here, because the question is kind of like impacting the layout of other elements is so like the way that SwiftUI layout works is, you know, like the parent asks the child for its size, but it’s kind of a proposal. The child can still decide, you know, to draw like bigger, to draw smaller. And it like reports its size.

So one thing that you can do here, and I would love to double check just to make sure, because this can get kind of complicated, but you can effectively, like, you know, you get proposed a size, but you might, you know, tell your child actually to draw a bit bigger than that. Hey, like you’re cool to draw this big, but then you tell your parent, I’m only this size.

So like, so you might be lying a little bit, but that means that, you know, you can like lay outside, you can lay outside of those bounds effectively and do an overlay that isn’t going to affect the layout because you’re just, you know, reporting a stable size, but also you can use like SwiftUI overlays or kind of like a higher level convenience on top of that.

So yeah, I’d go, I’d go so far as to say that’s not even like lying. That’s kind of the intent of like SwiftUI layout system, right? Is that parents propose sizes to children, and then the children get to look at the proposal and say, no, I’m actually this size or I do fit in those bounds, and I’m going to go here and or rather, I do fit in this size. I’m going to be this big. And then the parent can can play. There is there’s one case where that can or maybe more than one, but I know of at least one case where that can get you into trouble.

If you’re drawing outside of your, your reported bounds or outside of the layout frame that you’ve been given, and you’re in a scroll view. Yeah. The the system may remove your view from the view hierarchy because it thinks your layout bounds are off screen, but you have a protruberance sticking out into the screen and suddenly it disappears. Yes. And so combining. Talk. About that. Yeah it does.

And yeah. And so I learned that this year it’s. A good. That’s even a gotcha with, with overlay too, because I was, I was going to go with overlay just because overlay, you know, that you won’t affect the surrounding layout. You’re very isolated in that render. But also to that point, if you’re like overlaying a view big and you’re your host view is small and it scrolls up off the screen, that’s a, that’s a tricky one. Yeah, yeah. I watch this talk. Yeah.

It’s really good. Design talks that were really good this. Year. And that’s I mean, that’s another reason to stick with custom controls. Like there are all these interesting corner cases you have to consider. And so you know, maybe the drop down menu should actually collapse when the view that’s hosting it scrolls, right?

Because the person’s demonstrated intent not to interact with that because they’re scrolling it away. Or maybe it should stay and they’re trying to scroll it so they can see more information. It’s like there are these really fine corners that you need to consider when you build your own custom controls. Swipe actions are a really good example of this. The the container for swipe actions is responsible for coordinating all of the the various actions.

And when you scroll, you’ll notice that if you have like a, like a, if it’s swiped, basically that it’ll dismiss. So that that, you know, it’s detecting that intent that you’re scrolling away. And it’s all those fine little details like you were saying. Yeah. And thank you for bringing up swipe actions. Because. It is my favorite API that’s. New this. Year. And Stephen and Julia is what’s new in SwiftUI.

Talk talks about this, but previously you could apply swipe action modifier to rows in a list, but. But nowhere else in SwiftUI. And now you can make any container. A container that supports swipe actions by putting, you know, swipe action container on it. I think it’s a very literal name. And, and now you can add swipe actions there, which I think is it’s so much fun.

Before we move on fully, I do want to add one note, which is, you know, some of the things we said are like, oh, use system standard controls. And I totally agree, but I also don’t want to discourage people from making their own controls. Like, yes, it’s complicated. There are a lot of things to consider. It’s why it’s a serious investment. But sometimes they can be like, you know, the little touches of magic that like turn an app from like good to great.

But I encourage you to think very critically when you’re doing this. Like, am I adding real value to the experience by designing this as a custom control, or is it better as system standard UI? Because using system standard UI means you get like an experience people are immediately familiar with.

But if your app has a very specific case where you can do something more, then don’t be afraid to to drop down and get your hands dirty. And the other thing I bring up, and it’s something that that Jason mentioned in our last panel, if there is a ability to add custom styles for that, reach for a custom style before you wrap a control and make a custom control, because you’re going to get all the accessibility support and everything. You’re just controlling how it looks.

And so that’s a great way to approach sort of that style that you might want to go for, not to overload the term, I guess, while still, you know, getting that, you know, all the built in behaviors that you would expect from a built in control. Well, the other thing that I thought was interesting about what he said in that was not only do you get that, but also you can use all of the normal control initializers so you don’t have to create a million ones. Like that was a point. I feel like. I just think styling is really cool because of the points you just mentioned, but also like that initializer benefit, not having to maintain it is really nice. Yeah, yeah. How many initializers does button have? A lot. Many. Yeah.

There’s one fun thing I want to share about swipe actions, in particular the I don’t know the technical term, but the small circle buttons that exist as you swipe it open. If you’re using that outside, if you’re using the swipe actions modifier, those can be any view now.

So it’s not just a label, it’s not just a text, but you can, I wouldn’t recommend it, but you can put a navigation Split View in there and it’ll render. You’ll get something you will get. Now, we’ve lived up to SwiftUI After Dark. But more practical stuff in there, like your own your own custom view. It does. Again, it won’t just be limited to the UI window.

Window view subclass. I mean, dangerous experiments in SwiftUI won’t return. One from your view. Representable. All right, I think, I think we can take a couple more questions. We’re getting near the end of our time, Stephen. I’m going to I’m going to direct this one to you. So it’s it’s well known. And thanks. We’ve done a good job of communicating the breaking large SwiftUI views into smaller views benefit SwiftUI performance, but how small should they be?

And like, is there a best practice when we should make new struct views versus just adding at view or at viewbuilder computed properties? Right? So the way that I like to think about this is that breaking things into smaller views is not just about making smaller pieces, it’s actually about isolating the pieces of data that are actually responsible for those views updating.

So the example that I like to use is like, let’s say that you have a view that has a header and some content and a footer, and the header could update independently, the content could update independently. Same with the footer. You wouldn’t want to be in a situation where the entire view is being invalidated. And, and the body is running for everything when only one of those pieces of data changes.

And so that’s a case where it would make sense to maybe split that into three different views for header content footer. If you’re in a situation where the, you know, the dependencies are kind of shared across everything, then splitting things up isn’t really going to give you any benefit at all because you’re doing the same amount of work.

So like the way to think about it is, is that the goal is to, at the initialization point in a view body to provide a boundary where SwiftUI can basically do its comparison and say, actually, there’s nothing new here. So I don’t need to actually do do this work. And that’s why using view builders as computed properties instead of views, you don’t get that benefit because you’re basically declaring the same thing as one giant view body.

Right? Right. You’re like taking your implementation and you’re like moving it out of line, but it’s functionally the same as if it’s all combined into one. And so all the dependencies are still there, right? Whereas like just, I love this question. So I just want to like, even like summarize it for myself a little bit that you, you, you want to like, if you can break things into smaller groups of dependencies. So you could think of a view as like the.

It runs as often as any of its inputs change, like any of the things you pass into it. Bindings environment like whatever you read in body. When any of those things change, the entire thing is going to be reevaluated. And so if there’s like one thing that changes all the time and eight things that change very infrequently, and only a tiny part of your view body that changes based on that one thing that’s changing frequently. If you can move that bit out, then when that frequent thing is changing. And. And the original body doesn’t need it anymore, then it won’t run at all.

Now, if you like had to pass it through, then, then that that body would still run because it’s being passed through. But there’s other ways to like jump over. That’s a case where observable comes in handy because the pointer to the observable doesn’t change. And so it doesn’t change the super view, but the property that that little tiny sub view is reading out does cause it to redraw. So you can skip the big stuff up above and just do the little one right.

And don’t be afraid of having lots of views like views or structs, their value types, they’re cheap. You know, we shouldn’t be afraid of having lots of smaller pieces. All right, we’re nearing the end. But I wanted to get to this question. I think it might be a a good closer for us.

So Sam, I’m going to start with you and we’ll just swing across the panel. Okay. So having used SwiftUI since day one, SwiftUI one, maybe the framework has truly come of age. Thank you. Looking back at the evolution from the early state and the navigation pain points to the mature declarative engine we use today. What are you most proud of? Oh man. That’s that’s really tough. What am I most proud of? I would say it’s a combination of two things.

I think the first one is just like a smaller thing that I got to work on that I’m really proud of, which is the custom containers APIs. I talk about them a lot, and it’s a very complicated thing to express that I think we managed to distill down to its essence. I’m really happy with how that turned out and how the cool things people have made with it. And then the other is more about the overall shape of the framework.

We’ve done a really good job of making sure that we think about things in terms of like a little bit like more semantic pieces rather than like, oh, this is going to appear in this specific way on the device thinking, okay, what is the thing? Like, you know, a tabview, a tabview can either be the standard thing you’ve seen or it can be like a paginating scrollview. But like, ultimately they’re the same pieces like data flow wise.

And it’s been really cool getting to like rethink the platform’s UI systems in terms of like this new way of thinking about them, like how is their data flow arranged? And I’m really proud of the job we’ve done with putting the pieces together there. Cool. Russell, do you have something? Yeah. I can just quickly say that I’m most proud of how it’s grown and how we’ve been able to use it more and more internally.

As someone who’s worked on like UIKit for a very long time. You could you could poke around inside of like UI navigation controller and the view debugger, and you would see that we’re starting to use SwiftUI to build some of the new like core UI components that are used across all of the apps, even apps that are not been rebuilt using SwiftUI. It’s really nice to see it reach a level of maturity that we can use it in such broad systems. Yeah. Nick.

I’m. I’m blanking. The only thing that the only thing that’s coming into my head is just like, I’m, I’m just really proud of the team. A lot of people on the team have been around since since day one. And a lot of people are newer. And it’s just such a nice group of people and the way they think together. And I just love seeing people like laugh about horrible API. Things like. Tonight. Yeah. It’s like building that over some amount of years. It’s just as hard as building the framework. And so that’s something that I really like about it. Nice, I love that.

I like how we’ve taken, you know, things that end up being suboptimal. Like, for instance, Geometryreader figuring out the reasons why people are using them and actually providing new APIs that solve those problems. Things like on geometry, change on scroll visibility, change all of these places where people would reach for something like really figuring out those, those cases. I really like seeing that adaptation. Nice.

I think it’s just been really cool to see over the course of, you know, the years how like more of the lower level building blocks have been exposed to allow, you know, people to be able to build their own custom things? Because I feel like some of the stuff that we get to use internally developing for SwiftUI are really cool. And it’s cool to also give those tools to the broader world and see what people build. Yeah. Also, of course, now that we’ve all said this, like, I’m sure all of us are thinking of like ten better answers.

Like they’re just flooding into my mind. Hopefully that’ll suffice. We’ll save those for the next group. Exactly. So we’ve reached the end of this one, and we’re so thankful that you all joined us today and hope you found this helpful and maybe entertaining. A big thanks to our panelists and to all the folks working hard behind the scenes to make this happen this evening.

If we didn’t get to your questions, please visit the developer forums at developer.apple.com/forums to continue the discussion, and visit feedback.apple.com to file any bugs or feature requests and let us know about your use cases. Speaking of feedback, you should receive an email with the survey link to let us know about your experience with all of WWDC. We’d love to incorporate your feedback into future events. Again, thanks for joining us. I hope you have a great week. DC.