Deux serveurs MCP ont transformé Claude Code en système de build iOS

Je développe 11 applications iOS avec Claude Code. J’ai des hooks qui protègent la sécurité de mon Git, des règles qui imposent la qualité du code, et des définitions d’agents qui encodent les pratiques de mon équipe. Mais jusqu’à hier, chaque erreur de compilation impliquait de copier la sortie du terminal, de la coller en retour, et d’espérer que l’agent comprenne le contexte. La gestion du simulateur se faisait par des commandes xcrun simctl brutes. Les résultats de tests arrivaient sous forme de murs de texte non structurés.

Deux commandes claude mcp add ont changé la donne.

TL;DR

XcodeBuildMCP (76 outils, open source) gère les compilations, les tests, les simulateurs, le déploiement sur appareils réels et le débogage LLDB — le tout sans lancer Xcode. Le MCP Xcode natif d’Apple (20 outils, intégré à Xcode 26.3) se connecte directement à un processus Xcode en cours d’exécution pour les opérations sur les fichiers, les diagnostics en temps réel, la recherche dans la documentation, le REPL Swift et les aperçus SwiftUI. Ensemble, ils donnent à Claude Code un accès programmatique complet à la chaîne d’outils de développement iOS — du JSON structuré au lieu de l’analyse de logs, des appels d’outils au lieu de commandes shell. L’installation prend moins de 2 minutes.

Le problème

Claude Code excelle dans la lecture et l’écriture de Swift. Il comprend les patterns SwiftUI, les relations SwiftData et la concurrence Swift 6. Mais il était aveugle au système de compilation.

Quand une compilation échouait, l’agent devait :

1. Exécuter xcodebuild via Bash
2. Analyser des milliers de lignes de sortie non structurée
3. Espérer trouver l’erreur réelle parmi le bruit
4. Deviner quel fichier et quelle ligne avaient causé l’échec

Quand je voulais lancer des tests :

1. L’agent construisait la commande complète xcodebuild test de mémoire
2. Analysait le bundle xcresult (ou plus probablement, la sortie brute stdout)
3. Essayait de déterminer quels tests avaient réussi et lesquels avaient échoué

C’est l’équivalent de demander à un développeur d’écrire du code en lisant la sortie du compilateur à travers le trou d’une serrure. L’information était techniquement là, mais l’interface était inadaptée.

La solution : deux serveurs MCP complémentaires

XcodeBuildMCP (communautaire, open source)

XcodeBuildMCP encapsule xcodebuild et les outils associés en 76 outils MCP structurés. L’agent appelle xcode_build et reçoit du JSON avec des erreurs catégorisées, des avertissements et des emplacements de fichiers — pas un log de compilation de 3 000 lignes.

Outils principaux :

Installation :

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

Le flag -s user le rend global — disponible dans chaque projet sans configuration par projet. La variable d’environnement désactive la télémétrie (le comportement par défaut envoie des rapports de crash à Sentry ; je préfère ne pas y participer).¹

Apple Xcode MCP (natif, intégré à Xcode 26.3)

Apple a livré son propre serveur MCP dans Xcode 26.3 via xcrun mcpbridge. Il expose 20 outils qui se connectent directement au processus Xcode via XPC :

Installation :

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

Nécessite Xcode 26.3+ (actuellement en Release Candidate, disponible prochainement).

Pourquoi les deux ?

Ils se chevauchent sur les compilations et les tests, mais l’architecture diffère :

• XcodeBuildMCP fonctionne de manière autonome via le CLI xcodebuild — aucun processus Xcode n’est requis. Il ajoute 76 outils couvrant les simulateurs, les appareils réels, le débogage LLDB, l’automatisation UI et l’échafaudage de projets. Idéal pour les workflows headless et le développement proche de la CI.
• Apple Xcode MCP nécessite une instance Xcode en cours d’exécution et communique via XPC. Il fournit des opérations sur les fichiers dans le contexte du projet Xcode, des diagnostics de code en temps réel (pas seulement la sortie de compilation), et une recherche native dans la documentation incluant les sessions WWDC.

J’utilise les deux : XcodeBuildMCP pour le cycle compilation-test-débogage (il fonctionne sans ouvrir Xcode), et le MCP d’Apple quand j’ai besoin de recherches dans la documentation, de vérification via le REPL Swift, ou du rendu d’aperçus SwiftUI.

Le test en conditions réelles

J’ai lancé un bilan de santé complet sur mon application Water (SwiftUI + simulation de fluide Metal + HealthKit) avec ce prompt :

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)

Ce qui s’est passé

La configuration du simulateur a utilisé list_sims, session_set_defaults et boot_sim. L’agent a découvert qu’aucun iPhone 16 Pro n’existait dans le runtime iOS 26 (il avait été retiré), et a donc automatiquement basculé sur l’iPhone 17 Pro. C’est exactement le type de comportement adaptatif qui ne fonctionne pas avec des commandes xcodebuild codées en dur.

La compilation a initialement échoué — la Metal Toolchain n’avait pas été téléchargée sur la nouvelle installation Xcode. L’agent l’a détecté grâce à la sortie d’erreur structurée et a exécuté xcodebuild -downloadComponent MetalToolchain pour corriger le problème. La compilation a ensuite réussi avec 3 avertissements :

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

La sortie structurée signifiait que ces éléments revenaient sous forme d’avertissements catégorisés avec des références fichier:ligne exactes, et non enfouis dans un log.

Les tests ont échoué — mais l’échec était informatif. La sortie structurée a montré que 5 méthodes de test référençaient injectTapRipple(atNormalizedX:), une méthode que j’avais supprimée dans un commit précédent. L’agent a identifié le commit exact (7657068 — "remove tap ripple interaction entirely") et a listé les tests à mettre à jour. Zéro ambiguïté.

La recherche dans la documentation et le REPL Swift ont confirmé que HKQuantityType(.dietaryWater) est valide, retournant l’identifiant HKQuantityTypeIdentifierDietaryWater.

Le tableau des résultats

L’ensemble du bilan de santé s’est exécuté de manière autonome. Je n’ai pas ouvert Xcode, je n’ai copié aucun message d’erreur, je n’ai construit aucune commande xcodebuild.

Former l’agent

Installer des serveurs MCP ne suffit pas. L’agent doit savoir que les outils existent et quand les préférer aux commandes shell brutes. J’ai mis à jour ma définition d’agent ios-developer pour inclure des consignes explicites :

## 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.

Sans cela, l’agent retombera parfois sur xcodebuild via Bash ou utilisera WebSearch pour la documentation Apple au lieu de la recherche native. La définition d’agent comble cette lacune.²

Ce qui change en pratique

Avant MCP, mon workflow iOS avec Claude Code était :

1. Écrire du code avec Claude
2. Compiler manuellement dans Xcode (ou via xcodebuild dans le terminal)
3. Recopier les erreurs vers Claude
4. Recommencer

Après MCP :

1. Décrire ce que je veux
2. Claude écrit le code, le compile, lit les erreurs, les corrige, lance les tests et vérifie le comportement de l’API
3. Je révise le résultat final

La boucle compilation-erreur-correction qui nécessitait autrefois ma participation active se déroule désormais de manière autonome. L’agent ne devine pas ce qui a mal tourné à partir de texte brut — il lit des données structurées qui lui indiquent exactement ce qui a échoué, où et pourquoi.

C’est le schéma que j’observe sans cesse dans l’outillage IA : la percée ne consiste pas à rendre l’IA plus intelligente, mais à lui donner un accès structuré aux outils que les développeurs utilisent déjà. MCP est le protocole qui rend cela possible — tout comme les hooks ont donné à Claude Code des garde-fous déterministes, MCP lui fournit des interfaces d’outils déterministes. Xcode n’est pas le premier et ne sera pas le dernier outil de développement à s’exposer via MCP.³

Liste de vérification pour l’installation

Pour tous ceux qui utilisent Claude Code avec des projets iOS :

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

2. Installer Apple Xcode MCP (nécessite Xcode 26.3+) : bash claude mcp add --transport stdio xcode \ -s user -- xcrun mcpbridge

3. Vérifier que les deux sont connectés : bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Mettre à jour vos définitions d’agents pour référencer les nouveaux outils (sinon l’agent retombera parfois sur des commandes shell).

5. Démarrer une nouvelle session Claude Code — les outils MCP enregistrés en cours de session n’apparaîtront pas dans la recherche d’outils avant un redémarrage.

C’est tout. Deux commandes, un accès complet au système de build iOS.

FAQ

Ai-je toujours besoin d’avoir Xcode installé ?

Oui. Les deux serveurs MCP sont des enveloppes autour de la chaîne d’outils Xcode (xcodebuild, xcrun, simctl). Xcode doit être installé et configuré. Les serveurs MCP donnent à Claude Code un accès structuré à ces outils — ils ne les remplacent pas.

XcodeBuildMCP fonctionne-t-il avec les projets SwiftPM uniquement ?

Oui. XcodeBuildMCP prend en charge à la fois les projets .xcodeproj/.xcworkspace et les projets Swift Package Manager. Utilisez discover_projs pour trouver les types de projets disponibles, puis build_sim ou build_device avec le scheme approprié.

Qu’en est-il des pipelines CI/CD ?

Les serveurs MCP s’exécutent localement avec Claude Code. Pour la CI/CD, vous continueriez à utiliser xcodebuild directement ou des outils comme Fastlane. L’approche MCP est spécifiquement conçue pour la boucle de développement interactive où un agent IA a besoin de retours structurés pendant le cycle écriture-compilation-test.