Flutter 3.44 landete am 19. Mai 2026 auf dem Google I/O mit einem Release, das weit über typische Incremental Updates hinausgeht. Zentrale Neuerungen sind Hybrid Composition++ für Android, Swift Package Manager als neuer iOS/macOS-Standard und verbesserter Vulkan-Support für Impeller. Die mit Abstand folgenreichste Entscheidung für bestehende Projekte ist dabei der Wechsel des Dependency-Managers auf Apple-Plattformen — ein Schritt, der nicht optional ist, sondern durch einen externen Zeitplan erzwungen wird.
Was ist passiert?
Ab Flutter 3.44 ersetzt Swift Package Manager (SwiftPM) CocoaPods als Standard-Dependency-Manager für iOS- und macOS-Apps — ohne Ruby-Installation, ohne CocoaPods-Setup. Der Hintergrund ist nicht allein Googles strategische Entscheidung: CocoaPods befindet sich offiziell im Maintenance-Modus, und sein Registry wird am 2. Dezember 2026 permanent read-only. Neue Versionen oder Pods werden nach diesem Datum nicht mehr veröffentlicht. Zeitgleich hat Firebase angekündigt, neue SDK-Versionen bereits ab Oktober 2026 — zwei Monate vor dem Registry-Freeze — nicht mehr über CocoaPods zu veröffentlichen, um sicherzustellen, dass die letzten publizierten Versionen stabil und verifiziert sind.
Das Flutter-Team schreibt dazu im offiziellen Blog: „To ensure that your apps continue receiving dependency updates and to provide access to the Swift package ecosystem, Flutter is transitioning to Apple's supported dependency management solution: Swift Package Manager." (flutter.dev/blog, April 2026)
Warum ist das technisch und strategisch bedeutsam?
CocoaPods war über mehr als ein Jahrzehnt das strukturelle Fundament für iOS-Abhängigkeiten in Flutter-Projekten — und gleichzeitig eine der häufigsten Ursachen für Onboarding-Probleme, CI-Fehler und Versionskonflikte. Die Ruby-basierte Architektur war eine regelmäßige Quelle für „works on my machine"-Fehler in CI-Umgebungen, aufwändige Setup-Prozesse auf neuen Entwicklermaschinen und zeitraubende Debugging-Sessions bei Versionskonflikten.
SwiftPM löst diese strukturellen Probleme fundamental: Swift Package Manager ist direkt in Xcode integriert, wird von Apple gepflegt und hat die funktionale Reife erreicht, um komplexe Dependency-Graphen zu verwalten. Für Flutter-Teams bedeutet das konkret: Pod-install-Schritte entfallen aus CI-Skripten, da SPM-Auflösung automatisch während des Xcode-Builds geschieht — vorausgesetzt, macOS mit Xcode 14+ ist vorhanden, ohne zusätzliche Tooling-Installationen.
Die Migration selbst ist für die meisten Projekte weniger aufwändig, als sie wirkt. Die Migration ist für die Mehrheit der Projekte automatisch: Nach `flutter upgrade` auf 3.44 erkennt die CLI die Version, migriert das Xcode-Projekt zu SwiftPM und lädt die Swift-Packages, von denen die Plugins abhängen. Wenn ein Projekt noch Plugins nutzt, die SwiftPM nicht unterstützen, gibt Flutter eine Warnung aus und fällt für diese spezifische Abhängigkeit auf CocoaPods zurück.
Konkreter Handlungsbedarf für Unternehmen
Drei Faktoren machen dieses Thema zu einer Priorität für laufende und geplante Flutter-Projekte:
Erstens der Plugin-Reifegrad: Bislang haben 61 % der Top-100-iOS-Plugins migriert. Die übrigen müssen nachziehen — und zur Beschleunigung erhalten Packages ohne SwiftPM-Unterstützung ab sofort niedrigere pub.dev-Scores. Teams müssen ihren Dependency-Tree aktiv prüfen und ggf. Plugin-Maintainer kontaktieren oder Alternativen evaluieren.
Zweitens die iOS-Deployment-Target-Anforderung: Das Mindest-Deployment-Target für SPM liegt bei iOS 15.0. Firebase und viele moderne Swift-Packages setzen iOS 15+ voraus. Projekte, die noch ältere Deployment Targets pflegen, müssen hier zwingend nachziehen — eine technische Schuld, die sich nicht umgehen lässt.
Drittens die Deadline-Struktur: Firebase stoppt die Veröffentlichung neuer SDK-Versionen über CocoaPods bereits im Oktober 2026 — sechs Monate früher als der Registry-Freeze. Wer bis dahin nicht migriert hat, empfängt keine neuen Firebase-Updates mehr über den bisherigen Kanal. Zusätzliche native Abhängigkeiten — Drittanbieter-Analytics-SDKs, Mapping-Bibliotheken, Payment-Integrationen — müssen separat evaluiert werden.
Einordnung und Empfehlung
Parallel zum SPM-Wechsel führt Flutter 3.44 mit Agentic Hot Reload eine weitere strukturell relevante Neuerung ein: Der MCP-Server verbindet sich automatisch mit laufenden Dart- und Flutter-Applikationen, sodass Coding Agents wie Antigravity Hot Reload direkt aus dem Agent-Workflow auslösen können — ohne manuellen Eingriff. Das adressiert einen der größten Reibungspunkte in KI-gestützten Entwicklungsworkflows direkt.
Die CocoaPods-Ablösung verdient dennoch die höchste Priorität, weil sie nicht aufgeschoben werden kann. Für Teams bei Portalworks empfehle ich folgendes Vorgehen: sofortige Inventur aller iOS-Plugins nach SPM-Kompatibilität, paralleles Testen des SwiftPM-Builds auf einem Feature-Branch, und Abschluss der Migration vor Oktober 2026 — dem faktischen Firebase-Cutoff. Der Escape-Hatch über `enable-swift-package-manager: false` in der pubspec.yaml ist kurzfristig nutzbar, funktioniert jedoch bei komplexeren Projekten nicht immer reibungslos und bleibt eine temporäre Lösung. Wer jetzt beginnt, hat ausreichend Zeit für eine kontrollierte Migration; wer wartet, riskiert Zeitdruck im schlechtesten Entwicklungszeitfenster.
