Dos servidores MCP convirtieron Claude Code en un sistema de compilación para iOS

Desarrollo 11 aplicaciones iOS con Claude Code. Tengo hooks que protegen la seguridad de mi git, reglas que garantizan la calidad del código y definiciones de agentes que codifican los patrones de mi equipo. Pero hasta ayer, cada error de compilación significaba copiar la salida del terminal, pegarla de vuelta y esperar que el agente entendiera el contexto. La gestión del simulador eran comandos xcrun simctl sin procesar. Los resultados de las pruebas llegaban como muros de texto sin estructura.

Dos comandos claude mcp add cambiaron eso.

TL;DR

XcodeBuildMCP (76 herramientas, código abierto) maneja compilaciones, pruebas, simuladores, despliegue en dispositivos reales y depuración LLDB — todo sin necesidad de tener Xcode abierto. El MCP nativo de Apple para Xcode (20 herramientas, incluido con Xcode 26.3) se conecta directamente a un proceso de Xcode en ejecución para operaciones de archivos, diagnósticos en tiempo real, búsqueda de documentación, Swift REPL y previsualizaciones de SwiftUI. Juntos le dan a Claude Code acceso programático completo a la cadena de herramientas de desarrollo iOS — JSON estructurado en lugar de parsear logs, llamadas a herramientas en lugar de comandos de shell. La configuración toma menos de 2 minutos.

La brecha

Claude Code es excepcional leyendo y escribiendo Swift. Entiende patrones de SwiftUI, relaciones de SwiftData y concurrencia de Swift 6. Pero estaba ciego ante el sistema de compilación.

Cuando una compilación fallaba, el agente tenía que:

1. Ejecutar xcodebuild a través de Bash
2. Parsear miles de líneas de salida sin estructura
3. Esperar encontrar el error real entre el ruido
4. Adivinar qué archivo y línea causaron el fallo

Cuando quería ejecutar pruebas:

1. El agente construye el comando completo de xcodebuild test de memoria
2. Parsear el bundle xcresult (o más probablemente, la salida cruda de stdout)
3. Intentar determinar qué pruebas pasaron y cuáles fallaron

Esto es el equivalente a pedirle a un desarrollador que escriba código leyendo la salida del compilador a través de una cerradura. La información técnicamente estaba ahí, pero la interfaz era incorrecta.

La solución: dos servidores MCP complementarios

XcodeBuildMCP (comunidad, código abierto)

XcodeBuildMCP envuelve xcodebuild y herramientas relacionadas en 76 herramientas MCP estructuradas. El agente llama a xcode_build y recibe JSON con errores categorizados, advertencias y ubicaciones de archivos — no un log de compilación de 3.000 líneas.

Herramientas clave:

Instalación:

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

La bandera -s user lo hace global — disponible en cada proyecto sin configuración por proyecto. La variable de entorno desactiva la telemetría (por defecto envía informes de errores a Sentry; prefiero no participar).¹

Apple Xcode MCP (nativo, incluido con Xcode 26.3)

Apple incluyó su propio servidor MCP en Xcode 26.3 a través de xcrun mcpbridge. Expone 20 herramientas que se conectan directamente al proceso de Xcode mediante XPC:

Instalación:

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

Requiere Xcode 26.3+ (actualmente Release Candidate, próximo a lanzarse).

¿Por qué ambos?

Se superponen en compilaciones y pruebas, pero la arquitectura difiere:

• XcodeBuildMCP funciona de forma independiente a través del CLI xcodebuild — no requiere un proceso de Xcode. Agrega 76 herramientas que cubren simuladores, dispositivos reales, depuración LLDB, automatización de UI y creación de proyectos. Ideal para flujos de trabajo sin interfaz gráfica y desarrollo adyacente a CI.
• Apple Xcode MCP requiere una instancia de Xcode en ejecución y se comunica mediante XPC. Proporciona operaciones de archivos dentro del contexto del proyecto de Xcode, diagnósticos de código en tiempo real (no solo la salida de compilación) y búsqueda nativa de documentación incluyendo sesiones de WWDC.

Uso ambos: XcodeBuildMCP para el ciclo de compilar-probar-depurar (funciona sin tener Xcode abierto), y el MCP de Apple cuando necesito consultas de documentación, verificación con Swift REPL o renderizado de previsualizaciones de SwiftUI.

La prueba en el mundo real

Ejecuté una verificación completa de salud en mi aplicación Water (SwiftUI + simulación de fluidos con Metal + HealthKit) usando este 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)

Qué sucedió

La configuración del simulador utilizó list_sims, session_set_defaults y boot_sim. El agente descubrió que no existe un iPhone 16 Pro en el runtime de iOS 26 (fue retirado), así que automáticamente cambió al iPhone 17 Pro. Este es el tipo de comportamiento adaptativo que se rompe con comandos xcodebuild escritos de forma fija.

La compilación falló inicialmente — el Metal Toolchain no estaba descargado en la nueva instalación de Xcode. El agente detectó esto a partir de la salida de errores estructurada y ejecutó xcodebuild -downloadComponent MetalToolchain para corregirlo. La compilación luego tuvo éxito con 3 advertencias:

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

La salida estructurada significó que estas advertencias regresaron categorizadas con referencias exactas de archivo:línea, no enterradas en un log.

Las pruebas fallaron — pero el fallo fue informativo. La salida estructurada mostró que 5 métodos de prueba referenciaban injectTapRipple(atNormalizedX:), un método que eliminé en un commit anterior. El agente identificó el commit exacto (7657068 — "remove tap ripple interaction entirely") y listó qué pruebas necesitaban actualización. Cero ambigüedad.

La búsqueda de documentación y Swift REPL confirmaron que HKQuantityType(.dietaryWater) es válido, devolviendo el identificador HKQuantityTypeIdentifierDietaryWater.

La tabla de resultados

La verificación completa de salud se ejecutó de forma autónoma. No abrí Xcode, no copié ningún mensaje de error, no construí ningún comando xcodebuild.

Enseñando al agente

Instalar servidores MCP no es suficiente. El agente necesita saber que las herramientas existen y cuándo preferirlas sobre comandos de shell sin procesar. Actualicé la definición de mi agente ios-developer para incluir orientación explícita:

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

Sin esto, el agente a veces recurrirá a xcodebuild a través de Bash o usará WebSearch para documentación de Apple en lugar de la búsqueda nativa. La definición del agente cierra esa brecha.²

Qué cambia en la práctica

Antes de MCP, mi flujo de trabajo iOS con Claude Code era:

1. Escribir código con Claude
2. Compilar manualmente en Xcode (o a través de xcodebuild en la terminal)
3. Copiar los errores de vuelta a Claude
4. Repetir

Después de MCP:

1. Describir lo que quiero
2. Claude escribe el código, lo compila, lee los errores, los corrige, ejecuta las pruebas y verifica el comportamiento de la API
3. Reviso el resultado final

El ciclo de compilar-error-corregir que antes requería mi participación activa ahora ocurre de forma autónoma. El agente no está adivinando qué salió mal a partir de texto sin procesar — lee datos estructurados que le indican exactamente qué falló, dónde y por qué.

Este es el patrón que sigo viendo en las herramientas de IA: el avance no consiste en hacer la IA más inteligente, sino en darle acceso estructurado a las herramientas que los desarrolladores ya usan. MCP es el protocolo que hace esto posible — al igual que los hooks le dieron a Claude Code protecciones determinísticas, MCP le proporciona interfaces de herramientas determinísticas. Xcode no es la primera y no será la última herramienta de desarrollo en exponerse a través de MCP.³

Lista de verificación de configuración

Para cualquier persona que use Claude Code con proyectos iOS:

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

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

3. Verificar que ambos estén conectados: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Actualizar las definiciones de agentes para referenciar las nuevas herramientas (o el agente a veces recurrirá a comandos de shell).

5. Iniciar una nueva sesión de Claude Code — las herramientas MCP registradas durante una sesión no aparecerán en la búsqueda de herramientas hasta reiniciar.

Eso es todo. Dos comandos, acceso completo al sistema de compilación iOS.

FAQ

¿Todavía necesito tener Xcode instalado?

Sí. Ambos servidores MCP son envoltorios alrededor de la cadena de herramientas de Xcode (xcodebuild, xcrun, simctl). Xcode debe estar instalado y configurado. Los servidores MCP le dan a Claude Code acceso estructurado a estas herramientas — no las reemplazan.

¿Funciona XcodeBuildMCP con proyectos exclusivos de SwiftPM?

Sí. XcodeBuildMCP soporta tanto proyectos .xcodeproj/.xcworkspace como proyectos de Swift Package Manager. Use discover_projs para encontrar los tipos de proyecto disponibles, luego build_sim o build_device con el scheme correspondiente.

¿Qué hay de los pipelines de CI/CD?

Los servidores MCP se ejecutan localmente con Claude Code. Para CI/CD, continuaría usando xcodebuild directamente o herramientas como Fastlane. El enfoque MCP es específicamente para el ciclo de desarrollo interactivo donde un agente de IA necesita retroalimentación estructurada durante el ciclo de código-compilación-pruebas.