Die besten CI/CD-Plattformen für Cordova-Apps 2026 im Vergleich

Die beste CI/CD-Plattform für eine Cordova-App ist 2026 meist eine allgemeine CI-Plattform, die den Cordova CLI unter Linux für Android und unter macOS für iOS ausführen kann: GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI oder Azure DevOps. Was aber keine davon ersetzt, ist der managed live update-Service, den Cordova-Teams von App Center und Appflow gewohnt waren. Dieser Vergleich deckt Build-Support, Signing, Store-Publishing, Live Updates und die langfristige Perspektive jeder Option ab.

Der aktuelle Stand von Cordova CI/CD

Drei Managed Services haben das Cordova-Ökosystem aufgebaut – alle drei sind weg oder werden eingestellt:

Das Framework Cordova veröffentlicht weiterhin Plattform-Releases. Die Arbeit, die zu dir übergegangen ist, ist alles rund um den Build: Signing-Speicher, Store-Uploads, Versionsnummern und Over-the-Air-Updates.

Wenn du heute nur eine funktionierende Pipeline brauchst, starte mit CI/CD für Cordova-Apps, für das es einen vollständigen GitHub Actions-Workflow gibt. Dieser Artikel hilft dir zu entscheiden, wo du ihn laufen lässt.

Was ein Cordova-Team vergleichen sollte

1. Cordova-Kenntnisse. Hat die Plattform Cordova-Schritte oder Templates, oder skriptest du cordova build selbst? Skripten ist in Ordnung; es sind überall dieselben drei Befehle.
2. macOS-Runner mit Xcode 26, den App Store Connect seit dem 28. April 2026 erfordert.
3. Signing-Speicher für den Android-Keystore, das iOS-Zertifikat und die Provisioning-Profile.
4. Store-Publishing zu TestFlight und Google Play-Tracks.
5. Live Updates für Fixes im Web-Layer.
6. Git-Hosting und Self-Hosting, was für Enterprise- und Behörden-Apps wichtig ist, die oft noch auf Cordova setzen.

Feature-Matrix

Capgo sitzt neben der CI, die du wählst, statt sie zu ersetzen: Deine CI baut die Cordova-Binaries, und Capgo Live Updates liefert nur Web-Änderungen an installierte Apps aus. Capgo Build ist für Capacitor-Projekte dokumentiert, daher ist es keine Option, um ein Cordova-Binary zu bauen.

Plattform für Plattform

GitHub Aktionen

Die gängigste Wahl für Cordova-Teams auf GitHub. Android-Builds laufen auf ubuntu-latest mit actions/setup-java. iOS-Builds laufen auf macos-26 mit vorinstalliertem Xcode 26. Du dekodierst den Keystore und .p12 aus Secrets, schreibst ein build.json, und führst cordova buildaus. Uploads nutzen fastlane, xcrun altool, oder Community-Actions für Play-Uploads. Keine Cordova-spezifischen Features, aber es steht dir auch nichts im Weg. Beachte die macOS-Minutenkosten bei privaten Repositories.

GitLab CI

Der gleiche Scripting-Ansatz. Hosted macOS-Runner gibt es auf GitLab.com für Premium und Ultimate in Beta, mit Images wie macos-26-xcode-26. Selbstverwaltete GitLab-Instanzen, die viele regulierte Cordova-Teams nutzen, benötigen eigene Mac-Runner. Secure Files sind ein sauberer Ort für den Keystore und das Provisioning Profile. Siehe CI/CD in GitLab einrichten.

Bitrise

Die Mobile-CI mit dem klarsten Cordova-Support. Die Step-Library enthält Cordova-Steps für das Projekt-Setup und das Archivieren von iOS- und Android-Builds, dazu code Signing-Management und Store-Deploy-Steps. Wenn du einen UI-getriebenen Workflow willst und mit Credit-basiertem Pricing einverstanden bist, kommst du hier dem alten App-Center-Build-Erlebnis am nächsten.

Codemagic

Codemagic dokumentiert Ionic-Cordova-Builds in codemagic.yaml, mit verwalteten Android-Keystores, automatischem iOS-Signing über einen App Store Connect API Key und Veröffentlichen auf TestFlight und Google Play. Die Preise richten sich nach Build-Minuten oder einem festen Jahresplan. Ideal für Teams, die YAML im Repository mögen, aber das Signing abgeben wollen.

Appcircle

Appcircle baut Cordova über Custom-Scripts im Workflow auf seinen iOS- und Android-Build-Pipelines auf und bietet zusätzlich Ablage für Signing-Identities, Verteilung an Tester, einen Enterprise App Store sowie Store-Publishing. Appcircle Server läuft komplett auf deiner eigenen Infrastruktur – das stärkste Self-Hosting-Angebot in dieser Liste.

CircleCI

Skriptbasierte Cordova-Builds auf Linux-Docker-Executors für Android und Apple-Silicon-macOS-Executors für iOS. Signing und Uploads laufen über fastlane oder Shell. Sinnvoll, wenn CircleCI bereits dein Backend baut.

Azure DevOps

Azure Pipelines führt Cordova CLI als Skriptschritte aus und ergänzt First-Party-Tasks für die Installation von Apple-Zertifikaten und Provisioning Profiles aus Secure Files, Android-Signing und Store-Releases über Marketplace-Erweiterungen. Azure DevOps Server deckt On-Premises-Anforderungen ab. Viele ehemalige App Center-Kunden sind hier gelandet.

Xcode Cloud

Nur für den iOS-Teil möglich. Ein ci_scripts/ci_post_clone.sh Hook installiert Node, stellt Cordova-Plattformen wieder her und baut den Web-Layer, bevor Xcode Cloud das generierte Projekt archiviert. Da Cordova platforms/ios zum Build-Zeitpunkt generiert, muss der Workspace-Pfad beim Start des Workflows vorhanden sein, was das Setup umständlich macht. Die meisten Cordova-Teams nutzen es nur, wenn sie es bereits für native Apps einsetzen.

VoltBuilder

Eher ein Build-Service als eine CI: Du lädst ein ZIP deines Projekts mit Signing-Dateien hoch und erhältst Store-ready Binaries für Cordova- und Capacitor-Projekte. Keine Git-Trigger, Pipelines oder Live Updates. Nützlich für kleine Teams ohne CI. Siehe die Voltbuilder-Alternative Vergleichsseite.

Ionic Appflow

Immer noch die vollständigste Cordova-Plattform mit Builds, Signing, Publishing und Live Updates. Sie ist aber auch diejenige mit einem Enddatum. Wenn du Appflow nutzt, lautet die Frage nicht, ob du wechselst, sondern wann. Siehe Alternative zu Appflow.

Die live update-Lücke schließen

Jede allgemeine CI in dieser Liste erzeugt signierte Binaries. Keine davon liefert Over-the-Air-Updates an installierte Apps, und die alten Community-Hot-code-Push-Plugins werden nicht mehr gepflegt. Für Cordova bleibt bis Ende 2027 nur Appflow, ein selbst gehosteter Update-Server oder Capgo.

Capgo unterstützt Cordova über @capgo/cordova-updater, das den Capacitor-Updater API spiegelt und denselben Backend, Kanäle und CLI verwendet. Es erfordert Cordova iOS 7+ und Cordova Android 13+ und darf nicht mit cordova-plugin-ionic-webview. Installiere es mit deiner Capgo-App-ID:

cordova plugin add @capgo/cordova-updater --variable APP_ID=com.example.app
cordova prepare android ios

Rufe cordova.plugins.Updater.notifyAppReady() danach deviceready bei jedem Start, dann füge einen Schritt zu deiner CI für Web-only-Releases hinzu:

bun run build
bunx @capgo/cli@latest bundle upload --channel=production

Plugin-Zusätze oder -Upgrades erfordern weiterhin einen Store-Build; Capgo markiert Bundles, deren Native-Plugins vom Live-Bundle abweichen. Details im Cordova-Updater-Docs und live update-Kompatibilität. Die gesamte Pipeline, inklusive des live update-Jobs, liegt in CI/CD für Cordova-Apps.

Optional: Was der Wechsel zu Capacitor in der CI bringt

Für Live Updates ist eine Migration nicht zwingend erforderlich. Teams, die migrieren, tun dies meistens primär für die Build-Seite.

Capacitor führt die meisten Cordova-Plugins unverändert aus, behält deinen Web-code bei und committet die nativen Projekte in Git, statt sie neu zu generieren. Das macht CI-Builds vorhersagbarer. Deine Capgo App-ID und Channels bleiben erhalten, nur das Updater-Plugin ändert sich. Nach der Migration:

• Dein Linux-CI-Job läuft bun run build, bunx cap sync, und ein bunx @capgo/cli@latest build request pro Plattform. Kein macOS-Runner für iOS nötig.
• Web-only-Releases werden als Live Updates mit Channels, Rollbacks und Kompatibilitätsprüfungen veröffentlicht: bunx @capgo/cli@latest bundle upload --channel production.
• bunx @capgo/cli@latest build needed sagt der Pipeline, ob überhaupt ein Native Build nötig ist.

Migrations-Guide: Migration von Cordova zu Capacitor. Wenn du Hilfe brauchst, siehe Von Cordova zu Capacitor.

Die richtige Wahl treffen

Checkliste für die Migration von App Center oder Appflow

• Lade deinen Android Upload Keystore und deine iOS-Distribution herunter .p12 mit privaten Schlüsseln. Falls die alte Plattform diese generiert hat, exportiere sie, bevor du den Zugriff verlierst.
• Notiere aktuelle Versionscodes und Build-Nummern, damit der erste Build auf der neuen Plattform nicht kollidiert.
• Erstelle einen Google Play Service-Account und einen App Store Connect API Key für die neue CI.
• Liste alle Umgebungsvariablen auf, die die alte Plattform zur Build-Zeit injiziert hat.
• Führe vor dem Umstieg auf Produktion einen Internal-Track-Build und einen TestFlight-Build durch.
• Lege deinen live update-Plan fest, bevor der alte Dienst abgeschaltet wird, nicht danach.

Für mehr Details zu den iOS- und Android-Entscheidungen lies CI/CD-Plattformen für iOS-Apps im Vergleich und CI/CD-Plattformen für Android-Apps im Vergleich.