An AI assistant can read your Swift files fine. It can’t build them, can’t run a test, and has no idea which file belongs to which target. So every fix turns into clipboard work: copy the error out of Xcode, paste it into a chat window, paste the answer back, build again.

Two things close that gap, and both have names that sound bigger than they are: MCP and agent skills. Neither one needs anything installed if you have Xcode 27.

What MCP actually is

MCP stands for Model Context Protocol. It’s an open standard that lets an AI tool call functions inside some other program. The current spec version is 2025-11-25, and there’s an official Swift SDK if you ever want to write a server yourself. It needs Swift 6.0 and runs on iOS 16 and up.

Three words cover the whole vocabulary:

  • A server exposes tools. Build this scheme. Run these tests. Read the console.
  • A client is the AI tool calling them. Claude Code, Codex, Cursor.
  • A transport is how they talk. On your own Mac that’s usually stdio.

A server is a program that lists what it can do and then does it when asked. Nothing more mysterious than that.

Turning on Xcode’s MCP server

Xcode 27 ships with one built in. This is the part most people miss, because there’s nothing to install.

  1. Open Xcode Settings, go to the Intelligence tab, find Model Context Protocol.
  2. Tick “Allow external agents to use Xcode tools.”

Now register it with your agent. For Claude Code:

claude mcp add --scope user --transport stdio xcode -- xcrun mcpbridge
claude mcp list

For Codex:

codex mcp add xcode -- xcrun mcpbridge

Xcode shows a permission prompt the first time something connects. xcrun mcpbridge resolves through your selected toolchain, so whichever Xcode your command line tools point at is the one the agent gets.

What you actually get

Once it’s connected the agent can build the active scheme and read back errors and warnings with file paths and line numbers. It can run your whole test suite or one method. It can switch schemes and run destinations, read console output from a running app, and send LLDB commands into the same debug session as Xcode’s console, so po from the agent and po from you see the same state.

The list goes further than build and run: rendering a specific #Preview to an image, reading the Issue Navigator, editing target build settings without touching project.pbxproj by hand, adding Info.plist keys, inserting String Catalog translations, driving the simulator with synthetic taps, and pulling your top crash signatures from the last 14 days.

Two of those carry most of the value. Structured build errors, because the copy and paste loop disappears. And preview rendering, because the agent can finally see that the layout it just wrote is wrong.

Skills are just folders

A skill is a folder with a SKILL.md inside. The file opens with two lines of YAML and continues as plain markdown. Here’s a small one:

---
name: swiftui-view-review
description: Reviews SwiftUI views for state ownership and layout mistakes. Use when adding or editing a SwiftUI view.
---

# SwiftUI view review

Check these before calling a view done.

1. Every `@State` property is private. Anything passed in from a parent
   is a `let` or a `@Binding`, never `@State`.
2. No `AnyView` unless the branches really return different types.
3. Long lists use `LazyVStack` inside `ScrollView`, not `VStack`.
4. Every image and icon has an accessibility label, or is explicitly
   marked decorative.
5. Run the preview and read the console. A purple runtime warning is
   a bug, not noise.

Here’s the mechanic that makes skills cheap. The agent loads only name and description at startup, roughly a hundred tokens each. The body stays on disk until your request matches the description. Ten skills sitting in a folder cost you almost nothing until one of them is needed.

Which means the description is the whole game. A description like “Guidelines for SwiftUI views” never fires, because it says what the file is about and never says when to reach for it. Write what it does and when it applies, in that order.

Where the folder goes:

  • ~/.claude/skills/swiftui-view-review/SKILL.md for things you want in every project
  • .claude/skills/swiftui-view-review/SKILL.md inside the repo for team knowledge that should be committed

Apple wrote seven of these for you

Xcode 27 ships the skills its own assistant uses, and there’s a command to export them:

xcrun agent skills export --output-dir ~/.claude/skills

You get seven folders back: swiftui-specialist, swiftui-whats-new-27, test-modernizer, uikit-app-modernization, c-bounds-safety, device-interaction, and audit-xcode-security-settings. Restart your agent afterwards, since skills are discovered at startup.

If the command isn’t found, your command line tools are pointing at an older Xcode. Fix it in Settings, Locations tab, Command Line Tools dropdown.

Five of those seven only read and edit source files, so they work in any agent anywhere. device-interaction and audit-xcode-security-settings need Xcode’s own tools, which is exactly what the MCP connection above gives them.

Pick your first one by what’s actually on fire. If your app still builds its window in AppDelegate, start with uikit-app-modernization, because that pattern stops launching under the iOS 27 SDK. If you’re mid migration to strict concurrency, test-modernizer goes well with turning on default actor isolation.

What to get right first

One skill, one job. A skill called ios-stuff never triggers at the right moment. swiftui-view-review does.

Write the description for the trigger. It’s not a title. It’s the sentence the agent matches your request against.

Keep SKILL.md short. Under about 60 lines. Long files get skimmed by agents the same way they get skimmed by people. Push the detail into a second markdown file and link to it.

Put your project’s facts in the skill. Scheme name, test target, which simulator, the one build flag that always breaks. That’s knowledge you currently retype every session.

Re-export Apple’s skills after each Xcode update. The export is a snapshot, not a live link. swiftui-whats-new-27 in particular goes stale.

Read the diff before the tests run. An agent that can build and run code on your Mac is convenient right up until it isn’t.

Where it isn’t worth it

For writing a doc comment or asking a one-off question about a function, none of this helps. The model handles code as text just fine and the setup adds nothing.

The security tradeoff is real too. Enabling the MCP server means external processes can trigger builds and run code on your machine. The server only accepts local connections, so it isn’t sitting on the network, but be deliberate about which tools you hand the keys to.

If you want an alternative that works without Xcode open, XcodeBuildMCP wraps xcodebuild and the simulator tools as a standalone server. Apple’s is the one in this post because it needs no install at all.

Frequently Asked Questions

Do I need Xcode 27 for any of this? For the built in MCP server and the skill export, yes. Skills themselves are just folders with markdown in them, so those work with any agent on any Xcode version.

Is MCP an Apple thing? No. It’s an open standard with SDKs in several languages, including Swift. Apple shipped a server that speaks it, which is different from owning it.

Do skills and MCP do the same thing? No, and mixing them up costs time. Skills tell the agent how to write code. MCP lets it run things. Most of the value shows up when you have both.

Will this write my app for me? It won’t. What it removes is the manual loop of build, read error, paste error, apply fix, build again. You still decide what’s correct.

Can I use these skills without any AI tool? Yes, and it’s underrated. Export them and read them. They’re Apple’s own written guidance on SwiftUI structure, UIKit modernization, and test migration, in plain markdown.