Ein iOS-Build-Rechner auf dem Mac mini M4: die KI-Agenten von Xcode, xcodebuild und selbst gehostete CI

Warum iOS-Arbeit einen Mac braucht, und deshalb auch ein iOS-bauender Agent

Xcode ist Apples eigene Entwicklungsumgebung und der einzige unterstützte Weg, eine iOS-App zu bauen, zu signieren und einzureichen, und die aktuelle Version, Xcode 27, lässt sich nur auf einem Mac mit „macOS Tahoe 26.6 or later“ auf Apple Silicon installieren (developer.apple.com, xcode-release-notes/xcode-27-release-notes, geprüft im September 2026). Apple setzt das auch bei der Einreichung durch, nicht nur beim Bauen: Seit dem 28. April 2026 müssen an App Store Connect hochgeladene Apps mit dem SDK für iOS 26 oder neuer gebaut sein, dazu passende Mindestversionen für iPadOS, tvOS, visionOS und watchOS (developer.apple.com/news/upcoming-requirements, geprüft im September 2026), was in der Praxis eine aktuelle Xcode-Installation bedeutet.

Ein Agent, der ein Projekt öffnen, seine Testsuite ausführen oder ein Archiv für TestFlight erzeugen soll, ruft dieselbe Xcode-Toolchain auf wie ein Entwickler, auf demselben Betriebssystem, mit denselben installierten Simulatoren. Einen eigenen, leichteren iOS-Build-Weg für die Automatisierung gibt es nicht.

Warum ein ständig laufender Mac mini statt des Notebooks, auf dem Xcode schon läuft

Ein Notebook mit installiertem Xcode erfüllt die harte Voraussetzung oben bereits, muss aber offen, wach und verbunden bleiben, solange ein Agent mitten in einem Build oder Testlauf steckt oder auf einen langsam startenden Simulator wartet; wer zuklappt, um einen Zug zu erreichen, beendet die Sitzung gleich mit. Ein ständig laufender Mac mini M4 hebt diese Einschränkung auf, genau wie bei jeder anderen Art unbeaufsichtigter Coding-Agenten: Eingesteckt an einem Schreibtisch, hält er Xcode, die Simulatoren und den Agenten, der sie steuert, am Laufen, lange nachdem das Notebook, das die Sitzung gestartet hat, schlafen gegangen ist.

Diesen Agenten zu erreichen, funktioniert genau wie das Setup im Ratgeber zum Programmieren mit KI aus der Ferne: Tailscale bringt beide Geräte ins selbe private Netzwerk, mosh hält eine Sitzung über Ruhezustand und wechselndes WLAN hinweg am Leben, und herdr hält den Agentenprozess zwischen den Verbindungen am Laufen. Ein iOS-Build-Rechner ist ein Rechner zum Programmieren aus der Ferne, auf dem eben Xcode läuft.

Die eigenen Agenten von Xcode zuerst: Claude Agent und Codex über das Model Context Protocol

Der direkteste Weg, einen KI-Agenten auf ein iOS-Projekt anzusetzen, ist der, den Apple in Xcode selbst eingebaut hat: Xcode 26.3 „makes its capabilities available through the Model Context Protocol, an open standard that gives developers the flexibility to use any compatible agent or tool with Xcode“ (apple.com/newsroom, 2026/02/xcode-26-point-3-unlocks-the-power-of-agentic-coding, geprüft im September 2026). Dieselbe Ankündigung nennt zwei Agenten namentlich, die direkten Zugriff in Xcode haben: Claude Agent von Anthropic und Codex von OpenAI.

So betrieben, arbeitet der Agent im selben Xcode-Fenster, das auch ein Entwickler nutzen würde: Er kann Xcode bitten, ein Target zu bauen, einen Testplan auszuführen oder das Ergebnis einer SwiftUI-Vorschau über Xcodes eigenen MCP-Server zu lesen, statt einen separaten Build auf der Kommandozeile anzustoßen. Das beschränkt den Agenten auf das Projekt, das Xcode schon geöffnet hat, eine engere und berechenbarere Angriffsfläche als ein Terminal-Agent, der jeden beliebigen Befehl ausführen darf.

Terminal-Agenten: Bauen und Testen mit xcodebuild über dasselbe Remote-Setup

Ein terminalbasierter Coding-Agent, wie ihn der Ratgeber zum Programmieren mit KI aus der Ferne behandelt oder wie er in einer Agenten-Sandbox-VM läuft, braucht Xcodes eigenen MCP-Server nicht, um ein iOS-Projekt zu bauen; er steuert dasselbe Kommandozeilenwerkzeug, das die CI-Skripte eines Entwicklers schon nutzen. Apples eigene Hinweise zum Bauen außerhalb der Xcode-Oberfläche beschreiben xcodebuild als genau das Werkzeug dafür: „build, query, analyze, test, and archive operations“ für ein Projekt oder einen Workspace von der Kommandozeile aus (developer.apple.com/library/archive/technotes/tn2339, geprüft im September 2026).

xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' build
xcodebuild -scheme MyApp -destination 'platform=iOS Simulator,name=iPhone 17' test

Über mosh und herdr läuft dieser Befehl genau wie jeder andere Agentenbefehl im Remote-Setup: Die Sitzung übersteht Ruhezustand und Netzwechsel des Notebooks, und herdr hält den Build zwischen den Verbindungen am Laufen. Auch die eigene Sandbox des Agenten ist einen Blick wert: Die Codex-CLI von OpenAI zum Beispiel dokumentiert, dass sie „uses Seatbelt on macOS“, um einzuschränken, was ein von ihr ausgeführter Befehl berühren kann (developers.openai.com/codex/agent-approvals-security, geprüft im September 2026), zusätzlich zu dem, was eine Tart-VM drumherum schon bietet.

Das aktuelle Xcode und das macOS, das es braucht

Xcode 27 ist am 14. September 2026 als Build 27A266a allgemein erschienen, zusammen mit iOS 27, und verlangt „macOS Tahoe 26.6 or later“, nur auf Apple Silicon; auf einem Intel-Mac lässt es sich nicht installieren (developer.apple.com, xcode-release-notes/xcode-27-release-notes, geprüft im September 2026). Sein Vorgänger Xcode 26.6 unterstützte noch Intel-Hardware; einen Build-Rechner, der vor September 2026 eingerichtet wurde, sollten Sie also gegen diese engere Voraussetzung prüfen.

Apple liefert Betas weiter neben der Hauptversion, nicht stattdessen: Die erste Beta von Xcode 27.1 folgte der Hauptversion 27.0 nach vier Tagen und brachte SDK-Unterstützung für ein neues Gerät (macrumors.com, 2026/09/18/apple-releases-xcode-27-1-beta-iphone-duo-support, geprüft im September 2026). Ein Gerät, das auch gegen das SDK des nächsten Quartals testet, bevor es erscheint, hat am Ende zwei Xcode-Installationen nebeneinander; das Speicherbudget unten berücksichtigt das.

Continuous Integration: ein selbst gehosteter Runner auf demselben Mini

Ein Agent, der seine eigenen Änderungen committet, ist ein Grund, Build und Testsuite unabhängig noch einmal auszuführen, so wie der Pull Request eines menschlichen Mitwirkenden eine CI auslösen würde. GitHubs eigener selbst gehosteter Runner ist die direkte Option für einen Mac mini, auf dem Xcode schon läuft: Er unterstützt „macOS 11.0 (Big Sur) or later“, und die Runner-Anwendung selbst „only requires minimal resources“ über das hinaus, was der Build braucht (docs.github.com, en/actions/reference/runners/self-hosted-runners, geprüft im September 2026). Eine Grenze gilt unabhängig vom Runner: „If you want to run workflows that use Docker container actions or service containers, you must use a Linux machine and Docker must be installed“ (gleiche Quelle); dieser eine Workflow-Schritt muss also woanders laufen.

Ein selbst gehosteter Git-Server kommt ohne GitHub an dieselbe Stelle. Giteas eigener Actions-Runner veröffentlicht fertige macOS-Programme direkt auf seiner Release-Seite (gitea.com/gitea/runner/releases, geprüft im September 2026); Forgejo, der Fork von Gitea, liefert ebenfalls einen eigenen Actions-Runner, seine Admin-Anleitung nennt aber nur ein Programm, einen Docker-Container oder ein Paket für Linux-Distributionen, keinen macOS-Build (forgejo.org/docs, latest/admin/actions, geprüft im September 2026). Auch GitLab Runner lässt sich auf einem Mac installieren, als Hintergrunddienst statt als Systemdienst: „GitLab Runner runs as a user-mode LaunchAgent, not as a system-level LaunchDaemon. This is the only supported mode“, mit Installationsprogrammen für „Apple Silicon or Intel x86-64 systems“ (docs.gitlab.com, runner/install/osx, geprüft im September 2026).

Apples eigene gehostete Alternative lässt den Mini für die CI ganz weg: Xcode Cloud „is a continuous integration and delivery service built into Xcode and designed expressly for Apple developers“ (developer.apple.com, xcode-cloud, geprüft im September 2026), und eine Mitgliedschaft im Apple Developer Program enthält bereits 25 Rechenstunden im Monat, mit bezahlten Stufen von 100 bis 10.000 Stunden im Monat (gleiche Quelle). Ein Projekt, das nur gelegentlich einen Build auf einer sauberen Maschine braucht, kommt mit diesem Kontingent allein aus; eines, das bei jedem Commit eines Agenten baut, verbraucht es schneller, und dort lohnt sich ein selbst gehosteter Runner auf dem Mini.

Warum das ein Laufwerk schneller füllt als der eigene Code der App

Xcodes eigener Platzbedarf übertrifft fast jedes iOS-Projekt, das es baut. Gemessen auf einem Mac mini M4 im September 2026: Die Anwendung Xcode 26.6 selbst ist 3,5 GB groß; die Simulator-Laufzeit für iOS 26.5, geladen, sobald ein Projekt erstmals diese iOS-Version anvisiert, etwa 7,9 GB, und die Laufzeit für watchOS 26.5 für eine Begleit-App etwa 3,7 GB, beide abgelesen aus xcrun simctl runtime list -j. DerivedData, der Build-Cache, den Xcode für jedes Projekt schreibt und selten von selbst leert, war auf demselben Gerät nach gewöhnlicher Nutzung auf 37 GB angewachsen, vollständig aus Build-Produkten und Indizes, die Xcode für entbehrlich hält, aber nie selbst entsorgt.

Zwei weitere Kategorien haben keinen veröffentlichten Herstellerwert und waren auf diesem Gerät nicht zum Messen vorhanden; die Tabelle unten behandelt sie daher als unsere eigene Schätzung: Archive, die signierten .xcarchive-Bündel, die Xcode für jeden an App Store Connect eingereichten oder für Ad-hoc-Tests exportierten Build behält, und Gerätesupport-Dateien, die Debug-Symbole pro iOS-Version, die Xcode lädt, wenn zum ersten Mal ein physisches Gerät mit dieser Version verbunden wird. Eine zweite vollständige Xcode-Installation, behalten für das Beta-SDK des nächsten Quartals wie im Abschnitt oben beschrieben, kostet ungefähr so viel wie die erste.

Das sind nach unserer Schätzung 120 GB, bevor auch nur eine Zeile des eigenen Codes der App, ihre Abhängigkeiten oder ihre eigenen Build-Produkte Platz belegen: 136 GB Rest bei 256 GB, 392 GB bei 512 GB, 1880 GB bei 2 TB. Das Repository eines iOS-Projekts und seine Abhängigkeiten über Swift Package Manager oder CocoaPods bringen selten mehr als ein paar Gigabyte dazu; es sind Xcodes eigene Werkzeuge, nicht die gebaute App, die das Laufwerk tatsächlich füllen. Für einen M4 im Basismodell mit regelmäßigen Builds lässt das interne 2-TB-Modul Platz für Xcode und laufende Projekte auf dem Startvolume, ohne Build-Caches verlegen zu müssen.

Aufräumbefehle, die sich regelmäßig lohnen

Simulator-Laufzeiten und alte Plattform-SDKs lassen sich hier am leichtesten zurückholen, und Apples eigene Entwicklerforen dokumentieren die Befehle dafür, ohne die Dateien eines Projekts anzufassen (developer.apple.com/forums, geprüft im September 2026):

xcrun simctl runtime list
xcrun simctl runtime delete unavailable
xcrun simctl runtime delete --notUsedSinceDays 365
xcodebuild -downloadPlatform iOS

Für DerivedData gibt es kein entsprechendes eingebautes Aufräumen; den ganzen Ordner zu löschen, ist ungefährlich (Xcode baut ihn beim nächsten Build langsam neu auf) und der direkteste Weg, die oben gemessenen 37 GB zurückzuholen. Archive sehen Sie besser von Hand im Organizer-Fenster von Xcode durch, da jedes ein bestimmter signierter Build ist, den man vielleicht noch behalten möchte.

Die ehrlichen Einschränkungen

• Dass Xcode 27 nur auf Apple Silicon läuft, ist keine Warnung für die Zukunft, sondern der aktuelle Stand: Ein Mac mini mit Intel kann das aktuelle Xcode gar nicht ausführen und ist auf Xcode 26.6 oder älter beschränkt (developer.apple.com, xcode-release-notes/xcode-27-release-notes, geprüft im September 2026), das irgendwann hinter Apples eigene SDK-Mindestversionen für neue Einreichungen im App Store zurückfällt.
• Xcodes eingebauter MCP-Server, genutzt über Claude Agent oder Codex in Xcode selbst, funktioniert nur, solange Xcode den Build ausführt; ein Terminal-Agent, der xcodebuild direkt steuert, hängt nicht davon ab, dass Xcode geöffnet bleibt. Das zählt bei einem unbeaufsichtigten nächtlichen Lauf, bei dem niemand bemerkt, wenn die App sich beendet.
• Die Werte oben für DerivedData, Archive und Gerätesupport sind eine Momentaufnahme gewöhnlicher Nutzung auf einem Mac mini M4, keine Obergrenze: Ein Gerät, das mehrere Projekte baut oder seltener aufgeräumt wird, misst mehr.
• Ein selbst gehosteter CI-Runner auf demselben Mini, der die App baut, ist bequem, aber keine Garantie für eine saubere Maschine wie ein gehosteter Runner oder Xcode Cloud: Übrig gebliebenes DerivedData oder eine halb fertige Agenten-Sitzung können einen Build lokal bestehen lassen, der bei einem wirklich frischen Checkout scheitern würde.