Stand: 14.08.2026. Die offizielle Flutter-Dokumentation nennt für den aktuellen Flutter-3.44-Zweig Flutter 3.44.7 und für Add-to-App mindestens Xcode 15.0. Daraus folgt Ihre Entscheidung für diese Woche: Neue Projekte und kompatible Standard-Apps sollten auf Swift Package Manager wechseln. Pluginreiche Projekte, komplexe Add-to-App-Integrationen und mehrere native Targets sollten zunächst CocoaPods als Rückfallweg behalten. (Flutter-Dokumentation zu Add-to-App)

Diese Anleitung richtet sich an Sie, wenn Sie einen Flutter 3.44 iOS-Build für den App Store betreiben, ein Bestandsprojekt migrieren oder eine CI/CD-Umgebung auf einem Remote Mac pflegen. Sie ist ebenfalls für Plugin-Autoren, Add-to-App-Teams und kleine Entwicklergruppen gedacht, die keine zweite macOS-Testumgebung für Fehlersuche und Rückfall haben.

01

Die Entscheidung nach Projektrolle

Flutter 3.44 verwendet Swift Package Manager für native iOS- und macOS-Abhängigkeiten als Standard. Die Release Notes nennen außerdem Warnungen für Plugins ohne SwiftPM-Unterstützung sowie geführte Hinweise bei inkompatiblen Projekten. Das bedeutet aber nicht, dass jeder erfolgreiche flutter pub get bereits eine produktionsfähige Migration beweist. (Flutter-3.44-Release-Notes)

Sie müssen vier Zustände getrennt bewerten:

  1. Abhängigkeiten werden aufgelöst.
  2. Die App kompiliert im Debug-Modus.
  3. Ein Release Archive wird erstellt.
  4. Signierung und Upload-Vorprüfung funktionieren.

Erst der vierte Zustand ist für eine Veröffentlichung relevant. Ein Simulatorstart beweist weder korrekte Zertifikate noch funktionierende Entitlements oder eine brauchbare Archive-Konfiguration.

Projekttyp Empfehlung für 2026 Rückfallstrategie
Neues Flutter-Projekt ohne eigene iOS-Anpassungen Swift Package Manager direkt verwenden Repository-Stand vor der Migration behalten
Bestandsprojekt mit üblichen Plugins Migrationszweig anlegen und kontrolliert wechseln Podfile, Lock-Datei und funktionierenden Build sichern
Pluginreiches Projekt mit privaten Pods Doppelstrategie beibehalten Nicht kompatible Plugins vorerst über CocoaPods einbinden
Add-to-App mit bestehendem Xcode-Host Separat validieren Bestehende Host-Integration nicht sofort löschen
Mehrere Flavors, Extensions oder eigene Targets Erst Target für Target prüfen Release-Zweig mit alter Build-Konfiguration erhalten
CI/CD- oder Remote-Mac-Umgebung Migration in sauberer Umgebung reproduzieren Produktive Pipeline erst nach Archive-Test umstellen

Die klare Grenze lautet: Wenn ein zentraler Baustein noch nicht mit Swift Package Manager funktioniert, ist ein paralleler Betrieb kein Rückschritt, sondern eine kontrollierte Übergangsphase. Flutter dokumentiert weiterhin CocoaPods-Unterstützung für die Rückwärtskompatibilität. (Flutter-Dokumentation zu Plugins und Paketen)

02

Warum der Wechsel mehr als eine Podfile-Änderung ist

Erstens: Plugins können unterschiedliche Integrationswege verlangen

Ein Flutter-Projekt besteht nicht nur aus Dart-Code. Plugins bringen native iOS- oder macOS-Abhängigkeiten, Ressourcen, Mindestversionen und manchmal eigene Build-Schritte mit. Flutter beschreibt SwiftPM inzwischen als primäre Strategie für native Darwin-Abhängigkeiten, dokumentiert aber weiterhin CocoaPods für Entwickler, die noch nicht migriert haben.

Für Sie entstehen dadurch drei typische Zustände:

  • Alle Plugins unterstützen SwiftPM.
  • Die meisten Plugins unterstützen SwiftPM, mindestens eines fällt auf CocoaPods zurück.
  • Ein Plugin blockiert die gewünschte Integration vollständig.

Der zweite Fall ist besonders gefährlich, weil er äußerlich wie eine erfolgreiche Migration aussehen kann. Tatsächlich entsteht eine gemischte Abhängigkeitslandschaft. Das ist nicht automatisch falsch. Sie müssen aber prüfen, ob Xcode dieselbe Framework-Struktur, dieselben Ressourcen und dieselben Build-Phasen erhält.

Zweitens: Signierung hängt an Targets und Build-Phasen

Die Umstellung der Abhängigkeitsverwaltung ersetzt nicht Ihr Apple-Entwicklerkonto, Ihre Zertifikate oder die Bundle-ID. Sie kann aber beeinflussen, wie Frameworks und Ressourcen in das App-Produkt gelangen. Bei mehreren Targets betrifft das zum Beispiel:

  • die Haupt-App,
  • Notification Extensions,
  • Share Extensions,
  • App Clips,
  • interne Test-Targets,
  • unterschiedliche Flavor-Konfigurationen.

Ein Debug-Build auf dem Simulator kann deshalb erfolgreich sein, während das Release Archive an einer Extension oder an einer fehlenden Signatur scheitert. Flutter nennt in den 3.44-Änderungen unter anderem Verbesserungen und Fehlerbehebungen rund um Code Signing und SwiftPM-Integration. Das ist ein Grund für sorgfältige Tests, aber kein Beleg dafür, dass Ihre individuelle Signierung automatisch korrekt bleibt.

Drittens: Add-to-App folgt nicht demselben Pfad wie eine neue Flutter-App

Bei Add-to-App wird Flutter in ein bestehendes iOS-Projekt eingebettet. Der Host kann Swift oder Objective-C verwenden und behält eigene Build-Konfigurationen. Die offizielle Anleitung beschreibt für die neue SwiftPM-Integration einen eigenen Migrationsweg. Eine bisherige CocoaPods- oder Embedded-Framework-Integration darf daher nicht einfach durch die Schritte für eine Standard-Flutter-App ersetzt werden. (Flutter-Anleitung zur iOS-Add-to-App-Integration)

Zusätzlich können relative Pfade, eigene Xcode-Schemes, Host-Targets und Build-Phasen voneinander abweichen. Testen Sie Add-to-App deshalb als eigenes Migrationsprojekt. Behandeln Sie es nicht wie eine normale Änderung an Runner.

Achtung: Die angekündigte Umstellung des CocoaPods-Trunk auf „read-only“ ist für den 02.12.2026 geplant. Die Betreiber weisen jedoch darauf hin, dass sich der Zeitplan noch ändern kann. Bestehende Builds sollen dadurch nicht automatisch unbrauchbar werden. Schreiben Sie deshalb heute eine Rückfallstrategie, aber migrieren Sie nicht aus einer falschen Annahme über ein sofortiges Ende von CocoaPods. (CocoaPods-Ankündigung zum Spezifikations-Repository)

03

Neue Projekte: Standard beibehalten, Abhängigkeiten früh prüfen

Bei einem neu angelegten Flutter-Projekt fehlen meist die Altlasten, die eine Migration teuer machen: alte Podfile-Anpassungen, manuelle Ruby-Hooks, historische Build-Skripte und nicht dokumentierte Xcode-Einstellungen. Für diesen Projekttyp ist der Standard von Flutter 3.44 der sinnvollste Ausgangspunkt.

Gehen Sie trotzdem nicht davon aus, dass jedes neue Plugin automatisch kompatibel ist. Prüfen Sie vor dem ersten Release:

  • Unterstützt jedes native Plugin SwiftPM?
  • Werden iOS- und macOS-Plattformen getrennt korrekt beschrieben?
  • Sind Mindestplattformen und Ressourcen vollständig?
  • Erscheinen die Abhängigkeiten im erwarteten Xcode-Target?
  • Funktioniert der Release-Build mit Ihrer echten Bundle-ID?

Plugin-Autoren müssen für native Darwin-Abhängigkeiten unter anderem eine Package.swift-Struktur bereitstellen. Die Flutter-Dokumentation beschreibt auch weiterhin die ältere Podspec-Variante für Abwärtskompatibilität.

Sie sollten CocoaPods bei einem neuen Projekt nicht allein deshalb aktiv wiederherstellen, weil ein älteres Tutorial es verlangt. Eine Ausnahme ist ein für Ihre App unverzichtbares SDK, das noch ausschließlich über CocoaPods verteilt wird. Dann dokumentieren Sie diese Ausnahme und planen die spätere Ablösung als eigenes Arbeitspaket.

04

Bestandsprojekte: Migration in einem kontrollierten Zweig

Für eine gewöhnliche Flutter-App mit wenigen nativen Anpassungen ist eine Migration 2026 sinnvoll. Sie sollten aber nicht im produktiven Release-Zweig beginnen. Erstellen Sie zunächst einen Migrationszweig und frieren Sie den letzten veröffentlichungsfähigen Stand ein.

Erste Phase: Bestand erfassen

Notieren Sie vor der Änderung:

  • Flutter- und Dart-Version,
  • Xcode-Version,
  • iOS-Mindestversion,
  • alle Flutter-Plugins,
  • direkte Pod-Abhängigkeiten,
  • eigene Build-Skripte,
  • Flavors und Schemes,
  • Extensions und Test-Targets,
  • Signierungs- und Exportkonfiguration.

Prüfen Sie danach, ob Ihr Projekt alte Flutter-Integrationsschritte im Podfile enthält. Die offizielle Add-to-App-Migrationsanleitung verlangt bei früheren CocoaPods-Integrationen zunächst die Entfernung der alten Flutter-Installation aus dem Podfile. Diese Anweisung gilt für den jeweiligen Integrationstyp; sie ist kein Freibrief, jede eigene Pod-Abhängigkeit ohne Ersatz zu löschen.

Zweite Phase: Abhängigkeiten vergleichen

Führen Sie die Migration zunächst ohne gleichzeitige Plugin-Upgrades durch. Wenn Sie Flutter-Version, Plugins, Xcode und Abhängigkeitsmanager gleichzeitig ändern, ist die Fehlerursache später kaum feststellbar.

Vergleichen Sie mindestens:

  • die aufgelösten Versionen,
  • die Framework- und Ressourcenliste,
  • die Build-Phasen,
  • die Deployment Targets,
  • die Einträge für jedes Target,
  • die erzeugte App-Struktur im Archive.

Ein erfolgreicher Debug-Build ist nur ein Zwischenstand. Ein Release Archive muss zusätzlich die tatsächlichen Distribution-Einstellungen, Entitlements und Signierungsprofile durchlaufen.

Dritte Phase: Rückfall vorbereiten

Behalten Sie den funktionierenden Podfile-Stand, die Lock-Datei und die bisherige CI/CD-Konfiguration. Legen Sie fest, wie Sie innerhalb eines Arbeitstages auf den alten Build zurückkehren. Dazu gehört nicht nur ein Git-Revert. Sie brauchen auch:

  • eine wiederherstellbare Toolchain,
  • bekannte Cache-Pfade,
  • dokumentierte Umgebungsvariablen,
  • eine funktionierende Signierungsquelle,
  • einen reproduzierbaren Upload-Vorcheck.

Wenn Sie für den Rückfall erst ein altes Ruby-Setup aus einer vergessenen Entwicklungsmaschine suchen müssen, existiert praktisch kein Rückfall.

05

Pluginreiche, Multi-Target- und Add-to-App-Projekte

Plugin-Autoren müssen den Downstream-Build prüfen

Als Plugin-Autor sollten Sie nicht nur das eigene Beispielprojekt starten. Ihre Prüfung muss zeigen, dass ein fremdes Flutter-Projekt das Plugin mit SwiftPM tatsächlich auflösen und bauen kann.

Kontrollieren Sie:

  • Package.swift im vorgesehenen iOS- oder macOS-Verzeichnis,
  • native Ressourcen und Resource Bundles,
  • Plattform-Mindestversionen,
  • Swift- und Objective-C-Schnittstellen,
  • Test-Targets,
  • Debug- und Release-Konfiguration,
  • Nutzung des Plugins in einem neuen Projekt und in einem älteren Bestandssystem.

Flutter dokumentiert die Erstellung von Plugin-Projekten und die Deklaration nativer SwiftPM-Abhängigkeiten. Ein Plugin kann dabei weiterhin eine CocoaPods-Beschreibung für Nutzer bereitstellen, die noch nicht umgestellt haben.

Mehrere Targets werden einzeln validiert

Bei einer App mit Flavors oder Extensions reicht ein Test des Haupttargets nicht. Ein Plugin kann in Debug-Staging korrekt erscheinen, aber in Release-Production fehlen. Prüfen Sie jede relevante Kombination, statt nur eine grüne Standard-Scheme zu verwenden.

Besonders aufmerksam sollten Sie bei privaten Pods, lokalen Frameworks, manuellen Header-Suchpfaden und benutzerdefinierten Build-Skripten sein. Diese Elemente sind häufig nicht durch den Standardpfad einer neuen Flutter-App abgedeckt.

Add-to-App separat behandeln

Flutter unterstützt Add-to-App für iOS und beschreibt auch den Aufbau eines Flutter-Moduls als Swift Package. Die Integration bleibt dennoch vom Host-Projekt abhängig. Bei einem bestehenden iOS-Host müssen Sie daher die Flutter-Modul-Ausgabe, relative Pfade, Xcode-Schemes und die Host-Signierung gemeinsam prüfen.

Für komplexe Add-to-App-Projekte lautet die Empfehlung: nicht sofort umstellen, sondern einen isolierten Host-Branch mit identischem Release-Scheme aufbauen. Erst wenn dieser Branch ein signiertes Archive erzeugt, darf die neue Integration in die Hauptpipeline.

06

Der Flutter-3.44-iOS-Build im direkten Vergleich

Die folgende Übersicht trennt die technische Lage von der Betriebsentscheidung. CocoaPods ist nicht plötzlich wertlos. SwiftPM ist aber für neue Flutter-3.44-Projekte der strategische Standard.

Kriterium Swift Package Manager CocoaPods
Rolle in Flutter 3.44 Standard für native iOS- und macOS-Abhängigkeiten Rückwärtskompatibilität und Rückfallweg
Geeignet für neue Projekte Ja, sofern Plugins kompatibel sind Nur bei konkreten SDK- oder Plugin-Anforderungen
Abhängigkeit von Podfile und Ruby Geringer Häufig vorhanden
Plugin-Kompatibilität Muss je Plugin geprüft werden Für ältere Plugins oft der etablierte Weg
Add-to-App Neuer offizieller Integrationspfad Legacy-Integration bleibt relevant
Risiko bei sofortigem Löschen Fehlende Plugins oder Targets Weniger kurzfristige Änderungen, aber mehr Altlasten
Beste Entscheidung für CI/CD Nach sauberem Archive-Test Als dokumentierter Rückfall

Für Ihre Entscheidung ist nicht ausschlaggebend, ob eine einzelne lokale Kompilierung gelingt. Entscheidend ist, ob die gesamte Lieferkette dieselbe Ausgabe erzeugt: Dependency Resolution, Release Compile, Archive, Signierung und Upload-Vorprüfung.

07

Fünf Schritte für die Migration auf einem Remote Mac

Ein Remote Mac ist besonders nützlich, wenn Ihr lokaler Rechner keine getrennte macOS-Testumgebung bereitstellt. Die Maschine sollte nicht als magische Fehlerbehebung dienen. Sie ist ein reproduzierbarer Prüfstand.

1. Toolchain und Ausgangszustand festhalten

Legen Sie Flutter-Version, Xcode-Version, macOS-Version und Git-Commit fest. Führen Sie anschließend aus:

flutter doctor -v
flutter --version
xcodebuild -version
flutter pub get

Speichern Sie die Ausgaben als Build-Artefakte. Ohne diesen Ausgangszustand können Sie einen späteren Fehler nicht sauber der Migration zuordnen. Die Flutter-Dokumentation empfiehlt flutter doctor -v zur Prüfung der Entwicklungsumgebung. (Flutter-Anleitung zur Einrichtung auf macOS)

2. Eine saubere Umgebung verwenden

Holen Sie den Projektstand neu aus dem Repository. Verlassen Sie sich nicht auf lokale Xcode-, Pub- oder SwiftPM-Caches. Löschen Sie nur dokumentiert und kontrolliert generierte Verzeichnisse. Ihr Ziel ist nicht, jeden Cache dauerhaft zu verbieten, sondern einmal zu prüfen, ob das Projekt ohne zufällig vorhandene Artefakte funktioniert.

Prüfen Sie außerdem, ob Zertifikate, Provisioning Profiles und App-Store-Zugangsdaten außerhalb des Quellcodes sicher bereitgestellt werden. Private Schlüssel gehören weder in Git noch in Chatprotokolle oder Build-Logs.

3. Abhängigkeiten und Plugins protokollieren

Führen Sie flutter pub deps aus und erstellen Sie eine Liste aller iOS- und macOS-relevanten Plugins. Markieren Sie Plugins mit:

  • SwiftPM-Unterstützung,
  • CocoaPods-Abhängigkeit,
  • privaten nativen Bibliotheken,
  • eigenen Build-Schritten,
  • mehreren Plattform-Targets.

Wenn Flutter wegen eines inkompatiblen Plugins auf CocoaPods zurückfällt, dokumentieren Sie genau dieses Plugin. Eine gemischte Lösung muss nachvollziehbar sein, damit der nächste Entwickler nicht irrtümlich alle Pods entfernt.

4. Debug, Release und Archive getrennt bauen

Testen Sie mindestens einen Simulator-Build und einen echten Release-Pfad. Ein möglicher Ablauf ist:

flutter clean
flutter pub get
flutter build ios --release --no-codesign

Danach öffnen Sie das iOS-Projekt in Xcode oder verwenden die für Ihre Pipeline dokumentierte xcodebuild-Konfiguration. Erzeugen Sie ein Release Archive mit Ihrer echten Scheme und prüfen Sie die Signierung. Verwenden Sie für Pfade, Team-IDs und Profile nur Platzhalter in internen Anleitungen:

<WORKSPACE>
<SCHEME>
<ARCHIVE_PATH>
<EXPORT_OPTIONS>

Der Parameter --no-codesign ist nur für den Kompilierungstest geeignet. Er beweist nicht, dass Ihr signiertes Produktionsartefakt exportiert oder hochgeladen werden kann.

5. Rückfall und Upload-Vorprüfung testen

Wechseln Sie kontrolliert auf den vorherigen Commit zurück und prüfen Sie, ob der alte Build weiterhin reproduzierbar ist. Danach testen Sie erneut den Migrationszweig. Halten Sie fest, ob Fehler in einer dieser Phasen auftreten:

  • Dependency Resolution,
  • Swift- oder Objective-C-Kompilierung,
  • Ressourcenverarbeitung,
  • Archive-Erstellung,
  • Code Signing,
  • Export,
  • Upload-Vorprüfung.

Die Aufteilung verhindert, dass Sie ein Signierungsproblem fälschlich dem neuen Abhängigkeitsmanager zuschreiben.

08

Checkliste für die Freigabe

  • [ ] Flutter- und Xcode-Version im Build-Log gespeichert
  • [ ] Alle iOS- und macOS-Plugins auf SwiftPM- oder CocoaPods-Pfad geprüft
  • [ ] Neue Abhängigkeiten ohne unkontrollierte lokale Caches aufgelöst
  • [ ] Debug-Build auf Simulator oder Testgerät erfolgreich
  • [ ] Release-Build ohne Debug-only-Konfiguration erfolgreich
  • [ ] Haupt-App und jede relevante Extension archiviert
  • [ ] Bundle-ID, Entitlements und Signierung kontrolliert
  • [ ] Export des Archives mit Produktions-Scheme geprüft
  • [ ] Upload-Vorprüfung ohne echte Zugangsdaten im Log durchgeführt
  • [ ] Alter Podfile- und CI/CD-Stand wiederherstellbar
  • [ ] Fehlerklassifizierung für Dependency, Compile, Archive und Signierung dokumentiert
  • [ ] Remote-Mac- oder CI-Umgebung aus einem frischen Checkout reproduziert

Diese Liste ist absichtlich strenger als ein lokaler Start mit flutter run. Ein App-Store-Release hängt an den letzten vier Punkten, nicht am ersten sichtbaren grünen Build.

09

Häufige Fragen zur Migration

Brauchen Sie nach Flutter 3.44 noch CocoaPods?

Für ein neues, kompatibles Projekt normalerweise nicht als primären Weg. CocoaPods bleibt aber sinnvoll, wenn ein Plugin noch keine SwiftPM-Integration besitzt oder Ihr Projekt eigene Pods verwendet. Die offizielle Flutter-Dokumentation bezeichnet CocoaPods als weiterhin unterstützten Kompatibilitätsweg. Sie sollten es erst entfernen, wenn alle betroffenen Targets und der Release-Pfad erfolgreich geprüft wurden.

Was tun bei einem Plugin ohne SwiftPM-Unterstützung?

Aktualisieren Sie das Plugin nicht blind während der Flutter-Migration. Prüfen Sie zunächst, ob Flutter den betreffenden Baustein automatisch über CocoaPods weiter einbindet. Wenn dieser Rückfall funktioniert, können Sie die Migration mit einer dokumentierten Mischkonfiguration fortsetzen. Wenn das Plugin den Release-Build blockiert, brauchen Sie ein kompatibles Update, einen Ersatz oder eine bewusst verschobene Migration.

Verändert die Migration Ihre iOS-Signierung?

Nicht automatisch. Zertifikate und Entitlements bleiben eigene Bestandteile Ihrer Apple-Buildkonfiguration. Die neue Abhängigkeitsauflösung kann jedoch verändern, welche Frameworks, Ressourcen und Build-Phasen in ein Target gelangen. Deshalb müssen Sie ein signiertes Release Archive testen. Nur ein Simulatorlauf oder ein unsignierter flutter build ios reicht für diese Entscheidung nicht.

Wie prüfen Sie den Build auf einem Remote Mac?

Starten Sie mit einem frischen Checkout und speichern Sie flutter doctor -v, Flutter-Version und Xcode-Version. Lösen Sie danach die Abhängigkeiten neu auf, bauen Sie Debug und Release, erzeugen Sie ein Archive und prüfen Sie Signierung sowie Export. Nutzen Sie den Remote Mac als getrennten Prüfstand. Wenn die Migration dort nur mit persönlichen Caches funktioniert, ist die CI/CD-Konfiguration noch nicht reproduzierbar.

10

Ihre Entscheidung für diese Woche

Wenn Sie ein neues Flutter-Projekt starten, verwenden Sie den Flutter-3.44-Standard mit Swift Package Manager und prüfen Sie Plugins vor der ersten Veröffentlichung. Bei einem normalen Bestandsprojekt legen Sie einen Migrationszweig an, vergleichen Dependency Resolution, Release Archive und Signierung und halten den alten Podfile-Stand als Rückfall bereit.

Bei privaten Pods, mehreren Flavors, Extensions, eigenen Targets oder Add-to-App sollten Sie CocoaPods nicht vorschnell löschen. Die geplante Read-only-Umstellung des CocoaPods-Trunk am 02.12.2026 ist ein Anlass zur Planung, aber kein Beweis für einen sofortigen Build-Ausfall.

Der größte praktische Nachteil Ihrer bisherigen Umgebung ist meist nicht Flutter selbst, sondern die fehlende Trennung zwischen Entwicklungsrechner, produktiver Signierung und Test-Build. Ein lokaler Rechner kann durch Caches einen defekten Build scheinbar reparieren. Eine dauerhaft laufende CI-Maschine bindet dagegen Hardware und Pflegeaufwand, obwohl Sie die Migration vielleicht nur wenige Wochen intensiv testen müssen.

Wenn Sie für diese Prüfung keinen unabhängigen Mac bereitstellen können, ist ein zeitlich begrenzter Remote Mac von VpsMesh eine sachliche Zwischenlösung: Sie kopieren Ihre vorhandene Toolchain, führen den Vorher-nachher-Vergleich aus und entscheiden erst danach über eine dauerhafte Build-Umgebung. Für die Planung können Sie die Mac-Mietpreise von VpsMesh prüfen oder sich zunächst über die verfügbaren Remote-Mac-Optionen informieren. Für einen langfristig stabilen, täglichen Schwerlastbetrieb kann ein eigener Mac wirtschaftlicher sein; für Migrationstests, Release-Überprüfungen und temporäre CI/CD-Phasen ist die mietenbasierte Trennung oft die risikoärmere Variante.