Die besten CI/CD-Plattformen für Capacitor Apps in 2026

Die Auswahl für Capacitor CI/CD ist geschrumpft. Die Build- und Distribution-Services von Microsoft App Center wurden am 31. März 2025 eingestellt. Ionic Appflow wird über mehrere Jahre schrittweise abgewickelt. GitHub Actions, GitLab CI, Bitrise und Codemagic gibt es noch, und sie sind immer noch gut bei den Aufgaben, für die sie entwickelt wurden.

Der Fehler ist, das als reinen Vergleich zu sehen, bei dem du auswählst eine Plattform und zieht die gesamte Pipeline dorthin um. Die meisten Capacitor Teams nutzen bereits CI. Was ihnen jedoch fehlt, sind die drei Aufgaben, die allgemeine CI-Systeme immer noch schlecht bewältigen: signierte Native Builds, Live-Updates, und die App auf ein echtes Smartphone zu bringen.

Capgo ist genau für diese drei Aufgaben gebaut und darauf ausgelegt, zu laufen innerhalb der CI, der du bereits vertraust. Nutze GitHub Actions oder GitLab CI weiterhin für Linting, Type-Checks, Unit-Tests und den Web-Build. Rufe Capgo auf, wenn die Pipeline eine iOS- oder Android-Binary, ein Over-the-Air Bundle oder einen Preview-Build benötigt, den Tester installieren können.

Die Landschaft 2026

Zwei Namen tauchen in den Suchergebnissen immer noch auf, obwohl sie für 2026 keine Kaufoption mehr darstellen.

• Microsoft App Center wird am 31. März 2025 eingestellt. Build und Distribution wurden gestoppt. Analytics und Diagnostics laufen noch bis zum 31. März 2027. CodePush ist kein von Microsoft gehosteter Service mehr. Falls du noch eine App Center Pipeline nutzt, lies Migration von App Center zu Capgo.
• Ionic Appflow hat den kommerziellen Verkauf am 11. Februar 2025 eingestellt. Bestandskunden behalten den Zugriff bis 31. Dezember 2027. Es funktioniert weiterhin, aber alles, was du jetzt startest, muss vor 2028 migriert werden. Siehe Alternative zu Ionic Appflow.

Damit bleiben die Plattformen übrig, die Teams tatsächlich nutzen:

• GitHub Aktionen und GitLab CI: Allzweck-CI. Exzellent auf Linux. Teuer und unausgereift bei Native Mobile.
• Bitrise und Codemagic: Mobile-CI-Spezialisten. Stark bei Signing und Store-Submit. Keine verwalteten Capacitor Live Updates.
• Capgo: Capacitor-native Live Updates, native Builds in der Cloud und installierbare Device-Previews – aufgerufen aus deiner bestehenden CI.
• Capawesome Cloud: Capacitor-native Live Updates und Native Builds als CI-Ersatz. Du verbindest Git und verlässt GitHub Actions. Geschlossenes Backend, voller Vendor Lock-in und eine Preishistorie, die sich schon mehr als einmal geändert hat.

Die sinnvolle Frage im Jahr 2026 lautet nicht: „Welche CI soll GitHub Actions ersetzen?“ Sondern: „Was sollte GitHub Actions aufrufen, wenn eine Capacitor App ein Binary, ein OTA-Bundle oder einen Install auf dem Handy braucht?“

Was Generalist-CIs immer noch schlecht beherrschen

GitHub Actions und GitLab CI sind gute Werkzeuge. Sie sind jedoch keine Native Build Farm, kein OTA-Netzwerk und kein QA-Device-Lab.

Native Builds

Für iOS werden weiterhin Xcode, Zertifikate, Provisioning Profiles und ein Mac benötigt. Android braucht einen Keystore und einen Play Upload Key. Gehostete macOS-Minuten bei GitHub Actions sind deutlich teurer als Linux-Minuten. Selbst nach der Preissenkung von GitHub im Januar 2026 kostet eine Standard-macOS-Minute immer noch etwa das Zehnfache einer Linux-Minute (GitHub Actions Abrechnung).

Deshalb teilen viele Capacitor Teams die Pipeline bereits auf: Linux für PR-Checks, etwas anderes für die signierte Binary. Capgo Native Builds ist dieses etwas andere. Der Job läuft auf ubuntu-latest. Capgo stellt den Mac bereit.

Live Updates

CI kann ein Web-Bundle kompilieren. Es kann dieses Bundle jedoch nicht mit Channels, Rollback, Verschlüsselung und Device Logs an Geräte ausliefern, auf denen die App bereits installiert ist. Live Updates sind ein Produkt, kein YAML-Schritt. Capacitor Teams, die auf OTA verzichten, müssen auf die App Store- und Play Store-Reviews warten, selbst wenn es nur um JavaScript-Fixes geht, die nie eine neue Binary erfordert hätten.

Capgo Capgo Live Updates steht neben der CI. Die Pipeline baut die Web-App und lädt das Bundle hoch. Nutzer erhalten die Änderungen ohne Store-Roundtrip, solange sich der native Shell nicht geändert hat.

Mobile App-Testing

Unit-Tests unter Linux beweisen nicht, dass die App auf einem Smartphone läuft. TestFlight-Verarbeitung, interne Play-Tracks und „Kannst du diese IPA installieren, die ich dir gerade gemailt habe?“ sind der langsame Teil des Reviews. Capgo PR-Previews jeden Pull Request auf einen Channel legen. Tester wechseln den Channel in der App, die sie bereits haben. Native Build-Jobs können zudem einen QR-Install-Link für die APK oder IPA bereitstellen.

Das ist keine Device Farm. Wenn du Emulator-Matrizen oder Firebase Test Lab brauchst, lass diese Jobs in der CI. Capgo schließt die Lücke, die CI selten füllt: ein Mensch mit einem Smartphone, der in unter einer Minute den richtigen Build ansieht.

Feature-Matrix

Drei Dinge fallen auf. Capgo, Capawesome Cloud und Appflow kombinieren verwaltete Live Updates mit Native Builds, wobei Appflow eingestellt wird. Nur Capgo ist darauf ausgelegt, beibehalten GitHub Actions oder GitLab CI zu ergänzen, statt sie zu ersetzen. Capawesome Cloud ist die andere Capacitor-native Option, aber es ist ein Ersatz-CI mit geschlossenem Backend. Bitrise und Codemagic können die native Binary verwalten, aber OTA und Device Previews müssen Sie selbst zusammenstellen.

Die Plattformen im Detail

Capgo

Capgo ist die Capacitor Release-Layer, die allgemeinen CI-Systemen fehlt.

• Live Updates: verschlüsselte Web-Bundle OTA, Channels, Rollback, Delta Updates und Device Logs.
• Native Builds: signierte iOS- und Android-Binaries in der Cloud, inklusive Store-Submit. Der CI-Runner kann auf Linux bleiben. Capgo ist bereits auf Xcode 26 für die App-Store-Connect-Anforderung vom April 2026.
• Device-Testing: PR-Preview-Channels, QR-Links auf nativen Artefakten und den Capgo Mobile App um ein Bundle auf einem echten Device zu testen.

Linting und Unit-Tests werden nicht von GitHub Actions entfernt. Stattdessen fügst du zwei CLI Aufrufe hinzu, sobald der Web-Build erfolgreich war:

- name: Live update
  run: npx @capgo/cli@latest bundle upload --channel production

- name: Native build
  run: npx @capgo/cli@latest build request com.example.app --platform ios --build-mode release

Kostenpflichtige Pläne starten bei $12/Monat bei jährlicher Abrechnung und enthalten Live Updates sowie Native Build-Zeit (ca. 15 Builds/Monat, zusätzliche Minuten werden über Credits abgerechnet). Dieser Einstiegspreis wurde seit dem Launch nicht erhöht. Siehe Preise, CI/CD mit Capgo Build, und die GitHub Actions Build-Guide.

Das Updater-Plugin ist Open Source (MPL-2.0) und das Backend ebenfalls (AGPL-3.0). Du kannst sie auditieren, forken oder selbst hosten. Die kostenpflichtige Capgo Cloud ist eine optionale Infrastruktur, keine Falle.

Capawesome Cloud

Capawesome Cloud CI — Native Builds plus Live Updates, jetzt als Capawesome Platform vertrieben — ist die andere Capacitor-native Option, die OTA mit Cloud-Builds für iOS und Android kombiniert. Das Produktversprechen ist das Gegenteil von Capgo: ersetzen GitHub Actions und GitLab, anstatt sie einfach einzubinden.

Ihr Post zum Launch der Native Builds ist eindeutig: Kein Drittanbieter-CI/CD. Verbinde GitHub, GitLab, Bitbucket oder Azure DevOps. Pack die Pipeline in capawesome.config.json. Führe sie in der Capawesome Cloud aus. Du kannst einen Build über ein CLI triggern, aber der vorgesehene Workflow ist Vendor-hosted CI. Git-Integration, Signing, Build-Minuten, Live Updates und Store-Submit laufen alle über ein geschlossenes Backend. Das Plugin und CLI sind Open Source. Das Backend ist es nicht. Self-Hosting ist höchstens teilweise möglich: Du kannst Bundles hosten, aber die Metadaten bleiben in der Capawesome Cloud.

Das bedeutet totalen Vendor Lock-in. Ein späterer Wechsel bedeutet, den Updater, die Build-Konfiguration, die Git-Verbindung und die Release-Metadaten mit umzuziehen. Capgo hält diese Teile in deinem Repo und deiner CI, und der Open-Source-Updater sowie das Backend bieten dir einen einfachen Ausstieg.

Auch die Preisgestaltung unterscheidet sich. Das kostenpflichtige Angebot von Capgo war bisher 12 $/Monat seit dem Launch jährlich abgerechnet. Er wurde nie erhöht. Capawesome hat das kommerzielle Modell bereits mehrfach geändert:

• Launch von Native Builds: von $9/Monat für 1.000 Live Updates und 200 Build-Minuten. Das Business war $299/Monat.
• Mai 2026 Plattform-Relaunch: Live Updates wurden von MAU auf eine Abrechnung pro Update umgestellt, dann zurück zu MAU nach Kundenbeschwerden. Das komplette Plattform-Paket (Builds, Live Updates und Publishing) startet bei $19/Monat. Business ist $499/Monat.
• Die aktuellen öffentlichen Preise trennen Live Updates (ab $9/Monat) von der vollen Plattform (ab $19/Monat).

Ein günstigerer Preis, der sich ständig ändert, ist nicht dasselbe wie ein fairer Preis, der stabil bleibt. Wenn du Capacitor Live Updates und Native Builds willst, ohne deine CI aufzugeben, passt Capgo. Wenn du bereits auf Capawesome-Plugins setzt und deren Git-basierte CI willst, lies den Capgo vs. Capawesome Cloud und Migrationsleitfaden.

Quellen: Ankündigung zu Capawesome Native Builds, Ankündigung zur Capawesome Platform, Capawesome-Preise.

GitHub Aktionen

GitHub Actions ist die Standard-CI für die meisten Capacitor-Repos und sollte es für PR-Checks auch bleiben. Linux-Jobs sind günstig. Der Workflow liegt direkt neben dem code. Caching, Matrix-Builds und erforderliche Status-Checks sind bereits gelöst.

Was es nicht ist: eine Mobile-DevOps-Plattform. Du schreibst das YAML. Du bindest Fastlane oder Capgo fürs Signing ein. Du hostest dein eigenes OTA, oder du hast gar kein OTA. macOS-Minuten dominieren die Rechnung, sobald iOS-Builds bei jedem Pull Request laufen.

Der Hybrid, der funktioniert: GitHub Actions für Lint, Tests und npm run build. Capgo für bundle upload, native Builds und Previews. Diese Aufteilung ist günstiger und schneller, als die gesamte Mobile-Pipeline auf gehostete Macs zu zwingen. Setup-Guides: GitHub Actions Live Updates und automatischer Build und Release.

GitLab CI

Gleicher Aufbau wie GitHub Actions. Starke Linux-CI, optionale Mac-Runner, keine verwalteten Capacitor Live Updates, kein installierbarer PR-Channel. Wenn das Repo schon auf GitLab liegt, behalte es. Nutze Capgo .gitlab-ci.yml auf dieselbe Weise. Siehe GitLab Setup und automatische Android-Builds auf GitLab.

Bitrise

Bitrise ist eine Mobile-CI-Plattform mit einer umfangreichen Step-Library, Managed Signing und Store-Publishing. Du kannst eine Capacitor App mit npm Steps sowie nativen iOS- und Android-Steps bauen. Es ist eine gute Wahl, wenn das Team eine dedizierte Mobile-Runner-Flotte möchte und kein OTA benötigt.

Was fehlt, ist der Capacitor-ähnliche Release-Loop: Live Updates, PR-Channels und ein CLI, das dein bestehender GitHub Workflow aufrufen kann, ohne die gesamte Pipeline zu verschieben. Das Pricing liegt zudem im oberen Bereich für Mobile CI. Nutze Bitrise, wenn ihr bereits für native Apps darauf standardisiert seid. Füge Capgo hinzu, wenn du weiterhin OTA und Device-Previews brauchst; geh nicht davon aus, dass Bitrise diese Ebene ersetzt.

Codemagic

Codemagic startete als Flutter-Builder und dokumentiert nun Ionic- und Capacitor YAML-Workflows, inklusive Managed Android Keystores, App Store Connect API Keys sowie Publishing zu TestFlight und Play. Signing ist eine Stärke.

Es hat dieselbe Lücke wie Bitrise: keine Managed Live Updates. Du müsstest OTA-Bundles weiterhin woanders hochladen. Wenn die einzige Lücke in deinem GitHub Actions Setup darin besteht, dass du „kein Fastlane auf einem Mac warten willst“, kann Codemagic diese Lücke schließen. Capgo schließt diese Lücke und die OTA- und Preview-Lücken in einem CLI. Codemagic-Walkthroughs auf dieser Seite: iOS mit Codemagic.

Ionic Appflow

Appflow ist das All-in-One-Produkt von Ionic: Native Builds, Signing, Live Updates und Store-Publishing. Es ist außerdem ein CI-Ersatz, kein Plugin für GitHub Actions. Ionic hat am 11. Februar 2025 das Ende des kommerziellen Angebots angekündigt. Bestandskunden behalten den Zugriff bis zum 31. Dezember 2027.

Wenn du bereits Appflow nutzt, plane den Ausstieg jetzt statt erst Ende 2027. Der 1:1-Umstieg ist Capgo für Live Updates und Native Builds, während du GitHub Actions für die PR-Automatisierung behältst (oder dorthin zurückkehrst). Migration: von Appflow zu Capgo.

Microsoft App Center

Keine Option für 2026. Builds und Distribution endeten am 31. März 2025. CodePush als gehosteter Service gibt es nicht mehr. Teams, die die Migration nie abgeschlossen haben, suchen noch immer danach. Der Capacitor-Weg ist Capgo für OTA plus Capgo Build oder deine CI für Binaries. Starte mit App Center Migration und CodePush-Alternativen.

Xcode Cloud

Apples CI ist in Ordnung für reine iOS-Native-Apps, die schon in App Store Connect sind. Es baut kein Android, liefert keine Capacitor Live Updates und bietet keine PR-Channels für Web-Bundle-QA. Betrachte es als Apple-seitiges Extra, nicht als Capacitor-Plattform.

Wie Capgo in deine Pipeline passt

Das beste Setup für 2026 sieht so aus:

1. Bei jedem Pull Request, installieren GitHub Actions oder GitLab CI die Abhängigkeiten, führen Tests aus und bauen die Web-App unter Linux.
2. Wenn die Änderung nur die Web-App betrifft, lädt Capgo ein Bundle in einen PR-Channel hoch. Reviewer öffnen die bestehende App, wechseln den Channel und testen. Kein Warten auf TestFlight. Siehe Mache jeden Pull Request zu einer installierbaren Preview.
3. Wenn sich nativer code, Plugins oder Berechtigungen geändert haben, fordert derselbe Workflow einen Capgo Native Build an und teilt einen QR-Code zum Installieren.
4. Auf dem Main-Branch oder einem Version-Tag, liefert Capgo ein Produktions-live update oder eine signierte Binary an TestFlight und Play aus, je nachdem, was sich tatsächlich geändert hat.

Ein kompakter GitHub Actions-Entwurf:

name: Capacitor CI
on:
  pull_request:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  web:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Upload live update
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: npx @capgo/cli@latest bundle upload --channel production
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
      - name: Native build on tag-style releases
        if: startsWith(github.ref, 'refs/tags/v')
        run: npx @capgo/cli@latest build request com.example.app --platform ios --build-mode release
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
          CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }}
          APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }}
          APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }}
          APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }}
          APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }}

Der Entwurf gilt nur für iOS. Android benötigt ANDROID_KEYSTORE_FILE, KEYSTORE_KEY_ALIAS, KEYSTORE_KEY_PASSWORD, KEYSTORE_STORE_PASSWORD, und PLAY_CONFIG_JSON. Kopiere nicht den iOS- env Block, sondern ändere nur --platform. Nutze die Matrix im GitHub Actions Build-Guide. Signing-Secrets bleiben in GitHub und werden als Umgebungsvariablen beim Build-Request übergeben. Capgo muss nicht deine Git-Source-of-Truth sein. Vollständige Beispiele findest du in den Builder GitHub Actions Docs und CI/CD-Integration.

Das richtige Setup wählen

Es gibt keinen universellen Gewinner. Diese Szenarien decken die meisten Capacitor Teams ab.

Du nutzt bereits GitHub Actions oder GitLab CI. Behalte sie. Füge Capgo für Live Updates, Native Builds und PR-Previews hinzu. Das ist die Standard-Antwort für 2026.

Du nutzt Capawesome Cloud. Man will die Git-Anbindung, den YAML-Ersatz und die Release-Metadaten. Das ist praktisch, bis man wechseln möchte. Capgo behält dein CI, ist komplett Open Source und hat den Einstiegspreis von 12 $ nicht erhöht. Siehe Capgo vs. Capawesome Cloud.

Du bist noch bei Appflow. Du hast bis zum 31. Dezember 2027 Zeit. Abwarten führt zu einem Migrationsstau. Verlagere Live Updates und Native Builds zu Capgo und nutze GitHub Actions für die PR-Automatisierung, falls Appflow auch dein CI war.

Du wechselst von App Center weg. Die Build-Pipeline ist weg und CodePush ist kein Hosted-Produkt. Ersetze beides durch Capgo, anstatt OTA mühsam auf GitHub Actions neu aufzubauen.

macOS-Minuten treiben die GitHub Rechnung in die Höhe. Lass Linting und Unit-Tests auf GitHub. Verlagere Native Builds zu Capgo, damit iOS nicht mehr auf gehosteten Macs in Actions läuft. Behalte die PR-Status-Checks dort, wo sie sind.

Du startest 2026 eine Capacitor App. Überspringe Appflow und App Center. Starte mit GitHub Actions für dein CI. Füge Capgo ab Tag eins für OTA, Cloud Builds und Device Previews hinzu. Bitrise oder Codemagic kannst du später ergänzen, falls du spezielle Runner oder Step-Libraries brauchst. Die meisten Teams benötigen diese zusätzliche Plattform nie. Nutze Capawesome Cloud nur, wenn dir deren Plugin-Katalog wichtig genug ist, um ein anderes CI in Kauf zu nehmen.

FAQ

Was ist die beste CI/CD-Plattform für Capacitor Apps?

Nutze deine bestehende CI für Linting, Unit-Tests und Web-Builds. Ergänze sie durch Capgo für signierte native iOS- und Android-Builds, Live Updates und installierbare Device-Tests. Bitrise und Codemagic können Native Builds ersetzen, falls du keine Live Updates benötigst. Capawesome Cloud deckt OTA und Native Builds ab, fungiert aber als Ersatz-CI mit geschlossenem Backend. Appflow steht Bestandskunden bis zum 31. Dezember 2027 zur Verfügung, ist aber keine Option für neue Projekte.

Sollte ich GitHub Actions durch eine Mobile-CI-Plattform ersetzen?

Meistens nein. GitHub Actions und GitLab CI sind stark bei Pull-Request-Checks auf Linux. Der teure Teil sind macOS Native Builds, Signing, Live Updates und das Deployment auf ein Smartphone. Capgo ist darauf ausgelegt, in die bestehende Pipeline integriert zu werden, statt sie zu ersetzen.

Bieten Bitrise und Codemagic Live Updates für Capacitor an?

Nein. Beide sind stark bei Native Builds, Signing und Store-Publishing. Du benötigst weiterhin ein separates Live-Update-Produkt, um JavaScript, CSS und HTML ohne Store-Review auszuliefern. Capgo deckt Native Builds und Live Updates im selben Workflow ab.

Wie testet Capgo eine Mobile App aus der CI heraus?

Capgo verwandelt Pull Requests in installierbare Previews auf dedizierten Channels, teilt Native Build-Artefakte als QR-Code-Links und erlaubt es der QA, Channels direkt in der App auf dem Device zu wechseln. Das ist schneller als auf TestFlight zu warten. Es ist kein Ersatz für Device-Farms zur Emulator-Matrix-Prüfung.

Ist Ionic Appflow 2026 noch eine sinnvolle Wahl?

Nur, wenn du bereits Kunde bist. Ionic hat am 11. Februar 2025 den Verkauf neuer kommerzieller Lizenzen eingestellt, bestehende Appflow-Zugänge laufen bis zum 31. Dezember 2027 weiter. Neue Capacitor-Projekte sollten ihr CI behalten und Capgo ergänzen, statt auf einer Plattform mit Abschaltdatum zu starten.

Wie schneidet Capawesome Cloud CI im Vergleich zu Capgo ab?

Capawesome Cloud ist eine All-in-One Capacitor CI: Git verbinden, GitHub Actions verlassen und Native Builds plus Live Updates in deren Cloud ausführen. Das ist Vendor Lock-in. Capgo ist Open Source (Plugin und Backend), lässt sich in dein bestehendes CI einhängen und hat seit dem Launch denselben bezahlten Einstiegspreis von 12 $/Monat. Capawesome hat die Preise schon mehrfach umgebaut, unter anderem Native Builds ab 9 $/Monat beim Launch und ein Platform SKU ab 19 $/Monat im Mai 2026, während Business von 299 $ auf 499 $/Monat stieg.

Fazit

Die Capacitor-Shortlist für 2026 ist kleiner, als sie aussieht: zwei eingestellte oder auslaufende All-in-One-Plattformen, zwei Mobile-CI-Generalisten ohne OTA, eine Git-verbundene Capacitor CI, die deine Pipeline ersetzt, und ein General-Purpose-Runner, den du bereits hast. Das Team, das am schnellsten liefert, ist nicht das Team, das sein CI bei einem neuen Anbieter neu aufsetzt. Es ist das Team, das GitHub Actions oder GitLab CI behält und eine Capacitor-Schicht für die Jobs ergänzt, die das CI noch schlecht macht.

Diese Schicht ist Capgo: Native Builds, Live-Updates, und Device-Testing, ausgelöst durch deine bestehende Pipeline. Open Source. Faire Preise ohne Erhöhungen. Kein geschlossenes CI-Ersatzprodukt.

Erstelle ein Capgo Konto, folge dann CI/CD-Integration oder Capgo Build über GitHub Actions. Wenn du zuerst die Produktansicht sehen willst, starte mit Native Builds, Capgo Live Updates, und PR-Previews.