Hello, and welcome to the SwiftUI for Beginners group lab. 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: Gabriel, Jeff, Sam, Seema, and Trevor. In addition to us 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 today about getting started with SwiftUI. If you have code-specific questions or we can't get to your question today, we'll continue the conversation on the developer forums at developer.apple.com/forums. If you have a bug or feature request, please go to feedbackassistant.apple.com. We'll focus on questions today that will help the broadest audience. Whether you're new to programming, new to Apple's platforms, or just new to SwiftUI, we're looking forward to answering your questions. We'll start with a quick overview of SwiftUI, then dig into Q&A. Seema, get us started. SwiftUI is Apple's declarative user interface framework, used to build apps across all of Apple's platforms. When you are building a new app or a new feature, SwiftUI is the right tool to use. There are a few reasons for this. SwiftUI comes with a wide range of features. These enable your apps to take advantage of the devices they run on, feel native on Apple's platforms, and add rich interactivity. And adding those features requires less code, enabling you to move from prototype to production faster and empowering you to focus on what makes your app unique. SwiftUI embraces incremental adoption, so you can use it exactly where you need it. There is no expectation that an entire app needs to be SwiftUI to be able to take advantage of it. These qualities make it easier for anyone to learn how to build an app using SwiftUI. Views are the basic building blocks of user interfaces and are important to everything you do in SwiftUI. Every pixel you see on screen is in some way defined by a view. Views are expressed declaratively. You describe what view you want in your user interface and SwiftUI produces the results. This code creates a horizontal stack that consists of a label, which is a combination of an icon and a title, a spacer, and a text at the end. This same declarative syntax applies to other containers, such as scrollable lists. This list is given a collection of pets and creates a series of rows using the properties of each pet. At no point did we need to describe the actions necessary to produce this interface, such as adding or removing from the list. This is because SwiftUI views are descriptions of what the current state of the UI should be. They are not long-lived object instances that receive imperative commands over time. As such, SwiftUI views are value types, defined using structures instead of classes. Composition is used throughout SwiftUI and is an essential part of every user interface. Rearranging and experimenting with container views is effortless. The code itself resembles the hierarchy of views that it creates. This horizontal stack contains three views: an image, vertical stack, and spacer. And the vertical stack contains two views of its own: the label and text. View hierarchies can be encapsulated into custom views and view modifiers, enabling the same compositional features and quick iteration. These custom views can have inputs that change how their body is constructed. This view has a property for the pet that this row represents, which can be used to change the contents of the contained views. This lets the same view display information about whiskers, as well as rufous and bubbles. And custom views can be used like any other view. Here, they're used in a list to create fresh rows for each pet. But apps aren't just static screens. their dynamic, changing with time and interaction. Of course, SwiftUI has you covered there too. Views in SwiftUI are state-driven. You declare what state they depend on, and SwiftUI does the work to keep your views in sync with that data. When your view's state changes over time, SwiftUI automatically keeps the UI that depends on it up to date, while avoiding re-evaluating things that won't change, eliminating both boilerplate and update bugs. SwiftUI has several tools for state management. The simplest one is @State. State creates a new internal source of data for a view. When you mark a view property as @State, SwiftUI manages its storage and provides it back for the view to read and write. This view, for example, allows people to rate a pet's tricks. It's using state to keep track of the current rating, allowing it to change over time. The value is displayed prominently in the middle. And it has two buttons to increment and decrement the value. SwiftUI maintains the value of this state behind the scenes. When the button is tapped, its action is called, incrementing the internal state of the view. SwiftUI notices this change and calls body on RatingView, which returns a new text value. The result is then updated on screen. To add animation to this state change, just wrap with animation around the text. Here, SwiftUI applied a default crossfade animation to the text, but you can also customize the transition. In this case, using a numeric text content transition fits perfectly. SwiftUI automatically provides adaptivity along several dimensions. The app already looks great in dark mode and supports several accessibility features, such as dynamic type. Many components across SwiftUI have this same adaptive quality. One example is Searchable, which is applied to the list of pets here. SwiftUI takes care of all the details to make that happen in an idiomatic way. And through incremental adoption of other modifiers, you can customize the experience, such as adding suggestions, scopes, and tokens. SwiftUI's declarative and adaptive use pack in a lot of functionality in just a few lines of code. There are controls, like button, toggle, and picker, Container views like Navigation Stack, Tab View, and List. Presentations such as Sheets and Popovers. And many more examples that you can explore in the documentation. And when you are ready to create unique custom experiences, SwiftUI also has another layer of API that provides low level control. You can build your own control styles. Use Canvas for high-performance imperative drawing, create completely custom layouts, and even apply custom metal shaders directly to SwiftUI views. SwiftUI is available when building an app for any Apple platform. Thanks for that great introduction. Are you excited to start building? We can't wait to help you get started. And so now we'll go to your questions. Our first question comes from Donald. And I think I'll start this one off with you, Jeff. So the question is, as a beginner, I'm confused. Should I use React Native or SwiftUI? Both are incredible, but I think React Native allows me to release on both platforms. Can you introduce some of the advantages of what SwiftUI can do? Sure. So I would say that one great advantage of SwiftUI is that it's intimately tied to all of Apple's platforms. And so when we introduce new design language, for example, Liquid Glass last year, you get a lot of that for free just by using our native UI framework in your apps versus something like React Native, where you might not be getting those same platform advantages. We also evolve the behaviors of our APIs over time to take advantage of new features in our devices and our operating systems as well. Yeah, one of the things I get to do in my role as a technical evangelist is go out and meet with lots of developers. And one of the things we saw in our workshops about the new design was, So the new design released at the same time as some design changes on other platforms. And we sort of all went in different directions. And the developers that had chosen a cross-platform framework were finding that they were landing in an awkward middle spot. They weren't adapting to the platforms as they were. And so those folks were moving away from multi-platform frameworks and towards native frameworks on all the platforms that they deployed on. because they were finding that the seeming efficiencies at the beginning actually meant a lot more work at the end and more work at a time in the production cycle where it was hard to adapt. And so I think, especially when we have the agentic coding, that Colentis moves so fast at the beginning stages of a project, making the final polish stages easier is sort of a thing to emphasize. There's also the aspect to it that SwiftUI is built on Swift, which is a really incredible programming language. And so just by using SwiftUI, you're able to leverage the power of this incredibly performant, expressive language, which is something you don't get with some other non-native frameworks. Yeah, yeah. All right, the next question, and I'm going to try to read off this person's username. AIdidlitfi. As an accounting student with zero knowledge in coding, and Sima, I'll let you take a first crack at this. What's the best approach to learn coding and building an app with SwiftUI? That's a great question. So the way I approach this and I would recommend approaching this is kind of just think about your life. What is one of the problems that you encounter every day? Or think about your family. What would be an app that would help them? And that would motivate you to come up with an idea that would be helpful for you, your friends and family. And then you get to share it around and see them use your app and actually improve their life with it. That's how I like also like years ago got into like iOS development. And then I think nowadays with agentic coding and Xcode, you get to build it faster. And I see it come live on screen in minutes, and it's great. And actually, this year, we have enhanced our agent-according capabilities and Xcode with some of the skills that can help you build even better experiences. So, yeah, go ahead and give it a try. Hopefully it works out great. And I love that idea of finding some little problem or thing you want to build. Find what that spark is. I think it might be kind of fun to talk about what some of our first apps were when we got into this. Like, Sima, are you willing to share what one of your first apps was? Yeah, I have two. The first app I built was like a Pomodoro timer because I, back then, I was like very into kind of organizing the way I work. And I like some of those productivity tools. And I wanted to build a custom experience for myself. And I really enjoyed customizing the app for me and kind of seeing myself, like, take advantage of, like, using it and, like, actually make my work more productive. So that was my first app. Nice. Anybody else want to share first apps? I got a good one. When I was a little kid, our dogs, for my family growing up, used to, like, jump on our bed all the time. And I had, like, just started learning about, like, iOS development. And the only way we could find to consistently get them to get off the bed was if they heard, like, our doorbell sound. So I recorded our doorbell sound. I made an app that we called Dogbell, where you could just, like, press the button, and it would make the dogs jump off the bed. Very useful. Yeah. Anybody else have one? I think one of my first ones, but this was probably with AppKit, because this was a while ago, was a to-do list app, because I was always forgetting to do things. And I probably also didn't spend enough time on it because I'm sure I forgot to finish it. Nice, excellent. I learned iOS development at a coding boot camp, and they had a ping pong table there. And my friend and I that were just learning, we would play ping pong all the time when we'd take breaks. We would always argue over the records and who was better. And so we at one point just built a little app to keep track of who won more games historically. Who was better? He was much better. It turns out I knew that all along. Yeah, you should have been keeping track, apparently. I have made an app specifically for colorblindness. So as somebody who has red-green colorblindness, I found that it was really enjoyable to actually go through the process of making an app and kind of adjusting it for my own needs for day-to-day, figuring out differentiating things, and kind of making an app that felt natural to the way that I work, I come about my life. Nice. I love it. Excellent. So thanks for sharing. Our next question comes from Sehan. And maybe I'll start with you on this one, Trevor. Sehan writes, I'm a CS student just starting iOS development. If your goal were to become a highly skilled, job-ready iOS engineer in 2026, what roadmap would you follow from Swift fundamentals to advanced app development? And which skills would you prioritize most? There's a lot there. I think we're all going to be able to jump in. Yeah. I would start with Swift. That's the basic building block. Make sure you have a good understanding of the basic language that you're going to be working with on iOS. Swift can be really different if you're coming from another language, the type system, concurrency. There's lots of features that are going to be new and really interesting. And honestly, I think really great to learn from the start versus maybe learning unsafe habits in another language where Swift will kind of enforce those things for you and allow you to learn them along the way as you're learning, which is great. And then I think the fun part becomes diving into SwiftUI, building a basic app, something that you're going to have fun with, one of those things. There's some really great resources online for SwiftUI. The online interactive tutorials, I think, were the most incredible introduction to SwiftUI. When I saw animations in there, something really clicked for me. And that would be, I think, the first couple months. There's a ton within just those two things, but that's where I would start. Anybody have anything to add to that? And I think one of the things that I think is going to be valuable is, like, use the agentic tools. Make those part of your learning. But make sure you're thinking about the output they're producing, right? The goal. So I was a teacher in a prior career. And when a teacher assigns an assignment, it's not because they want the answer. They know the answer. what the teacher is looking for is they're trying to give you practice on an area, right, to up-level your skills. And you can do the same thing with your own work. If you have an app you want to build and you're using eugenic programming to help you get started, look at the output, understand what it's doing, engage with it deeply, not just at the surface. Anybody want to? Also, I was just going to say a quick add-on. When it comes to, like, using LLMs for programming generally or for learning specifically, treat them like tutors. Like you can just, you know, instead of just having them generate code and like looking at it and studying it, you can ask them questions about it. Like it is really like having an interactive thing with you that has a really deep domain expertise on a lot of stuff. Yeah, that's totally what I was going to get at, too, is like I feel like these tools are really great at explaining concepts. And so this can be a really valuable tool to learn some of the underlying kind of CS concepts as well. especially when you're building an app you need to know a lot more parts than just the UI right there's networking calls and data storage and all that that it can probably do a great job explaining some of the underlying algorithms that you might want to use for some of those pieces as well. That gets another kind of interesting thing you can do with these like instead of asking the agent to write some code for you you can take a stab at writing the code and ask the agent for a code review. It's like, you know, what could I have done better here? What were there APIs I should have considered or looked at? And so it's nice to have that tutor in your pocket. It's kind of cool. Ah, this is a great question. Sam, I'm going to start with you on this one. Okay, what you got? Since you covered this in our little intro segment. So this is from Will Picks. For a beginner coming to SwiftUI, what exactly happens under the hood when I use at state? Why can't I just use a standard Swift var for data displayed in the UI? Yeah, so one of the big concepts behind SwiftUI is that we want views to be very lightweight descriptions of the actual thing that's getting displayed, rather than some long-lived thing that sits around and you change over time. but we do still need some place to store the information that is going to change over time, like if you have a counter that's incrementing or just some value that needs to change over time. So what state says is, hey, SwiftUI, take this value and own it. Make a persistent thing that you can kind of keep around, a little box for it, and it does this under the hood. It makes a little, it allocates a little piece of memory which just lets it sit with this value, and then it gives you the ability to read it and to write it whenever you have closures that change. And the combination of these tricks basically means that you don't have to think too much about where the values are getting stored or memory allocation or any of the complexities under the hood. You can just make the value and change it. Yep, yep. So that I think for folks who maybe have more like a CS background or are coming from perhaps like UIKit or another sort of traditional object-oriented framework, I mean, it's not required to have that background to use SwiftUI, but that sort of difference that a SwiftUI struck is a value that describes the view. And so SwiftUI is like making an instance of it. It's grabbing the state that you have stored away, putting it all together. It's rendering the pixels, and that just throws it away. And the pixels are on the screen, and memory is preserved for other work now. And so that's sort of one of the things that's really different about SwiftUI. It's like you've got this template for what the view should look like. It pulls all the pieces together, puts the pixels together, and then it's on its way. Yeah, I do think that for lots of people who start out with SwiftUI, a lot of times it's confusing in terms of like, when should I use add state? Or when should I just store something as a variable on the view struct? And as Sam, I think, and Kurt, you just touched on, SwiftUI will recreate your view struct many times as your parent view updates and just through your app's lifecycle. And so it sometimes becomes harder for you to kind of use this just the normal property because it'll just get thrown away every time. And so I think state is a great tool to kind of let SwiftUI kind of store this value away and kind of keep it there alive for you so that every time view is recreated, the new value is available to you and you're able to actually change the state. The Swift language is really nice here because if you try to just declare a variable inside of a view body and then change it, you'll get a compiler error and you won't be able to build your app. And so at least you have that nice warning to say, hey, use that state here to key Swift UI in on knowing when it needs to redraw. That actually loops back to our first question And part of Sam's answer to that is why choose SwiftUI? Because it's embedded in this type-safe programming language, the compiler is going to find your mistakes for you instead of having to tease them out at runtime. I always find it miraculous when using Swift or honestly any strongly typed language, how often your code compiles, and then it just works after compiling. It sometimes feels a little miraculous. Yeah. Full disclosure here. Sam and I are both programming languages nerds. And so anytime you give us a chance to talk about programming languages, we will and we won't shut up. But in order to keep that from happening and also because this next question names four programming languages, Gabriel, I'm going to start with you on this one and then maybe throw it to Jeff. This is from MKWB. I'm primarily a web designer with knowledge only in HTML, CSS, some PHP, some JavaScript, and some Lua. It's a pretty good list, so don't show yourself short. But I'm interested in learning to develop apps for Apple platforms. How easy would it be for someone with little to no traditional coding knowledge or skills to get started with Swift and SwiftUI? Yeah, especially for someone who already has experience in stuff like Lua and JavaScript, it's pretty easy. First of all, in terms of Swift as the language itself, it is very similar to many other C-like languages. So you'll be well at home with the syntax. A lot of the concepts will make sense to you if you've done JavaScript. And in terms of SwiftUI as the kind of embedded language, a lot of it kind of feels similar to what HTML and CSS will be. Obviously, a little bit tangentially different. But a lot of the concepts and the kind of immediately apparent hierarchy that you're used to by reading through HTML is kind of the same way that you would declare your views in SwiftUI. And again, I want to stress, don't underestimate the knowledge that you already have. It's a huge starting point to have any coding knowledge at all. And Swift enforcing things at compile time. And there's also a whole bunch of developer documentation, especially now with these agentic tools that are readily available for you. What I find particularly helpful-- so I'm somebody who started with Swift, and I've now needed to actually dabble in Objective-C for various reasons-- is I find it actually useful to use these agentic tools and ask them, hey, I have this concept of this flow written out in Swift, what is the idiomatic way that this would look in Objective-C or something like that? And having that kind of back and forth, say, taking this knowledge that I already have, can you help me convert my mental model into a different idiom? Sure, sure. Jeff, I feel like Gabriel's answer sort of started us walking back your career history. Yeah, so for context, Many years before I came to Apple, I started basically doing HTML and CSS, maybe not any PHP. And when I started working on SwiftUI, I found it very similar to doing that before, especially in terms of how you describe the structure, like Gabriel was talking. So I'd also say that a lot of our kind of layout concepts feel pretty at home if you've been working in kind of building web pages and stuff as well. So it sounds to me like you have a great start already. Also, the web is like, you know, was the world of declarative frameworks before Apple platforms were, right? Like, you know, HTML is itself declarative, and then, you know, there are a bunch of frameworks built on top of it that are declarative in a very similar way to SwiftUI is. So if you have any experience with those, that helps too. The other thing I'd mention, I think, is if you're coming from the web, You're used to a browser that's updating as you're making edits, which is a little bit different than sort of a compile-and-run architecture that most native languages have. Check out previews in Xcode so you can see the dynamic updates. Now with Device Hub in Xcode 27, you also have options for showing the simulator right there or actually pulling a mirror of your device on screen. And so there are tools for getting those instantaneous previews, But I think that is one of the road bumps that people hit. So make sure you check out previews and use that to see how to sort of preview what you're working on. Trevor, I think I'll throw this one to you to start here. This question comes from Classic Flame. My question, where should I start? Especially in SwiftUI, there's so many tutorials, even on the Apple developer side, and it's a little bit confusing what to do first. Where should I begin? I'm a Java developer and want to begin with iOS programming. Thank you. Like I mentioned earlier, those initial tutorials, can we link those somewhere? Yeah, I think we have a mechanism for doing that. I'll ask our folks in the back room if they could respond in the thread with links. Knowing the folks in the back room, they may have already done that. I think those tutorials, there's a series of tutorials that will walk you through everything from here is a view body to state to animations, and here's how data flows in SwiftUI. It will give you a really, really solid foundation to start with, and I think that is probably the best initial set of resources. Personally, I think when I started learning SwiftUI, I worked through Paul Hudson's 100 Days of SwiftUI. - So say we all. Yeah, which I think lots of people have found that super helpful, and that's a great little, very bite-sized chunks of content that are great. Yeah, to add to that, going back to the community resources, there are lots of books people have written about iOS development, lots of articles available online from other authors we have in the community. Yeah, and the official Apple tutorial is great because not only it teaches you SwiftUI, it also teaches you how do you then make your app more production-ready with, I think they also discussed some of the common data storage solutions and databases and how to wire it up to your app. So there's lots of depth there, so definitely start there. And if you feel like it's lacking some of the details, there's always the community resources that can walk you through. And I actually want to throw back to your first answer, Seema about getting started. It's like sometimes it's instead of just like, all right, I'm gonna do all these tutorials, these are what I'm supposed to do. Sometimes it's a matter of like, this is what I want to make, and then let that guide the tutorials. - Yeah, that's the most effective. - Search or ask the agents, yeah. - Yeah, that's the most effective way I also feel like is to learn those tools, because when you're, we have the goal of like, I want my app to do all these features, And it's like, okay, what are the tools that get me to implement those and wire them up all together so that the app does what I initially intended it to? And that's the best way for you to learn. And even if you're following a tutorial online on how to build a certain kind of looking app, I've encouraged you to think about what would be another feature you can extend this app with to make it more personal to you, not just what the tutorial shows. and that's going to help you kind of really solidify those concepts that you read about. And there's just so much satisfaction in building something that solved the problem you had. This did make me realize that we haven't talked about the human interface guidelines at all, which is another great resource on the developer website, which can walk you through some of the kind of design concepts that are common to Apple's platforms and help make your app feel right at home on whatever platform you're developing. Yeah, and that actually raises another thing that I really like to do to learn part of an API or something is play around with other apps. There's this really cool thing in mail. If you're in your inbox and you scroll up, the inbox title flows into the title bar, And then the number of messages animates in behind it. And it's just a delightful interaction. I'm like, wait. And I guess I could have. I work at Apple. I could have just gone ass. How did you build this? But I wanted to learn. And so I tried to figure out how would I build that with the pieces that are in the API. And so it's kind of fun to do that. I'm like, oh, yeah. That's just code. I can do that. I really enjoy that part of the experience, too. All right. So this is a question that may call back to our conversation around state. So I'll start with you, Sam. Sure. This is from Charlie. Charlie asks, what are the best practices in SwiftUI to handle frequent real-time state updates, like sensor data, without causing unnecessary view redraws or lagging the UI? I'll throw to you after this, Gabriel. I think you'll have something to say, too. Yeah, there's a lot of tools at your disposal here. And it's really going to depend on the specific kind of data. but if you have things that are updating on a per-frame basis or very, very frequently, just AdObservable is a really good tool for these kinds of things. If you put data in an AdObservable and then you use it in various parts of your app, SwiftUI makes sure that only things that changed in your observable actually cause UI updates. It's very specific about that. Other things to make sure of or make sure you're not updating values that are dependent on various places in your UI and at too high a frequency, right? You want to very much limit your dependencies. - Gabriel, do you have a follow-up on that? - Yeah, and like what Sam was saying, you kind of want to make sure that you have as cheap a view body as you can get, as much of a leaf view, if you may, for these types of rapidly updating things, because you don't want to have a situation where we throw away large chunks of your data and have to redraw that. And also, if you have content that is like a series of content, there's stuff like timeline view. And also, if you need lower level control, you also have things like lazy stacks, where you can kind of consolidate the information that you have directly to whatever is in your viewport. A lot of these optimizations are also handled for you if you have stuff in like a foreach. So if you have a foreach that lives inside of something that is lazy, like a lazy stack or a list, you can kind of be rest assured that we will try to make sure that we're only invalidating and redrawing as much as we need to. But yeah, so keep your view bodies small and evaluate where you can make things lazy if you can. Yeah. So a couple of other things I would add to that. If you have something that's updating per frame, I would ask the question, does your UI need to update per frame or can your data model compute some semantic value like let's say you really have three states that you're computing between um you know something that does update at a very high frequency then you only have to reevaluate your view body whenever you transition between those three states and so you can get a lot of performance gains there and then the other like just general best practice is avoid putting those things in the environment right because you it may invalidate a lot of views downstream of that. - Yeah, and to add to that, I also wanted to touch on the concurrency angle a little bit. I think it's very easy when you have something like timeline view or something kind of updates per frame kind of accidentally start doing some asynchronous work and that can add up quickly. And SwiftUI views work best when the inputs through the views are more synchronous and you kind of keep most of the async stuff outside and then you also get to test that and really reason about it a little bit better. And that also helps us make your animations way smoother and view updates work more effectively. - Also just to quickly bring it back to somebody who's maybe a little newer to the framework, I think the thread across all these pieces of advice is break things up into small reusable pieces. It'll both help with your code organization so you can understand the things you're writing, But it also plays really nicely with SwiftUI's performance model. So that's how you'll get the best code. Yeah. Sorry. No, please. I was going to say, if you're just getting started with this too, you can take a lot of comfort in that SwiftUI manages so much of this for you, right? And so there's no need to get really stressed out about this performance right off the bat, right? You're going to get really good, lazy performance out of SwiftUI just by using it naturally. And then optimize when you need to, right? Like profile and try to optimize faster. The SwiftUI instrument is really good for profiling. that really helps you get a lot of insights about where you're spending time. - Yeah, so Instruments is an advanced tool. It's probably not something you're picking up on the first stage of your journey. But if you're coming from maybe another one of Apple's UI frameworks to SwiftUI, maybe you know Instruments already. So not all beginners to SwiftUI are beginners in general. - You can start by trusting SwiftUI's laziness And then when you start running into performance bottlenecks, that's when it's a really good time to start breaking out the heavy-hitting tools and doing some analysis. So, Charlie, that was a great question. Clearly, we have a few things on that one, so I appreciate that. So the next question, and Sima, maybe I'll start with you on this one. This comes from Itricho, and the question is, has Apple intelligence within Xcode been fed with all the information and documentation around SwiftUI? having tried to vibe code with Gemini its ability was okay but often hit recurring issues with Swift yeah that is a common issue we see with large language models sometimes producing a little bit incorrect results when it comes to SwiftUI and some of our newer APIs that maybe the model wasn't really trained on yet but this year we've introduced SwiftUI skills that actually we're fed with all of our internal knowledge, all the best practices we have for data flow in your apps, for the new APIs that were introduced. And you get them out of the box when you use coding, agentic coding in Xcode. It automatically has access to all these skills. So every time you build a new app, it's going to automatically invoke those skills whenever needed. There is a way to export those skills to use those other third-party models that you may be using. We did cover a way to do that in What's New in SwiftUI talk, so go ahead and check that out. I think it mentions that in the very last bit of that talk. The third to last slide of What's New in SwiftUI. So watch to the end. Yeah. Anything to add to that? I think that sort of sums it up. The nature of LOMs is they have the data that they were trained on at the time they were trained. And so skills and the other things that we're adding are a great way to level them up as we level ourselves up. Yeah, and also they're always evolving. So, I mean, if you find that it is stumbling in the new Xcode skills that we have, please, please file feedback. It'll really help us out in improving these tools for everybody. But we did find that the models got significantly better reasoning when they were invoking those skills. So we're sure that the skills should provide greater comfort when using those models. Also, while you're mentioning filing feedback, if you're new, especially to Apple Platforms development, file lots of feedback about everything. Any issues you hit in the betas, even just things that are confusing to you about the framework. getting to hear your thoughts on the tools we're shipping is like how we decide how to evolve them. Yeah, and there's two ways to give us that feedback. If you're running the betas, their feedback assistant app is part of all the betas now. So you can file feedback right from your device, whether that's your MacBook or your phone or your iPad. If you aren't running the betas, but you're running, well, whatever you're running, I guess. But especially feedback on the skills that we've added in Xcode 27, you can go to feedback assistant, all one word, dot apple dot com, and that's the other way to file that if you don't have the betas installed. Do developers need to do anything to enable the skills, or they're just kind of there by default? They should be there. When you go to Xcode and you invoke the coding agent window, where you prompt the model, the skills should be already loaded, And I think that they would be invoked based on the context of what the... So you have a SwiftUI file open and it's going to kind of know. Right, yeah. So it should kind of refer to the appropriate skill when needed based on the context, which is great. And if you're using an LLM outside of Xcode, make sure you check out what's new in SwiftUI so you can export those skills because those will not have that baked in by default. Right. And let me try for a segue here. Our next question is from Aziz. And Aziz, and I think I'm going to start with you on this one, Jeff. So it's back to the performance question. What are the best practices in order to make my SwiftUI views performant and not have unnecessary view updates? And the segue here is that the agentic coding conversation in Xcode is implemented in SwiftUI, and it's highly performant. And so it's definitely possible to make highly performant code with SwiftUI. But I wonder if we could talk a little bit more about what are some of the best practices. And we talked about breaking views down, but is there any more we can say there? Yeah, and I think we talked a little bit about using Observable. This is like a really nice tool because the way it works is only properties that change that are also read by your view will establish that dependency to kind of reevaluate the body. So if you change a property that is only read by, you know, say one view or two views, then only those are going to update. And you don't have to worry about any unnecessary updates outside of that. Yeah, and I think that gets at the mental model that I find helpful for thinking about SwiftUI view updates. Like if you've got a view and it's got – I hope this works on – let me draw with my hand. But if you've got a view and it has a bunch of subviews in it and then they have subviews and so it sort of forms like a tree, When the view at the top has to run its body, anything that it reads will cause its body to run. Then it instantiates the views underneath it. But if they haven't changed, we don't need to run their bodies. It just runs that one at the top. But similarly with observables, so if you've got an object that represents the data that you're showing, if there's a view way down the tree and it's the only one that reads one of those pieces of data, then only that little one down at the end needs to update. And so if you look at your views and you've got a view that is reading every single property of some observable, well, that view is going to update a lot, right? And so that's an opportunity to maybe break out some pieces of that. Yeah. One advice I have is also, and I think we touched on that, but make sure to, with environment, make sure to kind of only read the environment that you're actually using in ViewsBody because every time environment changes, we also have to invalidate all the views that read it so that they stay up to date. And it is an important kind of thing to watch out for to keep the unnecessary environment outside. Yeah, yeah. So for folks who haven't experienced or worked with this yet, environment is a mechanism for injecting some values at the top of a view hierarchy and then being able to read it down at the leaves leaves without having to pass it along every time. It was really designed for things like color scheme, screen size, stuff that doesn't change rapidly. You can also pass observables through it, and that works fine because they're only updating at the point they're read from. But avoid, and that's what you're saying, Seema, avoid don't pass the current time in milliseconds in the environment because everything down the tree is going to be updating all the time. I did want to get back, I guess, a little bit to what you said earlier about breaking things up. I think this is also a really important thing to think about in terms of trying to make your view bodies as small as is reasonable for what they need to do and extracting out pieces into your own custom views and spreading things apart that way. It's also a great tool for being able to reuse components across different places of your app. Yeah, another to add to that, a great way to kind of spot check those places is sometimes you notice how you like add like the same set of modifiers like in different parts of your view hierarchy and that's a great way to like take those like modifiers and kind of abstract it into like a custom modifier that you can then like apply. And same thing with like some bits of your views that look repetitive across the app, you can kind of take them into custom views and then reuse them, and that's going to make your code more maintainable, more readable. And yeah, I think it's a great way to kind of go about that. Yeah, I love that. And there's a couple of things I saw talking to developers in the community and questions that came up a lot that are also related to performance. One way people will sometimes try to simplify a view that has a very large body is to pull pieces of that view out and put them in computed properties in the same view. I wonder, you're smiling, so I'm going to take this to you, Trevor. Is that effective, or what's the right approach there? I think it's just inferior to refactoring that chunk. That chunk of the view into its own custom view. And there's a couple reasons for that, right? One is if you, let's say you have a button that's at the bottom of a view, and that's some custom stack of buttons, let's say. If I refactor that into its own custom view, then one, SwiftUI can only reevaluate that view body when something that actually relies on changes, so you can get better performance there. But two, now I have better modularization of my code base, and I can go reuse that stack of buttons somewhere else. It can help with testing, right? There's so many other benefits that you would get by just moving it into a custom view, and personally I think it's much more readable. So I would avoid that pattern of these computed properties inside of a view. - I feel like it does also depend on your use case 'cause sometimes if the property is really small as long for readability, it's fine, but because sometimes when you're moving to a custom view, you also have to move some of the state into it and maybe you're only planning to really use that code in one view, So it really just depends on your usage, but I think the general guidance should definitely be abstract more pieces outside of your view and put them in the custom views. I think it's a great guidance in general to have. Yeah, and from a performance standpoint, moving something out of body and into a computed property doesn't actually buy you anything. It's as if it was in body. It really is only a readability win. So until you break it into a separate view that SwiftUI can invalidate separately, you don't get the performance improvements. Can I say two more things on this? Yes, please. Sorry, I have so many ideas about performance apparently. Avoid doing any heavy work inside of view bodies because they may run frequently. So like one example I think that's easy to reason about is you might create a number formatter inside of a view body to format some number that you're showing inside of text, right? Can you create that number formatter somewhere else that's cached that's not being allocated every time your view body runs, right? So if you can avoid those little things, those are easy refactors. Array transformations are another one that people run into with like a for each and things like that that are often a problem. And then the second thing is, don't worry about this too much if you're just starting SwiftUI. That's good. It's going to do so much for you. It's good performance out of that. Also, all of this guidance is in the skills. So if you're using a model to generate that code, it should automatically put refactor reviews into smaller views. So that's great, I think. And that is a perfect segue to our next question. I'm really on it with the segues today. I feel like Simo might be reading ahead. This is from N586FL. Rolls off the tongue. In a world of a genic AI, what is the effective way to leverage AI within Xcode and SwiftUI to help ensure that the student is learning SwiftUI and not just having the AI write the code for them? And is there an effective learning plan that incorporates AI without derailing people's education? And the teacher in my heart just loves this question. It's so important. So any thoughts on this? I would love anybody to chime in. Ask questions. Ask AI questions. Like when you see it spit out like a chunk of code and you don't understand what the code is doing, ask it a question like, hey, what is this doing? And if you have an idea in your head that's like, oh, maybe I could have done this differently, then ask it again and be like, hey, could I do it this way? And how can I accomplish that? And then I feel like that is the most effective way to learn. And I think if you don't ask those questions, you'll quickly find yourself in a situation where you have an app, but then you're trying to add something to it, but you feel like you don't even know how the code is structured and where should the new piece go. And I think kind of building that confidence with your code through like asking those questions is a great way to learn. And I think like I think Sam was mentioning earlier, it's like really treat it like a tutor, especially when you're a beginner. When you're more advanced, you might feel more comfortable kind of like trying to put as much speed into your work as possible. But when you're a beginner, treat it like a tutor. You're asking it questions when it's writing something. It's supposed to be an informative thing. try and, like, a tutor is not going to tell you the answer to your question and then just leave it at that, right? That it doesn't do anything for you. So when you get something generated by an AI, definitely be, like, interrogative about it. Ask a lot of questions. If you don't understand step-by-step what the AI is writing, try just, like, hammering home what is this code doing? Because it's, honestly, it's one of the greatest ways to learn because you get to experiment really fast and you get to learn concepts basically on the fly without even having to have like some prerecorded thing. Also, like as you go up the skill curve too and you are getting to the point where you're like more comfortable and making a lot of the decisions for yourself, I encourage people to like treat LLMs like less like an employee and more like a coworker. Like, you know, when I'm working with anyone on this panel, like so often I'll be like, hey, I've got this idea. I wanna build this thing. Here's what I'm thinking. What do you think of this? Is this at all correct? And you sort of go back and forth and then it will, the LM or your coworkers will give you an answer and then sometimes you push back on that answer and it's this real back and forth and that's how you learn stuff. - It's the most sophisticated rubber ducky we've ever invented. - Yeah, seriously, exactly. - Totally. - I mean, to me, I think programming is a very creative endeavor It's important, at least to me, that I maintain that when doing it. And so I think everyone needs to find the right balance between how they want to use these tools and also get the creative enjoyment out of building whatever apps they're building as well. And I think, you know, having taught computer science, one of the really, like, fascinating things to watch as students sort of grow is you start being able to think in bigger chunks, right? The first time you sit down with a programming language and you're like, let X equals five. Like, this whole idea of storing something is a big deal, and it takes a bit to wrap your head around. And then you've got loops and methods and classes. And we've sort of, we've been moving up and down this abstraction hierarchy in our conversation today. And one of the things about the LLMs is like they can go to the fully abstract end of it, right? And skip right over sort of this foundational knowledge. And so like maybe take smaller steps. Like explain this loop to me. Why does that solve the problem? Or I need to do this thing. What are three options? okay, then I can ask the LLM questions. Like, well, why would that be a good option? What's interesting about that? Or why might this be a better option? And it's like, with an LLM, you can be the wonderful or annoying student who's like raising their hand to ask a question all the time, and it never gets tired of answering them. Yeah, it's like maintain your curiosity, basically. You mentioned like the pros versus cons of an approach thing. Like, in my opinion, the difference between like a good engineer and a great engineer is their ability to like look at multiple possible decisions and like weigh the trade-offs between them. So like making sure that you're not letting the LLM do that part of the analysis is I think really important. Yeah I was about to say like the same thing almost where like in like engineering generally there are like many ways to accomplish one solution and maybe one way is like more performant than another one or like maybe it uses a different tool and I think when you kind of master some of those concepts you're able to kind of tell, okay, for this use case, I'm going to use this tool, I'm going to use this data structure. And through this kind of prompting, you'll be able to discover all these tools and kind of see, given this specific example I have, what would be the best approach? Because I feel like it can seem like the solution is like there's only one solution to your current problem when you're using LLMs. But in reality, there can be many alternative approaches that you should be able to kind of wait on and like figure out like what is the best one it feels like the culture around coding with lms right now has moved so much to like how do we produce more code faster faster faster right and like at the end of the day the goal isn't code right like the hard part is understanding and so i still think like maybe i haven't moved up the skill curve but 90 of the time that i'm using these things i'm just using them to like build a deeper understanding of the code i'm working in. And I still find, as an engineer, that that is they're incredible for that. And if you can avoid the trap of how do I just produce more code and think, how can I use this to really, really gain a deeper understanding that I might not be able to otherwise, I think that's an incredible way to leverage that. Awesome. The clock says we've only got about five minutes left, and we've got a few questions queued up still. So maybe we switch to game show mode and see and see how fast we can click through these. I've got a buzzer. So feel free to interrupt your teammates if you think they're going to run out the clock. But let's see how many of these we can wrap up before we wrap up. So next one. And I'm just going to send these down the line. If you need a pass, pass. So Sam, we'll start with you. Okay. Noelle Ling and Noelle Ling. So now I'm blowing our time by making it. Noelle Lilinger writes, I'm looking for a high-level resource to build a clear metal model of SwiftUI. Is there an official one-page overview, chart, flow diagram that explains how these pieces fit together and what options developers have? I forget what they're called. It's not a document, but there are a lot of talks that were released, especially around the early days of the framework. Yes, we did Intro to SwiftUI where Jacob codes up an app using sandwiches. It doesn't actually use the sandwiches to make the app, at a staff about sandwiches. And also we have SwiftUI Essentials video. And there's a great one-pager on getting started with SwiftUI on the developer. Definitely check those out for me. I've always found, like, the sessions are killer. They teach so much so quickly, so I can't recommend enough giving them a watch. All right. Trevor, you get the next one. From Fossil Coder, I feel like a kindred soul. When I use AI tools to write SwiftUI code, I keep hitting the same errors. Code looks right, but won't compile behaves unexpectedly, how can I use Xcode's AI tools more effectively as a beginner, so I'm learning correct SwiftUI patterns instead of picking up bad habits from broken suggestions? - Seema, you might be better at this one than I am. The answer is skills. - Yeah, you should, again, third time of me kind of plugging this, but in Xcode 27, check out the skills. We really put all the best practices into them and the models should be able to pick them up and use the best practices we recommend without those bad patterns. So yeah, check it out. - Also, if you can allow the model to check its work by compiling, right? BDF-Swift, is it moves so many errors to compile time. And so the model can find those and iterate on its approach. - And I would also say, go piece by piece when you're starting out. AI models have this tendency that they really want to like one shot, implement everything at the same time. And that will often lead to errors. So piecemeal it, take as much of it apart as you can. And I think that's going to produce better code because it's going to be more encapsulated. Yep, for sure. Gabriel, I'm going to throw this one to you from Florentine F. What's one thing announced yesterday that you think beginners will overlook or will matter very much as they grow? Okay, so layout flexibility. We had a lot of stuff in this area, and generally with this year we've done a lot of layout improvements, But layout flexibility is a really big thing, especially because, you know, your iPad apps and macOS apps and Vision Pro apps all kind of fall under this umbrella of resizability. And now with iPhone mirroring, your iPhone apps are also resizable. So it's really important to see how much of your app can you make flexible with SwiftUI. We have a lot of constructs. And as you get more advanced, you can even dip down into some of the more complicated things, like making your own custom layout when things start to get complicated. And also, DeviceHub is a great new application that lets you test all sorts of things, all sorts of aspect ratios. It's really a great resource. Yeah. I know when I was starting out with iOS development, I only built apps for the size phone that I had. Yes. Because that's what I was testing now. And so DeviceHub is going to be great and resizable previews for testing on different sizes. All right. I think we can get one more in if you're fast, Jeff. This is from Matasa Yal-E. how to best convert a design of an app from a designer to SwiftUI. Do you recommend the Xcode coding assistant? And if so, which one? Oh, wow. I can't say this is ever something I've had to do. I would say probably I would go about it by looking at what they've built and considering the various layout primitives that we have in SwiftUI and kind of using your own translation engine to do that. I don't know if we have a skill that will handle this automatically. We do not. We also have connections. to... Yeah, I was about to say about the Figma connections and we have Sketch and Figma connections that produce SwiftUI code. Oh, nice. Given the design you're making in those tools. So definitely go check those out. And yeah, I don't know. Anyone else? Well, I think... Dang it. We have to. So we're going to leave it on a cliffhanger. Come back and ask the question again at our 9 a.m. Pacific group lab tomorrow, and we can pick up the conversation. But that's the end of this group lab. We're so thankful that you all joined us today and hope you found this really helpful. A big thanks to our panelists, as well as all of the folks working hard behind the scenes to make this happen today. As I mentioned earlier, if we didn't get to your questions, please visit the developer forums at developer.apple.com slash forums, where we can continue the discussion or go deeper into code. And visit feedbackassistant.apple.com to file any bugs or feature requests. We really do appreciate that feedback. Speaking of feedback, you should receive an email with a survey link to let us know about your experience with WWDC. We would love to incorporate your feedback into future events. Thanks again for joining us, and have a great WWDC. see.