Hello and good afternoon from Cupertino. Welcome to today's Xcode Tips and Tricks Group Lab. I'm Angelica and I have the privilege of being the host today with some incredible panelists from the Xcode team to answer all of your questions. Now we are so glad so many of you are able to join us today. So let's jump right in. I'd like to do a round of introductions starting with Chris from across the table. Cool. Thanks. I'm Chris Miles. I work on live coding experiences in Xcode. That's things like previews and playgrounds and integrating those technologies into our agentic workflows. Hey, I'm Jake. I'm a designer on the Xcode team, most recently involved in themes and some of the toolbar customization. So very exciting times. My name is John. I manage several of the front end Xcode teams, like the window, Chrome, source editor, search, code completion, and design tools. Hi, my name is Katspar, and I work on the instruments team here at Apple. My job is creating profiling tools so that you can all optimize and make your apps better. Hello, I'm Chris. I work on the organizer window for crash reporting and uploading to the App Store, and I work on some of the signing UI in Xcode. Great. So our first question from developers was actually also going to be my question for you all. Thanks for the question, Pachaya. Nice to have you again at a group lab. But from Chris to Chris, I would like to ask each of you, what are the most useful Xcode tips and tricks that most people may miss out on or maybe are lesser known in your opinion? I know I wanted to call this out especially because a little known fact, Xcode is built with Xcode. You all not only built features for Xcode, but use it on a daily basis. So what would you say is your number one lesser known feature in Xcode? The tip I'll pick is a feature we added to last year's release, which is the ability to put a playground into any Swift file in your project. We added a playground macro that lets you just run code snippets in any of your Swift files. So you can simply import playgrounds and then use the hash playground macro to define a snippet of code. and then you can just run that code. And like any playground, you'll get the expression results shown for you on the side. And then you can just use that to explore Swift API and that kind of thing, which is pretty handy. Yeah, and it's super easy to make those now where you can use the new project command and you can get a new Swift file with a playground macro rate in it. It's awesome. Yeah, that's right. Yeah, basically file new playground will give you that modern form of just a single Swift file with a playground in it. and you can just use that to experiment and explore Swift code, the dream. - Not just that, but also like models that you wanna test, 'cause you could actually use Playgrounds to test out models. - Yeah, you can play with foundation models in those Swift files, and you can also put UI code and preview that all in just a standalone Swift file, so that's made that really easy. - That's awesome. My tip is kind of cheating because it's new this year, so I don't know how well-known it is, but with the new themes in Xcode, you can have different themes chosen for different workspaces. So if you have two projects, you can have one bright and red and one blue, and now it's super easy to tell them apart. Or based on your mood, maybe you want to swap them out. It can be a lot of fun. One of my favorites is when I'm writing some new code, I'll typically write several types all in one file, maybe some protocols, some enums, some structs all together. And then I've got to split them up. And I can go through the new file dialog, making new files and putting them in over and over again. a kind of hidden feature in Xcode is you just cut the text that you want to move to a new file and put your keyboard focus in the file navigator and hit paste. It'll make a new file with the content of your pasteboard and it'll guess the file name based on what you're pasting. So if you're pasting in struct person, you're going to get person.swift and it's a real time saver unless you kind of organize when you're done sort of making everything work together. Use that all the time. That's a great one. I've been doing a lot of refactoring recently with Xcode and rewriting out of our Objective-C code to Swift. So for me, find call hierarchy was really a helper. So being able to quickly understand where my function is being called from, what are the dependencies, not only at one level, but going even deeper. So that's really handy and it was super helpful. I have two, if that's all right. When I'm looking at a file in Xcode, I'm constantly using a command shift J to navigate to open the navigator and see where that file is in the source code in the folder. And the other one that I use, developing Xcode on the Mac, what we're constantly doing is we want to differentiate the debug Xcode from the Xcode that we're using. So I'll use the debug bar and you can change the appearance of the debug application. So I'll change it to dark mode so I I can see the difference between them. That's really cool. I wanted to add to command shift J. If you use open quickly, search for a function instead of a file, and then use command shift J, you could find it exactly where it is in your project. It's like my favorite combo. All right. Another question from a developer, Phanteks, is asking, which recent Xcode feature do you think deserves more attention? I've got an answer for this one. When you're -- a challenge with using Xcode on a large team is project file conflicts. You've probably all experienced this. Like, I make a change, my colleague makes a change, we conflict, and it doesn't feel like we're working on the same thing. We added a feature a couple years ago, maybe in Xcode 16 -- might have been 15, I'm not sure -- where we have folders instead of groups. You can see the difference in them in the Navigator. The gray ones are the old groups, and the blue ones are the new folders. When you add a folder instead of a group to represent all your source code, Xcode doesn't record the list of files, which means you'll find that if you convert your whole project to use these new folders and you start adding new files to your project, you generally get zero diffs in the project file, and it can just drastically cut down on the conflicts that you have for your teams. I can't recall one conflict that I've had working on Xcode since we've adopted this feature in the project format. And there's tons of us working on the project with tons of projects, so it's a real time saver. Yeah, we've adopted that on the instruments team as well. And I feel like it also was an opportunity for us to rethink about the grouping and the folders. You know, over the years, we've had some mess in there. So it allowed us to just clean that stuff up as well. I have an oldie but a goodie, is that in the schemes, you know, up at the top of Xcode, you can edit the scheme. And you can set different user defaults. And it's very common that we are trying out new features under a user default. And you can click and unclick them there. And I'm constantly doing that. That's awesome. One of my favorite things, and this might not be like a hidden feature or something, but I just love being able to filter in the console down to different components or categories. And it makes it so much cleaner to debug something if you actually take the time to organize, which you can then just use an agent to organize it for you. But yeah, it's wonderful to get your logs sorted nicely. A variant of that with the filtering that's less discoverable, super useful, in many of the menus in Xcode, especially the ones along the jump bar at the top of the editor, it just looks like a normal menu. But if you start typing, it'll filter the menu with the code completion, open quickly, style text matching. So you can get to a function definition really fast that way. One that's useful to know when you're previewing your UI is you can show variants, like show me all the light mode, dark mode, or different dynamic type sizes. But new this year, you can also put, you can pass in arguments to your previews. So you could, maybe you've got an enum with various types. You could pass in enum.allvalues, and then your single preview can then take that argument and just give you a grid of the preview rendered with all those, all at once, which is really good. I have one more that is performance related. So quite often you have memory of your application that is exceeding your expectations, and you will open memory graph debugger to search for leaks. but sometimes memory graph debugger is not gonna give you information about the footprint of your app. So you can actually open this memgraph right in the instruments. There's a little share button that maybe is a bit hidden, but developers can open that up and see the timeline of their allocations. - Yeah, there's a great session on memory analysis that actually uses that feature where you're actually able to export the memgraph to instruments. I wanted to call out, I know everyone loves print debugging, but conditions and breakpoints is one of my favorite things that I like to call out. Breakpoints are already pretty incredible, but if you just secondary click on it, there's a whole modal that actually pops up where you could set conditions, number of retries or number of repetitions, things like that. Really cool. It makes them so you can just leave a breakpoint there and it'll trigger when you actually need it to trigger. All right. Moving on to a highly upvoted comment, not a question. Let's look at this one from Franklin Biaru. Not a question, just a thank you to the Xcode team for adding the delete derived data menu item in Xcode 27. Many of us have spent years manually deleting folders, running terminal commands, or maintaining custom scripts just to do this. Thank you for making every day Xcode workflows a little better. I wanted to give that to you, John, because it's for you. But definitely your feedback has been incredible and instrumental in all of this, so please continue sending us feedback if you need to use this. But any comments or behind-the-scenes thought process behind delete-derived data, other than feedback we've gotten? I mean, there's lots of reasons why you might do it. Like, you could be running out of disk space. Sometimes it's faster than cleaning. You know, you just want to be sure and start over. Other times it's masking problems in your project. You know, like it's easy to have a sort of hidden dependency between two targets, where depending on the way the parallel build runs, the build succeeds or fails. And so sometimes it's easier to reach for that to just sort of like start over. But maybe if you see the same pattern of failures, try analyzing your project and see if there's a missing dependency. And then you won't have to do it so much. Great. All right. So next question we have is from Formidable Studio. The question is, I want to try out the Xcode 27 beta on my MacBook, but I also want to be able to use Xcode 26 to push out my apps. Can I do this, or will it break my setup? So you can definitely do this. The main thing you'll want to be concerned with is just making sure you stick to the features from the public SDK that we already shipped so that your app still builds with that old version of Xcode. Sometimes we add new features to Xcode itself that require the new version of Xcode. sometimes they're pervasive like the blue blue folder i mentioned earlier um this year we only added one and you'd really have to go out of your way to use it there's a check box in the inspector to like opt into some stricter project validation on loading you're not going to check this by accident so feel confident using the new xcode to explore it while you you know maintain compatibility with the shipping version yeah and i think um specifically especially you could use both Xcode 26 and 27 if you're using macOS Tahoe. Xcode 26, I believe, does not run on macOS Golden Gate. That is true. Yeah. So you could use both if you're using Tahoe. And I believe you do have to worry a little bit about, especially if you're building or shipping to the App Store, making sure Xcode Select is pointing in the right place and things like that. Also a great opportunity to use Xcode Cloud. Yes. Because then you're not the one building it. Exactly. If you want to test the compatibility or at least what the build status would be for your app on Xcode 27, try out Xcode Cloud. 25 free hours. Plenty for you to be able to do that. All right. Let's take a look at the next question from Phanteks. What's the most underrated Xcode feature that even experienced developers don't use enough? This could be for anyone on the panel. I mean I would I'm gonna plug the the blue folder thing again like I can't stress enough how much this will Reduce your project conflicts and it's true that we have a lot of projects that don't use it because you have to do like a conversion Step to do it, but I it is like really worth the payoff at the end So I'd encourage you to go through that and convert your groups to folders I have a I wouldn't say it's like the most underrated one ever but in the canvas Let's say you have two different Swift files in your project. You have one for your data and one for your SwiftUI views. You may notice that when you go to a file that doesn't have a SwiftUI preview at the bottom of it, your canvas may go away if there's no content to display. But you can always pin the tabs inside of the canvas. And new this year, you pin individual tabs as opposed to the entire file. So you could, for example, open up your SwiftUI view file, pin the tab for your content view or whatever your preview is. And you can just start navigating around knowing that your preview will be maintained. And it's a great way to work. And you can start playing around with data and other files, and it'll keep updating. I mean, I think there are all kinds of tricks that I'm always finding out, even if I'm experienced. And I think Chris has given a great presentation. There's so much that you can do while the program is still paused. You're mentioning conditional breakpoints. And, you know, if you want to maintain that state, there's so much you can do. I mean, I've used this forever, but I've talked about breakpoints with you can have them signal a sound and not actually pause. That's always a good one. But, you know, I think like Xcode Cloud is an example of people miss that that's really something that very easy to set up. And, you know, you don't even need to learn it very much. It just will work on its own. Yeah, there's a lot of updates actually in Xcode Cloud this year, especially that people, it's like a really great time to try it out. The onboarding was improved as well as some build performance, things like that. It's even easier to set it up right inside of Xcode. You don't even have to go to App Store Connect. Yeah. It includes things like webhook configuration is also now built into Xcode and everything too. So it can make your workflows pretty powerful. All right. Any other underrated features people can think of? I want to call that. The Xcode has really powerful search too. When you're really looking for something across a large project, you can open the search navigator and by default, you're just searching for keywords and things, partial search, partial word searches. But you can search for regular expressions. You can search, I think, by symbol. John knows this better than I do. Yeah, you can do the multi-word search for words that are in proximity. And then actually, so for underused, I would say one of the coolest things you can do with this is to combine the search field with the filter field at the bottom so you can get kind of like a Boolean search. and then little known fact the results in the find navigator when they're highlighted you can press delete and they're removed from the search set so you can sort of like narrow your scope to the things you have to work on or like if you're gonna you know rename or change something you can work your way through the list deleting them one at a time until they're all gone and last tip related to that sometimes we'll do a query and there's a bunch of matches and I want to kind of get an overview of how much like where where are these and you want to see all the file names in all of Xcode's navigators, if you hold the command key and then click on the disclosure triangle, it'll collapse all the siblings so that you can see sort of all the file names at once. And then I'm going to add one more find feature to so many of them. You mentioned find call hierarchy earlier. We also added queries for showing a type hierarchy, both up to the root and down to the leaves. So if you're considering some big refactor and you want to know how many things conform to this protocol or how many subtypes are there, you can bring them all up in a tree and then work your way through it. Yeah, I'm probably a bit biased here, but I would say all of the profiling tools that we offer. So from the organizer that allows you to see how your data is behaving, how your app is behaving with your users, to instruments and profiling at desk. I think that like, I really love profiling and I think that there's something great about making your app better. It's a pretty addictive process actually. So yeah, I recommend people to try it out and improve their apps. I was going to say, especially in instruments, flame graph, combination with top functions, makes things so much easier to find when you're profiling something. So if you haven't tried it yet, this is a really great time to start. Yeah, and there is a great session this year, ProfileFix 05, that focuses on explaining these concepts. So I recommend everyone to check it out. And we have a SwiftUI instrument, don't we? Yeah. It's great for your heart-wracking performance. That's correct. So yeah, if you're experiencing problems with your SwiftUI app specifically, there's a dedicated template. Template. Same thing with concurrency, same thing with agentic foundation models. We have templates for everything. I wanted to call out the SwiftUI instrument. There was a session actually last year for it. Definitely take a watch of that one. But yeah, I like to call that out too because instruments in general use it. But you could also, you start with a template, and then if you want to include other instruments in there, you can, and you could actually save those templates for your own use case if that is the way you want to work for every time you want to profile your app. All right, really great underrated Xcode features. Let's take a look at the next question from M. Blackmon. Great username also. What caveats should we be aware of when running Xcode 27 beta the same machine with Xcode 26. We talked a little bit about this, but is there any caveats or things to be aware of? - I think you're set, go for it. We use lots of versions of Xcode every day, lots of versions of Mac OS, so we're prepared for this. Go ahead and use two versions of Xcode at the same time, totally supported. - One might look really colorful, and one might look really normal or plain, so that might be the only major cause or concern. I believe, I think there's a couple of notes on like project file incompatibility. Is there anything around there between Xcode 26 and 27? Some years, but not really this year. Okay, great. Awesome. And let's see. Let's move on to the next question then to Scott G. There can sometimes be painful merge conflicts with.xcodeproj files, which some developers address by generating their own project files with Tuist or Xcode Gen. Are there any tips and tricks to minimize these merge conflicts without the use of such third-party tools? John. Well, I'll expand on using the blue folders instead of the gray groups. That's going to cut your project size probably in a third if you adopt it. Some tips on using it most successfully. The blue folders are members of targets. That wasn't the case with groups. And you want the targets of the blue folders to really align with the source code inside of it, because any deviation from that is going to get recorded in the project. So if you've got a framework with 150 source files and they're all together in the same target, none of it will be recorded. There's a couple of test files in there for a test target. Those will be listed in the project file. So get them in alignment as much as you can. The first time you adopt this, you're going to get a huge diff, because two thirds of your project is going to go away, which is why you're not getting conflicts anymore. Getting that first integration step, if you're on a big team, can be hard because your colleagues are going to keep changing the project file as you work. The workflow for moving to the folders is to click on one of the groups in the navigator, right-click, and choose Convert to Folder. If you hold Option, it'll just preflight the operation. It'll tell you that in the menu, and it'll tell you which things need to be resolved before you can complete the migration. I'd encourage you to resolve all the errors without migrating anything. Commit that. then it's really easy to finish off that migration at any time where you're not going to conflict with all your peers who are still working on your project. One other, in the project inspector, if you happen to work on many Xcode projects together, which some of us do, Xcode is composed of many Xcode projects, there's a checkbox in there which is set for all projects created in the last several years, but for older ones it won't be, that says minimize, maybe cross-project references or something, check that box. It's basically free and it's also, if you're in this scenario of using many projects, it's gonna delete thousands of lines from your project files. So, another easy way to avoid some conflicts. - I'll need to make sure that we have the check. - I think we did it for you. - What about build settings and things like that? - You could move, you wanna take this? - That's a useful one. You can put your build settings in files called xe-config files if you'd like to just manage them outside in their own text file. You can put some build settings in there and then still use build settings in the editor to inherit those settings and override them. Or you can move all your build settings into XD config files. And if you're not sure like what the build setting name is, like what do I call it? A tip is to, when you're looking at the build settings editor, open the inspector, select the help inspector and just select one of the build setting lines and you'll say the name of the build setting in the help inspector. I'll use that all the time. The source editing experience for working with XC config files has been tuned up a bit this year as well. So it can be a nicer experience. Yeah, there's some syntax coloring there. And then you can just copy the build setting row as well to get the key name and paste it into the config file. Yeah, that's right. And those config files have a great sort of audit trail, and they can have comments. And really easy to review in the PR as well. Adding comments for them is one of the big bonuses. Awesome. Great. Hopefully that covers your questions, Scott. We're going to move on to a new question from another developer, Newbee. On Xcode 27, Markdown is fantastic. I didn't see the WWDC sessions mentioning them. Are there any cool tricks with Markdown? And are there any improvements? This is a second question. Are there any improvements on source control side of things in Xcode? I wish multi-select was possible on stashes to delete at once. So first question first. Let's start with any cool tricks with Markdown. well you can um you can view markdown files i mean we have a good renderer now and you can view them as rendered nicely formatted or you can view them in their original form if you use um open as and just you know select source code instead of rendered then you'll see markdown and it's in it in its textual form and that can be useful to move back and forth but in both forms you can edit that markdown uh just straight in the editor which is really cool yeah yeah and not just uh in just as as like a standalone file, but when you're working with an agent and you're creating a plan or some other markdown file inside of the transcript area or the editor, you can just work on the markdown as if you were working on it as a standalone file. It's just the same experience in both places, which is really amazing. - Yeah, and you could do it side by side as well as like the rendered markdown on the canvas on the right side as well. - Yeah, that's right. Just use the canvas preview button to open that and yeah, you can see it side by side. All right, so following up on the second question that Newby had, which is, are there any improvements on the source control side of things in Xcode? Well, we'll definitely take a comment for the multi-select on the stash. I'll be bringing that back to the team when we leave. We've done a bunch of infrastructure work this year. I mean, we've actually completely redid the navigator that's there. You can't tell because it's exactly the same. It just works better. So plug for the engineer that did that. Thank you. I'm not recalling a specific, you know, version control enhancement other than us continuing to sort of make the workflow that manages cloning packages and cloning XO projects all be consistent with all their authentication and everything else. And so we're improving that every year. Yeah. There's good performance improvements. Oh, yeah. Especially if you have lots of tags in your repository. We have millions of tags. And the performance of millions of tags is a lot better this year. there's one more little kind of like bonus improvement which is we're finally using red and green as our diff colors so I think that's important to you but kind of like a I guess this is an even more secret tip is if you want to customize your theme colors we actually allow you to customize those red and green colors so if you want to go pick something slightly different or you love the purple and orange feel free awesome and of course if you have feedback particularly around source control updates, like John mentioned, definitely file those. We do read them, and it actually helps us keep track of suggestions, use cases that developers have for these features. So please file it in feedbackassistant.apple.com. All right, moving on to the next question from Tammy Santana. When a Swift Package Manager package like MLX Swift LM updates its macros, Xcode requires manual re-approval time, breaking CI builds and blocking compilation? Can macro trust be pinned to a package identity instead of requiring reapproval on every update? This is interesting because this is a particular use case, and I think I've heard a few reports of this, but do you all have any insights on how this can be done better? I think we'd want to take that back to the package. Yeah, I was going to say, we don't have experts on package managers specifically here, so this might be good for us to be able to send over to our colleagues. But the things that I do know is that I'm surprised that it's invalidating trust on every update. So make sure you submit something on feedback. Let us know exactly what's happening in your use case or like what package you're using. That'll help us kind of track this down, figure out what's going on. All right. Moving on to a highly upvoted question from C.Gontijo. I hope I pronounced that correctly. Is there a way to open the terminal on the project root folder in Xcode? That's a great idea. Not directly, right? Yeah, you could open terminal and then maybe drag one of the file references from the navigator into terminal to change that directory in a more convenient way. A related feature, not exactly what you're asking for, but useful once you get to the terminal, is the file inspector now lists the, we call it the working copy relative path, so that you can just double click on the inspector, get all the text for the file path, and then do your get operations or whatever it is that you wanted to do in there. And that's really useful. - Yeah, I do think this is a great feedback to file, especially because we have things like right click, navigate our show in Finder, if you wanted that functionality in terminal. Like, it's definitely possible. Great, awesome. All right, moving on to, ooh, this is a great question. From Chrisia, what are the most useful Xcode keyboard shortcuts you use daily? This is gonna, how much time do we have? I feel like we could go on and on with this one. - I'm sure we've all got some. We already talked about shift command J to show in the project navigator the location of the current file, the reference to the current file that you're working on. We've got shift command Y is show and hide the debug area, which I use all the time as I'm jumping in and out. Another one that I use a lot is run this test over again. And I remember that because it's all three modifiers in the bottom row, control, option, command, and G. Don't try and remember which ones just all three of those actually I was like, I feel like my hands have remembered keyboard shortcuts and I don't know which Yeah, absolutely One of my favorites is simply to refresh previews So previews can pause when you're making larger changes and there's a button to hit or get them to continue But if you do command option P everyone has to do this with their hands to remember exactly how this is done But command option P should refresh the preview automatically and it's really nice to quickly and easily get it back up and running. I'm going to go with Control-6. I don't know the name of this menu command, but when I want to learn the name of a menu command or something dead, I'll often press it repeatedly if I'm feeling lucky and look at the menu to see which thing highlights and then go find in there which thing has a key equivalent. Now let me tell you what Control-6 does. Control-6 opens the rightmost element of the path control above the editor, which lists all the types and functions in the file that you're in, and then you can type into that menu to filter it. So it kind of gives you a really scoped open quickly on the file I'm already in, which is how I like to use it. - Nice. - For me, it's probably gonna be command option up and down to be able to switch between implementation and header in Objective-C. That's just, I use it all the time when adding a new header and I want to just fill in the implementation. So really useful. - You always need command shift O. Command shift O is open quickly. So you can navigate to any symbol or do a lot of things with OpenQuickly. And I'm always using Command-Control-R, which is launch without building. So if you want to tear down your application and you want to create some state on disk or something and just relaunch without building, that's what you do all the time. Super useful. When your agent has reported that it's done building and everything looks great, you can just use that command to launch it without having to build again, which is awesome. And as a reminder for folks, if you're not aware, in Xcode settings, you can find all of these keybinds and make your own in a really easy to browse table. So every action that can exist in Xcode is in there, it's searchable, and you can make your own keyboard shortcuts as well. - Yeah, I was gonna say, most useful, command shift O, command R, command U. - Yes, the basics for sure, absolutely. - The basics, the things that you find in the product menu, basically. Profile. - Command I. - Command + I, yeah. - Control backslash I use all the time. It jumps to the next diff that hits this file so you can quickly jump between all the changed lines. - Yeah, that's what we do. - And command backslash is toggle a comment, which I find very useful, especially in SiftUI. If you're like, turn this modifier off, just comment it out, command slash. - Yep. - Mm-hmm. All right. I mean, we could probably keep going about - Yeah, forever. - Before it's working on. But let's take a look at another highly upvoted question from Claire KC. What are the most common beginner mistakes in Xcode? This is a great one. And how do I avoid them? Most common mistakes in Xcode. I mean, mine is trying to learn all of the features all at once. Xcode does a lot. It's a workhorse of an app. So I think you don't have to necessarily look at every single feature right away. Get to know the things that you're going to use most, like your source editor, your inspectors, your navigators, things like that. I'll highlight two things that, you know, if you're using code signing, if you're developing for the phone, you do want to use automatic signing. I mean, I think over the years, maybe you switched to manual signing because there was advice online that you wanted to take. But I think for most cases now, automatic signing is really there for you. And, you know, you can easily get stuck if you're a newbie on these kinds of manual signing workflows. They're too tough. So use automatic signing. That's what I'd say. Yeah. This kind of question was deep in my heart when I was thinking about how to simplify some of the experience for Xcode 27. So the toolbar being full of the controls that were previously in other areas and moving them up to the top level, you can right-click on them. You can customize them. You can swap out things for your workflow. It should make it a little bit easier to get started with a more simple setup. so you know new project you get an app you don't have to ask answer any questions you can just start to code and see results on the right hand side um same with the playground if you want to see other results um so you don't necessarily need to go into the template picker try to find the most complicated looking project diving in trying to add a bunch of targets um but you're also at a very fortunate time where when you do want to start doing some of these things you can reach for agents to help you. So it can be a great safety net when you're navigating around. And also, please use source control. So any mistakes you do make, you can revert back. Yeah. That was something in a different group lab that I was hosting. It's just like, please, please use Git. Yeah. If you don't know how to use it, your agent will. And it's not too hard. That's probably one of the most really challenging things to get started with if you've never used it before, but always use it. I was going to say, when you create a new project, that's on by default, correct? So, yeah. Using, starting a Git repository for each of your projects is invaluable. Even if you're working, I always hear, like, oh, but it's just me. I don't have a team. I don't have PRs to file that other people will review. It's just for fixing, like, work that you've done that you want to revert. It's so invaluable to be able to do that. It's the best undo system ever. Like, you want this. It's awesome. If you're building different features, you could keep them separate. You don't have to necessarily conflate the two sets of work. So please use source control. - I have two actually on the profiling side. So I think that first one is profiling on the simulator. This doesn't represent your actual device. So we always profile on an actual real device. And second thing, sometimes I see people profiling a debug build and that's not advisable. you want compiler to apply all the optimizations and then check it out. Sometimes you're gonna start chasing something that is not really a problem in the real world. - Yeah, definitely. Yeah, profiling an iPhone simulator is definitely, you're not gonna get the right data. Any other? - I think if you're new, you should adopt the greatest new framework ideas. You should use Swift concurrency. You know, but you're Swift UI. Yeah, Swift UI. There's some coding code along sessions as well that we've done over the years. Those might be a great place to have a like expert guiding you that you can then, you know, play around in your own space or go off the beaten path. When I was first getting started programming in general, which is like not completely related to Xcode, but sometimes I would take an open source project, like a little game or something. It was maybe something that was made like, you know, 48 hours. So it's relatively small. and just try to rewrite it one-to-one, and at some point you get something that actually works on your side. So not only can you learn Xcode by trying to just kind of play around with what's inside of it, but just getting your focus on your code and leaving Xcode as a tool that can power you up after you get your initial stuff running, that's probably the most important bit. Yeah, we actually, I was going to mention there's code-along sessions, and while they're usually on a particular topic, like I know there's one on Swift concurrency from last year that SEMA did, And what's really great about watching those sessions is just seeing it in the context of Xcode and seeing how the tools are integrated in that workflow while you're learning about a new concept as well. All the little icons they're clicking on. And you're like, that's what, okay, got it. That's what that one's for. Yeah. All right. Any other? I'd just say if you're starting a new project, start organizing it almost straight away from the start. Even though you don't know if it's going to turn into a big project yet. Like John says, with these folder types, just, you know, you have UI code and maybe you have, you know, different screens and you just start organizing it. The folders are cheap and easy. And you'll thank yourself later once it grows into, you know, dozens and dozens of files. Yeah. I often actually find myself reaching for agents for that, too. Like, OK, we did one giant file that's now 600 lines long. Let's make this organized, please. Do that more often and more consistently. You'll have a great time. Yeah, definitely. Kind of related to that too is something new in Xcode 27 is the way files and projects are created. You no longer have to go through that whole modal. You could actually just start a new project and it'll be a blank project. So if you start there, explore the tools, you know, prototype, iterate, things like that. And then once you get to a place where you're just like, oh, I want to save this, start organizing it. We also made that so easy so that you can go experiment, you know, in a small context, like in a little sandbox, playground, et cetera. Yeah. Yeah. So I would say there are no beginner mistakes. It's just things that you have to try out a little bit more and use the tools that we have to be able to iterate on it. All right. Great. Let's see. Let's go to a question from Protonster. Protonster? What are the most efficient workflows for generating and maintaining Doc C documentation alongside active development? Anyone have any insights for this? This is an area I wish I was better at in general, documenting my code. Yeah, it assumes we write documentation. I was going to say, better development practices than these guys. Write your documentation. I know that there's the documentation preview assistant, so anything that you have written in your source files will automatically be visible in the documentation preview assistant and you could host a Docs doxy archive as a static website for PR review So you can also use that if you want it to be part of your project And use it in your gifts and you you might have the inverse of this request Which is like how do I generate and you know do a great job having like a lot of documentation? You might also want to rein an agent back They love to add documentation comments that go way too much into detail or reveal implementation details sometimes So when you are requesting for things to be, you know, like now is the time where this is now API, I really want to make sure that it's documented. Taking the time to review it is really important. - I also would recommend writing articles. So Instruments team writes a lot of articles before we release the features. So like internal developers can learn how to use them before we release them externally. And for us, like I recently learned that I can actually put images in both light and dark mode. and that is really helpful. It actually swaps them automatically depending on the viewer. I will say Doxy is open source, so if you want to take a look at how to use it or implement any details about it, you can check out the repo for it. But also there are some great sessions on Doxy from a few years ago. Unfortunately, I don't remember all the titles, but please use the... Actually, developer.apple.com has a generative AI search feature, So if you put in Doxy there, you'll find all the resources about Doxy. All right. Let's take a look at the next question from Theo K. Which settings or practices can improve build time significantly? It's a great one. Any tips on build performance or build time performance? I'd be happy to take this. Do one of you guys want to do it? Go for it. Okay. So one of the main things you're probably thinking about with build performance is your incremental build performance. You know, like Chris mentioned, press, well, how about Chris's tip again? command control R, sometimes you've made some code changes and then you realize I don't actually need those to debug this another time. Command control R is the fastest way to run again. That's run without building. So next would be like as you work, how much of your build from last time is getting invalidated by the changes you're making this time. And so that has to do with sort of like how connected all your source code is to each other. If you split your code into different modules, either packages or frameworks or whatever technique is, you know, fits best with your workflow, then whole sections of your project can be unreachable from other sections, meaning they won't have to be rebuilt after many changes to them. So that's a great way to save time. There's an assistant editor on the build log that will show you the build timeline. So you could try to understand why more stuff is building than you expect or that things are taking much longer than you expect to build. There's some build settings that you can opt into, maybe in a config file that will give you warnings if the certain Swift expressions take longer than expected to type check and so you can ratchet down a threshold and get everything building quickly by just maybe sometimes breaking expressions into multiple lines and then another gotcha is script phases that people have that run unconditionally and sometimes those script phases they're just they're slow for whatever they do or they invalidate previous build results so they They have to build over and over again. So just be careful with the script phases. Make sure that they only run when necessary by declaring their inputs in the project editor. - Is there a warning when you create a script phase without the inputs and outputs? - There might be. - There might be. - Yes. - I'm like wondering also build with timing summary. - Yeah, that's that assistant that you can bring up, I think. - And yeah, the build timeline, there's actually a session from a few years ago now, the build timeline, about using the build timeline specifically. I was thinking too, I don't know if this is necessarily related, but explicit modules, potentially, especially if you're using dependencies and modularizing your project, you'll want to optimize for those dependencies. - Yeah, I'm not personally an expert on these features, but SwiftNOW also has like private and internal import, and I imagine those can sort of reign in the relationship across modules and help you reuse build products from one build to the next as well. - All right. - Well, there are probably better experts than us, so go to the forums as well if you have any specific use cases or problems that you're trying to solve with your build performance, and we'll have people there to answer your questions. Great, let's go to the next question from Pyrtza. What tricks should I employ to get Xcode previews to load faster, not having to wait for an off-screen simulator instance to launch again? yeah i think these would be you know similar sorts of tips to the previous question it's all about getting the build performance to be what you expect it to be and then once once a preview is up and running then the the machinery just does the minimum amount of work just to you know reload that that current that current source file and update the preview same thing for one of those inline playground macros so I think if the initial build is slow I mean they share the same build artifacts so you can do an initial build and run and then if you preview then it should be relatively quick because it's using the products that have already been built but and then it's just principles that we already talked about you know modularizing your project and everything yeah all right Let's move on to another question from Newbie. For automatic code formatting, I understand Swift format exists, but I'm not sure how to integrate it into Xcode. I have added them via build phases so that when I compile, it gets run. It works mostly, but at times when I start typing something and it starts to run, keeps throwing alerts and load about loading from disk. So I guess this is specific to specifically adding Swift format into their projects. I do think that this is a great one for a feedback report if you're encountering workflow issues, because this is a very specific use case. So I do highly recommend you file a feedback for us as well. But any other tips for newbie here on how to make this better? Well, you could consider when you run it, right? Like you could integrate it in a way that runs on build or runs on save, where you could be integrated into your Git workflow so that it runs as like a preparatory step to committing. And that is probably gonna be one of the less disruptive, I don't know if that's the right word, but you know, it's not gonna get in your way, you know, if you do it then, and you'll be able to get the right format into your repository as it goes in, which is what really matters. - That's true. And especially 'cause that's also when your pull request is like complete, you're ready for a review, your feature development's complete. Probably the best time to do that rather than continually doing it on code refactor anyway. All right, great. Another question from Protonster: "What are the most underutilized LLDB commands or breakpoint actions for isolating state changes without stopping execution?" I think this is because Chris you mentioned play sound, but what breakpoint actions could they use without stopping execution? Yeah play sound is a good one when you just need that feedback. It might be hit over and over or you just want to you just want to learn like is this part of the code actually being here and you can get that audio feedback or you could if it's something you want to hit more more often or have more diagnostics you can you can log a message straight from that action which is really handy it saves you you know putting in print somewhere you can just have the break point do that like print a trace and you know trying to log like when these things are occurring yeah you can call any any LDB command from there this This isn't exactly answering the question. It's more about when to stop at just the right time. I'm often debugging drag and drop or window layout issues that are happening, and there's lots of layout calls, and there's not a condition to stop on exactly the right one. And so I'll make a conditional breakpoint that has to do with the shift key being held on my Mac. And so then I'll get the program to the exact right state where layout has happened thousands of times, and then I'll press shift and trigger it and stop at just the right time to debug. That's cool. That's really cool. - We can skip couple of invocation, like couple of hits of the breakpoint as well, right? Like sometimes that's useful, like when you know the third one is what I want. So I've been using that. - Yeah. - Any other underutilized LLDB commands? - I mean, underutilized, sometimes I reach for PO, like I use the command PO when I could use the variables view. Sometimes I think a command is not always the answer. - Yeah, sure. - The variables view will tell you, you know, the values of everything that you have in scope. So that's usually what I'm asking PO for. - You can also like go the other way. Sometimes I'll use expression and then Swift's print so that I'm sure I'm getting like exactly like the scaping that I'm expecting on the output, you know, text. It's just another version of using that stuff. - For instruments development, we do a lot of work with like hex numbers. So I've been using p/x to print it as a x number. So that's really useful for my line of work. Sometimes-- I'm not sure if it's a good habit-- but sometimes I'll wonder what the program is doing, and I'll use the pause button. I mean, I don't know. This question is about how not to pause. But sometimes I intentionally pause just to see, where is the program lost? I haven't set a breakpoint, and I already don't have logging or something. So that's useful. Yeah. I do think that LLDB commands in breakpoints, it's a really good combination of both because I mentioned conditional breakpoints or at least being able to set things for the breakpoint. And if you were to do, you know, if you're used to print debugging and you want to still see that in the console, you can have that breakpoint print and then not have it committed into your project where you have random print statements. So that's one of my favorite things to do if you're just used to seeing print debugging or using print debugging. All right, great. Let's move to another highly upvoted question from THBI. Can I see unused vars, properties, functions, et cetera in Xcode? If not, why not? I think this comes down to what the compiler can reliably determine through static analysis and compilation. you will see warnings for unused variables because it can reliably know, yes, you defined a variable in scope, you haven't used it, you might want to know about that. Things like public properties can't reasonably be reasoned about because they're public. Who knows who's going to use them? So it would be interesting to hear feedback on use cases where you think it's something that's quite clearly what you expect as a developer, but the compiler or the build system is not giving you that information. I would plug in find call hierarchies again. If you're not sure, just run it and you will see what is calling into that function. But obviously that's not going to list everything in your project. It's something that you already suspect. Yeah, and I think the public properties one especially is just you can't make any of those assumptions because it might be called by something else. So that's really an interesting question, especially from THBI. If you are needing this in Xcode again, I don't want to sound like a broken record, but feedback assistant, please. There are, I believe, third-party tools that do this, but if the use case is needed for Xcode to surface that, it would be great to get a feedback report and the use case specifically. Great. Let's take a look at, oh, I love this username. Brewinstallpoppy has a question. Is deleting derived data an actual engineering practice or a superstition? We've all collectively agreed to perform. Also, besides derived data and Xcode 27, what should we really reach for at first when a build gets haunted? I love Brew and Saul Poppy. What a great question. Do you all have any insights on... Derived data is not a superstition, as you mentioned, John, that there's actual reasons for. I mean, it's both, right? It's like it is both a superstition and it works sometimes. So what happened, right? And so earlier I was saying that like, like, you know, a common example is like two targets. You know, you have a target that depends on the output of another target somehow, but in a non-obvious way. And the build typically gets ordered so that the first target's product is produced before the second target consumes it. You know, and so you build and you get this error and you're like, what is happening? You know, why can't you see this definition? It's clearly right here in this file, you know, and your go-to reaction might be to just destroy this directory and try again. And then it works. And you're like, what is going on? Right? So these problems are hard. It's like debugging a race condition in your code, except you're debugging a race condition in the Xcode build system, and you don't get to see the source code. Well, I guess you do get to see the source code of that now. So check it out and debug it. Please. But those are some of the biggest causes. Or that you're piling up stuff from your previous builds that it's taking too much disk space, and you want to get rid of it. Or there is a race condition in the actual build system, and you're working around one of our bugs. Like, those are the reasons why you're deleting that directory. And we want to fix all of those. And, you know, so if you think that we are building your source code incorrectly, because, you know, we actually don't think you should ever have to delete the derived data. It's like it's a workaround for our bug or your bug. So please send us the bug report, especially if you can reproduce it and know what sequence of edits leads to you taking this response, because, you know, it's a superstition that works. based on my experience like i actually think that xcode 27 got a lot better like sometimes in previous versions i would switch between branches and it would fail the build now it's it's working way way way better so um and yeah on the size of derived data i've been i'm sure many developers have been utilizing more work trees so that creates a new uh build folder for for your uh for your project so yeah sometimes you might want to just clean it after after too many work trees Yeah. All right. But yes, I believe in Xcode 27 especially, there should be a reduction in the need of deleting derived data, taking a lot of effort to make sure that those problems that you typically encounter are resolved. We've absolutely focused and fixed many instances of this, but I don't want to say that it is fixed, but it is something we take very seriously. So I don't have any problems. I wanted to acknowledge something that you said as an aside that maybe some folks aren't aware of. You said, oh, you can look at the source code. Yeah, Swift build is open source, which is the build system for Xcode. So if you do want to take a look at how it's working, check out the repo. All right. Great. Any last minute? What other tools should they reach for if their build gets haunted other than deleting drive data? We do have clean right clean I don't know if these features are still supported you used to be able to turn off parallelized builds You know and that was like an opportunity for maybe more predictably finding one of these missing dependencies But I'm not not sure of other features that we would have Yeah, I think I think if you're still reaching for derived data please reach out to us so that we could try to figure out in what other cases we could still improve this experience. All right. We have time for a couple more questions. So I'm going to move on to a question from Tammy Santana. Love using Cloud Code in Xcode, building a 50-file SwiftUI app with it. One issue. When context compresses mid-session, the agent silently loses project understanding. and I had to write a 230 line Claude MD file as a workaround. Would love a compression indicator and a pause before editing mode to protect project. This is more of a feature request. But specifically around agent workflows, trying to get a compression indicator, is that a possibility? Anything's possible with feedback. No, that is a good feedback. I mean, there's good opportunities there to perhaps looking at how you're using that session, perhaps looking at starting, if you haven't already, with plan mode and getting something planned out and written to disk. And then the context isn't in your chat window, chat session. It's on disk and the model can reach for that whenever it wants to. Yeah, I would say generally creating artifacts that you could reference. because also if you're switching between models or going between sessions or you have to wait until the next day, you don't lose that context and you don't rely on the window being your only source of truth. Yeah. And you want to be a little careful. The CloudMD is loaded into the context by default. So if it's 230 lines or more, you are growing the context by default. But this is an area where we love feedback here. So please, if you have any workflow impediments or you want to see things improved, always file feedback, especially this time of year. All right. I think we have time for one more question. I'm just scanning through to see if there's one that would be great to wrap up on. I think I'm going to go with signing and provisioning profiles. For Chris, I think this is a question for you. From KLKJ99. Signing and provisioning profiles always trip me and my team up. We often see mismatches and code signing issues while building. What can we do to mitigate that in Xcode? And each time we need to build and test in instruments, we have to manually switch a bunch of provisioning profiles in many targets. I'm unfamiliar with an instruments issue. I think that might be sometimes what we see developers do. I'm not sure if that's what you're doing, is using distribution certificate for their release configuration. And that has all sorts of problems, because that prevents developers from using tools like allocations that actually require your build to be like debuggable and have the right entitlement. So if that's what you're doing, sometimes developers disable this code sign inject base entitlements setting to work around some issues, that also is not the right thing to do. So that's on instruments. I mean, I'd say another thing is I'd plug automatic signing again. And one thing that people would use manual signing for is because they ultimately want to set up some CI. And if you're interested in Xcode Cloud, then the signing is handled for you. So you can easily use automatic signing locally. And the other thing is along the lines of what Casper is saying is that I have seen setups where you have a debug configuration and you have a release configuration. and that feels like you should use distribution signing for the release configuration, and that's not exactly true. You want to use regular signing locally, and then when you go to upload to the App Store, that is when you distribution sign. It's unnecessary to kind of do distribution signing locally, and it can mess things up. I think it's quite common, like large projects, many developers working on something, workarounding it at some point in time, and then you have these artifacts based on. Yeah. Well, hopefully that answers your question, KLKJ99. If you do have specific issues with your setup, or particularly around code signing issues, again, can't say it enough, developer.apple.com slash forums, where we could also see what other experiences other developers are having, and they can join in the conversation and potentially help debug this with you. All right? Along with our engineers, of course. It's not just all of you on the forums. All right. I think we have time for one more question, and this might be an interesting one to end on. Protonster is asking, how can I configure Xcode's code folding and structural navigation to visually suppress noise and keep only the high-value logic on screen? Seems like a really great feature request. Yes, definitely. Definitely file feedback around how you picture yourself working. So you can imagine a world where you just kind of want to see basically what the jump bar is giving you, but like in code form. Like this kind of stuff is really, really useful feedback to file. So if you can give your workflow or your specific use case while you're giving feedback, it can help us take a look at how to tackle problems like these. You might also choose to organize your source code so that the noise is contained in one spot. Like you can split definitions for a type across many extensions or many files. So you could choose to sort of contain and put the junk in the junk drawer if you want. I will say you could check out the Xcode's editor menu also to look at code folding actions. If there's something there, that actually helps with your workflow. But I agree. I think what's interesting about this is what do you consider visual noise? And so I think it depends on the use case. So feedback's going to help us try to chase that one down for you. All right. And that is all the time we have. We got through lots of questions. Thank you to our panelists, Chris, Jake, John, Casper, other Chris. Thank you for your answers and your insights today. Thank you for everyone behind the scenes who helped triage questions as well as helped keep the show running. And of course, thank you all who joined, who asked the question or just tuned in. It was such a privilege for us to be able to host this for you today. Don't forget, like I've mentioned already multiple times, if we didn't get to your question today, please go to developer.apple.com slash forums where we could continue the conversation. And I mentioned briefly, there is a generative AI-powered search in developer.apple.com where you could search any of the topics we talked about today, and it'll provide you sessions, documentation, articles, anything we got for you to help you in your journey. And last but not least, please submit your code-level questions bug reports and enhancement requests in feedbackassistant.apple.com. Thank you again. Have a great WWDC.