Swift Testing: Linux- und macOS-CI aufteilen

📋 Inhaltsverzeichnis

Fehlerbild: Die Swift-Tests laufen unter Linux durch, aber Sie wissen nicht, ob damit auch der Apple-Build abgesichert ist.
Schnellste Lösung: Führen Sie plattformunabhängige Swift-Package-Tests auf Linux aus und verlagern Sie Prüfungen mit Apple SDK, Xcode, Simulator oder Signierung auf macOS.

Für wen dieser Leitfaden gedacht ist: Sie pflegen ein plattformübergreifendes Swift Package und möchten allgemeine Tests in Ihrer Linux-CI behalten.
Sie entwickeln Apple-Plattform-Apps und müssen Package-Tests von Xcode-Prüfungen abgrenzen.
Sie planen macOS-CI-Kapazität oder prüfen, ob ein Remote Mac eine konkrete Aufgabe übernehmen kann.

Swift Testing unter Linux und macOS: Die Grenze folgt den Abhängigkeiten

Swift Testing kann in einer Linux-CI eingesetzt werden. Daraus folgt aber nicht, dass jedes Swift-Testziel unter Linux ausführbar ist. Die Plattformübersicht im offiziellen Swift-Testing-Projekt nennt Linux und Apple-Plattformen als unterstützte Umgebungen. Für Ihr Projekt bleibt entscheidend, welche APIs, Abhängigkeiten und Systemfunktionen der zu prüfende Code tatsächlich benötigt.

Prüfen Sie daher nicht nur, ob ein Test mit Swift Testing geschrieben wurde. Prüfen Sie, ob sein gesamter Pfad für die Zielplattform gebaut werden kann: das Testziel, importierte Module, transitive Abhängigkeiten, bedingte Kompilierung und die verwendeten Laufzeitfunktionen. Die Swift-Plattformübersicht hilft dabei, die allgemeine Plattformunterstützung der Sprache einzuordnen. Sie ersetzt nicht die Prüfung Ihrer konkreten Paketkonfiguration.

Ein Swift Package, das Datenmodelle, Parser oder reine Geschäftsregeln testet, kann sich für Linux eignen, sofern seine Abhängigkeiten dort ebenfalls verfügbar sind. Sobald ein Test UIKit, SwiftUI oder eine andere Apple-spezifische Schnittstelle voraussetzt, reicht die allgemeine Unterstützung von Swift Testing nicht aus. Die UIKit-Dokumentation beschreibt ein Apple-Plattform-Framework; ein erfolgreicher Linux-Lauf eines anderen Testziels beweist nicht, dass UIKit-Code auf Linux gebaut oder ausgeführt werden kann.

Szenario	Linux-CI	macOS-CI	Einschätzung
Package mit plattformneutraler Logik und passenden Abhängigkeiten	Tests ausführen und Ergebnisse sichern	Optional für dieselben allgemeinen Tests	Linux ist ein geeigneter Prüfpfad, ersetzt aber keine separaten Apple-Plattformprüfungen.
Testziel mit Apple-Frameworks oder plattformspezifischen APIs	Nur tatsächlich kompatible Teilziele prüfen	Build und Tests in der benötigten Apple-Umgebung ausführen	macOS ist erforderlich, sobald der Testpfad Apple-SDKs voraussetzt.
App-Build, Simulatorlauf, UI-Automatisierung oder Signierung	Kein Ersatz für die Apple-Werkzeuge	Xcode-Aufgabe gezielt ausführen	Linux kann ergänzen, aber diese Apple-Plattformnachweise nicht liefern.

Die Tabelle ist eine Zuordnungshilfe, keine pauschale Aussage über jedes Package. Die PackageDescription-Dokumentation des Swift Package Manager beschreibt, wie Packages und Targets deklariert werden. Nutzen Sie diese Struktur, um zu erkennen, ob ein Testziel durch Plattformbedingungen, Produkte oder Abhängigkeiten eingeschränkt ist.

Allgemeine Package-Tests statt Apple-Plattformprüfungen

Wenn Ihre Tests reine Swift-Logik abdecken, kann Linux Arbeit übernehmen, die keinen Apple-spezifischen Build voraussetzt. Dazu können Prüfungen gehören, die Eingaben verarbeiten, Regeln anwenden oder Ergebnisse vergleichen. Ob ein konkreter Test in diese Gruppe fällt, entscheidet jedoch nicht sein Name: Ein scheinbar allgemeiner Test kann indirekt auf ein plattformspezifisches Modul zugreifen.

Gehen Sie den Abhängigkeitsgraphen vom Testziel aus durch. Erfassen Sie direkte und transitive Packages, importierte Module sowie Code, der über Bedingungen wie #if os(...) unterschiedliche Implementierungen auswählt. Ein Linux-Erfolg bestätigt nur den Code, der unter Linux tatsächlich kompiliert und getestet wurde. Er sagt nichts über einen Apple-spezifischen Zweig aus, den diese Ausführung übersprungen hat.

Für ein erstes Signal können Sie den vorgesehenen Package-Testbefehl in der Linux-Umgebung ausführen:

swift test

Der Swift Package Manager dokumentiert seine Funktionen in der offiziellen Package-Manager-Dokumentation. Verwenden Sie den Befehl nicht als abstrakten Kompatibilitätstest: Er muss im selben Container- oder Runner-Kontext laufen, den Ihre CI später verwendet. Ein lokaler Erfolg auf einer anderen Plattform ist kein Ersatz für diesen Lauf.

Dokumentieren Sie, welche Testziele ausgeführt wurden und welche aus Plattformgründen nicht in die Linux-Aufgabe gehören. Wenn Sie ein plattformübergreifendes Package aufteilen, sollte die CI-Matrix die Aufteilung sichtbar machen, statt nur einen allgemeinen Status wie „Tests bestanden“ zu melden.

Apple-SDK, Xcode und Simulator bleiben eigene Nachweise

Ein App-Build benötigt die passende Apple-Toolchain und das jeweilige SDK. Simulatorprüfungen benötigen zusätzlich eine geeignete Simulatorumgebung; UI-Tests müssen die App in der dafür vorgesehenen Umgebung ausführen. Wenn die Auslieferung Signierung voraussetzt, muss auch dieser Schritt in einem dafür geeigneten Apple-Plattformablauf stattfinden. Linux-Tests können diese Aufgaben nicht stellvertretend erledigen.

Apple beschreibt in der Dokumentation zum Testen mit Xcode, welche Testarten über Xcode ausgeführt werden können. Die Anleitung zum Hinzufügen von Tests zu einem Xcode-Projekt ordnet Tests den Testzielen eines Projekts zu. Für das Ausführen einer App auf simulierten oder physischen Geräten gelten die von Apple beschriebenen Anforderungen an die jeweilige Umgebung; siehe die Dokumentation zu Simulatoren und Geräten.

Auch wenn ein App-Projekt ein wiederverwendbares Swift Package enthält, darf dessen Linux-Test nicht mit dem Nachweis verwechselt werden, dass die App für ein Apple-Betriebssystem gebaut werden kann. Trennen Sie im CI-Bericht daher mindestens drei Arten von Ergebnissen: Package-Logik, Apple-Plattform-Build und Laufzeittests wie Simulator- oder UI-Prüfungen. Die konkrete Aufteilung hängt davon ab, welche Testziele Ihr Projekt tatsächlich besitzt.

CI-Aufgabe	Beleg, den der Lauf liefern sollte	Was ein grüner Status nicht beweist
Linux-Test eines kompatiblen Package-Ziels	Commit, Ziel, Plattform und Testergebnis	Dass Apple-Frameworks oder App-Ziele gebaut wurden
Xcode-Build auf macOS	Projekt beziehungsweise Scheme, SDK-Kontext und Build-Ergebnis	Dass UI-Verhalten auf einem Gerät fehlerfrei ist
Simulator- oder UI-Test	Ausgewählte Laufumgebung und Testbericht	Dass eine erforderliche Signierung oder Verteilung abgeschlossen ist
Signierungsbezogene Prüfung	Nachvollziehbare Ausgabe des vorgesehenen Apple-Ablaufs	Dass nicht ausgeführte Package-Tests bestanden sind

Achten Sie besonders auf bedingte Kompilierung: Ein Testziel kann auf Linux erfolgreich sein, weil ein Apple-spezifischer Zweig dort gar nicht kompiliert wird. Markieren Sie deshalb im Bericht nicht nur den Status, sondern auch Plattform und tatsächlich ausgeführte Ziele.

Gemeinsame Quellen, bedingte Kompilierung und abweichende Resultate

Bei gemeinsam genutztem Code können dieselben Quelldateien auf Linux und macOS unterschiedliche Zweige durchlaufen. Dazu kommen Abhängigkeiten, die nur für bestimmte Plattformen verfügbar sind, und Systemverhalten, das sich zwischen den Umgebungen unterscheidet. Vergleichen Sie deshalb nicht ausschließlich, ob beide CI-Aufträge grün sind. Vergleichen Sie, welche Assertions, Module und Testziele tatsächlich in jedem Auftrag enthalten waren.

Eine belastbare Matrix macht diese Unterschiede sichtbar. Wenn ein Test unter Linux wegen einer Plattformbedingung übersprungen wird, führen Sie ihn nicht stillschweigend als erledigt. Halten Sie fest, welcher macOS-Auftrag den betreffenden Pfad übernimmt. Wenn eine Abhängigkeit auf einer Plattform fehlt, entscheiden Sie, ob das Testziel getrennt, die Implementierung abstrahiert oder die betreffende Prüfung ausschließlich auf der passenden Plattform ausgeführt werden soll.

Die folgende Matrix bewertet keine Laufzeit und verspricht keine Beschleunigung. Sie hilft, fehlende Nachweise vor dem Zusammenführen oder Veröffentlichen zu erkennen.

Prüffeld	Linux-Auftrag	macOS-Auftrag	Bewertung
Gleicher Commit geprüft	Commit-ID im Laufbericht erfassen	Dieselbe Commit-ID erfassen	Hoch, wenn beide Ergebnisse eindeutig zusammengehören
Testziele benannt	Ausgeführte und ausgeschlossene Ziele festhalten	Ausgeführte und ausgeschlossene Ziele festhalten	Hoch, wenn die Abdeckung nachvollziehbar ist
Plattformzweige abgedeckt	Linux-spezifischen Pfad nachweisen	Apple-spezifischen Pfad nachweisen	Hoch, wenn kein Zweig nur vermutet wird
Artefakte und Berichte verfügbar	Testergebnis und relevante Ausgabe sichern	Build- und Testbericht sichern	Mittel, wenn Berichte nicht eindeutig einem Commit zugeordnet sind
Gesamtergebnis zusammengeführt	Linux-Status getrennt ausweisen	Apple-Status getrennt ausweisen	Niedrig, wenn ein grüner Einzelauftrag als vollständige Freigabe gilt

Linux und macOS als zusammengehörige CI-Spuren betreiben

Wenn Ihre bestehende Pipeline bereits allgemeine Tests auf Linux ausführt, müssen Sie diese Arbeit nicht allein deshalb auf macOS verschieben, weil das Projekt auch eine Apple-App enthält. Ergänzen Sie stattdessen einen macOS-Auftrag für die Apple-spezifischen Aufgaben. Beide Spuren müssen sich auf denselben Quellstand beziehen und getrennte, verständliche Testnachweise liefern.

Ein umsetzbarer Ablauf:

Testziele inventarisieren. Listen Sie Packages, App-Targets und Testziele auf. Notieren Sie, welche Frameworks und externen Abhängigkeiten jedes Ziel importiert.
Plattformbedingungen markieren. Prüfen Sie bedingte Kompilierung, plattformspezifische Abhängigkeiten und APIs. Trennen Sie dabei „kann unter Linux gebaut werden“ von „deckt den Apple-Pfad ab“.
Linux-Aufgaben festlegen. Verschieben Sie nur solche Tests in den Linux-Auftrag, deren vollständiger Abhängigkeits- und Ausführungspfad dort funktioniert. Lassen Sie den CI-Befehl in der tatsächlichen Runner-Umgebung laufen.
macOS-Aufgaben ergänzen. Führen Sie Xcode-Builds, Apple-SDK-Prüfungen, Simulator- oder UI-Tests sowie notwendige Signierungsschritte auf macOS aus.
Ergebnisse an denselben Commit binden. Speichern Sie Commit, Testziel, Plattform und Bericht für jeden Auftrag. Zusammengehörige Läufe dürfen nicht aus unterschiedlichen Quellständen zusammengesetzt werden.
Die Matrix bei Änderungen aktualisieren. Wenn ein Package eine neue Abhängigkeit erhält oder ein Testziel Apple-APIs importiert, prüfen Sie die Zuordnung erneut. Eine frühere Linux-Freigabe gilt nicht automatisch für eine veränderte Abhängigkeitsstruktur.

Legen Sie außerdem fest, wer fehlende Testergebnisse freigibt. Ein Teammitglied sollte nicht aus dem allgemeinen CI-Status ableiten müssen, ob der Simulatorlauf tatsächlich ausgeführt wurde. Apple beschreibt mit Testplänen eine Möglichkeit, Tests in Xcode zu organisieren und Feedback gezielter zu strukturieren; Details finden Sie in der Dokumentation zu Testplänen.

Entscheidung nach Aufgaben statt nach Runner-Verfügbarkeit

Verwenden Sie diese Bedingungen, bevor Sie einen Auftrag Linux oder macOS zuweisen:

Wenn das Testziel keine Apple-SDKs, Apple-Frameworks, Simulatorfunktionen oder Signierung benötigt und seine Abhängigkeiten Linux unterstützen, dann führen Sie es auf Linux aus. Andernfalls gehört es nicht ohne weiteren Nachweis in den Linux-Pfad.
Wenn die Aufgabe einen Xcode-Build, ein Apple SDK oder einen Simulator erfordert, dann führen Sie diese Prüfung auf macOS aus. Ein Linux-Test kann parallel laufen, ersetzt sie aber nicht.
Wenn derselbe Quellcode plattformabhängige Zweige enthält, dann ordnen Sie jedem Zweig einen expliziten Prüfauftrag zu. Wenn ein Zweig in der CI nicht ausgeführt wird, kennzeichnen Sie ihn als nicht geprüft.
Wenn Ihr Projekt ausschließlich plattformunabhängige Package-Tests enthält, dann ist ein macOS-Auftrag nicht automatisch nötig. Wenn eine Apple-Auslieferung zum Projekt gehört, ergänzen Sie die erforderliche Apple-Plattformprüfung.
Wenn Sie noch unsicher sind, testen Sie zunächst ein konkretes Testziel in beiden vorgesehenen Umgebungen und vergleichen Sie Build-Ausgabe, Testbericht und Abhängigkeiten. Verschieben Sie nicht vorsorglich die gesamte Pipeline.

Die Trennung sollte auch Datenschutz und Stabilität berücksichtigen. Für macOS-Aufträge mit Zertifikaten oder anderen Geheimnissen müssen Sie den Zugriff auf erforderliche CI-Identitäten begrenzen und deren Verwendung protokollieren. Legen Sie fest, welche Build-Artefakte und Testberichte gespeichert werden, wer darauf zugreifen darf und wann sie entfernt werden. Bei einem extern betriebenen Ausführungssystem sollten Sie vor der Nutzung außerdem die Datenflüsse und internen Vorgaben zur DSGVO prüfen. Das sind Betriebsanforderungen, keine pauschale Zusicherung über einen bestimmten Runner.

FAQ: Plattformgrenzen von Swift Testing

Kann ich Swift Testing in einer Linux-CI ausführen?

Ja, sofern das Paket, das Testziel, seine Abhängigkeiten und die getesteten Codepfade mit Linux kompatibel sind. Die offizielle Plattformübersicht von Swift Testing nennt Linux als unterstützte Plattform. Das ist jedoch keine Zusage, dass jedes Apple-Projekt oder jede Testfunktion dort läuft. Prüfen Sie den konkreten Abhängigkeitsgraphen und lassen Sie den Testbefehl in der tatsächlichen Linux-Umgebung ausführen.

Welche Swift-Package-Tests brauchen einen macOS-Runner?

Ein macOS-Runner ist erforderlich, wenn ein Test Apple-Plattform-Frameworks oder APIs voraussetzt, die unter Linux nicht verfügbar sind, oder wenn der Prüfschritt Xcode, ein Apple SDK, den Simulator oder Signierung benötigt. Entscheidend ist nicht die Dateiendung und auch nicht, ob ein Package grundsätzlich plattformübergreifend ist. Prüfen Sie die Abhängigkeiten des jeweiligen Testziels und die konkrete Plattformanforderung.

Reicht ein erfolgreicher Linux-Test als Nachweis für Xcode?

Nein. Ein erfolgreicher Linux-Lauf belegt nur die getesteten Codepfade in der Linux-Umgebung. Er ersetzt weder den Build mit dem vorgesehenen Apple SDK noch Simulator- oder UI-Tests und auch keine notwendige Signierungsprüfung. Dokumentieren Sie die Plattform, den Commit, das Testziel und die erzeugten Ergebnisse, damit ein grüner Linux-Lauf nicht mit einer vollständigen Apple-Plattformfreigabe verwechselt wird.

Wie teile ich die CI eines plattformübergreifenden Swift-Projekts auf?

Ordnen Sie Testziele nach ihren tatsächlichen Plattformabhängigkeiten zu. Lassen Sie plattformunabhängige Paketprüfungen auf Linux laufen und führen Sie Apple-SDK-, Xcode-, Simulator- und Signierungsaufgaben auf macOS aus. Sichern Sie bei beiden Läufen denselben Commit und halten Sie fest, welche Ziele ausgeführt wurden. So entstehen zusammengehörige Ergebnisse statt zweier nicht vergleichbarer CI-Aussagen.

Wenn Ihre vorhandene Linux-CI nur Apple-spezifische Nachweise offenlässt, ist das kein Grund, die gesamte Pipeline zu ersetzen: Ergänzen Sie zunächst genau die macOS-Aufgabe, die Ihr Projekt tatsächlich benötigt. Eine selbst verwaltete Mac-Umgebung kann mehr Wartungs- und Betriebsarbeit bedeuten; eine gemietete Ausführung ist eher für zeitweise benötigte Apple-Plattformprüfungen interessant. Prüfen Sie vor einer Entscheidung die eigenen Anforderungen an Werkzeuge, Geheimnisse, Stabilität und Datenverarbeitung. Als technische Einordnung können Sie unseren Vergleich zu Bare Metal und macOS-Virtualisierung heranziehen. Testen Sie anschließend einen realen Xcode- oder Simulatorauftrag samt Ergebnisbericht, bevor Sie daraus einen dauerhaften Bedarf ableiten. Wenn Sie dafür eine Mac-Umgebung erwägen, finden Sie die Angaben zu den MacDate-Angeboten und gleichen Sie sie mit Ihren CI-Anforderungen ab.