Flutter 3.47 iOS CI: So prüfen Sie SwiftPM – Checkliste 2026

Flutter dokumentiert Swift Package Manager seit Flutter 3.44 als Standard für iOS- und macOS-Abhängigkeiten; für Flutter 3.47 sollten Sie trotzdem je Projektszenario prüfen, welcher Pfad tatsächlich genutzt wird. Schalten Sie erst dann vollständig um, wenn Plugins, Abhängigkeitsauflösung und Archivierung auf einem sauberen Mac-CI-Knoten erfolgreich geprüft sind. Ein erfolgreicher Build auf einem Entwickler-Mac reicht als Freigabe nicht aus.

Für Flutter-iOS-Anwendungsverantwortliche: Sie müssen vor dem Upgrade den Zustand vorhandener Plugins und nativer Abhängigkeiten klären.
Für CI- und DevOps-Teams: Sie benötigen nachvollziehbare Nachweise für Auflösung, Tests, Archivierung und Signierung auf einem Mac-Build-Knoten.
Für Plugin-Maintainer: Sie müssen belegen, ob Ihr Plugin SwiftPM unterstützt oder einen CocoaPods-Pfad benötigt.

Zuletzt geprüft am 31.10.2026 anhand der Flutter-Veröffentlichungsnotizen, der Flutter-Dokumentation zu SwiftPM und der Apple-Anleitung für CI-Builds.

Projektzustand und Migration für Flutter 3.47 feststellen

Die Flutter-Veröffentlichungsnotizen führen Flutter 3.47 als stabile Version. Die Flutter-Dokumentation erklärt außerdem, dass Swift Package Manager seit Flutter 3.44 die Standardmethode für iOS- und macOS-Abhängigkeiten ist. Das beschreibt die Plattformrichtung, beweist aber nicht, dass ein bestehendes Projekt automatisch sämtliche früheren Einstellungen, Plugins oder Skripte auf SwiftPM umgestellt hat. Prüfen Sie deshalb den konkreten Projektstand anhand der Flutter-Veröffentlichungsnotizen und der Flutter-Anleitung für SwiftPM in Anwendungsprojekten.

Unterscheiden Sie bei der Bestandsaufnahme zwischen einer automatischen Anpassung durch Flutter-Werkzeuge und Änderungen, die das Team selbst vorgenommen hat. Eine aktualisierte Flutter-Version kann mit älteren Projektdateien, selbst verwalteten Build-Schritten und Plugins zusammentreffen, die noch nicht für SwiftPM eingerichtet sind. Notieren Sie deshalb für jedes Ziel, welche Konfiguration im Repository liegt und welcher Paketmanager im CI-Protokoll tatsächlich erscheint.

Prüfpunkte für die Bestandsaufnahme

• [ ] Flutter-Version und Projekt-Commit sind in den CI-Protokollen eindeutig festgehalten.
• [ ] Die verwendete iOS-Projektkonfiguration stimmt mit dem aktuellen Repository-Stand überein.
• [ ] Das Team hat eigene Migrationseingriffe von Änderungen durch Flutter-Werkzeuge getrennt dokumentiert.
• [ ] Build-Skripte, Pod-Konfigurationen und gegebenenfalls SwiftPM-Dateien sind auf nicht versionierte lokale Annahmen geprüft.
• [ ] Die Paketauflösung und der Build werden nicht allein aus einem bereits eingerichteten Entwicklerarbeitsplatz abgeleitet.

Die Flutter-Dokumentation zur iOS-Bereitstellung dient als zusätzliche Referenz für die Release-Kette. Für die Abnahme ist jedoch die Kombination aus Projektdaten, Plugin-Erklärungen und CI-Ausgabe maßgeblich. Wenn ein Repository bereits eigene Integrationsschritte enthält, sollten diese einzeln bewertet werden; eine pauschale Bereinigung kann notwendige Teamkonfigurationen entfernen.

Plugin-Szenarien nach Paketpfad abnehmen

Nicht alle Flutter-Plugins stehen bei der Umstellung auf demselben Stand. Ein Plugin kann SwiftPM-Metadaten enthalten, weiterhin CocoaPods verwenden oder mehrere native Abhängigkeiten mit unterschiedlichen Integrationswegen kombinieren. Die Entscheidung muss sich auf die Plugin-Dokumentation und den tatsächlichen Build stützen, nicht auf die Annahme, dass ein erfolgreicher Lauf auf einer einzelnen Maschine die gesamte Abhängigkeitskette beweist. Flutter beschreibt Anforderungen und Migration für Autoren in der SwiftPM-Anleitung für Plugin-Maintainer und der Dokumentation zur Entwicklung von Flutter-Paketen und Plugins.

Für Plugins, die SwiftPM unterstützen, gehört die Paketbeschreibung ebenso in die Prüfung wie die aufgelösten Abhängigkeiten. Eine Lock-Datei, die lokal erzeugt wird, aber nicht im Repository liegt, kann erklären, warum Entwicklerarbeitsplatz und CI unterschiedliche Versionen beziehen. Umgekehrt genügt das Vorhandensein einer Lock-Datei nicht, wenn das CI sie ignoriert oder eine andere Build-Route ausführt. Lassen Sie daher den Build-Log erkennen, welche Dateien und Paketquellen tatsächlich verwendet wurden.

Bei einem Plugin ohne SwiftPM-Unterstützung kann Flutter laut Dokumentation auf CocoaPods zurückfallen. Das ist eine Option für die Integration, kein Nachweis, dass jedes Plugin oder jede Kombination nativer Abhängigkeiten ohne Änderungen funktioniert. Die Abnahme sollte festhalten, ob der Flutter-Aufruf den Rückfall ankündigt, ob CocoaPods im konkreten Lauf tatsächlich ausgeführt wurde und welche Abhängigkeiten darüber eingebunden werden. Stimmen Plugin-Dokumentation und CI-Protokoll nicht überein, bleibt der Fall offen, bis die Abweichung erklärt ist.

Flutter-Modul in eine native iOS-Anwendung integrieren

Ein Flutter-iOS-Anwendungsprojekt und ein bestehendes natives iOS-Projekt mit eingebettetem Flutter-Modul sind unterschiedliche Abnahmeszenarien. Beim zweiten Fall kontrolliert das Team nicht nur die Flutter-Seite: Auch das Host-Projekt, seine Paketauflösung und der Aufruf des Build-Prozesses müssen zum vorgesehenen Release passen. Verwenden Sie hierfür die offizielle Anleitung zum Einbinden von Flutter in ein bestehendes iOS-Projekt, statt die Abnahme eines eigenständigen Flutter-Projekts unverändert zu übernehmen.

Wenn ein bestehendes Modul bisher über CocoaPods eingebunden wurde, erfassen Sie vor der Migration zunächst alle Host-Einstellungen, Skripte und Abhängigkeiten, die mit diesem Weg verbunden sind. Die Anleitung gibt den Rahmen für die Integration vor; welche lokale Konfiguration entfallen darf, hängt vom konkreten Host-Projekt ab. Entfernen Sie daher nicht auf Verdacht sämtliche Pod-bezogenen Dateien oder Schritte. Trennen Sie die Bereinigung alter Konfiguration von der Prüfung der neuen Paketauflösung und führen Sie nach jeder Änderung einen eigenen Host-Build aus.

Für die Freigabe ist wichtig, dass der Build-Einstiegspunkt im CI dem tatsächlich verwendeten Release-Prozess entspricht. Wird das Flutter-Modul isoliert gebaut, während die Auslieferung über das native Host-Projekt erfolgt, ist die Abnahme unvollständig. Dokumentieren Sie, welche Projektdateien geöffnet beziehungsweise angesprochen werden, wie das Modul eingebunden wird und an welcher Stelle Tests, Archivierung und Signierung stattfinden.

Sauberen Mac-CI-Build bis zur Signierung prüfen

Eine belastbare Abnahme beginnt mit einem frischen oder kontrolliert bereinigten Mac-CI-Arbeitsverzeichnis, nicht mit dem Cache eines langjährig genutzten Entwicklerarbeitsplatzes. Apple beschreibt in seiner Anleitung für Swift-Paket- und App-Builds in CI, wie Swift-Pakete und Anwendungen in kontinuierlichen Integrationsabläufen gebaut werden. Das Team sollte zusätzlich die tatsächlichen Flutter-Aufrufe und Projektkonfigurationen protokollieren.

Arbeiten Sie die folgenden Schritte für einen repräsentativen Commit ab und bewahren Sie die Ausgaben als getrennte Build-Nachweise auf:

1. Ausgangslage festhalten. Erfassen Sie Commit, Flutter-Version, Xcode-Umgebung und die im Repository versionierten Paket- und Projektdateien. Notieren Sie auch, ob das Projekt eine eigenständige Flutter-Anwendung oder ein Flutter-Modul in einem Host-Projekt ist.
2. Arbeitsverzeichnis kontrollieren. Starten Sie mit einem sauberen Checkout oder einer nachvollziehbar bereinigten Umgebung. Stellen Sie sicher, dass keine lokal erzeugten Paketdateien, nicht eingecheckten Änderungen oder alten Build-Ergebnisse die Auflösung verdecken.
3. Abhängigkeiten neu auflösen. Führen Sie den im Projekt vorgesehenen Flutter- und Xcode-Buildpfad aus. Sichern Sie die Ausgabe, die erkennen lässt, ob SwiftPM, CocoaPods oder beide Wege beteiligt waren. Bei privaten Git- oder Paketquellen prüfen Sie die Authentifizierung, ohne Zugangsdaten in Protokolle oder Artefakte zu schreiben.
4. Build und Tests ausführen. Bauen Sie das betroffene iOS-Ziel mit den Release-relevanten Einstellungen und führen Sie die vorgesehenen Tests aus. Halten Sie Fehler bei Paketauflösung getrennt von Compiler-, Test- und Signierungsfehlern, damit ein Rückfall nicht eine andere Fehlerklasse verdeckt.
5. Archiv erzeugen. Erstellen Sie das Archiv über denselben Einstiegspunkt, den der Release-Prozess verwendet. Bewahren Sie das Archivprotokoll und die zugehörigen Build-Einstellungen auf; ein erfolgreicher Simulator-Build ersetzt diese Prüfung nicht.
6. Signierung kontrollieren. Prüfen Sie Identität, Bereitstellungsprofil und Ergebnis der Signierung anhand der Teamvorgaben. Stellen Sie sicher, dass CI-Geheimnisse nicht in Diagnoseausgaben gelangen und dass die verwendeten Zugangsdaten für private Abhängigkeiten geschützt bleiben.
7. Wiederholung dokumentieren. Lassen Sie denselben Commit erneut auf einem sauberen Arbeitsverzeichnis laufen. Weichen Paketpfad oder Archivresultat ab, ist die Ursache zu klären, bevor das Team die Migration als abgeschlossen markiert.

Bei privaten Swift-Paketen oder Git-Abhängigkeiten sollte die CI-Konfiguration außerdem den Umgang mit Git-Werkzeugen und Zugangsdaten einbeziehen. Apple behandelt die CI-Ausführung von Swift-Paketen in der verlinkten Anleitung; Projektverantwortliche müssen daraus die passende Umsetzung für ihre Repository-Berechtigungen ableiten. Geheimnisse gehören in einen verwalteten Geheimnisspeicher und nicht in Skriptargumente, die in Protokollen auftauchen können.

Migrationsumfang anhand von Freigabebedingungen bestimmen

Verwenden Sie die folgende Entscheidungslogik, statt die Umstellung für alle Projekte gleichzeitig freizugeben:

• Wenn alle relevanten Plugins SwiftPM unterstützen, die Pakete auf einem sauberen Mac aufgelöst werden und Tests sowie signiertes Archiv reproduzierbar gelingen, kann das Projekt auf den SwiftPM-Pfad umgestellt werden. Sichern Sie die Lock-Dateien und Abnahmeprotokolle im vorgesehenen Repository beziehungsweise Artefaktspeicher.
• Wenn einzelne Plugins SwiftPM noch nicht unterstützen, Flutter aber im konkreten Projekt nachvollziehbar auf CocoaPods zurückfällt und der saubere CI-Build erfolgreich ist, behalten Sie den erforderlichen Rückfall zunächst bei. Dokumentieren Sie betroffene Plugins, Paketpfad und Eigentümer für eine spätere erneute Prüfung.
• Wenn die Auflösung nur mit lokalem Cache gelingt, Lock-Dateien fehlen oder die Build-Protokolle den Paketpfad nicht belegen, geben Sie keine vollständige Migration frei. Beheben Sie zuerst die Reproduzierbarkeit und führen Sie danach die Abnahme erneut aus.
• Wenn ein Flutter-Modul in einer nativen App verwendet wird, entscheiden Sie erst nach einem erfolgreichen Host-Build samt Archivierung und Signierung. Ein isolierter Flutter-Build reicht für dieses Szenario nicht.
• Wenn der aktuelle Build bereits stabil ist, aber die Abhängigkeiten nicht eindeutig zugeordnet werden können, verschieben Sie die Umstellung oder führen Sie einen begrenzten Paralleltest durch, statt gleichzeitig Paketpfad, Host-Konfiguration und Signierung zu ändern.

CocoaPods sollte nicht als vermeintlich bereits abgeschaltet behandelt werden. Flutter führt den 2. Dezember 2026 als vorgesehenen Termin dafür an, das CocoaPods-Repository auf schreibgeschützt umzustellen; am Prüfdatum 31. Oktober 2026 liegt dieser Termin noch in der Zukunft. Das ist eine angekündigte Maßnahme, kein Beleg dafür, dass die Umstellung bereits erfolgt ist. Prüfen Sie vor einer Release-Entscheidung die aktuelle Flutter-Dokumentation und planen Sie die mögliche Veränderung als Risikofaktor ein.

Erstellen Sie für jedes Projekt eine knappe Abnahmeakte mit Pluginstatus, Paketpfad, Auflösungsergebnis, Commit, Build- und Testausgabe sowie Archiv- und Signierungsnachweis. Damit wird auch später erkennbar, ob ein Fehler durch eine neue Plugin-Version, geänderte Authentifizierung, eine Host-Projektänderung oder einen veränderten CI-Knoten entstanden ist. Wo Ergebnisse fehlen, sollte der Status ausdrücklich „nicht geprüft“ lauten und nicht als Kompatibilität interpretiert werden.

Häufige Fragen zur SwiftPM-Abnahme

Die Antworten auf typische Fragen zu Flutter 3.47, Plugin-Rückfällen, sauberer Paketauflösung und IPA-Archivierung finden Sie im FAQ-Bereich zu diesem Leitfaden. Verwenden Sie ihn als Einstieg in die Prüfung; die Freigabe sollte weiterhin auf den konkreten Projektdateien und CI-Nachweisen beruhen.

Als nächster Schritt empfiehlt sich ein repräsentatives Projekt, bei dem Abhängigkeitswiederherstellung, Tests und Archivierung auf einem Mac vollständig durchlaufen werden, bevor weitere Repositories umgestellt werden. Fehlt dem Team eine geeignete Mac-Build-Umgebung, kann es die Preise für Mac-Umgebungen bei RUVCLOUD mit den Kosten eines eigenen CI-Knotens vergleichen. Eine gemietete Umgebung ist vor allem für zeitweilige Migrationstests oder zusätzliche Kapazität interessant; bei dauerhaft hoher Auslastung, speziellen physischen Schnittstellen oder streng lokalen Geheimnisanforderungen kann ein eigener Mac die passendere Wahl sein. Für einen zeitlich begrenzten Testlauf lässt sich eine Mac-Umgebung bei RUVCLOUD anfragen.