Xcode MCP Server: Connect AI to Apple App Development

An Xcode MCP server connects an AI coding assistant to your Xcode project, giving it access to build results, test output, simulator logs, and project metadata through standard tool calls. Instead of copying error messages from Xcode into the chat, the assistant can read them directly and propose targeted fixes. Tools like fenbs keep the architectural decisions and where-we-left-off notes that travel with the project, so switching between coding assistants does not mean starting the context from scratch.

Xcode MCP servers are community-built and use xcodebuild, the Xcode command-line tool, and the Simulator runtime. Check the MCP server directory for available packages. The server must run on a Mac with Xcode and the command-line tools installed.

Connect an AI assistant to Xcode

1. Install Xcode command-line tools if you have not already: xcode-select --install. The MCP server uses xcodebuild and xcrun simctl, which are part of the command-line tools.
2. Install the Xcode MCP server package. Follow the package's setup instructions; most use npm or Python.
3. Add the server to your AI client's MCP config with the path to your Xcode project or workspace file as a parameter. See MCP server configuration for the config format.
4. Restart the AI client and ask the assistant to list the available schemes in your project as a first check. Verify the scheme names match what you see in Xcode.
5. Run a build through the AI and compare the result to a direct xcodebuild run. Make sure errors and warnings are reported correctly before using the connection for real work.

What the AI can do with Xcode

An Xcode MCP server can expose build operations (build, clean, archive), test runs, simulator management (boot, install, launch), device log streaming, and scheme and target listing. The exact set of operations depends on what the server chooses to implement.

The most common use cases are reading build errors and test failures directly, so the AI can analyze them without you copying and pasting, and triggering builds as part of a larger coding session. Archive and submission operations should require explicit human confirmation before proceeding.

Access boundaries and verification

An Xcode MCP server runs with your user account's permissions on your Mac. It can read and modify files in your project directory, run builds, and control simulators. Make sure you understand what write operations the server exposes and whether it requires any confirmation before making changes.

For any operation that changes code, creates a build artifact for distribution, or submits to the App Store, require explicit human approval. Document that requirement as a rule in your project context so every assistant session knows the boundary.

Keep development decisions available when switching tools

Apple development decisions accumulate: which deployment target to support, whether to use SwiftUI or UIKit for a given component, the current approach to dependency management, the test coverage requirement for a module, what was tried and failed. Without a shared record, each coding assistant starts from what it can read in the code, which is less than what is in the team's heads.

fenbs keeps those decisions and handoff notes in a project that any connected coding assistant can read. When you switch from one AI tool to another — say, from a general assistant to a specialized coding tool — both read the same decisions and the same note about where the last session left off.

Running tests through an Xcode MCP server requires a booted simulator before the test run begins. If the AI client starts a test without a booted simulator, Xcode will boot one automatically, which adds startup time and can time out if the session has a short timeout. Ask the server to boot a specific simulator first, specifying the device model and the iOS version, and wait for it to reach the booted state before triggering the test run. The xcrun simctl list devices command shows the current state of all available simulators. For sessions that test across multiple iOS versions, treat the simulator state as something to check explicitly rather than assume, since a previous session may have left a different simulator booted. Record the target simulator name and iOS version as a rule in the project context so the assistant always boots the correct device without needing to ask at the start of each session.

How to do this with fenbs

1. Create a free account and add a project for the iOS or macOS app.
2. Record key architecture decisions as Decisions and rules: deployment target, UI framework choices, testing conventions, and operations that require human sign-off.
3. Add the current in-progress tasks to the board. Note which features are in development, what is blocked, and what is waiting for a design decision.
4. Connect your coding assistant to fenbs at Integrations. It reads the decisions and task status before starting any work.
5. Before switching to a different AI tool or ending a session, save progress: what was built, what was tested, what the next session should start with.

fenbs does not connect to Xcode directly. It holds the project decisions and task status; the Xcode MCP server handles the live build and simulator interactions.