Een iOS-buildmachine op een Mac Mini M4: Xcode's AI-agents, xcodebuild en zelfgehoste CI

Waarom iOS-werk een Mac nodig heeft, en dus ook een agent die iOS bouwt

Xcode is Apple's eigen IDE en de enige ondersteunde manier om een iOS-app te bouwen, te ondertekenen en in te dienen, en de huidige release, Xcode 27, installeert alleen op een Mac met "macOS Tahoe 26.6 or later" op Apple silicon (developer.apple.com, xcode-release-notes/xcode-27-release-notes, gecontroleerd september 2026). Apple handhaaft dit ook op het moment van indienen, niet alleen bij het bouwen: sinds 28 april 2026 moeten apps die naar App Store Connect worden geüpload, gebouwd zijn met de iOS 26 SDK of nieuwer, naast overeenkomstige minimums voor iPadOS, tvOS, visionOS en watchOS (developer.apple.com/news/upcoming-requirements, gecontroleerd september 2026), wat in de praktijk een actuele Xcode-installatie betekent.

Een agent die gevraagd wordt een project te openen, de testsuite te draaien, of een archief voor TestFlight te produceren, roept dezelfde Xcode-toolchain aan die een menselijke ontwikkelaar zou gebruiken, op hetzelfde besturingssysteem, met dezelfde simulators geïnstalleerd. Er bestaat geen apart, lichter iOS-buildpad voor automatisering om in plaats daarvan te nemen.

Waarom een altijd-aan Mac Mini, niet de laptop waar Xcode al op draait

Een laptop met Xcode geïnstalleerd voldoet al aan de harde eis hierboven, maar moet ook open, wakker en verbonden blijven zolang een agent midden in een build, een testrun, of wachtend op een trage simulator-opstart zit; het deksel dichtklappen om de trein te halen beëindigt de sessie meteen mee. Een altijd-aan Mac Mini M4 neemt die beperking weg op dezelfde manier als bij elke andere onbeheerde codeeragent: aangesloten op een bureau houdt hij Xcode, de simulators en welke agent ze ook aanstuurt lang draaiende nadat de laptop die de sessie startte in slaap is gevallen.

Die agent bereiken werkt precies als de opstelling in de gids voor extern AI-coderen: Tailscale zet beide machines op hetzelfde private netwerk, mosh houdt een sessie in leven bij sluimerstand en roaming wifi, en herdr houdt het agentproces draaiende tussen aankoppelingen. Een iOS-buildmachine is een machine voor extern coderen die toevallig Xcode draait.

Xcode's eigen agents komen eerst: Claude Agent en Codex via het Model Context Protocol

De meest directe manier om een AI-agent op een iOS-project te richten, is degene die Apple in Xcode zelf ingebouwd heeft: 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, gecontroleerd september 2026). Dezelfde aankondiging noemt twee agents met naam die directe toegang hebben binnen Xcode: Anthropic's Claude Agent en OpenAI's Codex.

Op deze manier ingezet werkt de agent binnen hetzelfde Xcode-venster dat een ontwikkelaar zou gebruiken: hij kan Xcode vragen een target te bouwen, een testplan uit te voeren, of het resultaat van een SwiftUI-preview te lezen via Xcode's eigen MCP-server, in plaats van een aparte command-line build te starten. Dat houdt de agent beperkt tot welk project Xcode al open heeft, wat een smaller en voorspelbaarder oppervlak is dan een terminalagent die vrij is om elk commando te kiezen.

Terminalagents: bouwen en testen met xcodebuild over dezelfde externe opstelling

Een terminalgebaseerde codeeragent, van het soort dat de gids voor extern AI-coderen behandelt of dat binnen een agent-sandbox-VM draait, heeft Xcode's eigen MCP-server niet nodig om een iOS-project te bouwen; hij stuurt dezelfde command-line tool aan die de CI-scripts van een menselijke ontwikkelaar al gebruiken. Apple's eigen richtlijnen voor bouwen buiten de Xcode-interface beschrijven xcodebuild als de tool hiervoor: het uitvoeren van "build, query, analyze, test, and archive operations" tegen een project of workspace vanaf de command line (developer.apple.com/library/archive/technotes/tn2339, gecontroleerd september 2026).

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

Over mosh en herdr verloopt dat commando precies zoals elk ander agentcommando in de opstelling voor extern coderen: de sessie overleeft het slapen of roamen van de laptop, en herdr houdt de build draaiende tussen aankoppelingen. De eigen sandboxing van een agent is ook de moeite van het checken waard: de Codex CLI van OpenAI documenteert bijvoorbeeld dat hij "uses Seatbelt on macOS" om te beperken wat een commando dat hij uitvoert kan aanraken (developers.openai.com/codex/agent-approvals-security, gecontroleerd september 2026), bovenop wat een Tart-VM eromheen al biedt.

De huidige Xcode, en de macOS die hij nodig heeft

Xcode 27 bereikte algemene beschikbaarheid op 14 september 2026 als build 27A266a, samen met iOS 27, en vereist "macOS Tahoe 26.6 or later" op alleen Apple silicon; hij installeert niet op een Intel-Mac (developer.apple.com, xcode-release-notes/xcode-27-release-notes, gecontroleerd september 2026). Zijn voorganger, Xcode 26.6, ondersteunde nog Intel-hardware, dus een buildmachine die vóór september 2026 is opgezet, is het waard om tegen deze smallere eis te checken.

Apple blijft bèta's uitbrengen naast de release, niet in plaats ervan: de eerste bèta van Xcode 27.1 volgde vier dagen na de algemene release van 27.0, met SDK-ondersteuning voor een nieuw toestel (macrumors.com, 2026/09/18/apple-releases-xcode-27-1-beta-iphone-duo-support, gecontroleerd september 2026). Een machine die ook tegen de SDK van volgend kwartaal test voordat die uitkomt, eindigt met twee Xcode-installaties naast elkaar, waar het opslagbudget hieronder rekening mee houdt.

Continuous integration: een zelfgehoste runner op dezelfde Mini

Een agent die zijn eigen wijzigingen commit, is een reden om de build- en testsuite onafhankelijk opnieuw te draaien, zoals de PR van een menselijke bijdrager CI zou triggeren. GitHub's eigen zelfgehoste runner is de directe optie voor een Mac Mini die al Xcode draait: hij ondersteunt "macOS 11.0 (Big Sur) or later", en de runnertoepassing zelf "only requires minimal resources" naast wat de build zelf nodig heeft (docs.github.com, en/actions/reference/runners/self-hosted-runners, gecontroleerd september 2026). Eén beperking geldt ongeacht de 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" (dezelfde bron), dus die ene workflowstap moet elders draaien.

Een zelfgehoste Git-host komt op hetzelfde punt uit zonder GitHub. Gitea's eigen Actions-runner publiceert kant-en-klare macOS-binaries rechtstreeks op zijn releasepagina (gitea.com/gitea/runner/releases, gecontroleerd september 2026); Forgejo, de fork van Gitea, heeft ook zijn eigen Actions-runner, maar diens beheerdersgids noemt alleen een binary, een Docker-container, of een Linux-distributiepakket, geen macOS-build ertussen (forgejo.org/docs, latest/admin/actions, gecontroleerd september 2026). GitLab Runner installeert ook op een Mac, als achtergronddienst in plaats van een systeemdienst: "GitLab Runner runs as a user-mode LaunchAgent, not as a system-level LaunchDaemon. This is the only supported mode", met installatiebestanden voor "Apple Silicon or Intel x86-64 systems" (docs.gitlab.com, runner/install/osx, gecontroleerd september 2026).

Apple's eigen gehoste alternatief slaat de Mini voor CI helemaal over: Xcode Cloud "is a continuous integration and delivery service built into Xcode and designed expressly for Apple developers" (developer.apple.com, xcode-cloud, gecontroleerd september 2026), en een Apple Developer Program-lidmaatschap bevat al 25 compute-uren per maand, met betaalde niveaus van 100 uur tot 10.000 uur per maand (dezelfde bron). Een project dat maar af en toe een schone-machine-build nodig heeft, kan op dat quotum alleen vooruit; een project dat bij elke agentcommit bouwt, verbruikt het sneller, en daar verdient een zelfgehoste runner op de Mini zichzelf terug.

Waarom dit sneller een schijf vult dan de eigen code van de app ooit zou doen

Xcode's eigen voetafdruk overschaduwt bijna elk iOS-project dat hij bouwt. Gemeten op een Mac Mini M4 in september 2026: de Xcode 26.6-applicatie zelf is 3,5GB; de iOS 26.5-simulatorruntime, gedownload de eerste keer dat een project die iOS-versie target, is ongeveer 7,9GB, en de watchOS 26.5-runtime voor een companion-app is ongeveer 3,7GB, beide afgelezen uit xcrun simctl runtime list -j. DerivedData, de buildcache die Xcode voor elk project wegschrijft en zelden zelf opruimt, was op dezelfde machine gegroeid tot 37GB na gewoon gebruik, volledig uit buildproducten en indexen die Xcode als wegwerpbaar beschouwt maar zelf nooit wegwerpt.

Twee categorieën hebben geen door de leverancier gepubliceerd cijfer en waren niet aanwezig om te meten op deze machine, dus de tabel hieronder behandelt ze als onze eigen inschatting: archieven, de ondertekende .xcarchive-bundels die Xcode bewaart voor elke build die ingediend is bij App Store Connect of geëxporteerd voor ad-hoc testen, en device support-bestanden, de per-iOS-versie debug-symbolen die Xcode downloadt de eerste keer dat een fysiek toestel met die versie verbinding maakt. Een tweede volledige Xcode-installatie, aangehouden voor de bèta-SDK van volgend kwartaal zoals de sectie hierboven beschrijft, kost ongeveer evenveel als de eerste.

Dat is 120GB volgens onze inschatting voordat ook maar één regel van de eigen code van de app, zijn dependencies, of zijn eigen buildproducten ook maar iets aan ruimte kosten: 136GB over op 256GB, 392GB op 512GB, 1880GB op 2TB. De eigen repository van een iOS-project en zijn Swift Package Manager- of CocoaPods-dependencies voegen zelden meer dan een paar gigabyte daarbovenop toe; Xcode's eigen tooling, niet de app die gebouwd wordt, is wat de schijf daadwerkelijk vult.

Opruimcommando's die de moeite waard zijn om regelmatig te draaien

Simulatorruntimes en oude platform-SDK's zijn het makkelijkste deel om terug te winnen, en Apple's eigen ontwikkelaarsforums documenteren de commando's om dat te doen zonder de eigen bestanden van een project aan te raken (developer.apple.com/forums, gecontroleerd september 2026):

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

DerivedData heeft geen ingebouwde opschoning; de hele map verwijderen is veilig (Xcode bouwt hem, langzaam, opnieuw op bij de volgende build) en is de meest directe manier om de hierboven gemeten 37GB terug te winnen. Archieven zijn het waard om met de hand te bekijken in Xcode's eigen Organizer-venster in plaats van ze volgens een schema te verwijderen, aangezien elk archief een specifieke ondertekende build is die nog de moeite waard kan zijn om te bewaren.

De eerlijke kanttekeningen

• De eis van Xcode 27 dat er alleen Apple silicon ondersteund wordt, is geen toekomstige waarschuwing, het is de huidige stand van zaken: een Intel Mac Mini kan de huidige Xcode helemaal niet draaien en zit vast aan Xcode 26.6 of ouder (developer.apple.com, xcode-release-notes/xcode-27-release-notes, gecontroleerd september 2026), wat uiteindelijk achter zal raken bij Apple's eigen SDK-minimums voor nieuwe App Store-indieningen.
• Xcode's ingebouwde MCP-server, aangestuurd via Claude Agent of Codex binnen Xcode zelf, werkt alleen zolang Xcode zelf de build draait; een terminalagent die xcodebuild rechtstreeks aanstuurt, is daar niet van afhankelijk, wat van belang is voor een onbeheerde nachtelijke run waarbij niemand merkt als de app afsluit.
• De cijfers hierboven voor DerivedData, archieven en device support zijn een momentopname van gewoon gebruik op één Mac Mini M4, geen plafond: een machine die meerdere projecten bouwt, of minder vaak opgeruimd wordt, zal hoger uitkomen.
• Een zelfgehoste CI-runner op dezelfde Mini die de app bouwt, is handig, maar het is geen garantie voor een schone machine zoals een gehoste runner of Xcode Cloud dat wel is: achtergebleven DerivedData of een halfafgemaakte agentsessie kan een build lokaal laten slagen die op een werkelijk verse checkout zou falen.