Flutter iOS CI/CD: IPA auf Mac mini M4 mit CocoaPods-Cache-Tuning

Dieser Artikel behandelt nur eines: Flutter iOS CI/CD (Haupt-Keyword: Flutter iOS build on Mac mini) — wie Sie flutter build ipa stabil auf einem Mac mini M4 betreiben und CocoaPods-Cache, self-hosted macOS Runner sowie Android-/Test-Jobs auf Linux trennen. Der echte Engpass bei Flutter ist selten Dart, sondern die Mac-Pflicht der iOS-Buildkette: pod install → xcodebuild archive → Signierung → TestFlight-Upload. Diese Kette läuft nur auf dem Mac. Unser Team trennt typisch: Android auf Windows/Linux-CI, Flutter iOS CI fest auf einem dedizierten Mac mini im Rack. Bei nativem Xcode-Mix siehe langsame Xcode-Builds in die Cloud; Runner-Anmeldung und TCO: eigene macOS-Runner.

1) Warum Flutter iOS CI einen eigenen Mac braucht

„Eine Codebasis“ löst Wiederverwendung von Geschäftslogik — nicht von Build-Ebenen. iOS-Artefakte durchlaufen weiter die volle Xcode-Pipeline; Flutter iOS CI auf ubuntu-latest ist unmöglich. GitHub-gehostetes macOS ist teuer pro Minute, die Queue schwankt, und ohne persistenten Cache landet flutter build ipa wieder bei 15–25 Minuten. Flutter iOS CI/CD auf einem dauerhaft laufenden Mac mini bringt: festgezogene Flutter/Xcode-Versionen, dreistufigen wiederverwendbaren Cache, 24/7 ohne Deckel-Sleep — Android- und iOS-Release-Takte entkoppeln sich wirklich.

2) Flutter iOS CI Cloud-Architektur

So sieht unsere produktive Flutter iOS CI/CD-Topologie aus: Nicht jeder Entwickler braucht einen Mac lokal; das iOS-Paket kommt vom self-hosted Runner.

3) Drei Betriebsmodelle für Flutter iOS CI

Wir nutzen A + C: nach Merge flutter test auf Linux; Flutter iOS CI nur bei Tag/main-Merge über den Mac-mini-Runner. B eignet sich kurzfristig ohne Mac; langfristig Runner-Setup.

4) Flutter iOS CI Umgebungs-Checkliste (einmalig auf dem Mac mini)

1. Xcode + CLT: Passend zu ios/Podfile und Flutter-Kanal-Minimum. Danach sudo xcodebuild -license accept.
2. Flutter SDK: fvm oder festes ~/flutter; .fvmrc im Repo, damit Team und CI dieselbe Version nutzen.
3. CocoaPods: gem install cocoapods oder Homebrew; große Repos: Podfile.lock committen.
4. Signierung: Fastlane Match oder Xcode Auto-Signing. p12 und Provisioning nicht ins Git — verschlüsseltes Repo oder CI-Secrets.
5. Netzwerk: Region nahe Git-Remote und pub.dev/CDN; Firmen-Git ggf. VPN/Leitung — Ausgangshinweise im Hilfezentrum.

Beim ersten Lauf auf neuer Hardware flutter doctor -v ausführen und ins Team-Wiki legen — künftige Fehlersuche startet mit diesem „Gold-Snapshot“.

5) CocoaPods-Cache: Kern der Flutter-iOS-CI-Beschleunigung (mit Before/After)

Gleiches mittelgroßes Flutter-Repo (~40+ Plugins, Release-IPA), je 3 Läufe in 3 Umgebungen, Median — der Unterschied bei Flutter iOS CI hängt fast nur daran, ob der Cache auf dem Mac mini bleibt.

Vom zweiten Build von 12+ Minuten auf einstellig — dank der drei persistenten Schichten im Diagramm. Das ist die Schwelle, an der Flutter iOS build on Mac mini von „geht irgendwie“ zu „eignet sich als CI“ wird.

• PUB_CACHE / ~/.pub-cache: Runner-Env mit festem Pfad, Dart-Deps zwischen Jobs.
• CocoaPods cache + ios/Pods: unverändertes Podfile.lock → pod install überspringen; sonst inkrementell.
• DerivedData: fest ~/DerivedData; kein clean außer bei Xcode-Major-Upgrade.

6) Flutter iOS CI Befehlsablauf (SSH oder Runner-Skript)

Im Repo-Root ausführen; Flutter-Version durch Ihre Projektfestlegung ersetzen:

cd ~/work/my_flutter_app
export PUB_CACHE=$HOME/.pub-cache
fvm flutter pub get
cd ios && pod install --repo-update && cd ..
fvm flutter build ipa --release \
  --export-options-plist=ios/ExportOptions.plist

In GitHub Actions die Schritte in release-ios.yml, runs-on: [self-hosted, macos, flutter-ios]. Beim TestFlight-Upload sind Ausgang und Route zum App Store Connect vom Mac mini oft stabiler als heimisches WLAN.

7) GitHub Actions: Flutter iOS CI/CD Workflows trennen

Empfehlung: zwei Workflows (oder Matrix mit if):

• test-android.yml: auf ubuntu-latest flutter test, build apk.
• release-ios.yml: runs-on: [self-hosted, macos, flutter], nur bei Tag oder main-Merge build ipa + Upload.

Läuft VNC-Debug und Runner parallel auf dem Cloud-Mac, separaten Systembenutzer für Builds — sonst kollidieren manuelle Änderungen und automatisches Checkout. Parallelität und Disk: Runner-TCO. Windows als Haupt-OS: Xcode unter Windows + Cloud-Mac — bei Flutter fehlt lokal ebenfalls Xcode.

8) Häufige Probleme: Warum Flutter iOS CI hängt (how/fix)

Entspricht typischen Google-Suchen nach why/how/fix/error — unser Wiki-Einstieg.

pod install dauert 10+ Minuten — normal?

Why: Runner checkt jedes Mal in ein Temp-Verzeichnis aus, CocoaPods-Download-Cache nicht gemountet, oder pod install --repo-update steht im Default-Skript.
Fix: Festen WORK-Pfad; Podfile.lock-Hash vergleichen, bei Gleichheit überspringen; --repo-update in wöchentlichen Wartungs-Job.

xcodebuild archive schlägt fehl / exit code 65

Why: Flutter/Xcode-Version passen nicht, DerivedData kaputt, native Plugin inkompatibel zum SDK.
Fix: Zu CI-Start fvm flutter doctor -v loggen; DerivedData löschen und neu; Xcode Release Notes für Kanal.

signing failed / Provisioning passt nicht

Why: p12 nicht im Keychain, bundle id ≠ Profil, Match-Repo abgelaufen.
Fix: eigener Keychain auf dem Mac-mini-Runner; Fastlane Match erneuern; ggf. per VNC „immer vertrauen“ — häufigster Nicht-Code-Fehler in Flutter iOS CI.

DerivedData frisst die Platte

Why: parallele Jobs mehrerer Branches, alte Archives, mehrere Flutter-Versionen.
Fix: cron für ~/Library/Developer/Xcode/Archives; Runner-Parallelität 1–2; Disk ≥512 GB oder regelmäßig erweitern.

Flutter-Version uneinheitlich → Plugin-Build-Fehler

Why: Entwickler ohne fvm, CI anderer Kanal.
Fix: .fvmrc committen; CI einheitlich fvm install && fvm flutter pub get; PR-Template mit „Flutter SDK geändert?“.

9) Wann ein dedizierter Mac mini für Flutter iOS CI sinnvoll ist

10) FAQ (Flutter iOS CI/CD)

Unterschied Flutter iOS CI vs. natives iOS CI?
Extra-Schicht flutter pub get und Plugin-Codegen; Version muss zu .fvmrc passen; Xcode-Seite bleibt Pods + archive.

Vergleich Codemagic / gehostetes macOS?
Gehostet gut zum schnellen Testen; wenn der zweite Build stabil unter 10 Minuten und mit starkem Cache laufen soll, ist Flutter iOS build on Mac mini + self-hosted Runner kontrollierbarer.

Wie lange bis der erste durchläuft?
Erfahrene Teams ~1 Arbeitstag: Xcode/Flutter, Runner, Signierung, ein build ipa → TestFlight.