Zwei MCP-Server verwandelten Claude Code in ein iOS-Build-System

Ich entwickle 11 iOS-Apps mit Claude Code. Ich habe Hooks, die meine Git-Sicherheit schützen, Regeln, die Code-Qualität durchsetzen, und Agent-Definitionen, die die Muster meines Teams kodieren. Aber bis gestern bedeutete jeder Build-Fehler, Terminal-Ausgaben zu kopieren, sie zurückzufügen und zu hoffen, dass der Agent den Kontext versteht. Simulator-Verwaltung bestand aus rohen xcrun simctl-Befehlen. Testergebnisse kamen als unstrukturierte Textwände.

Zwei claude mcp add-Befehle haben das geändert.

TL;DR

XcodeBuildMCP (76 Tools, Open Source) übernimmt Builds, Tests, Simulatoren, Deployment auf echten Geräten und LLDB-Debugging — alles ohne laufendes Xcode. Apples natives Xcode MCP (20 Tools, wird mit Xcode 26.3 ausgeliefert) verbindet sich über XPC mit einem laufenden Xcode-Prozess für Dateioperationen, Echtzeit-Diagnosen, Dokumentationssuche, Swift REPL und SwiftUI-Vorschauen. Zusammen geben sie Claude Code vollen programmatischen Zugriff auf die iOS-Entwicklungs-Toolchain — strukturiertes JSON statt Log-Parsing, Tool-Aufrufe statt Shell-Befehle. Die Einrichtung dauert weniger als 2 Minuten.

Die Lücke

Claude Code ist hervorragend im Lesen und Schreiben von Swift. Es versteht SwiftUI-Muster, SwiftData-Beziehungen und Swift-6-Nebenläufigkeit. Aber es war blind für das Build-System.

Wenn ein Build fehlschlug, musste der Agent:

1. xcodebuild über Bash ausführen
2. Tausende Zeilen unstrukturierter Ausgabe parsen
3. Hoffen, den eigentlichen Fehler im Rauschen zu finden
4. Raten, welche Datei und Zeile den Fehler verursachte

Wenn ich Tests ausführen wollte:

1. Agent konstruiert den vollständigen xcodebuild test-Befehl aus dem Gedächtnis
2. Das xcresult-Bundle parsen (oder wahrscheinlicher die rohe stdout-Ausgabe)
3. Versuchen herauszufinden, welche Tests bestanden und welche fehlgeschlagen sind

Das ist das Äquivalent dazu, einen Entwickler zu bitten, Code zu schreiben, indem er Compiler-Ausgaben durch ein Schlüsselloch liest. Die Informationen waren technisch vorhanden, aber die Schnittstelle war falsch.

Die Lösung: Zwei komplementäre MCP-Server

XcodeBuildMCP (Community, Open Source)

XcodeBuildMCP verpackt xcodebuild und verwandte Tools in 76 strukturierte MCP-Tools. Der Agent ruft xcode_build auf und erhält JSON mit kategorisierten Fehlern, Warnungen und Dateipositionen zurück — kein 3.000 Zeilen langes Build-Log.

Wichtige Tools:

Installation:

claude mcp add XcodeBuildMCP \
  -s user \
  -e XCODEBUILDMCP_SENTRY_DISABLED=true \
  -- npx -y xcodebuildmcp@latest mcp

Das -s user-Flag macht es global — in jedem Projekt verfügbar ohne projektspezifische Konfiguration. Die Umgebungsvariable deaktiviert die Telemetrie (standardmäßig werden Absturzberichte an Sentry gesendet; ich ziehe es vor, das abzulehnen).¹

Apple Xcode MCP (Nativ, wird mit Xcode 26.3 ausgeliefert)

Apple hat seinen eigenen MCP-Server in Xcode 26.3 über xcrun mcpbridge ausgeliefert. Er stellt 20 Tools bereit, die sich über XPC direkt mit dem Xcode-Prozess verbinden:

Installation:

claude mcp add --transport stdio xcode -s user -- xcrun mcpbridge

Erfordert Xcode 26.3+ (derzeit Release Candidate, erscheint bald).

Warum beide?

Sie überschneiden sich bei Builds und Tests, aber die Architektur unterscheidet sich:

• XcodeBuildMCP arbeitet eigenständig über die xcodebuild CLI — kein Xcode-Prozess erforderlich. Es bietet 76 Tools für Simulatoren, echte Geräte, LLDB-Debugging, UI-Automatisierung und Projekt-Scaffolding. Ideal für Headless-Workflows und CI-nahe Entwicklung.
• Apple Xcode MCP erfordert eine laufende Xcode-Instanz und kommuniziert über XPC. Es bietet Dateioperationen im Xcode-Projektkontext, Echtzeit-Code-Diagnosen (nicht nur Build-Ausgaben) und native Dokumentationssuche einschließlich WWDC-Sessions.

Ich verwende beide: XcodeBuildMCP für den Build-Test-Debug-Zyklus (es funktioniert ohne geöffnetes Xcode) und Apples MCP, wenn ich Dokumentationssuchen, Swift-REPL-Verifikation oder SwiftUI-Vorschau-Rendering benötige.

Der Praxistest

Ich führte einen vollständigen Gesundheitscheck meiner Water-App (SwiftUI + Metal-Fluidsimulation + HealthKit) mit diesem Prompt durch:

Use the XcodeBuildMCP and Apple Xcode MCP tools to do a full
health check of this project:

1. List available simulators and boot an iPhone 16 Pro
2. Build the project for that simulator
3. Run existing tests and report pass/fail results
4. Search Apple docs for "HealthKit water intake"
5. Use the Swift REPL to verify HKQuantityType(.dietaryWater)

Was passierte

Simulator-Einrichtung verwendete list_sims, session_set_defaults und boot_sim. Der Agent stellte fest, dass kein iPhone 16 Pro in der iOS-26-Laufzeitumgebung existiert (es wurde eingestellt), und wechselte daher automatisch zum iPhone 17 Pro. Das ist genau die Art von adaptivem Verhalten, die bei fest kodierten xcodebuild-Befehlen nicht funktioniert.

Build schlug zunächst fehl — die Metal Toolchain war bei der neuen Xcode-Installation nicht heruntergeladen. Der Agent erkannte dies aus der strukturierten Fehlerausgabe und führte xcodebuild -downloadComponent MetalToolchain aus, um das Problem zu beheben. Der Build war dann mit 3 Warnungen erfolgreich:

HomeView.swift:132    UIScreen.main deprecated in iOS 26.0
LogWaterIntent.swift:61   Result of try? is unused

Strukturierte Ausgabe bedeutete, dass diese als kategorisierte Warnungen mit exakten Datei:Zeile-Referenzen zurückkamen, nicht irgendwo in einem Log vergraben.

Tests schlugen fehl — aber der Fehler war informativ. Die strukturierte Ausgabe zeigte, dass 5 Testmethoden injectTapRipple(atNormalizedX:) referenzierten, eine Methode, die ich in einem früheren Commit entfernt hatte. Der Agent identifizierte den exakten Commit (7657068 — "remove tap ripple interaction entirely") und listete auf, welche Tests aktualisiert werden mussten. Null Mehrdeutigkeit.

Dokumentationssuche und Swift REPL bestätigten, dass HKQuantityType(.dietaryWater) gültig ist und den Identifier HKQuantityTypeIdentifierDietaryWater zurückgibt.

Die Ergebnistabelle

Der gesamte Gesundheitscheck lief autonom. Ich habe Xcode nicht geöffnet, keine Fehlermeldungen kopiert, keine xcodebuild-Befehle konstruiert.

Den Agent anleiten

MCP-Server zu installieren reicht nicht aus. Der Agent muss wissen, dass die Tools existieren und wann er sie gegenüber rohen Shell-Befehlen bevorzugen soll. Ich habe meine ios-developer-Agent-Definition aktualisiert, um explizite Anleitungen aufzunehmen:

## Build & Test Tools (XcodeBuildMCP)

Prefer MCP tools over raw xcodebuild commands:

- **Build**: Use `build_sim` / `build_device` for structured errors
- **Test**: Use `test_sim` / `test_device` for pass/fail results
- **Simulators**: Use `list_sims`, `boot_sim`, `open_sim`
- **Debug**: Use `debug_attach_sim`, `debug_stack`, `debug_variables`

## Apple Xcode MCP (mcpbridge)

- **Documentation**: Use `DocumentationSearch` for Apple docs
- **Swift REPL**: Use `ExecuteSnippet` for API verification
- **Previews**: Use `RenderPreview` for headless SwiftUI rendering

Prefer these over WebSearch for Apple API questions
and over Bash `swift` for REPL tasks.

Ohne diese Anleitung fällt der Agent manchmal auf xcodebuild über Bash zurück oder verwendet WebSearch für Apple-Dokumentation anstatt der nativen Suche. Die Agent-Definition schließt diese Lücke.²

Was sich in der Praxis ändert

Vor MCP sah mein iOS-Workflow mit Claude Code so aus:

1. Code mit Claude schreiben
2. Manuell in Xcode bauen (oder über xcodebuild im Terminal)
3. Fehler zurück zu Claude kopieren
4. Wiederholen

Nach MCP:

1. Beschreiben, was ich möchte
2. Claude schreibt den Code, baut ihn, liest die Fehler, behebt sie, führt Tests aus und verifiziert das API-Verhalten
3. Ich überprüfe das Endergebnis

Die Build-Fehler-Behebungs-Schleife, die früher meine aktive Beteiligung erforderte, läuft jetzt autonom ab. Der Agent rät nicht anhand von Rohtext, was schiefgegangen ist — er liest strukturierte Daten, die ihm genau sagen, was fehlgeschlagen ist, wo und warum.

Das ist das Muster, das ich bei KI-Werkzeugen immer wieder sehe: Der Durchbruch besteht nicht darin, die KI schlauer zu machen, sondern ihr strukturierten Zugriff auf die Tools zu geben, die Entwickler bereits nutzen. MCP ist das Protokoll, das dies ermöglicht — genau wie Hooks Claude Code deterministische Leitplanken gaben, gibt MCP ihm deterministische Tool-Schnittstellen. Xcode ist nicht das erste und wird nicht das letzte Entwicklungstool sein, das sich über MCP zugänglich macht.³

Einrichtungs-Checkliste

Für alle, die Claude Code mit iOS-Projekten verwenden:

1. XcodeBuildMCP installieren (erfordert Xcode 26.3+): bash claude mcp add XcodeBuildMCP -s user \ -e XCODEBUILDMCP_SENTRY_DISABLED=true \ -- npx -y xcodebuildmcp@latest mcp

2. Apple Xcode MCP installieren (erfordert Xcode 26.3+): bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. Überprüfen, dass beide verbunden sind: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Agent-Definitionen aktualisieren, um die neuen Tools zu referenzieren (andernfalls fällt der Agent manchmal auf Shell-Befehle zurück).

5. Eine neue Claude-Code-Sitzung starten — MCP-Tools, die während einer Sitzung registriert werden, erscheinen erst nach einem Neustart in der Tool-Suche.

Das ist alles. Zwei Befehle, voller Zugriff auf das iOS-Build-System.

FAQ

Brauche ich Xcode trotzdem noch?

Ja. Beide MCP-Server sind Wrapper um Xcodes Toolchain (xcodebuild, xcrun, simctl). Xcode muss installiert und konfiguriert sein. Die MCP-Server geben Claude Code strukturierten Zugriff auf diese Tools — sie ersetzen sie nicht.

Funktioniert XcodeBuildMCP mit reinen SwiftPM-Projekten?

Ja. XcodeBuildMCP unterstützt sowohl .xcodeproj/.xcworkspace als auch Swift Package Manager-Projekte. Verwenden Sie discover_projs, um verfügbare Projekttypen zu finden, dann build_sim oder build_device mit dem entsprechenden Scheme.

Was ist mit CI/CD-Pipelines?

MCP-Server laufen lokal mit Claude Code. Für CI/CD würden Sie weiterhin xcodebuild direkt oder Tools wie Fastlane verwenden. Der MCP-Ansatz ist speziell für die interaktive Entwicklungsschleife gedacht, in der ein KI-Agent strukturiertes Feedback während des Code-Build-Test-Zyklus benötigt.