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. Thanks, Chris. Miles. I work on live coding experiences in Xcode. That’s things like previews and playgrounds and integrating those technologies into our 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 Kasper 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, 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, Pichaya. 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 useful. What are the most useful Xcode tips and tricks that most people may miss out on or 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 at any in any of your Swift files so you can.

You can simply import playgrounds and then use the 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 in 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 right in it. It’s awesome. Yeah. That’s right. Yeah. Basically file new playground will give you that, 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 want to test because you could actually use playgrounds to test out models. Yeah. You can, 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 like. I’ll write several types all in one file, maybe some protocols, some enums, some structs altogether. And then I got to split them up and I could go through the new file dialog, making new files and putting them in over and over again.

But kind of hidden feature in Xcode is if 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 dot swift. And as a real time saver, unless you kind of organize when you’re done sort of making everything work together.

All the time. That’s a great one. I’ve been doing a lot of refactoring recently with Xcode and rewriting a lot 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 in the folder. And the other one that I use developing Xcode on the Mac.

What I what what we’re constantly doing is what 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 of the debug application. So I’ll change it to dark mode. So I can, 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 can find it exactly where it is in your project. It’s like my favorite combo. All right. Another question from a developer fan. Tex is asking which recent Xcode feature do you think deserves more attention?

Oh, 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 probably all experienced this. Like I make a change, my colleague makes a change. We conflict, and it doesn’t even feel like we’re working on the same thing. We added a feature a couple of years ago. Maybe in an episode 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 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 a scheme and you can set. Different user defaults. And it’s very common that we’re 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, you know, 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, it’s wonderful to get your logs sorted nicely.

A variant of that with the filtering that’s like less discoverable, it’s super useful is 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 you can share variants like show me all the, you know, 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 all values, and then your single preview can then take that argument and just give you a grid of 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 going to give you information about the footprint of your app. So you can actually open this memgraph right.

In 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. And yeah, that’s actually there’s a, 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. And makes them so you can just leave a breakpoint there and it’ll trigger when you actually need it to trigger.

So all right, moving on to a highly upvoted comment, not a question. Let’s look at this one from Franklin Barroux 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 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 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, you know, the public SDK that we already shipped so that your app, you know, still builds with that old version of Xcode. Sometimes we add new features to Xcode itself that require, you know, the new version of Xcode.

Sometimes they’re pervasive, like the blue blue folder I mentioned earlier 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 in to some stricter project validation unloading. You’re not going to check this by accident, so feel confident using the new Xcode to explore it while you maintain compatibility with the shipping version.

Yeah. And I think specifically, 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, and I believe you do have to like worry a little bit about, especially if you’re building or shipping to the App Store, making sure like Xcode select is pointing in the right place and things like that. Yeah.

Also a great opportunity to use Xcode Cloud 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 going to plug the, the blue folders 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 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 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 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, you know, 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 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 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 you can make your workflows pretty powerful.

All right. Any other underrated features people can think of? I want to call out the Xcode has really powerful search to when you’re really looking for something across a large project. You know, 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. You can do the multiword 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 going to, 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 I’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 add one more fine feature. There’s so many of them is 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, from the organizer that allows you to see how your data is behaving, how your app is behaving with your users two instruments and profiling a disk. I think I really love profiling, and I think that there’s something great about making Europe 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. Profile FAQ’s verify that focuses on explaining these concepts. So I recommend everyone to check it out. And we have a SwiftUI instrument don’t we. Yeah that’s great for your view hierarchy performance. That’s correct. So yeah, if you’re experiencing problems with your SwiftUI app specifically, there’s a dedicated template template.

That same thing with concurrency. Same thing with Agentic. We have. Foundation models. There’s templates for everything. I wanted to call out the SwiftUI instrument. There was a session actually last year for it. Definitely take a 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 don’t, 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, great underrated Xcode features. Let’s take a look at the next question from M Blackman. Great username. Also, what caveats should we be aware of when running Xcode 27 beta on 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 you’re set. Go for it. We, we use lots of versions of Xcode every day on lots of versions of macOS. So we’re prepared for this, you know, go ahead and use two versions of Xcode at the same time. Totally supported. Yeah. One might look like really colorful and one might look really like normal or plain. So that might be the only major cause for concern. I believe, I think there’s a couple of notes on like project file and compatibility. Is there anything around there between Expo 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 Xcode, Xcode project files, which some developers address by generating their own project files with Twist 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 the the using the blue folders instead of the gray groups. You know, that’s going to cut your project size probably in a third if you adopt it. Bit 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 a 150 source files and they’re all together in the same target, none of it will be recorded.

If there’s a couple 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, right? 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 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. 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. It 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 going to 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. Yeah.

That’s a useful one. You can You can put your build settings in in files called X 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 config files. And if you’re not sure like what the build setting name is like, well, what do I call it?

A tip is to in 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 see the name of the build setting in the in the help inspector. I’ll use that all the time. The source editing experience for working with config files has been tuned up a bit this year as well, so it could 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 a 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 newbie 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 the second question. Are there any improvements on source control side of things in Xcode? I wish Multiselect was possible on stashes to delete at once. So first question first, let’s start with any cool tricks with markdown.

Well you can 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 open as and just, you know, select source code instead of rendered, then you’ll see markdown and it’s in its textual form.

And that can be useful to move back and forth. But in both forms, you can edit that markdown just straight in the editor, which is really cool. Yeah. And not just in just as like a standalone file, but when you’re working with an agent and you’re creating a plan or some other markdown file, like inside of the transcript area or the editor, you can just work on 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 to side, side by side, as well as like the, the rendered markdown as on the canvas on the right side as well. Yeah. That’s right. Just use the, the canvas like 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? We’ll definitely take a comment for the 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, the, the, 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 Excel projects all be consistent with all their authentication and everything else. And so we’re improving that every year. Yeah, there’s, there’s. Good performance improvements. Yeah. Oh yeah. Especially if you have lots of tags in your, 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 if that’s important to you, but kind of like a, I guess this is 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. 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 feedback.apple.com. All right, moving on to the next question from Tammy Santana.

When a Swift package manager package like ML Swift updates its macros, Xcode requires manual reapproval every 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. I’m surprised that it’s invalidating trust on every update. So make sure you submit something on feedback. Let us know exactly what what’s happening in your use case or 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 CE 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. Now. Like, yeah, you could open terminal and then maybe like 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 navigator and 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 navigator show in finder. If you wanted that functionality in terminal, like it’s definitely possible.

Great. Awesome. All right. Moving on to, oh, this is a great question from Krissha. What are the most useful Xcode keyboard shortcuts you use daily? This is 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 right to, you know, 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, all three modifiers in the bottom row control option command and G. Yeah, don’t try and remember which ones. Just all three of those in G.

I was like, I feel like my hands have remembered keyboard shortcuts and I don’t know which modifiers they actually are. 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 to 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 six.

I don’t know the name of this menu command, but when I want to learn the name of a menu command or something that 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 I think has a K equivalent. Now let me tell you what control six does.

Control six 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’s kind of like 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 going to 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 pretty 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 open quickly.

And I’m always using command control R which is launch without building. So if you if you want to tear down, you know, your application and you want to create some state on disk or something and like just relaunch without building. That’s, 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 like 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 going to say most useful command shift command R command you. Yes. The basics. For sure. Basically, the things that you find in the product menu, basically the profile. Command. A command I yeah, there’s one. Control control backslash I use all the time. It jumps to the next diff that is in this file. So you can quickly jump between all the changed. That’s a great one.

And command backslash is toggle a comment, which I find very useful, especially in SwiftUI for like turn this modifier off. Just comment it out. Command slash. Yeah. All right. I mean, we could probably keep going forever. But let’s take a look at another highly upvoted question from Claire Casey. 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 the features all at once. Xcode does a lot. It’s a, it’s a, it’s a workhorse 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, if you’re developing for the phone, you, you do want to use automatic signing. I mean, I think over the years, maybe you switch 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, on, 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, 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. Same with the playground if you want to see other results.

So you don’t necessarily need to go into the template picker or try to find the most complicated looking project diving in, trying to add a bunch of targets, but you’re also in 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 was 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 the most, one of the most like 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 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. 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, you know, 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 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 going to start chasing something that is not really a problem in the real world. Yeah, definitely. Yeah. Running, running, profiling like an iPhone simulator is definitely you’re not going to get the right data.

Any other I think I think if you’re new, you should adopt the greatest new framework ideas. You should use swift concurrency, you know, But just SwiftUI. Yeah. SwiftUI Swift. 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 play around in your own space or go off the the beaten path.

When I was first getting started programing 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, maybe something that was made like, you know, 48 hours. So it’s relatively small and just try to rewrite it 1 to 1. 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, just getting, you know, your focus on your, your code and leaving Xcode as a, 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. What’s really great about watching them, 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. So all the little icons that are 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, like from the start, even though you don’t know if it’s going to turn into a big project yet, like John says, with, with these folder types, just, you know, UI code, and maybe you have different screens and you just start organizing it. The folders are cheap and easy and you’ll thank yourself later once it grows into dozens and dozens of files.

Yep. I often actually find myself reaching for agents for that to like, okay, we did one giant file that’s now 600 lines long. Let’s make this organized. Please do that more often and more consistently and 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 could go experiment, you know, in a small context, like in a little sandbox, playground, etc.. Yeah. So 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, to iterate on it. All right. Great. Let’s see. Let’s go to a question from proton. Proton. 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. Yeah. Right. 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 diffs.

And you might have the inverse of this request, which is like, how do I generate and do a great job having 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 modes and that that is really helpful. It actually swaps them automatically depending on the viewer. So I will say doxy is open source. So if you want to take a look at how to use it or implement or 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 times significantly? That’s a great one. Any tips on build performance or build time performance? I’d be happy to take this one. Do you guys want to do it? Okay, so one of the main things that you’re probably thinking about with build performance is your incremental build performance. You know, like Chris mentioned, 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 timelines. 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 that you 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 emitted when you create a script phase without inputs and outputs? There might be days. Yes.

I’m like wondering also build with timing summary. Yeah. That’s a good. That’s that that assistant that you can bring up I think. And yeah, the, 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 to, I don’t know if this is necessarily related, but explicit modules potentially, especially if you’re using dependencies and modularizing your project, you want to optimize for those dependencies. Yeah, I’m not personally an expert on these features, but Swift now also has like private and internal import. And I imagine those can sort of rein 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, you know, 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 Piazza. 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 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 machinery just does the minimum amount of work just to reload 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. 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 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, you could integrate it in a way that runs on build or runs on save, or you could integrate it into your git workflow so that it runs as like a preparatory step to committing. And that is probably going to be one of the less disruptive.

I don’t know if that’s the right word, but you know, it’s not going to get in your way if you do it then and you’ll be able to, to get the right format into your repository as it goes in, which is what really matters. That’s true. And especially because that’s also when your, your pull request is like complete. You’re ready for a review, your future developments complete. It’s probably the best time to do that rather than continually doing it on code that you might refactor anyway.

All right. Great. Another question from proton stir. 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 Playsound, but what what breakpoint actions could they use without stopping execution? Yeah, Playsound 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 hit?

And you can get that audio feedback, or you could, if it’s something you want to hit more often or have more diagnostics, you can, you can log a message straight from that action, which is really handy. It saves you putting in print somewhere. You can just have the breakpoint do that. Like print a backtrace and trying to log like when these things are occurring. Yeah. You can call any, any lldb command from there.

This isn’t exactly answering the question. It’s more about when to stop at just the right time. I’m often debugging like drag and drop or like window layout issues that are happening. And there’s like 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 like 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 since then.

Then I’ll press shift and trigger it and stop at just the right time to debug. That’s cool. That’s really. Cool. You can skip a couple of invocations, like couple of hits of the breakpoint as well, right? Sometimes that’s useful, like when you know, the third one is what I want. So yeah, I’ve been using that. Yeah.

Any other underutilized lldb commands? I mean underutilized, sometimes I, I reach for Po like I use the command Po when I could use the variables view. Sometimes I think command is not always the answer. Yeah. That’s true. 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 escaping 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 slash x just to slash x to print it as a hex 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, like, I don’t know, you know, this, 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 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 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 could 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 a another highly upvoted question from THBI. Can I see unused vars, properties, functions, etc. in Xcode? If not, why not?

I think this comes down to what 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 define a variable in scope. You haven’t used it. You might. 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’d be interesting to hear feedback on use cases where you think it’s, 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 what is calling into that function. But obviously that’s not going to list everything in your project. Yeah. Something that you already suspect. Yeah. And I think the public properties one especially is just you can’t 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, you know, surface that it would be great to to get a feedback report and the use case specifically. Great.

Let’s take a look at, oh, I love this username brew install. Poppy 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 in Xcode 27, what should we really reach for at first when a build gets haunted?

I love brew install poppy. What a great question. Do you all have any insights on drive? Data is not is not a superstition, as you mentioned, John, that there’s actual reasons for it. I mean, it’s both, right? It’s like it is both a superstition and it like it works sometimes. So like, like what happened, right. 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 targets 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 it’s like debugging a race condition in your code, except you’re debugging a race condition and 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, but those are some of the, 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, you know, 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 sometimes in previous versions, I would switch between branches and it would fail the build. Now it’s working way, way, way better. So 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 build folder for, for your, 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, you should, there should be a reduction in the need of deleting derived data. I’ve taken a lot of effort to, to make sure that those, 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, you know, but it is something we take very seriously. So if you 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 you can look at the source code.

Yeah. Swift build is 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? How, what other what other tools should they reach for if their build gets haunted other than deleting drive data?

We do have clean write 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, I’m not sure of other features that we would have that would help you with this.

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 what, in what other cases we could still improve this, 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 Claude 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 cloud 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, you know, agent agent workflows. Trying to get a compression indicator. Is that a possibility?

Anything’s possible with feedback. Now that is a good feedback. I mean, it’s, 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, you know, 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 till 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 do you want to be a little careful? The cloud MD is is loaded into the context by default. So if it’s 230 lines or more, you know, you are growing the context by default. So yeah, 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 gonna go with signing and provisioning profiles for Chris. I think this is a question for you from K99KLKJ99. 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 that prevents developers from using tools like allocations that actually require your build to be 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 and, you know, one thing that people would use manual signing for is because they ultimately want to set up some CI. And if you’re, you know, interested in, 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 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 with large projects, many developers working on something workaround it at some point in time, and then you have these artifacts baked in. Yeah.

Well, hopefully that answers your question. KL KH 99. And if you do have specific issues with your like your setup or particularly around code signing issues. Again, can’t say it enough. developer.apple.com/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. Proton 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, great feature request. Yes, definitely. Definitely file feedback around how you can 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 just 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 is 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 help to 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/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. Code level questions, bug reports and enhancement requests and feedback. assistant.apple.com. Thank you again. Have a great Wwdc.