CI-Pipelines für Android und iOS

KMP teilt Code, liefert aber weiterhin zwei Apps aus. Eine gute CI erstellt, testet und paketiert Android und iOS bei jedem Push automatisch.

Der größte Vorteil liegt in der gemeinsamen Logik. Führen Sie die commonTest-Suite in der CI aus, damit eine fehlerhafte Regel einmal erkannt wird, bevor sie eine der beiden Apps erreicht.

Für Android erstellt die CI das APK oder Bundle. Die Aufgabe assembleRelease erzeugt das Artefakt, das Ihr Release-Schritt später hochlädt.

iOS-Jobs müssen auf einem macOS-Runner mit Xcode laufen. Linux kann weder das Kotlin/Native-Framework kompilieren noch die iOS-App erstellen.

Frische Runner sind langsam. Wenn Sie das Gradle-Home und Kotlin/Native-Abhängigkeiten über mehrere Jobs hinweg cachen, vermeiden Sie bei jedem Lauf erneute Downloads.

Wenn iOS Pods verwendet, cachen Sie den Pods-Ordner. Einen vollständigen Pod-Installationslauf bei jedem Durchlauf zu überspringen, spart beim iOS-Job spürbar Zeit.

Halten Sie Android und iOS als getrennte Jobs, damit eine fehlschlagende Plattform die andere nicht verbirgt. Beide sollen dennoch durch denselben Push gestartet werden.

Release-Builds benötigen Schlüssel. Speichern Sie Keystore und Zertifikate als verschlüsselte Secrets, niemals im Repository.

Führen Sie Lint- und Formatierungsprüfungen früh aus. Wenn Sie Stilprobleme und offensichtliche Fehler sofort erkennen, sparen Sie teure Build-Minuten bei ohnehin zum Scheitern verurteilten Läufen.

Speichern Sie das APK und das iOS-Artefakt aus jedem Lauf. Tester können einen Build direkt herunterladen, statt auf einen manuellen Export zu warten.

Führen Sie die vollständige Suite bei jedem Pull Request aus und blockieren Sie Merges, bis sie erfolgreich durchgelaufen ist. So bleibt main jederzeit auslieferbar.

Sie haben gemeinsame Tests in der CI ausgeführt, beide Apps erstellt – Android unter Linux und iOS unter macOS –, Abhängigkeiten gecacht, mit Secrets signiert und Merges von einem erfolgreichen Lauf abhängig gemacht. ✅