Agentic Coding with Xcode

Note: the final project provided with this lesson matches what is seen in the video, but may not match what the Agentic AI did for you!

We’ve got some errors still left over from our previous ask of the model’s help. What’s really nice about the MCP server that we set up and the tools that are available to it is that it now knows how to read an error list and a list of warnings from Xcode itself. So I’m going to tell it:

  There are a few errors. Please go and fix them.

And let’s see what it does with that.

It says, again, what it’s planning to do — it’s either going to use Xcode’s list navigation issues or refresh to start gathering information. It’s getting the issues, and it found some errors. It’s looking at whether there might be some gaps in our availability annotations on the model. That’s exactly correct. SwiftData model inheritance does need some availability annotations, so it’s going to throw some of those in there, because model inheritance only works for certain versions of the operating systems.

It is coming back and making sure that we continue to have two-space indentation, which is very nice. It’s planning a rewrite of Recipe.swift because there are some duplicated entries, so it’s cleaning up the code a little bit and compiling a unique sample data list. We’re looking at Recipe.swift now, and we haven’t gotten a complete update of that file yet. But assuming the agent does what it’s supposed to, we’ll see some availability annotations appear on top of this model — and there they are right there.

We’ve got a rewrite here, but this isn’t quite right. We’ve got a little bit of a version mismatch. We’re going to see if it catches that. And if it doesn’t, we’re going to ask it one more time to do an analysis. It now has an updated error message, which is great — that should inform it on what to do the next time we come around and ask it to rescan for any errors.

It’s again keeping our two-space indentation requirement in place, so that’s very nice. With a little bit of history in our chat, the tool is smart enough to realize that since I asked for it earlier, I want to keep it that way. So for any new code that it’s adding, it’s keeping that indentation request intact. It’s doing the same thing for RecipeDetailView, continuing to analyze the rest of the project, doing the same thing for BeverageDetailView, as well as the sample data.

And now it is rechecking the build errors — this is the assessment portion of the agent, verifying if any remaining files need indentation fixes after updating key Swift files, then checking errors again with Xcode’s list navigator issues. So I might not have to do anything. It is getting issues and has found some. Now it is going into that replanning phase and determining a next set of things to do. It correctly identifies the iOS 26 availability requirement from this message, updates everything to 26.0, those errors go away, and it is going through and checking one more time.

We’ve got a stale error from a generated file remaining. Let’s do a clean build — and that seems to have done it. I’m going to go ahead and ask it:

  Run a clean build.

And we’ll get that to handle that step for us. Our deployment target isn’t below iOS 26, so this works great for what we’re doing — we don’t need to worry about this extra step. The build is successful. Clean build completed successfully — xcodebuild, no errors reported.

That looks great. Let’s take a look at our new BeverageDetailView, because we haven’t looked at that before. It does have a preview available, so let’s see what the preview gives us. Okay, so this is a little bit different than our previous recipe view. We’ve got a brew profile that it’s come up with to give us some stats on the beverage. It’s got some tags up here to show whether it’s, for instance, a beverage or iced. There are some different icons for the ingredients — a little bit different than what we have for the recipe, which is what I asked for. That could be iterated on and improved as needed.

One more thing we’re going to do here — it’s always good to add documentation. So I’m going to ask the tool:

  Add documentation to the project where needed.

And we’re going to let that go. This is essentially asking the MCP tool to use its documentation-specific tools and add some information. And it’s actually giving us some options: inline code comments and doc strings for specific files or types; a new README; a short architecture overview; or Swift doc comments on public APIs only. Let’s do one, two, and three — and I always like to say please to the AI, just because I don’t want to get on its bad side.

Let’s see what it does with these. It should make some inline code comments, make a new README, and give me a little bit of an overview doc so I can see what I’m doing here. It’s adding some information for our BeverageDetailView and adding some other comments as needed. And of course, the important thing to note here is that it is vital to go back and make sure that the comments it is putting in — as with your code — are correct. The AI is only so good at figuring out what to do and what to add. It is up to the user, up to the developer, to make sure that everything is correct and functioning as intended.

It is going to make a README file, so I’m going to allow that to happen. It’s also making a metadata file — I’m going to do the same thing for the architecture file that it is creating. It’s giving you, again, a summary of what it did: added some inline documentation in these files, and made a new README and an architecture doc. Let’s go look at those real quick.

They may not be too detailed, but they’re going to be there. Oh, that’s interesting — they aren’t in the project. So let’s see if the new docs aren’t in the project:

  The new docs aren't in the project, please add them.

It looks like they were probably made on the file system but not added into the project itself. Let’s see if it can figure that out — I may have to go ahead and add those manually. It’s going to try to do this again, so let’s see if this works. Ah, there we go — add them to the Xcode project navigator as well. Yes, please do that. And it should add them to the actual Xcode project in addition to the file system.

Okay, they are in there, so let’s make sure this time. Hey, there we go — a README file. It understands how to do Markdown and gives you an overview. We’ve got an architecture document — kind of the same thing, but that’s okay. It gives us a basis for explaining how we’ve got things set up.

So, with a few simple requests to our agent — and in this instance, Codex — I was able to add a baked goods and beverages model, eventually get those to be based on SwiftData model inheritance that was introduced in iOS 26. We were able to convert and keep our indentations at two spaces instead of four. And we were also able to ask it to fix errors and add documentation to the project where needed.

Again, all of this needs a good scrub through to make sure that what was added was actually correct. But our initial look at the BeverageDetailView that it made for us does look pretty good — the information is there, it’s being presented correctly, and that’s a very good sign.

This is just the beginning of some of the functionality that Apple and Xcode will be adding in the years to come, I’m sure of it — as the systems underneath, like Codex and Claude, continue to increase in capability, and the tools available to them through the Model Context Protocol continue to get more and more powerful.