Kotlin Multiplatform iOS CI: 2026 verwaltet oder selbst gebaut?

Wenn Ihre Kotlin-Multiplatform-Pipeline bei iOS-Builds, Simulatoren oder Signierung an einem einzigen Mac-Knoten wartet, teilen Sie die Last nach Szenario auf.

Schnellste Lösung: Standard-PR-Prüfungen und elastische Simulator-Builds gehören vorzugsweise auf verwaltete macOS Agents; Produktionssignierung, private Abhängigkeiten und festgelegte Xcode-Umgebungen gehören auf einen isolierten Remote Mac. Bei stark schwankender Auslastung ist eine feste Produktionsbasis mit verwalteter Zusatzkapazität die belastbarste Architektur.

Diese Entscheidung betrifft nicht nur die Frage, ob ein Build erfolgreich endet. Sie betrifft auch Apple-Zertifikate, interne Repositories, Datenzugriff, reproduzierbare Xcode-Versionen, Wartezeiten bei Spitzenlast und die Wiederherstellung nach einem beschädigten Runner.

Für wen ist dieser Leitfaden gedacht?

Sie arbeiten an einem Kotlin-Multiplatform-Projekt und müssen iOS-Automatisierung, TestFlight-Veröffentlichungen oder Mac-Build-Ressourcen für ein Team verantworten. Sie brauchen klare Grenzen für Signierungsgeheimnisse, private Abhängigkeiten und Quellcodezugriffe.

Ebenso richtet sich der Text an IT-Leitungen und technische Entscheider, die Managed-Build-Ausgaben, eigene Mac-Knoten, Betriebsaufwand und das Risiko eines unterbrochenen Releases gemeinsam bewerten müssen.

Zuletzt aktualisiert am 27.08.2026; Versions- und Prozessangaben wurden anhand der verlinkten Kotlin- und Apple-Dokumentation geprüft.

SECTION 01Welche Kotlin-Multiplatform-Aufgaben brauchen tatsächlich einen Mac?

Die kurze Antwort lautet: Gemeinsame Kotlin-Prüfungen brauchen nicht automatisch macOS, ein echter iOS-Zielbuild mit Xcode jedoch schon. Kotlin Multiplatform kann gemeinsame Quelltexte und Logik getrennt von Apple-spezifischen Aufgaben prüfen. Sobald die Pipeline ein iOS-Framework, einen iOS-Simulator-Build, ein signiertes Archiv oder einen Upload zu App Store Connect erzeugen soll, muss ein macOS-fähiger Build-Knoten eingeplant werden.

Die Kotlin-Dokumentation zu nativen Binärdateien beschreibt, dass native Binärziele wie iosArm64 und iosSimulatorArm64 unterschiedliche Zielarchitekturen erzeugen. Daraus folgt eine wichtige Betriebsregel: Ein grüner Testlauf für den gemeinsamen Kotlin-Code beweist noch nicht, dass die iOS-Anwendung gebaut, signiert oder auf dem vorgesehenen Simulator ausgeführt werden kann.

Die Systemanforderungen dürfen Sie nicht aus einer allgemeinen „macOS-kompatibel“-Angabe ableiten. Apple führt den Status und die Anforderungen von Xcode in den offiziellen Xcode-Systemanforderungen. Für Xcode 27 ist der dort ausgewiesene Beta-Status entscheidend: Eine Pipeline, die diese Version testet, darf nicht stillschweigend als produktionskompatibel behandelt werden.

Benötigt ein iOS-Build für Kotlin Multiplatform einen Mac?

Für gemeinsame Tests lautet die Antwort nein. Für den verlässlichen iOS-Teil der Pipeline lautet sie in der Praxis ja: Sie benötigen einen macOS-Knoten, wenn Xcode, Apple-Simulatoren, Apple-Toolchains, Gerätearchive oder App-Store-Uploads beteiligt sind. Ein nicht-macOS-Job kann den gemeinsamen Code prüfen, aber keinen vollständigen Ersatz für die iOS-Abnahme liefern.

Der häufigste Fehler ist eine zu grobe Pipeline: Jeder Commit wird direkt an einen Mac geschickt, obwohl ein großer Teil der Prüfungen vorher auf einem allgemeinen Agent abgeschlossen werden könnte. Das erhöht die Mac-Warteschlange und vermischt zwei Aussagen, die getrennt gehören: „Der gemeinsame Code ist korrekt“ und „Das iOS-Produkt lässt sich mit dieser Apple-Umgebung bauen und veröffentlichen“.

SECTION 02PR-Prüfung und die richtige Mac-Auslastung

Beginnen Sie mit der billigsten und am wenigsten privilegierten Prüfung. Ein Pull Request sollte zunächst gemeinsame Kotlin-Tests, Abhängigkeitsauflösung, API-Kompatibilität, Formatierung und statische Regeln ausführen. Erst wenn diese Stufe erfolgreich ist, sollte ein macOS-Job das iOS-Framework oder die Anwendung für das relevante Ziel bauen.

Diese Aufteilung spart nicht automatisch Geld; sie verbessert zunächst die Aussagekraft jedes Jobs. Ein Managed Agent passt zu kurzlebigen PR-Aufgaben, wenn das Image, die Xcode-Version und die Abhängigkeiten ausreichend kontrollierbar sind. Die Sicherheitsrichtlinien für GitHub Actions weisen unter anderem auf die Risiken nicht vertrauenswürdiger Änderungen und privilegierter Workflows hin. Deshalb sollten Sie einen PR aus einem nicht vertrauenswürdigen Kontext niemals direkt mit Produktionsgeheimnissen ausstatten.

Zweiter Schritt: Die Pipeline in Vertrauensstufen zerlegen

Eine belastbare Aufteilung sieht so aus:

1. Quellcode-Stufe: Gemeinsame Tests und statische Prüfungen laufen ohne Apple-Zertifikate.
2. Apple-Build-Stufe: Ein macOS-Job erzeugt die vorgesehenen Frameworks oder Anwendungen, aber noch ohne Produktionsschlüssel.
3. Simulator-Stufe: Nur freigegebene Branches oder Merge-Kandidaten verwenden das vorbereitete Simulatorprofil.
4. Archiv-Stufe: Das signierte Archiv entsteht in einem geschützten Job mit begrenztem Zugriff.
5. Veröffentlichungs-Stufe: Der Upload wird als separater manueller oder regelbasierter Deployment-Schritt behandelt.

Die Kotlin-Anleitung für iOS-CI/CD mit TeamCity zeigt, dass Build-, Signierungs- und Veröffentlichungsaktionen als konkrete Pipeline-Schritte behandelt werden müssen. Übertragen auf Ihre CI-Plattform bedeutet das: Definieren Sie nicht nur „Build erfolgreich“, sondern auch, welches Artefakt entstanden ist, mit welchem Ziel es gebaut wurde und welche Berechtigung dafür verwendet wurde.

SECTION 03Simulator, Geräteziel und Xcode 27 im Vergleich

Ein Managed Agent ist für standardisierte Aufgaben attraktiv, wenn Sie keine dauerhafte Arbeitsumgebung benötigen. Er kann für PR-Builds, wiederholbare Simulatorprüfungen und zeitweise Parallelität geeignet sein. Der Nachteil liegt in der geringeren Kontrolle über Image-Lebenszyklus, vorinstallierte Simulatoren, Cache-Erhalt und den Zeitpunkt von Änderungen am Runner-Image.

Ein eigener oder gemieteter Remote Mac ist dagegen sinnvoll, wenn Sie die Xcode-Version gezielt einfrieren, einen Cache über mehrere Jobs erhalten oder ein festes Netzwerkprofil benötigen. Das macht die Umgebung kontrollierbarer, aber nicht automatisch sicher. Sie müssen Zugänge, Workspace-Bereinigung, Neustarts, Protokollierung und Aktualisierungen selbst als Abnahmekriterien definieren.

Kotlin Multiplatform-Builds sollten daher mindestens die relevanten Apple-Ziele getrennt prüfen. Ein iosSimulatorArm64-Ergebnis beantwortet eine andere Frage als ein iosArm64-Ergebnis. Es wäre ein Fehlschluss, aus einem erfolgreichen Simulator-Build auf ein korrekt signiertes Gerätearchiv zu schließen.

Für Xcode 27 gilt zusätzlich eine klare Grenze: Solange Apple diese Version als Beta führt, sollten Sie sie als Test- oder Vorbereitungsumgebung behandeln, nicht als stillschweigende Grundlage für jedes Produktionsrelease. Verwenden Sie die Apple-Angaben zum Xcode-Status und zu den Systemanforderungen bei jeder Änderung des Build-Images erneut.

Dritter Schritt: Ein reproduzierbares Zielprofil festlegen

Dokumentieren Sie für jedes Releaseziel mindestens:

• Kotlin- und Gradle-Version;
• ausgewählte Xcode-Version und deren Status;
• Zielarchitektur, etwa iosArm64 oder iosSimulatorArm64;
• verwendetes SDK und Simulatorprofil;
• Herkunft der Abhängigkeiten;
• Cache-Strategie und maximale Lebensdauer;
• erforderliche Netzwerkziele;
• erwartetes Artefakt und Prüfsumme.

Diese Liste enthält keine universell richtigen Versionswerte. Sie zwingt Sie jedoch, eine konkrete Umgebung zu benennen, statt „aktuelles Xcode“ als nicht reproduzierbare Variable zu verwenden.

SECTION 04Wie isolieren Sie Signierung und TestFlight-Veröffentlichung?

Die Produktionsveröffentlichung ist kein gewöhnlicher Build. Sie verbindet Quellcode, Archiv, Distribution Certificate, Keychain, App-Store-Berechtigungen und einen Upload-Kanal. Kotlin Multiplatform kann den iOS-Build automatisieren; die Vertrauensgrenze Ihrer Organisation bleibt davon unberührt.

Die Apple-Anleitung zum Hochladen von Builds zu App Store Connect beschreibt den vorgesehenen Upload-Prozess. Für die Pipeline folgt daraus, dass Sie den Upload als kontrollierte Handlung mit eigener Berechtigung behandeln sollten, anstatt jedes PR-Artefakt in derselben Umgebung signieren zu lassen.

Ein mögliches Berechtigungsmodell:

App-Store-Connect-API-Schlüssel, Zertifikate und Keychain-Material gehören nicht in den allgemeinen PR-Kontext. Legen Sie sie in einem geschützten Secret-System ab, begrenzen Sie den Workflow-Zugriff und protokollieren Sie jede Veröffentlichung. Deployment-Schutzregeln in GitHub Actions können dabei als Referenz für Freigaben und Umgebungsgrenzen dienen, unabhängig davon, welche CI-Plattform Sie einsetzen.

Vierter Schritt: Den Zertifikatsfluss abnehmen

Prüfen Sie den Releasepfad in dieser Reihenfolge:

1. Der Job erhält nur die Secrets, die für das konkrete Ziel notwendig sind.
2. Das Zertifikat wird ausschließlich in einer temporären oder klar isolierten Keychain verwendet.
3. Das Archiv wird nach der Signierung auf Team-ID, Bundle-ID und erwartete Entitlements geprüft.
4. Der Upload erhält eine eigene Freigabe und ist nicht automatisch aus jedem Branch möglich.
5. Logs dürfen keine Schlüssel, Profile oder sensiblen Umgebungsvariablen ausgeben.
6. Nach dem Job werden Arbeitsverzeichnis, temporäre Dateien und importierte Schlüssel entfernt.
7. Ein absichtlich abgebrochener Release wird gesperrt, nachvollziehbar wiederaufgenommen oder sauber neu gestartet.

Für mehrere Anwendungen und langfristig kontrollierte Releaseprozesse ist ein dedizierter Remote Mac häufig leichter zu begrenzen als ein breit genutzter, kurzlebiger Agent. Das gilt besonders, wenn Ihre Organisation eine feste Netzwerkroute, nachvollziehbare administrative Zugriffe oder eine getrennte Keychain-Policy verlangt. Prüfen Sie dennoch die tatsächliche Isolation: Ein dedizierter Knoten mit gemeinsamem Administratorkonto, offenen SSH-Schlüsseln und fehlender Protokollierung ist kein belastbares Sicherheitsdesign.

SECTION 05Private Abhängigkeiten und Kapazität in einer hybriden Architektur

Private Git-Repositories, interne Paketregister, Unternehmensproxy, feste IP-Freigaben oder Vorgaben zur Datenresidenz verändern die Auswahl des Knotens. Ein Managed Agent ist nur dann geeignet, wenn seine Netzwerk- und Datenverarbeitungsgrenzen zu Ihrer Sicherheitsfreigabe passen. Erweitern Sie nicht einfach die Secret-Berechtigungen, um eine ungeeignete Netzwerktopologie zu reparieren.

Bei einem dedizierten Remote Mac müssen Sie mindestens Konto-Isolation, Zugriff über SSH oder VNC, Workspace-Bereinigung, unbeaufsichtigte Neustarts, Patchfenster und Audit-Logs abnehmen. Self-hosted-Runner-Dokumentation und Dokumentation zu GitHub-hosted Runnern verdeutlichen die unterschiedliche Betriebsverantwortung: Bei selbst betriebenen Runnern liegt die Kontrolle über Maschine und Software zugleich bei Ihnen, damit aber auch die Verantwortung für deren Absicherung.

Fünfter Schritt: Mit vier Lastbildern planen

Planen Sie nicht anhand einer durchschnittlichen Build-Zahl, sondern anhand von vier getrennten Zuständen:

• Tagesbasis: Regelmäßige PR- und Merge-Prüfungen;
• Release-Spitze: Mehrere Archive oder TestFlight-Freigaben in engem Zeitfenster;
• Knotenausfall: Ein Mac oder ein Runner-Image ist nicht verfügbar;
• Xcode-Pilot: Eine neue, gegebenenfalls noch als Beta geführte Umgebung wird parallel geprüft.

Ein einfaches Kapazitätsmodell lautet:

Benötigte Mac-Kapazität = Tageslast + Spitzenlast + Ausfallreserve + Pilotbedarf

Bewerten Sie jede Komponente mit Ihrer tatsächlichen Jobdauer, Parallelität und zulässigen Wartezeit. Setzen Sie keine erfundenen Eurobeträge oder pauschalen Einsparquoten ein. Die Kostenformel kann trotzdem vollständig sein:

Gesamtkosten = Managed-Jobverbrauch + feste Mac-Mietkosten + CI-Verwaltung + Sicherheitsprüfung + Ausfallkosten

Für die Entscheidung müssen Sie außerdem die Auslastung eines dedizierten Knotens messen. Ein Mac, der nur während eines kurzen Releasefensters benötigt wird, kann als feste Basis unwirtschaftlich sein; ein Knoten mit privaten Abhängigkeiten und dauerhaft vorbereiteter Umgebung kann trotz niedriger Auslastung eine begründete Kontrollkomponente darstellen.

Kotlin Multiplatform iOS CI: verwaltet oder selbst betrieben?

Wählen Sie Managed Agents, wenn Ihre Hauptlast aus standardisierten PR-Prüfungen, zeitweise benötigten Simulator-Builds und stark schwankender Parallelität besteht. Sie profitieren von der schnelleren Bereitstellung, müssen aber Imageänderungen, verfügbare Xcode-Versionen und Datenzugriffsgrenzen regelmäßig prüfen.

Wählen Sie einen dedizierten Remote Mac, wenn Produktionssignierung, private Netzwerkabhängigkeiten, feste Xcode-Versionen oder eine dauerhaft vorbereitete Umgebung den Ausschlag geben. Sie erhalten mehr Kontrolle über den Knoten, übernehmen aber Patch-, Zugangs-, Wiederanlauf- und Bereinigungsaufgaben.

Wählen Sie die hybride Variante, wenn mindestens zwei Bedingungen gleichzeitig gelten: Ihre PR-Last schwankt deutlich, während Releasejobs feste Umgebungen brauchen; oder Ihre internen Abhängigkeiten dürfen nicht auf beliebige Runner gelangen, während öffentliche Prüfungen elastisch skalieren sollen. Die feste Produktionsbasis bleibt dann klein und kontrolliert, die zusätzliche Kapazität wird nur für geeignete, nicht privilegierte Aufgaben aktiviert.

SECTION 06Der belastbare nächste Schritt für Ihre Beschaffung

Markieren Sie zunächst in Ihrer Pipeline alle Jobs, die iosArm64, iosSimulatorArm64, Simulatorzugriff, private Netzwerke, Zertifikate oder App-Store-Uploads verwenden. Trennen Sie anschließend die Jobs, die lediglich gemeinsamen Kotlin-Code prüfen. Erst danach vergleichen Sie Runnerpreise, Mietkosten oder vorhandene Hardware.

Wenn Sie die Mac-Basis nicht dauerhaft kaufen möchten, kann ein gemieteter Remote Mac von MACNOX als isolierter Pilotknoten dienen. Das ist keine pauschale Zusage, dass Miete immer günstiger ist. Sie sollten mit echten Queue-Zeiten, Build-Artefakten, Neustartprotokollen und Wiederherstellungsübungen prüfen, ob der Knoten Ihre Produktionsanforderungen erfüllt. Einen Überblick über die verfügbaren MACNOX-Mac-Lösungen können Sie dabei getrennt von Ihrer technischen Abnahme betrachten.

Ein Managed-only-Modell hat als aktuelle Lösung drei konkrete Schwächen: Die Xcode- und Simulatorumgebung kann stärker vom Runner-Image abhängen, private Netzwerkzugriffe sind nicht immer zulässig, und die Kontrolle über langfristig benötigte Signierungsgrenzen ist verteilt. Eine lokale Beschaffung vermeidet einige dieser Punkte, verursacht aber Beschaffung, Hardwarealterung, Ersatzteilplanung und ungenutzte Kapazität. Für einen zeitlich begrenzten KMP-Piloten oder schwankende Release-Last kann ein Remote Mac deshalb die bessere operative Balance bieten, sofern Sie die Isolation und Wiederherstellung nachweisbar prüfen.

Wenn Ihre Messung eine dauerhafte, hohe und planbare Last ergibt, kann der Kauf eigener Hardware weiterhin sinnvoll sein. Wenn dagegen Spitzen, Pilotphasen oder mehrere parallele Xcode-Umgebungen dominieren, prüfen Sie die aktuellen MACNOX-Mietoptionen anhand Ihrer realen Jobdaten. Der nächste sinnvolle Schritt ist nicht die sofortige Vergrößerung des Pools, sondern ein abgegrenzter KMP-Produktionsversuch mit klaren Abnahmekriterien.

SECTION 07Weiterlesen

• iOS-Simulator auf einem macOS-Cloud-Server: technische Abnahme für CI und Tests
• Mac mini M4 mieten oder kaufen: TCO und Break-even für eigene CI-Knoten
• Remote-Zugriff auf den iOS-Simulator: Browser, VNC und SSH im CI-Workflow