Interact with Xcode via Apple's MCP bridge for building, testing, previewing, and debugging Apple platform projects. Use this skill whenever the user is working on Swift or SwiftUI code, building iOS/macOS/watchOS/tvOS/visionOS apps, wants to run or fix builds, run tests, render SwiftUI previews, search Apple documentation or WWDC transcripts, check Xcode diagnostics, or do any development that involves an Xcode project (.xcodeproj, .xcworkspace, or Package.swift). Also use when the user mentions Xcode by name, asks about build errors or warnings, wants to evaluate Swift snippets, or is iterating on UI with SwiftUI previews. Trigger even if the user doesn't explicitly mention Xcode — if they're working on Apple platform code and could benefit from Xcode integration, this skill applies.
You have access to Xcode through the xcode MCP server (xcrun mcpbridge). This gives you 24 tools that let you build projects, run tests, render SwiftUI previews, search Apple documentation, and more — all through Xcode's own engine.
Xcode must be running with a project open. The MCP bridge connects to the active Xcode instance — there's no headless mode. If tools return errors about connection or missing windows, ask the user to confirm Xcode is open with their project loaded, and that MCP is enabled (Settings > Intelligence > Model Context Protocol > Xcode Tools).
Almost every Xcode MCP tool requires a tabIdentifier — a string that identifies which Xcode window/tab to operate on. You get it by calling XcodeListWindows first.
Always start by calling mcp__xcode__XcodeListWindows at the beginning of any Xcode workflow. Cache the tabIdentifier and reuse it for all subsequent calls in the session. The only exception is DocumentationSearch, which doesn't need one.
If a tool call fails with a tabIdentifier error, call XcodeListWindows again — the identifier may have changed if the user switched projects or tabs.
XcodeListWindows — Returns open windows with tabIdentifier values. Call this first.Use these when you need Xcode-aware file operations (e.g., so Xcode tracks changes for diagnostics and builds). For simple reads of files outside the project, Claude's native Read tool is fine.
XcodeRead — Read file contentsXcodeWrite — Write entire file contentsXcodeUpdate — String-replacement edits (like Claude's Edit tool, but Xcode-aware)XcodeLS — List directory contentsXcodeGlob — Glob pattern file searchXcodeGrep — Regex search with context lines and output modesXcodeMakeDir — Create directoriesXcodeRM — Remove filesXcodeMV — Move/rename filesBuildProject — Trigger an incremental build (typically very fast, ~1s for incremental)GetBuildLog — Retrieve build logs; filter by severity to focus on errors or warningsRunAllTests — Run the full test suiteRunSomeTests — Run specific tests by target and test identifierGetTestList — List all available test targets and test identifiersXcodeListNavigatorIssues — List all current issues (errors, warnings) from the Issue NavigatorXcodeRefreshCodeIssuesInFile — Force Xcode to re-check a specific file for issuesExecuteSnippet — Run Swift code in a REPL-like environment with access to the project's module context. Useful for testing expressions, checking API behavior, or prototyping logic.RenderPreview — Render a SwiftUI preview as an image. Returns the rendered preview so you can see what the UI looks like.DocumentationSearch — Semantic search across Apple's developer documentation and WWDC session transcripts. Powered by on-device ML embeddings, so results are high quality. This is the only tool that does NOT require a tabIdentifier. Use it to look up APIs, find usage examples, or understand frameworks.The most common pattern when developing Apple platform code:
XcodeListWindows → save the tabIdentifierXcodeUpdate for targeted changes or XcodeWrite for new filesBuildProject to compileGetBuildLog filtered to errors. Read the diagnostics.RunAllTests or RunSomeTests to verify behaviorRenderPreview to see the visual outputThis loop is fast — incremental builds are typically under a second, so you can iterate quickly.
| Task | Use Xcode MCP | Use Claude Native |
|---|---|---|
| Edit Swift files in the project | XcodeUpdate (Xcode tracks the change) | Edit works too, but Xcode won't see changes until it re-indexes |
| Read a config file | Either works | Read is simpler |
| Build the project | BuildProject | N/A |
| Search for an API | DocumentationSearch | Web search |
| Find files by pattern | XcodeGlob | Glob |
| Run tests | RunAllTests / RunSomeTests | Bash with xcodebuild test (slower, less integrated) |
The general rule: use Xcode MCP tools when you want Xcode to be aware of the change (for builds, diagnostics, previews) or when you need Xcode-specific capabilities (documentation search, SwiftUI preview rendering, build system). Use Claude's native tools for quick reads or edits where Xcode awareness isn't important.
XcodeRefreshCodeIssuesInFile after editing to get real-time feedback before building.DocumentationSearch doesn't need a tabIdentifier and is great for quickly looking up API signatures, parameter types, or framework capabilities. Use it liberally when you're unsure about an API.GetTestList to find test identifiers, then RunSomeTests to run only relevant tests instead of the full suite.RenderPreview to see the result visually. This is much faster than building and running on a simulator.