Dwa serwery MCP zamieniły Claude Code w system budowania iOS

Tworzę 11 aplikacji iOS z Claude Code. Mam hooki, które chronią bezpieczeństwo mojego repozytorium git, reguły wymuszające jakość kodu oraz definicje agentów kodujące wzorce mojego zespołu. Ale jeszcze do wczoraj każdy błąd kompilacji oznaczał kopiowanie wyjścia terminala, wklejanie go z powrotem i nadzieję, że agent zrozumie kontekst. Zarządzanie symulatorami opierało się na surowych poleceniach xcrun simctl. Wyniki testów przychodziły jako nieustrukturyzowane ściany tekstu.

Dwa polecenia claude mcp add to zmieniły.

TL;DR

XcodeBuildMCP (76 narzędzi, open source) obsługuje kompilację, testy, symulatory, wdrażanie na fizyczne urządzenia i debugowanie LLDB — wszystko bez uruchomionego Xcode. Natywny Apple Xcode MCP (20 narzędzi, dostarczany z Xcode 26.3) łączy się z uruchomionym procesem Xcode w celu operacji na plikach, diagnostyki w czasie rzeczywistym, przeszukiwania dokumentacji, Swift REPL i podglądów SwiftUI. Razem dają Claude Code pełny programistyczny dostęp do łańcucha narzędzi iOS — ustrukturyzowany JSON zamiast parsowania logów, wywołania narzędzi zamiast poleceń powłoki. Konfiguracja zajmuje mniej niż 2 minuty.

Problem

Claude Code doskonale radzi sobie z czytaniem i pisaniem Swift. Rozumie wzorce SwiftUI, relacje SwiftData i współbieżność Swift 6. Ale był ślepy na system budowania.

Gdy kompilacja się nie powiodła, agent musiał:

1. Uruchomić xcodebuild przez Bash
2. Przetworzyć tysiące linii nieustrukturyzowanego wyjścia
3. Mieć nadzieję, że znajdzie faktyczny błąd wśród szumu
4. Zgadywać, który plik i linia spowodowały awarię

Gdy chciałem uruchomić testy:

1. Agent konstruuje pełne polecenie xcodebuild test z pamięci
2. Parsuje pakiet xcresult (lub bardziej prawdopodobnie surowe stdout)
3. Próbuje ustalić, które testy przeszły, a które nie

To odpowiednik proszenia programisty o pisanie kodu poprzez czytanie wyjścia kompilatora przez dziurkę od klucza. Informacja technicznie tam była, ale interfejs był niewłaściwy.

Rozwiązanie: Dwa komplementarne serwery MCP

XcodeBuildMCP (społecznościowy, open source)

XcodeBuildMCP opakowuje xcodebuild i powiązane narzędzia w 76 ustrukturyzowanych narzędzi MCP. Agent wywołuje xcode_build i otrzymuje JSON ze skategoryzowanymi błędami, ostrzeżeniami i lokalizacjami plików — a nie 3000-liniowy log kompilacji.

Kluczowe narzędzia:

Instalacja:

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

Flaga -s user ustawia zasięg globalny — dostępny w każdym projekcie bez konfiguracji per-projekt. Zmienna środowiskowa wyłącza telemetrię (domyślnie wysyłane są raporty awarii do Sentry; wolę z tego zrezygnować).¹

Apple Xcode MCP (natywny, dostarczany z Xcode 26.3)

Apple dostarczył własny serwer MCP w Xcode 26.3 przez xcrun mcpbridge. Udostępnia 20 narzędzi, które łączą się bezpośrednio z procesem Xcode przez XPC:

Instalacja:

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

Wymaga Xcode 26.3+ (obecnie Release Candidate, wkrótce oficjalna wersja).

Dlaczego oba?

Częściowo się pokrywają w zakresie kompilacji i testów, ale architektura się różni:

• XcodeBuildMCP działa samodzielnie przez CLI xcodebuild — bez konieczności uruchamiania procesu Xcode. Dodaje 76 narzędzi obejmujących symulatory, fizyczne urządzenia, debugowanie LLDB, automatyzację UI i scaffolding projektów. Idealny do bezgłowych przepływów pracy i środowisk zbliżonych do CI.
• Apple Xcode MCP wymaga uruchomionej instancji Xcode i komunikuje się przez XPC. Zapewnia operacje na plikach w kontekście projektu Xcode, diagnostykę kodu w czasie rzeczywistym (nie tylko wyjście kompilacji) oraz natywne przeszukiwanie dokumentacji, w tym sesji WWDC.

Używam obu: XcodeBuildMCP do cyklu buduj-testuj-debuguj (działa bez otwartego Xcode), a Apple MCP gdy potrzebuję wyszukiwania w dokumentacji, weryfikacji Swift REPL lub renderowania podglądów SwiftUI.

Test w praktyce

Przeprowadziłem pełny przegląd stanu mojej aplikacji Water (SwiftUI + symulacja płynów Metal + HealthKit) używając tego promptu:

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)

Co się wydarzyło

Konfiguracja symulatora wykorzystała list_sims, session_set_defaults i boot_sim. Agent odkrył, że iPhone 16 Pro nie istnieje w środowisku iOS 26 (został wycofany), więc automatycznie przełączył się na iPhone 17 Pro. To właśnie ten rodzaj adaptacyjnego zachowania, który nie działa przy zakodowanych na sztywno poleceniach xcodebuild.

Kompilacja początkowo się nie powiodła — Metal Toolchain nie został pobrany na nowej instalacji Xcode. Agent wykrył to z ustrukturyzowanego wyjścia błędów i uruchomił xcodebuild -downloadComponent MetalToolchain, aby to naprawić. Kompilacja następnie przeszła z 3 ostrzeżeniami:

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

Ustrukturyzowane wyjście oznaczało, że te informacje wróciły jako skategoryzowane ostrzeżenia z dokładnymi referencjami plik:linia, a nie pogrzebane w logu.

Testy nie przeszły — ale informacja o awarii była konkretna. Ustrukturyzowane wyjście pokazało, że 5 metod testowych odwoływało się do injectTapRipple(atNormalizedX:), metody którą usunąłem w poprzednim commicie. Agent zidentyfikował dokładny commit (7657068 — "remove tap ripple interaction entirely") i wymienił, które testy wymagają aktualizacji. Zero niejednoznaczności.

Przeszukiwanie dokumentacji i Swift REPL potwierdziły, że HKQuantityType(.dietaryWater) jest prawidłowy, zwracając identyfikator HKQuantityTypeIdentifierDietaryWater.

Tabela wyników

Cały przegląd stanu przebiegł autonomicznie. Nie otwierałem Xcode, nie kopiowałem żadnych komunikatów o błędach, nie konstruowałem żadnych poleceń xcodebuild.

Uczenie agenta

Instalacja serwerów MCP to nie wszystko. Agent musi wiedzieć, że narzędzia istnieją i kiedy preferować je nad surowymi poleceniami powłoki. Zaktualizowałem definicję mojego agenta ios-developer, dodając jawne wskazówki:

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

Bez tego agent czasami powraca do xcodebuild przez Bash lub używa WebSearch do dokumentacji Apple zamiast natywnego wyszukiwania. Definicja agenta eliminuje tę lukę.²

Co zmienia się w praktyce

Przed MCP mój przepływ pracy z iOS w Claude Code wyglądał tak:

1. Pisanie kodu z Claude
2. Ręczna kompilacja w Xcode (lub przez xcodebuild w terminalu)
3. Kopiowanie błędów z powrotem do Claude
4. Powtarzanie

Po MCP:

1. Opisuję, czego chcę
2. Claude pisze kod, kompiluje go, czyta błędy, naprawia je, uruchamia testy i weryfikuje zachowanie API
3. Przeglądam końcowy wynik

Pętla kompilacja-błąd-naprawa, która wcześniej wymagała mojego aktywnego udziału, teraz odbywa się autonomicznie. Agent nie zgaduje, co poszło nie tak, na podstawie surowego tekstu — czyta ustrukturyzowane dane, które dokładnie mówią mu, co się nie powiodło, gdzie i dlaczego.

To wzorzec, który ciągle obserwuję w narzędziach AI: przełom nie polega na uczynieniu AI inteligentniejszą, lecz na daniu jej ustrukturyzowanego dostępu do narzędzi, których programiści już używają. MCP to protokół, który to umożliwia — tak jak hooki dały Claude Code deterministyczne zabezpieczenia, MCP daje mu deterministyczne interfejsy narzędziowe. Xcode nie jest pierwszym i nie będzie ostatnim narzędziem deweloperskim udostępniającym się przez MCP.³

Lista kontrolna konfiguracji

Dla każdego, kto używa Claude Code z projektami iOS:

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

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

3. Weryfikacja połączenia obu: bash claude mcp list # XcodeBuildMCP: ... - Connected # xcode: xcrun mcpbridge - Connected

4. Aktualizacja definicji agentów, aby odwoływały się do nowych narzędzi (w przeciwnym razie agent czasami powraca do poleceń powłoki).

5. Uruchomienie nowej sesji Claude Code — narzędzia MCP zarejestrowane w trakcie sesji nie pojawią się w wyszukiwaniu narzędzi do ponownego uruchomienia.

To wszystko. Dwa polecenia, pełny dostęp do systemu budowania iOS.

FAQ

Czy nadal potrzebuję zainstalowanego Xcode?

Tak. Oba serwery MCP są nakładkami na łańcuch narzędzi Xcode (xcodebuild, xcrun, simctl). Xcode musi być zainstalowany i skonfigurowany. Serwery MCP dają Claude Code ustrukturyzowany dostęp do tych narzędzi — nie zastępują ich.

Czy XcodeBuildMCP działa z projektami opartymi wyłącznie na SwiftPM?

Tak. XcodeBuildMCP obsługuje zarówno projekty .xcodeproj/.xcworkspace, jak i Swift Package Manager. Można użyć discover_projs, aby znaleźć dostępne typy projektów, a następnie build_sim lub build_device z odpowiednim schematem.

A co z pipeline’ami CI/CD?

Serwery MCP działają lokalnie z Claude Code. W przypadku CI/CD nadal należy używać bezpośrednio xcodebuild lub narzędzi takich jak Fastlane. Podejście MCP jest przeznaczone specjalnie dla interaktywnej pętli deweloperskiej, w której agent AI potrzebuje ustrukturyzowanej informacji zwrotnej podczas cyklu kod-kompilacja-testy.