Dois servidores MCP transformaram o Claude Code em um sistema de build iOS

Eu desenvolvo 11 apps iOS com Claude Code. Tenho hooks que protegem minha segurança no Git, regras que garantem qualidade de código e definições de agentes que codificam os padrões da minha equipe. Mas até ontem, cada erro de build significava copiar a saída do terminal, colar de volta e torcer para o agente entender o contexto. O gerenciamento de simuladores era feito com comandos brutos de xcrun simctl. Os resultados de testes vinham como paredes de texto sem estrutura.

Dois comandos claude mcp add mudaram isso.

Resumo

XcodeBuildMCP (76 ferramentas, código aberto) gerencia builds, testes, simuladores, deploy em dispositivos reais e depuração LLDB — tudo sem precisar abrir o Xcode. O Xcode MCP nativo da Apple (20 ferramentas, incluído no Xcode 26.3) se conecta diretamente a um processo do Xcode em execução para operações de arquivo, diagnósticos em tempo real, busca de documentação, Swift REPL e previews de SwiftUI. Juntos, eles dão ao Claude Code acesso programático completo à toolchain de desenvolvimento iOS — JSON estruturado em vez de parsing de logs, chamadas de ferramentas em vez de comandos shell. A configuração leva menos de 2 minutos.

A lacuna

O Claude Code é excepcional em ler e escrever Swift. Ele entende padrões de SwiftUI, relacionamentos de SwiftData e concorrência do Swift 6. Mas era cego para o sistema de build.

Quando um build falhava, o agente precisava:

1. Executar xcodebuild via Bash
2. Fazer parsing de milhares de linhas de saída sem estrutura
3. Torcer para encontrar o erro real em meio ao ruído
4. Adivinhar qual arquivo e linha causaram a falha

Quando eu queria rodar testes:

1. O agente constrói o comando completo de xcodebuild test de memória
2. Faz parsing do bundle xcresult (ou, mais provavelmente, do stdout bruto)
3. Tenta descobrir quais testes passaram e quais falharam

Isso é o equivalente a pedir para um desenvolvedor escrever código lendo a saída do compilador por um buraco de fechadura. A informação estava tecnicamente lá, mas a interface estava errada.

A solução: dois servidores MCP complementares

XcodeBuildMCP (comunidade, código aberto)

O XcodeBuildMCP encapsula o xcodebuild e ferramentas relacionadas em 76 ferramentas MCP estruturadas. O agente chama xcode_build e recebe JSON com erros categorizados, avisos e localizações de arquivos — não um log de build de 3.000 linhas.

Ferramentas principais:

Instalação:

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

A flag -s user torna a configuração global — disponível em todos os projetos sem configuração individual. A variável de ambiente desabilita a telemetria (o padrão envia relatórios de crash para o Sentry; eu prefiro não participar).¹

Apple Xcode MCP (nativo, incluído no Xcode 26.3)

A Apple lançou seu próprio servidor MCP no Xcode 26.3 via xcrun mcpbridge. Ele expõe 20 ferramentas que se conectam diretamente ao processo do Xcode via XPC:

Instalação:

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

Requer Xcode 26.3+ (atualmente Release Candidate, lançamento em breve).

Por que os dois?

Eles se sobrepõem em builds e testes, mas a arquitetura é diferente:

• XcodeBuildMCP funciona de forma independente via CLI xcodebuild — nenhum processo do Xcode é necessário. Ele adiciona 76 ferramentas cobrindo simuladores, dispositivos reais, depuração LLDB, automação de UI e scaffolding de projetos. Ideal para fluxos de trabalho headless e desenvolvimento próximo ao CI.
• Apple Xcode MCP requer uma instância do Xcode em execução e se comunica via XPC. Ele fornece operações de arquivo dentro do contexto do projeto Xcode, diagnósticos de código em tempo real (não apenas saída de build) e busca nativa de documentação incluindo sessões da WWDC.

Eu uso os dois: XcodeBuildMCP para o ciclo de build-teste-depuração (funciona sem o Xcode aberto), e o MCP da Apple quando preciso de buscas de documentação, verificação via Swift REPL ou renderização de previews de SwiftUI.

O teste no mundo real

Executei uma verificação completa de saúde no meu app Water (SwiftUI + simulação de fluidos 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)

O que aconteceu

Configuração do simulador usou list_sims, session_set_defaults e boot_sim. O agente descobriu que nenhum iPhone 16 Pro existia no runtime do iOS 26 (ele foi descontinuado), então mudou automaticamente para o iPhone 17 Pro. Este é o tipo de comportamento adaptativo que quebra com comandos xcodebuild hardcoded.

O build falhou inicialmente — a Metal Toolchain não estava baixada na nova instalação do Xcode. O agente detectou isso pela saída de erros estruturada e executou xcodebuild -downloadComponent MetalToolchain para resolver. O build então foi bem-sucedido com 3 avisos:

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

A saída estruturada significou que esses avisos voltaram categorizados com referências exatas de arquivo:linha, não enterrados em um log.

Os testes falharam — mas a falha foi informativa. A saída estruturada mostrou que 5 métodos de teste referenciavam injectTapRipple(atNormalizedX:), um método que eu removi em um commit anterior. O agente identificou o commit exato (7657068 — "remove tap ripple interaction entirely") e listou quais testes precisavam de atualização. Zero ambiguidade.

A busca de documentação e o Swift REPL confirmaram que HKQuantityType(.dietaryWater) é válido, retornando o identificador HKQuantityTypeIdentifierDietaryWater.

A tabela de resultados

A verificação completa de saúde rodou de forma autônoma. Eu não abri o Xcode, não copiei nenhuma mensagem de erro, não construí nenhum comando xcodebuild.

Ensinando o agente

Instalar servidores MCP não é suficiente. O agente precisa saber que as ferramentas existem e quando preferi-las em vez de comandos shell brutos. Atualizei a definição do meu agente ios-developer para incluir orientação 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.

Sem isso, o agente às vezes vai recorrer ao xcodebuild via Bash ou usar WebSearch para documentação da Apple em vez da busca nativa. A definição do agente fecha essa lacuna.²

O que muda na prática

Antes do MCP, meu fluxo de trabalho iOS com Claude Code era:

1. Escrever código com Claude
2. Compilar manualmente no Xcode (ou via xcodebuild no terminal)
3. Copiar erros de volta para o Claude
4. Repetir

Depois do MCP:

1. Descrever o que eu quero
2. Claude escreve o código, compila, lê os erros, corrige, roda os testes e verifica o comportamento da API
3. Eu reviso o resultado final

O loop de build-erro-correção que antes exigia minha participação ativa agora acontece de forma autônoma. O agente não está adivinhando o que deu errado a partir de texto bruto — ele lê dados estruturados que dizem exatamente o que falhou, onde e por quê.

Este é o padrão que continuo vendo em ferramentas de IA: o avanço não é tornar a IA mais inteligente, é dar a ela acesso estruturado às ferramentas que os desenvolvedores já usam. MCP é o protocolo que torna isso possível — assim como os hooks deram ao Claude Code proteções determinísticas, o MCP fornece interfaces de ferramentas determinísticas. O Xcode não é a primeira e não será a última ferramenta de desenvolvimento a se expor através do MCP.³

Lista de verificação de configuração

Para quem usa Claude Code com projetos iOS:

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

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

3. Verifique se ambos estão conectados: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Atualize suas definições de agente para referenciar as novas ferramentas (ou o agente às vezes vai recorrer a comandos shell).

5. Inicie uma nova sessão do Claude Code — ferramentas MCP registradas durante uma sessão não aparecerão na busca de ferramentas até reiniciar.

É isso. Dois comandos, acesso completo ao sistema de build iOS.

Perguntas frequentes

Ainda preciso do Xcode instalado?

Sim. Ambos os servidores MCP são wrappers em torno da toolchain do Xcode (xcodebuild, xcrun, simctl). O Xcode precisa estar instalado e configurado. Os servidores MCP dão ao Claude Code acesso estruturado a essas ferramentas — eles não as substituem.

O XcodeBuildMCP funciona com projetos exclusivamente SwiftPM?

Sim. O XcodeBuildMCP suporta tanto .xcodeproj/.xcworkspace quanto projetos Swift Package Manager. Use discover_projs para encontrar os tipos de projeto disponíveis, depois build_sim ou build_device com o scheme apropriado.

E quanto a pipelines de CI/CD?

Os servidores MCP rodam localmente com o Claude Code. Para CI/CD, você continuaria usando xcodebuild diretamente ou ferramentas como Fastlane. A abordagem MCP é especificamente para o loop de desenvolvimento interativo onde um agente de IA precisa de feedback estruturado durante o ciclo de código-build-teste.