Flutter 3.44: Müssen iOS-Abhängigkeiten migriert werden? Entscheidungsleitfaden 2026

Für neue Projekte sollten Sie in Flutter 3.44 zuerst den Swift Package Manager einplanen; bestehende Projekte sollten CocoaPods nicht überstürzt ablösen, sondern Abhängigkeiten prüfen und die Umstellung in einer isolierten macOS-/Xcode-CI verifizieren. Das gilt besonders, wenn native Plugins, eigene Pod-Konfigurationen oder Signatur- und Archivierungsschritte beteiligt sind.

Dieser Beitrag richtet sich an Sie, wenn Sie eine Flutter-iOS-App warten und die Kompatibilität Ihrer Abhängigkeiten bewerten.
Er ist ebenso für Plugin- und Integrationsverantwortliche relevant, die Zuständigkeiten zwischen Dart- und nativer Ebene klären müssen.
Wenn Sie Apple-Plattform-CI betreiben, finden Sie Kriterien für eine getrennte Prüfung vor dem Produktionswechsel.

Zeitplan: Bis zur angekündigten Umstellung der CocoaPods-Spezifikationsregistrierung sollten Sie die Abhängigkeiten und Ihren CI-Nachweis erfassen, statt allein aus dem Termin eine sofortige Build-Unterbrechung abzuleiten. Die Flutter-Dokumentation nennt dafür den 02.12.2026 als geplantes Datum; die Ankündigung ist ein Plan und kein Beleg dafür, dass bestehende Projekte an diesem Tag automatisch nicht mehr bauen (Flutter-Projektsetup, CocoaPods-Ankündigung zur Spezifikationsregistrierung).

Diese Woche: Erstellen Sie eine Liste direkter und transitiver iOS-Abhängigkeiten und lassen Sie einen unveränderten Stand in einer separaten macOS-/Xcode-CI laufen. Erst wenn diese Baseline reproduzierbar ist, lässt sich ein Migrationsfehler von einem bereits bestehenden Build-Problem unterscheiden.

Neue Projekte oder Bestand: Die Ausgangslage entscheidet

Flutter dokumentiert ab Flutter 3.44 Swift Package Manager als Standardweg für iOS- und macOS-Abhängigkeiten; CocoaPods wird als im Wartungsmodus beschrieben. Diese offizielle Einordnung ist ein starkes Signal für die Planung neuer Projekte, aber sie besagt nicht, dass jedes bestehende Flutter-Projekt schon kompatibel migriert werden kann (Flutter-Anleitung zur iOS-Projektintegration).

Die Entscheidung hängt nicht nur vom Flutter-SDK ab. Maßgeblich ist, ob Ihre benötigten Plugins SPM unterstützen, ob native Änderungen außerhalb der Paketdeklarationen liegen und ob Ihre CI den gesamten Pfad bis zum signierten Artefakt abbildet. Prüfen Sie deshalb Projektart, Integrationen und Betriebsablauf getrennt.

SPM-Eignung: Flutter-Version, native Pakete und Werkzeugkette

Für ein neues Projekt ist SPM meist die vernünftigere Ausgangsbasis, sofern die benötigten nativen Abhängigkeiten und Plugins diesen Integrationsweg tatsächlich anbieten. Die Flutter-Dokumentation zur Entwicklung von Paketen und Plugins beschreibt, worauf Plugin-Autorinnen und -Autoren bei Plattformunterstützung achten müssen. Eine allgemeine SPM-Unterstützung eines Pakets ist dabei kein Ersatz für einen erfolgreichen Build mit Ihrer konkreten Flutter- und Xcode-Konfiguration.

Auch der Paketmanager selbst ist Teil der Werkzeugkette: Die Beschreibung des Swift Package Manager erklärt das Paketmodell und die Deklaration von Abhängigkeiten. Für Sie zählt nicht nur, ob ein Paket eine gültige Manifestdatei besitzt, sondern ob es in der von Flutter erzeugten iOS-Projektstruktur korrekt eingebunden wird und alle erforderlichen nativen Produkte bereitstellt.

Xcode und macOS sind Voraussetzungen für den iOS-Build. Flutter führt diese Plattformanforderungen in der iOS-Einrichtungsdokumentation auf. Ein Linux- oder Windows-Build kann daher Dart-Code prüfen, ersetzt aber nicht die Prüfung der Apple-spezifischen Kompilierung, Tests und Signierung. Legen Sie früh fest, welche macOS-/Xcode-Umgebung für Entwicklung und CI maßgeblich ist; sonst vergleichen Sie möglicherweise Ergebnisse aus nicht gleichwertigen Werkzeugketten.

Bestehende CocoaPods-Projekte: Plantermin ist keine automatische Abschaltung

Die CocoaPods-Mitteilung beschreibt eine geplante schreibgeschützte Spezifikationsregistrierung. Sie dürfen daraus nicht ableiten, dass ein vorhandenes Projekt am genannten Datum zwangsläufig unbaubar wird: Ein schreibgeschützter Registry-Zustand, die Verfügbarkeit bereits aufgelöster Abhängigkeiten und das erfolgreiche Bauen Ihres konkreten Projekts sind unterschiedliche Sachverhalte (CocoaPods-Mitteilung).

Entscheidend ist, wie Ihr Projekt Abhängigkeiten auflöst und welche Schritte beim Build auf die Spezifikationsquelle zugreifen. Ein vorhandener Lockfile-Eintrag kann für eine reproduzierbare Installation relevant sein, beweist aber weder, dass jede Abhängigkeit in jeder Umgebung verfügbar bleibt, noch dass sich alle Build-Skripte unverändert verhalten. Prüfen Sie die tatsächliche Auflösung mit einer sauberen CI-Umgebung, statt den Lockfile als Kompatibilitätsgarantie zu behandeln.

Bei einem laufenden Produkt ist der Wechsel außerdem mit Rückfall- und Freigabefragen verbunden: Wer wartet die native Integration? Wie werden Änderungen an Podfile, Xcode-Projekt oder Build-Skripten nachvollzogen? Wie stellen Sie sicher, dass Release- und Testkonfigurationen dieselben Abhängigkeiten verwenden? Wenn diese Antworten fehlen, ist ein sofortiger Vollwechsel meist riskanter als eine abgegrenzte Parallelprüfung.

Plugin-Kompatibilität: Direkte und transitive Abhängigkeiten unterscheiden

Die offensichtlichsten Kandidaten stehen in Ihrer eigenen pubspec-Datei. Die schwierigeren Fälle sitzen oft eine Ebene tiefer: Ein Flutter-Plugin kann weitere native Pakete einbinden oder eigene iOS-Build-Schritte voraussetzen. Deshalb sollten Sie nicht nur die Liste Ihrer direkten Flutter-Pakete prüfen, sondern für jedes iOS-Plugin auch dessen native Abhängigkeiten und dokumentierte Installationswege erfassen.

Bei jedem Kandidaten hilft eine knappe Statusklassifizierung:

• SPM-Unterstützung dokumentiert: Paketverantwortliche nennen SPM ausdrücklich und beschreiben die erforderliche Integration.
• Unterstützung unklar: Es gibt keine verlässliche Aussage, oder die Dokumentation behandelt nur CocoaPods.
• CocoaPods-gebunden: Podfile-Einträge, Podspecs, Shell-Skripte oder manuelle Xcode-Schritte sind für den Build erforderlich.
• Eigene Integration: Ihr Team hat native Anpassungen vorgenommen, die nicht mit einem unveränderten Paketupdate verschwinden dürfen.

Ein Beispiel: Eine Anwendung kann für ihre Dart-Abhängigkeiten sauber auflösen und dennoch an einem Plugin scheitern, das eine native Bibliothek über CocoaPods einbindet. Umgekehrt belegt ein erfolgreicher Dependency-Resolve nicht, dass Simulator-Tests, Gerätesignierung oder Archivierung funktionieren. Die Flutter-Anleitung für iOS-Projekte ist deshalb als Integrationsreferenz zu lesen, nicht als pauschale Zusage für jedes Drittanbieter-Plugin.

Was tun, wenn ein Flutter-Plugin SPM noch nicht unterstützt?

Wenn ein benötigtes Plugin SPM nicht unterstützt, sollten Sie zunächst beim Plugin-Maintainer den unterstützten Integrationsweg und den geplanten Status erfragen. Prüfen Sie zugleich, ob es eine gepflegte Alternative gibt oder ob Ihr Team die native Integration selbst verantworten kann. Eine ungeprüfte Umgehung in der Xcode-Projektdatei kann beim nächsten Flutter- oder Plugin-Update überschrieben werden und erschwert die Reproduzierbarkeit.

Für ein neues Projekt bedeutet das gegebenenfalls, das Plugin vor der Auswahl gegen Alternativen abzuwägen oder den Start auf einer dokumentierten CocoaPods-Abhängigkeit aufzubauen, wenn sie unverzichtbar ist. Für ein Bestandsprojekt ist ein zeitlich begrenzter Parallelbetrieb eine mögliche Zwischenlösung: Die bestehende Produktionspipeline bleibt stabil, während ein isolierter Zweig die SPM-Variante testet. Halten Sie dabei fest, wer Abweichungen pflegt und welches konkrete Ergebnis die Freigabe auslöst. Ohne einen verantwortlichen Maintainer ist „vorübergehend doppelt“ keine belastbare Strategie.

Abhängigkeiten prüfen oder sofort migrieren: Zuständigkeiten und Risiken

Es gibt drei realistische Handlungswege. Die Tabelle macht sichtbar, welcher Befund jeweils für die Entscheidung zählt; sie ersetzt keine projektspezifische Prüfung.

Die Verantwortlichkeit sollte vor dem ersten Änderungsversuch geklärt sein. Das Flutter-Team kann Paketdeklarationen und App-Konfiguration verantworten; die Plugin-Verantwortlichen müssen native Unterstützung und Aktualisierungen beurteilen; das CI-Team muss Build-Images, Zertifikate, Schlüsselbund und Artefaktablage prüfen. Wenn alle davon ausgehen, die jeweils andere Gruppe werde die Integration später übernehmen, bleibt die Migration zwischen Zuständigkeiten hängen.

Eine faire Kosten-Nutzen-Abwägung braucht keine erfundenen Stunden- oder Leistungswerte. Erfassen Sie stattdessen überprüfbare Kostenpositionen: zusätzliche Pflege eines Parallelpfads, benötigte Änderungen an Plugin-Code, Anpassungen der Build-Skripte, Wartung der Signaturumgebung und der Aufwand, einen reproduzierbaren Rückfall zu behalten. Diese Liste zeigt, ob die Migration für Ihr Team aktuell tragbar ist, ohne pauschale Aussagen über Geschwindigkeit oder Wartungskosten zu behaupten.

Wenn Sie für die isolierte Prüfung keine eigene Apple-Hardware vorhalten möchten, können Sie den Hostbedarf separat bewerten. Der Überblick zu Mac-Umgebungen und Auswahlkriterien hilft, Miet- und Eigenbetriebsmodelle gegenüberzustellen. Dabei bleiben Datenschutz, Zugriffskontrolle und die sichere Ablage von Signaturmaterial Ihre Verantwortung – unabhängig davon, wo der Mac betrieben wird.

Mac-CI: Vom erfolgreichen Resolve bis zum signierten Artefakt

Ein belastbarer CI-Nachweis muss mehrere Stufen abdecken. „Dependencies resolved“ bedeutet nur, dass der Paketmanager in dieser Umgebung die Abhängigkeiten auflösen konnte. Daraus folgt nicht automatisch, dass das Projekt kompiliert, die Tests bestehen oder ein signiertes Archiv für die vorgesehene Distribution entsteht.

1. Baseline sichern. Lassen Sie den bestehenden Produktionsstand in einer macOS-/Xcode-Umgebung laufen und archivieren Sie Auflösungsprotokolle, Build-Ausgaben und Testresultate. So können Sie spätere Fehler einer Änderung zuordnen, statt zunächst die alte Pipeline rekonstruieren zu müssen.
2. Projektbestand erfassen. Sichern Sie Podfile, Lockfiles, Flutter-Paketdatei, native Projektanpassungen und alle Skripte, die Abhängigkeiten oder Build-Schritte verändern. Markieren Sie direkte und transitive Plugins getrennt.
3. SPM-Variante isolieren. Verwenden Sie eine getrennte Branch- oder CI-Konfiguration. Verändern Sie nicht gleichzeitig Flutter-Version, Plugin-Versionen, Xcode-Projekt und Signierungslogik, wenn Sie aus dem Ergebnis auf eine bestimmte Ursache schließen müssen.
4. Auflösung und sauberen Build prüfen. Entfernen Sie nicht benötigte lokale Artefakte und lassen Sie die CI den vorgesehenen Installations- und Buildpfad erneut ausführen. Protokollieren Sie Fehler samt Werkzeugversionen und relevanten Umgebungsinformationen.
5. Tests und Releasepfad abnehmen. Führen Sie die für Ihr Projekt vorgesehenen Tests aus und prüfen Sie anschließend die tatsächlich genutzte Signierung und Archivierung. Bei mehreren Flavors müssen die relevanten Konfigurationen getrennt betrachtet werden; Flutter beschreibt deren iOS-Einrichtung in der Dokumentation zu iOS-Flavors.
6. Ergebnis begrenzen und freigeben. Halten Sie fest, welche Projektversion, Plugins und CI-Konfiguration erfolgreich waren. Ein bestandener Lauf belegt nur diese getestete Kombination – nicht die allgemeine Kompatibilität aller Flutter-Plugins.

Bewahren Sie die Protokolle so auf, dass ein anderes Teammitglied den Lauf nachvollziehen kann. Dazu gehören nicht nur die sichtbare Fehlermeldung, sondern auch Abhängigkeits-Lockfiles, relevante Umgebungsangaben und der genaue Build-Aufruf. Vermeiden Sie, Geheimnisse wie Zertifikate oder private Schlüssel in Logs oder Artefakte aufzunehmen; verwalten Sie Signaturmaterial über kontrollierte CI-Geheimnisse und dokumentierte Berechtigungen.

Bei Release-Flavors ist die Abnahme besonders leicht unvollständig: Ein Debug-Build kann erfolgreich sein, während eine andere Bundle-ID, ein abweichendes Entitlement oder ein separates Archivierungsprofil scheitert. Testen Sie deshalb die Konfiguration, die Sie tatsächlich verteilen wollen, und dokumentieren Sie, ob die CI einen Simulator-Build, Tests auf einem Gerät oder ein signiertes Archiv geprüft hat. Diese Ergebnisse sind nicht austauschbar.

Woran Sie den Wechsel festmachen

Migrieren Sie, wenn die benötigten Plugins und nativen Pakete den SPM-Weg nachvollziehbar unterstützen, die isolierte CI-Auflösung stabil ist und der für Sie relevante Build-, Test- und Signaturpfad besteht.

Validieren Sie zunächst parallel, wenn die Anwendung CocoaPods-spezifische Schritte enthält, ein Pluginstatus unklar ist oder Ihre Produktionspipeline einen Rückfall benötigt. Legen Sie dafür eine verantwortliche Person und konkrete Freigabekriterien fest.

Schieben Sie die Umstellung vorerst auf, wenn eine kritische native Abhängigkeit nicht unterstützt wird und weder eine gepflegte Alternative noch eine intern wartbare Integration existiert. Das ist keine Freistellung von der Prüfung: Überwachen Sie die offiziellen Flutter- und CocoaPods-Angaben und wiederholen Sie die Bestandsaufnahme, wenn sich deren Status ändert.

Zuletzt geprüft am 04.11.2026 anhand der verlinkten Flutter-Dokumentation und der offiziellen CocoaPods-Ankündigung. Die Aussage zum schreibgeschützten Registry-Zustand bleibt eine geplante Änderung mit dem dort genannten Termin 02.12.2026; prüfen Sie den tatsächlichen Status insbesondere um diesen Termin erneut. Die CI-Empfehlungen hier sind Prüfkriterien für Ihr Projekt, keine Zusicherung, dass ungeprüfte Plugins kompatibel sind.

Wenn Sie heute überwiegend auf einem lokalen Rechner oder einer Linux-CI arbeiten, fehlen Ihnen für den Apple-Build möglicherweise Xcode, macOS und ein vollständig prüfbarer Signaturpfad. Das sind reale Einschränkungen gegenüber einer verfügbaren Mac-Umgebung; zugleich ist ein eigener Mac nicht für jedes Team sinnvoll, wenn die Hardware nur für eine abgegrenzte Migration oder Testphase benötigt wird. Für diese Fälle können Sie eine Mac-Umgebung bei VpsHold als zeitlich begrenzte Prüfressource erwägen und Ihre eigenen Abhängigkeiten, Datenschutzanforderungen und Release-Schritte darauf validieren. Bei dauerhaft hoher Auslastung oder benötigten physischen Schnittstellen kann ein eigener Mac die passendere Wahl sein.