Hello and welcome to the SwiftUI for beginners Group lab. My name is 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, Sima 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 feedback.apple.com. We’ll focus on questions today that will help the broadest audience. Whether you’re new to programing, 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. Sima. 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. View these qualities. Make it easy 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 result. 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 do 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, destroying 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 contain views. This lets the same view display information about whiskers as well as Rufus 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. They’re 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 state changes over time. SwiftUI automatically keeps the UI that depends on it up to date while avoiding reevaluating 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 rating view, 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 is declarative and adaptive. Use backend 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 .

Our our first question comes from Donald. And I think I think I’ll start this one off with 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 and your apps versus something like React Native, where you might not be getting those, 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 one of the things I get to do in my role as, 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, and so those folks were, 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 in a, at a time in the production cycle where it was hard to adapt. And so I think especially when we have a genetic coding that moves so fast at the beginning stages of a project, making the final polished stages easier is, is sort of the thing to emphasize.

Yeah. There’s also like the aspect to it that, you know, SwiftUI is built on Swift, which is like a really incredible programing 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 with some other non-native frameworks. Yeah.

All right. The next question, and I’m going to try to read off this person’s username, aididlufty. As an accounting student with zero knowledge in coding. And 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 that’s a great question.

So the way I approach this and like I would recommend to approaching this is kind of just think about your life. What, like, what is like one of the problems that you encounter every day or like, think about your family, like, what are like, 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 a genetic coding in Xcode, you get to build it faster and see it come alive on screen in like minutes. And it’s great. And actually, this year we have enhanced our genetic coding capabilities in Xcode with some of the skills that, you know, can help you build even better experiences.

So yeah, go ahead and give it a try. Yeah, hopefully it works out great. And I love that idea of finding some little problem or thing you want to build, you know, find, 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 Sema, 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 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 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 they recorded our doorbell sound and I made an app that we called Dog Bell where you could just like press the button and it would make the dogs jump off the bed.

Oh, that’s 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 was a to do list app because I was always forgetting to, 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 like, like just learning. We’d play ping pong all the time. When we would take breaks, we would always argue over like 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. He should have been keeping track. Apparently. I made an app specifically for colorblindness. So as somebody who has red green color blindness, I found that, you know, 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, you know, 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, so thanks for sharing. Our next question comes from Cihan, and maybe I’ll start with you on this one. Trevor Cihan 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 with Swift, right. Like that’s the the basic building block, right? Make sure you have a good understanding of the basic language that you’re going to be working with on iOS. The Swift can be really different if you’re coming from another language, the type system concurrency, right?

There’s there’s lots of features that are, are going to be kind of new and really interesting. And honestly, I think really great to learn from the start versus maybe learning an unsafe habits in another language. Like 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’s, that would be, I think the first couple months. You know, there’s a ton within just those two things, but that’s where I would start. Yeah.

Anybody have anything to add to that? I think one of the things that that I think is going to be valuable is like, use the tools, make those part of your learning, but make sure you’re thinking about the output they’re producing, right? The, the goal. So I, 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 what the teacher is looking for is they’re trying to give you practice on an area, right? To uplevel your skills. And you can do the same thing with your your own work. If you’re using, if you have an app you want to build and you’re using a genetic programing 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. Oh, sorry. I was just going to say a quick add on when it comes to like using LLMs for programing 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’s, it is really like having an interactive thing with you that has a really deep domain expertise on a lot of stuff. So 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 could 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, what could I have done better here? What were their APIs I should have considered or looked at? And so it’s, it’s nice to have that, that tutor tutor in your pocket. It’s kind of cool.

This is a great question, Sam. I’m going to start with you on this one. Since you got. You covered this in our in our little intro segment. So this is from Will picks for beginner coming to SwiftUI. What exactly happens under the hood when I use @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 like very lightweight descriptions of like the actual thing that’s getting displayed rather than like 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 we have a counter that’s incrementing or just some value that needs to to like change over time.

So what state says is, hey, SwiftUI, take this value and like 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 like a little, you know, it allocates a little piece of memory, which just lets it sit with this value.

And then it gives you the ability to, to read it and to write it whenever you have like closures that change and that the combination of these tricks basically means that you don’t have to think too much about like where the values are getting stored or like 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, for folks who maybe have more like a CS background or coming from perhaps like UIKit or another sort of traditional object oriented framework, I framework. I mean, it’s not required to have that background to to use SwiftUI, but that sort of difference, that SwiftUI struct is a 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 it just throws it away. And the pixels are on the screen and memory is preserved for other other work now. And so that’s sort of one of the things that’s really different about SwiftUI is 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 like start out with SwiftUI, a lot of times it’s a confusing in terms of like, when should I use @State or when should I just like store something as a variable on the view struct? And as Sam, I think you just touched on SwiftUI, I 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, right? Like you’ll get a compiler error and you won’t be able to build your app. And so like, at least you have that nice warning to say, hey, use that state here to key SwiftUI in on knowing when it needs to redraw.

That actually loops back to our first question is like, why? And part of Sam’s answer to that is why choose SwiftUI? Because it’s embedded in this type safe programing 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’s like sometimes it feels a little miraculous. Yeah, full full disclosure here Sam and I are both programing languages nerds. And so anytime you give us a chance to talk about programing languages, we will. And we, we won’t shut up. But, but in order to keep that from happening and also because this next question names for programing languages.

I’m Gabriel I’m going to start with you on this one and then maybe throw to Jeff. This is from MK WB. 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 sell 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, it’s 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 like embedded language, a lot of it kind of feels similar to what HTML and CSS will be.

Obviously a little bit, a little bit tangentially different, but, you know, a lot of the concepts and the, the kind of immediately apparent hierarchy that you’re used to by reading through HTML is kind of the same way that you declare your views in SwiftUI. And I 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, you know, swift and forcing things at compile time. And there’s also a whole bunch of developer documentation, especially now with these tech 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, you know, various reasons is I find it actually useful to use these tech tools and ask them, hey, I have this like concept of like 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, 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, I started basically doing HTML and CSS, maybe not any PHP. And when I started working on SwiftUI, I found it very similar to, to doing that before, especially in terms of like how you describe the structure like, 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. Yeah, yeah. Also, the web is like, you know, was the world of declarative frameworks before Apple platforms were right. Like, you know, HTML is 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. So if you have any experience with those, that helps to. 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, 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 in Xcode 27, you also have options for showing the simulator right there or actually pulling a mirror of your device on, on screen.

And so there, there are tools for getting those instantaneous previews, but I think, I think that is one of the, the road bumps that people hit. And so make sure you check out previews and use that to, 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 programing. Thank you.

Yeah. Like I mentioned earlier, those initial tutorials I don’t like if. Can we link those somewhere? Yeah, I think I think we have a mechanism for doing that. I’ll ask 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 like, here is a view body to state to animations, right? And here’s how to 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 yeah, which I think lots of people have found that that super helpful. And that’s a great little very bite sized chunks of content that are great. Yeah. To add to that, I like 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 discuss like some of the common like data storage solutions and like databases and how to wire it up to your app. So there’s lots of depth there. So definitely start there. And you know, 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, Sima, about about getting started.

It’s like sometimes it’s, it’s instead of just like, all right, I’m going to 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 like, you know, search or ask the agents. Yeah, yeah. That’s the most effective way.

I also like, like, 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 like a tutorial online on like how to build like a certain kind of looking app, I would encourage you to like 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 like building something that solves a problem you had.

Yeah, this did make me realize that we, we haven’t talked about the human interface guidelines at all, which, 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, on whatever platform you’re developing for. Yeah. And that actually raises another thing that I really like to do to like learn part of an API or something is like play around with other apps.

Like, yeah, like there’s this really cool thing in, in mail, if you’re in your inbox and you scroll up the The inbox. Tidal flows into the the tidal bar, and then the number of messages like animates in behind it. And like, 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. Asked, how did you build this?

But, but I wanted to learn. And so I, I like tried to figure out how would I build that with the pieces that are in the API. And so it’s, it’s kind of fun to do that. 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 may call back to our conversation around state. So I’ll start with you, Sam. This is from 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. 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, you know, upgrading, updating on like a per frame basis or, you know, very, very frequently, just @Observable is a really good tool for these kinds of things. If you put data in an observable 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 are like, make sure you’re not like updating like values that are dependent on various places in your UI and like at too high a frequency, right? You want to very much limit your dependencies. Yeah. Gabriel did a follow up on that. Yeah. So and like what Sam was saying, like you don’t, you kind of want to make sure that you have a as cheap a view body as you can get as much of like a leaf view, if you may, for these types of like 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 you know is like, 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 other things I would add to that.

If you are, you have something that’s updating per frame. I would ask the question, does your UI actually 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, 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 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, like start doing some asynchronous work and that can add up quickly. And SwiftUI views are work best when the inputs to the views are synchronous. And you kind of keep most of the async stuff like 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 expectedly. Yeah. Also, just to quickly bring it back to somebody who’s maybe a little nearer to the framework, I think the thread across all these pieces of advice is like, break things up into small reusable pieces.

It’ll both help with like 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. I’m sorry. No, please. I was going to say, if you’re just getting started with this too, like you can take a lot of comfort in that SwiftUI manages so much of this for you.

Right. And so like, there’s no need to get really stressed out about this performance right off the bat, right? You’re going to get really good performance out of SwiftUI just by using it naturally and then optimize when you need to. Right. Like profile and and try to SwiftUI.

Instrument is really good for profiling. It really helps you get a lot of insights about like 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 if you’re coming from maybe another one of Apple’s UI frameworks to SwiftUI, maybe, you know, instruments already.

So like not all beginners are, are to SwiftUI are, are beginners in general. You can like start by, by trusting SwiftUI laziness. And then when you start like 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 we have that one. So I. Appreciate that. So the the next question, and maybe I’ll start with you on this one. This comes from 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 common issue we see with large language. Language models kind of sometimes producing a little bit incorrect results. When it comes 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 Swift.

SwiftUI skills that actually with fed with all of our internal knowledge that all the best practices we have for data flow in your apps for the new APIs that we introduced, and you get them out of the box when you use coding agent decoding 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 with 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, but it is the. Third to last slide of what’s. New in SwiftUI. So watch to the end. Yeah.

Anything to add? Add to that. I think that sort of sums it up. The the nature of, of LLMs is they have the data that they were, were trained on at the time they were trained. And, and so skills and the other things that we’re adding are, are a great way to level them up as, 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. Yeah. But we did find that the models got significantly better like reasoning when they were invoking those skills. So we’re sure that the skills should provide greater kind of 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 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. So yeah. And there’s. There’s. There’s two ways to give, 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, from your device, whether that’s your, your MacBook or your phone or your iPad.

If you aren’t running the betas, but you’re running your whatever you’re running, I guess, but like especially feedback on the, the skills that we’ve added in Xcode 27, you can go to feedback assistant all one word.apple.com. And that’s the other way to file that. If you don’t have the betas installed.

Do you 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 like window or like you prompt the model. The skills should be already loaded. And I think that they would be invoked, like based on the context of like, what, 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, on the context, which is great. And if you’re using an LLM outside 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, and let me, let me try for a segue here.

Our next question is from Z and Z. And I think I’m going to start with you on, 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 genetic 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 when we talked about breaking views down, but is there any more we can say there? Yeah. And I think we we talked a little bit about using observable. This is like a really nice tool because the way it works is only properties that that change that are also read by your view will establish that dependency to kind of reevaluate the body.

So if you, if you change a property that is only read by, 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, 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, you know, let me 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, it instantiates the views underneath it. But if they haven’t changed, we don’t need to run their bodies like it just runs that one at the top. But similarly with like 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 like, 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 some pieces of that. Yeah.

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 views body 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 like keep the unnecessary environment outside. Yeah, yeah. So environment.

So, 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 leaf leaves without having to pass it along every time. And it was really designed for things like color scheme, you know, screen size stuff that doesn’t change rapidly.

You can you can also pass observables through it. And that works works fine because they’re only updating at the point they’re read from, but you avoid and this is what you’re saying Sema avoid like, you know, don’t pass the current time in milliseconds in the environment because everything down the tree is going to be updating all the time. Yeah.

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, your view bodies kind of as small as is reasonable for, for what they need to do and kind of extracting out pieces into a, you know, 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, 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, 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 apply.

And same thing with like some bits of your views that are like, look repetitive across the app, you can kind of take them into custom views and then reuse them. And that’ll, 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.

There’s a couple of things I saw talking to developers in the community and questions that came up a lot that 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 gonna take this to you, Trevor. Is that effective or is what’s the right approach there? I think it’s just inferior to refactoring that chunk That chunk of the view into throwing shade.

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 at 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 it 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, 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, I would avoid that pattern of these computed properties inside of a view. I feel like it does also depend on like your use case. Because like sometimes if like the property is like really small and like for readability, like it’s fine.

But because like sometimes we like move into a custom view, you also have to like move some of the state into it. And, you know, maybe you’re only planning to really use that code in like one view. So it really just depends on like your usage. But I think the general guidance should definitely be like, like abstract more pieces outside of your view and like put them into custom views. I think it’s a great guidance in general to have.

Yeah, from a, 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? 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, right? So like one example, I think it’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 format or somewhere else that’s cached that’s not being allocated every time your view body runs right?

So if you can avoid those, those little things, those are easy. Refactors array transformations are another one that people run into with like foreach 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, right? That’s good. It’s going to do so much for you.

Like it’s good performance out of. All of this guidance is in the skills. So if you’re using yeah, if you’re using a model to generate that code, it should automatically put like refactor views into smaller views. So that’s, that’s great I think. And that is a perfect segue to our next question from and this, I feel like Sema might be reading ahead.

This is from N586FL rolls off the tongue in a world of a generic 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 I, 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, like, 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 like you have an app, but then like you’re trying to like add something to it, but like you feel like you don’t even like, know what, what, like how the code is structured and where should like 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 like a tutor is not going to tell you the answer to your question, and then just leave it at that. Write 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. So 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 want to build this thing. Here’s what I’m thinking. Like, what do you think of this? Like, is this at all correct? Like, and you sort of go back and forth and then it will, you know, give you the LLM or your coworkers will give you an answer. And then sometimes you push back on that answer and it’s like this real back and forth and like, that’s how you learn stuff. It’s the most sophisticated rubber ducky we’ve ever invented. Yeah, seriously? Exactly. Totally.

Yeah. I mean, to me, I think like programing is, is a very creative endeavor. And it’s important, you know, at least to me that like, I maintain that when, when doing it. And so I think everyone needs to find the right balance between how they want to use these tools and also, you know, get the creative enjoyment out of out of building whatever apps they’re building as well.

And I think, you know, having taught computer science, one of the really 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 programing 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, 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, explain this loop to me. Why does that solve the problem? Or I need to do this thing.

What are three options? Okay. Then then I can ask them 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. Yeah. You mentioned like the pros versus cons of an approach thing like. In my opinion, the difference between a good engineer and a great engineer is their ability to like, look at multiple possible decisions and weigh the trade offs between them.

So like making sure that you’re not letting the LM 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 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 like through this kind of prompting, you’ll be able to discover all these tools and kind of see like given, given this specific example, I have like, what would be the best approach? Because I feel like, like it can, 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 can. You should be able to kind of weigh on and like figure out like, what is the best one?

It feels like the culture around coding with LLMs 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 like, I still find as an engineer that that is like, they’re incredible for that.

And if you can avoid the trap of like, how do I just produce more code and think like, how can I use this to like, really, really, like gain a deeper understanding that I might not be able to otherwise? I think that’s an incredible way to, to leverage them, especially as a beginner. So we’re 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 to game show mode and see to see how fast we can we can click through these.

So so feel, feel free to, to interrupt your teammates if 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 will need to pass pass. So Sam we’ll start with you. Okay. Noel and Noel linger.

So now I’m blowing our Time by Noel linger writes, I’m looking for a high level resource to build a clearer mental 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 forgot what they’re called. It’s not a document, but there are a lot of talks that were released, especially like around the. Yes, we we. Did intro to SwiftUI where Jacob codes up an app using using sandwiches. It doesn’t actually use the sandwiches to make that, but it’s sandwiches. And also we have SwiftUI essentials video.

And there’s a great one pager on getting started with SwiftUI on the 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 fossil 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 or 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.

You might be better at this one than I am. The answer is skills. Yeah, you should again like third time of me kind of plugging this, but like in Xcode seven, check out the skills. We really put all the best practices into them and like the models should be able to kind of pick them up and use the best practices to recommend without those like bad patterns.

So yeah, check it out. Also, if you can allow the model to check its work by compiling. Right. The beauty of Swift is it moves so many errors to compile time, right? 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 wanted 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. Yeah for sure. Gabriel I’m going to throw 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 resizable 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.

Yeah. So and also Device hub is a great new application that lets you test all sorts of things, all sorts of aspect ratios. It’s really a great resource. So yeah, I know when I was starting out with iOS development, I, I only build built apps for the size phone that I had.

Yes. Because that’s what I was testing on. So Device hub is going to be great for resizable previews for testing on different sizes. So all right, I think we can get one more in if you’re fast. Jeff, this is from Matt Matasar l e. How to best convert a design of an app from a designer to SwiftUI. Do you recommend 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 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 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. Given the design you make in those tools. So definitely go check those out. And yeah, I don’t know anyone else. Yeah. I think. Oh dang it. You have to.

So we’re going to leave it on a on a cliffhanger. Come back and ask the question again at hour 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/forums where we can continue the discussion or go deeper into code and visit feedback.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.