Xcode 27: Wie wählen Sie die Interoperabilität von Swift Testing und XCTest? Leitfaden 2026

Swift Testing und XCTest können in einem Projekt nebeneinander eingesetzt werden. Das bedeutet jedoch nicht, dass jede Funktion des einen Frameworks innerhalb eines Tests des anderen Frameworks gleich behandelt wird. Die Interoperabilitätseinstellung bestimmt, wie bestimmte Probleme an der Grenze zwischen den Frameworks behandelt werden. Sie ersetzt weder XCTest noch Swift Testing als Ganzes.

Ein kleines Beispiel zeigt, was Sie bewerten sollten:

import Testing
import XCTest

@Test
func legacyAssertionFromSwiftTesting() {
    XCTAssertTrue(true)
}

Der Test wird mit Swift Testing deklariert, ruft aber eine Assertion aus XCTest auf. Bei der Wahl des Modus geht es nicht nur darum, ob dieser Test kompiliert oder ausgeführt wird. Entscheidend ist auch, ob ein Problem sichtbar wird, welchen Schweregrad es erhält und ob das Ergebnis für Ihr Team und Ihre CI-Auswertung eindeutig ist.

Die Apple-Migrationsanleitung für den Übergang von XCTest beschreibt, wie Sie vorhandene Tests schrittweise weiterverwenden und neue Tests ergänzen können. XCTest bleibt zugleich ein eigenständiges Framework; seine APIs sind weiterhin relevant, wenn Ihr Bestand darauf aufbaut.

Trennen Sie bei der Prüfung vier Fragen:

• Koexistenz: Beide Frameworks dürfen im selben Projekt oder Testsatz vorkommen.
• Aufrufrichtung: Ein Test kann eine API des jeweils anderen Frameworks verwenden. Prüfen Sie, welche dieser Übergänge tatsächlich in Ihrem Bestand vorkommen.
• Problembehandlung: Der Interoperabilitätsmodus beeinflusst, wie solche Probleme behandelt und angezeigt werden.
• Ausführung: Ein erfolgreicher Testlauf beweist allein nicht, dass die Einstellung den von Ihrem Team erwarteten Schweregrad liefert.

Die WWDC26-Vorführung zur Migration erläutert die Übergänge anhand von Beispielen. Betrachten Sie die dort gezeigten Resultate jedoch als Erklärung, nicht als Messung Ihrer eigenen Umgebung. Maßgeblich bleiben Ihr Projekt, der ausgewählte Testplan und der tatsächliche Ausführungspfad.

Können Swift Testing und XCTest im selben Testpaket koexistieren?

Ja. Sie können beide Frameworks im selben Testsatz verwenden und Tests schrittweise ergänzen, statt den Bestand auf einmal umzuschreiben. Für die Abnahme genügt die bloße Koexistenz aber nicht. Prüfen Sie, welches Framework den Test ausführt und ob frameworkübergreifende Aufrufe gemäß Ihrer Teamregel behandelt werden.

Die Modi limited, complete, strict und none stehen für unterschiedliche Regeln zur Behandlung frameworkübergreifender Probleme. Entscheidend ist, wie sichtbar ein Problem wird und wie stark die Konfiguration die betreffende Verwendung einschränkt. Die Xcode-27-Veröffentlichungshinweise beschreiben die Modi. Gleichen Sie die dortige Definition mit einem kleinen Test in Ihrem Projekt ab, bevor Sie eine Teamvorgabe festlegen.

• limited – bestehende Kompatibilität prüfen: Dieser Modus ist besonders wichtig, wenn ein älterer Testplan nach einem Upgrade weiterhin eine frühere Einstellung verwendet. Behandeln Sie ihn nicht als Beleg dafür, dass die Migration vollständig geprüft wurde. Ermitteln Sie stattdessen, welche Hinweise und Einschränkungen in Ihrem konkreten Testlauf sichtbar sind.
• complete – Migration mit erhaltener Einstufung bewerten: Dieser Modus ist ein sinnvoller Ausgangspunkt für eine schrittweise Migration. Relevante Probleme behalten ihre ursprüngliche Schweregradeinstufung. Dadurch können Sie beurteilen, ob ein Frameworkwechsel die Diagnose verändert hat, ohne dass sich der Testinhalt geändert hat.
• strict – gezielte Durchsetzung: Wählen Sie diesen Modus, wenn Ihre Richtlinie bestimmte frameworkübergreifende Aufrufe ausdrücklich verhindern soll. Er ist keine pauschale Lösung für einen Bestand, dessen Aufrufe noch nicht untersucht wurden. Legen Sie vorher fest, welche Verstöße unterbunden werden und wie sie behoben werden sollen.
• none – Interoperabilitätsbehandlung ausschalten: Verwenden Sie diesen Modus allenfalls für eine begrenzte Diagnose mit einer klaren Hypothese. Als dauerhafte Einstellung kann er relevante Probleme verdecken. Ein grüner CI-Lauf ist kein ausreichender Grund, ein wichtiges Signal aus der Auswertung zu entfernen.

Sollten Sie limited oder complete wählen?

Für die schrittweise Migration ist complete der geeignetere Ausgangspunkt, wenn Sie Probleme sichtbar halten und ihre ursprüngliche Schweregradeinstufung bewahren möchten. Ältere Testpläne können weiterhin limited verwenden. Wechseln Sie deshalb nicht blind den Modus, sondern prüfen Sie zuerst den aktiven Testplan. Führen Sie danach denselben Test aus und vergleichen Sie das Ergebnis mit der Teamvorgabe.

Entscheiden Sie nicht danach, welches Framework grundsätzlich vorzuziehen ist. Fragen Sie stattdessen, ob der Bestand vorerst unverändert weiterlaufen muss, ob Übergangsprobleme samt bisherigem Schweregrad sichtbar bleiben sollen oder ob bestimmte Aufrufe künftig verboten werden sollen. Erst wenn diese Anforderungen feststehen, können Sie limited, complete oder strict nachvollziehbar begründen.

Hinweis: Setzen Sie none nicht ein, nur weil ein CI-Job danach wieder erfolgreich ist. Dokumentieren Sie zunächst das konkrete Problem, die erwartete Wirkung der Einstellung und eine mögliche gezielte Korrektur. Sonst verlieren Sie ein wichtiges Diagnosesignal, ohne die Ursache zu beseitigen.

Die verwendete Xcode-Version verrät nicht automatisch, welcher Interoperabilitätsmodus in Ihrem Projekt aktiv ist. Ein älterer Testplan kann eine frühere Konfiguration wie limited beibehalten, während ein neu angelegtes Projekt eine andere Voreinstellung nutzt. Leiten Sie den tatsächlich verwendeten Wert daher nicht allein aus einem Upgrade auf Xcode 27 ab.

Apple behandelt Testpläne als Teil der Testorganisation und -ausführung. Prüfen Sie den konkreten Plan in Xcode und gleichen Sie ihn mit der Dokumentation zur Organisation von Tests und Testplänen ab. Achten Sie darauf, dass Sie den Plan kontrollieren, der im verwendeten Scheme tatsächlich ausgewählt ist. Eine Änderung an einem Plan, den der Testlauf nicht nutzt, verändert dessen Verhalten nicht.

Gehen Sie für eine belastbare Prüfung in dieser Reihenfolge vor:

1. Öffnen Sie das Scheme, das lokal und in CI für den betreffenden Testlauf verwendet wird.
2. Ermitteln Sie, welcher Testplan für diesen Lauf ausgewählt ist.
3. Kontrollieren Sie die Interoperabilitätseinstellung im ausgewählten Plan.
4. Halten Sie fest, ob der Plan aus einem älteren Projekt übernommen oder neu angelegt wurde.
5. Führen Sie einen Test aus, der tatsächlich einen Aufruf zwischen XCTest und Swift Testing enthält.
6. Vergleichen Sie die sichtbaren Probleme und ihre Schweregrade mit Ihrer Teamvorgabe.
7. Wiederholen Sie den Test mit dem vorgesehenen CI-Ausführungspfad.

Die Apple-Anleitung zum Ausführen von Tests und Interpretieren der Ergebnisse hilft dabei, Xcode-Ausgaben und Kommandozeilenläufe einzuordnen. Bewahren Sie den ausgewählten Testplan und das Ergebnis Ihres Minimaltests als Nachweis auf. So lässt sich später feststellen, ob ein verändertes Ergebnis vom Test selbst, von der Einstellung oder vom Ausführungspfad stammt.

Warum bleibt ein älterer Xcode-Testplan nach dem Upgrade auf limited?

Ein Upgrade belegt nicht, dass die Einstellungen jedes bestehenden Testplans geändert wurden. Ein Projekt kann weiterhin einen älteren Plan verwenden und damit eine frühere Einstellung beibehalten. Prüfen Sie den aktiven Plan im Scheme direkt. Erst ein Test mit einem frameworkübergreifenden Beispiel zeigt, ob die Wirkung Ihrer Erwartung entspricht.

Ein Swift Package und ein Xcode-Projekt können unterschiedliche Konfigurationswege verwenden. Daraus folgt nicht, dass beide automatisch denselben Modus haben. Auch der Toolchain-Stand und die Angabe swift-tools-version können für Ihre Bewertung relevant sein. Übertragen Sie einen beobachteten Standardwert deshalb nicht ungeprüft auf andere Pakete, Projekte oder Startpfade.

Das ist besonders wichtig, wenn lokale Entwickler Tests in Xcode starten, während CI ein Paket oder ein Scheme über die Kommandozeile ausführt. Die Ausführungspfade können unterschiedliche Konfigurationen und Einstiegspunkte nutzen. Dokumentieren Sie daher für jeden Pfad, welche Projektdatei, welcher Testplan und welche Toolchain tatsächlich verwendet werden.

Unterscheidet sich der Standardmodus bei Swift Package und Xcode-Projekt?

Behandeln Sie die Standardwerte nicht als identisch, solange Sie sie nicht für beide Projektarten geprüft haben. Vergleichen Sie die Einstellungen des Swift Package mit dem ausgewählten Xcode-Testplan. Berücksichtigen Sie außerdem Toolchain und swift-tools-version. Ein einzelner erfolgreicher Lauf begründet keine allgemeine Regel für andere Repositories.

Verwenden Sie für den Vergleich dieselbe Testlogik und möglichst vergleichbare Ausführungspfade:

• Legen Sie einen kleinen Test an, der eine XCTest-Assertion aus einem Swift-Testing-Test heraus aufruft.
• Führen Sie ihn im Swift-Package-Kontext aus und halten Sie Konfiguration und Ausgabe fest.
• Führen Sie denselben Fall über den ausgewählten Xcode-Testplan aus.
• Starten Sie anschließend den vorgesehenen CI-Aufruf und prüfen Sie, welches Scheme oder Paket er tatsächlich adressiert.
• Vergleichen Sie nicht nur „bestanden“ und „fehlgeschlagen“, sondern auch angezeigte Probleme, deren Schweregrad und die Zuordnung zum Testlauf.

Nutzen Sie keine Shell-Umgebungsvariable als vermeintlich allgemeine Abkürzung, wenn Apple für Ihren konkreten Ausführungspfad keine entsprechende Wirkung dokumentiert. Die Quelle muss zur Aussage passen: Ein Eintrag in den Release Notes belegt nicht automatisch das Verhalten jeder Package-Konfiguration. Wenn Sie in Ihrem Setup einen Wert ermitteln, halten Sie Toolchain, Projektart und Startbefehl fest.

Für Swift 6.4 gilt dieselbe Vorsicht. Die Version allein sagt Ihnen nicht, welcher Interoperabilitätsmodus in einem bestimmten Testplan aktiv ist. Trennen Sie eine Sprach- oder Toolchain-Migration von der Prüfung der Testplaneinstellung. Andernfalls kann ein veränderter Testbefund fälschlich der Swift-Version zugeschrieben werden, obwohl sich tatsächlich der Plan oder Ausführungspfad geändert hat.

Ein Modus ist für Ihr Team erst akzeptiert, wenn seine Wirkung überprüfbar ist. Verwenden Sie dafür nicht nur den Exit-Code des Testprozesses. Prüfen Sie, ob ein frameworkübergreifendes Problem erfasst wird, ob sein Schweregrad der Teamvorgabe entspricht und ob vorhandene Tests weiter ausgeführt werden. So vermeiden Sie sowohl unnötige Migrationsblockaden als auch den Verlust aussagekräftiger Hinweise.

Die Dokumentation zu Issue.record beschreibt, wie Swift Testing Probleme mit Schweregrad und Quellposition festhalten kann. Nutzen Sie diese Informationen, wenn Ihre Tests eigene Diagnosen ergänzen. Verwechseln Sie ein selbst aufgezeichnetes Issue jedoch nicht mit dem Nachweis, dass ein Interoperabilitätsmodus XCTest-Aufrufe wie gewünscht behandelt. Dafür benötigen Sie einen Test, der genau diesen Übergang abbildet.

Führen Sie die folgende Prüfliste für jeden relevanten Ausführungspfad aus:

• [ ] Der verwendete Testplan ist im Scheme eindeutig festgehalten.
• [ ] Der Modus wurde im aktiven Testplan geprüft und nicht aus der Xcode-Version abgeleitet.
• [ ] Ein Minimaltest enthält einen tatsächlichen Aufruf zwischen Swift Testing und XCTest.
• [ ] Das Ergebnis zeigt das erwartete Problem oder bestätigt dessen beabsichtigte Behandlung.
• [ ] Der gemeldete Schweregrad entspricht der Teamrichtlinie.
• [ ] Ein vorhandener XCTest-Test läuft nach der Änderung weiterhin.
• [ ] Der Swift-Package-Lauf und der Xcode-Lauf wurden getrennt bewertet.
• [ ] Die CI-Ausgabe lässt erkennen, welches Scheme beziehungsweise Paket ausgeführt wurde.
• [ ] Ein Wechsel zu none ist mit einem konkreten Diagnosezweck begründet und wird nach der Prüfung zurückgenommen oder ausdrücklich freigegeben.
• [ ] Die verwendete Toolchain und swift-tools-version sind im Prüfprotokoll dokumentiert.

Diese Prüfliste eignet sich auch für Remote-Mac-CI, ohne dass Sie eine einheitliche Umgebung voraussetzen. Führen Sie auf dem tatsächlichen Knoten denselben Testfall mit demselben ausgewählten Plan aus. Ein lokaler Xcode-Lauf kann korrekt sein, während der CI-Aufruf ein anderes Scheme oder einen anderen Pfad nutzt. Umgekehrt beweist eine Abweichung nicht automatisch einen Fehler des Interoperabilitätsmodus. Sie kann aus einer anderen Projekt- oder Toolchain-Konfiguration entstehen.

Bewahren Sie als Migrationsnachweis die Konfiguration, den Startbefehl und die relevante Ausgabe gemeinsam auf. Ergänzen Sie, ob der Lauf in Xcode, über die Kommandozeile oder auf dem CI-Knoten gestartet wurde. So lässt sich bei einem späteren Fehlerbericht feststellen, ob sich der Test, der Modus oder nur der Ausführungspfad geändert hat. Diese Trennung ist besonders hilfreich, wenn mehrere Teams denselben Bestand betreuen.

Wenn ein Lauf scheitert, ändern Sie nicht sofort den Modus. Prüfen Sie zuerst, ob der Test tatsächlich den erwarteten Plan verwendet. Kontrollieren Sie anschließend den konkreten frameworkübergreifenden Aufruf und gleichen Sie die Diagnose mit der Apple-Beschreibung ab. Entscheiden Sie erst dann, ob complete beibehalten, strict für eine gezielte Richtlinie eingeführt oder eine Teststelle angepasst werden soll. Bei none muss die Diagnosefrage dokumentiert sein; der Modus darf keine dauerhafte Abkürzung für die Ursachenanalyse werden.

Für viele Teams mit gemischtem Testbestand ist complete der sinnvollste Modus, um eine schrittweise Migration zu bewerten, sofern die tatsächliche Testplaneinstellung dazu passt. limited kann in älteren Plänen weiterhin aktiv sein. strict ist eine bewusste Richtlinienentscheidung. none bleibt ein Diagnosewerkzeug und sollte CI-Fehler nicht einfach unsichtbar machen.

Richten Sie die Entscheidung an der beobachteten Wirkung aus:

• Wenn vorhandene Tests ohne unangemessene Einschränkungen weiterlaufen müssen, prüfen Sie zuerst den aktuellen Modus und den ausgewählten Testplan.
• Wenn Sie Übergangsprobleme sichtbar halten und deren ursprüngliche Schweregradeinstufung bewahren möchten, bewerten Sie complete anhand des Minimaltests.
• Wenn Ihre Teamrichtlinie bestimmte Aufrufe ausdrücklich untersagt, prüfen Sie strict anhand konkreter Verstöße und dokumentierter Korrekturen.
• Wenn ein Lauf vorübergehend von der normalen Behandlung abweichen muss, halten Sie Diagnosezweck, Verantwortlichkeit und Rückkehr zur Teamkonfiguration fest.
• Wenn lokale und entfernte Ergebnisse abweichen, vergleichen Sie zuerst Testplan, Toolchain und Startbefehl, bevor Sie den Modus vereinheitlichen.

Ein gemischter Testsatz muss nicht sofort vollständig migriert werden. Sie können vorhandene Tests zunächst weiter ausführen, neue Tests mit Swift Testing ergänzen und die Übergänge nachvollziehbar protokollieren. Vereinheitlichen Sie den Modus erst, wenn relevante Testfälle über Xcode, Package-Kontext und CI hinweg ein reproduzierbares Ergebnis liefern. Benötigt Ihr Team dagegen eine klare Grenze zwischen den Frameworks, ist eine gezielte strenge Richtlinie belastbarer als ein stilles Abschalten der Diagnose.

Wenn Sie für diese Prüfung noch eine geeignete Mac-Umgebung aufbauen, finden Sie im CALMVPS-Angebot für Mac-Umgebungen einen Einstieg zu den verfügbaren Möglichkeiten. Vergleichen Sie für eine zeitlich begrenzte Test- oder CI-Umgebung anschließend die CALMVPS-Mietoptionen mit Ihrem tatsächlichen Bedarf. Eine Linux-VM kann die macOS-spezifische Toolchain nicht ersetzen; ein eigener Mac kann bei dauerhaft ausgelasteter Arbeit oder benötigten physischen Schnittstellen dagegen passender sein. Mieten Sie nur, wenn Sie eine vorübergehende Testkapazität oder einen zusätzlichen CI-Knoten benötigen.

Prüfen Sie vor der nächsten Freigabe den Interoperabilitätsmodus des vorhandenen Testplans direkt und führen Sie denselben Minimaltest lokal sowie in CI aus. So entscheiden Sie anhand sichtbarer Testergebnisse statt anhand eines vermuteten Standardwerts, ob complete, strict oder eine beibehaltene Kompatibilität zu Ihrer Migration passt.