Zum Hauptinhalt springen
Produktions-Updates

Alle Nutzer auf den neuesten Fix bringen

Lade ein neues Web-Bundle über CLI oder CI hoch. Geräte laden es im Hintergrund herunter und führen es aus, sobald die App das nächste Mal in den Vordergrund kommt. Roll es prozentual aus, beobachte es in Observe und mach bei Problemen einen Rollback.

Keine Kreditkarte erforderlich
Automatischer Rollback integriert
Nur Web-Layer-Updates

Das Problem

Ein Store-Release ist ein zu langsamer Weg für kleine Fixes

Der Store-only-Weg für Fixes

1

Bug finden

Monitoring oder Support meldet einen Fehler. Der Fix besteht nur aus wenigen Zeilen JavaScript oder CSS.

2

Neues Binary bauen

Version erhöhen, Build für iOS und Android erstellen und zwei Store-Submissions vorbereiten.

3

Auf Review warten

Der Store-Review dauert oft 24–48 Stunden, manchmal viel länger. Eine Ablehnung lässt dich von vorn beginnen.

4

Warten auf User-Updates

Nach der Freigabe muss jeder User die neue Version erst installieren. Bis dahin nutzen sie die alte code.

Jeder Schritt verzögert den Zeitraum zwischen dem fertigen Fix und dem Einsatz auf den Geräten deiner User.

Warum Store-Fixes User nur langsam erreichen

24–48h+

Typische Review-Zeit im Store

Apple und Google prüfen jede neue Binary. Die Review dauert oft 24–48 Stunden, manchmal deutlich länger, und eine Ablehnung bedeutet ein erneutes Einreichen.

Pro Nutzer

Store-Updates hängen vom Gerät ab

Ein Store-Update erreicht ein Gerät erst, wenn der Nutzer oder die Auto-Update-Einstellung es installiert. Manche Geräte bleiben lange auf alten Builds.

2 Stores

Zwei Submissions pro Fix

Derselbe Web-Fix muss separat durch den App Store und Google Play, jeweils mit eigenem Review und Release.

Die Lösung

Wie ein live update deine Nutzer erreicht

Das ist das Standard-Update-Verhalten von Capgo. Keine Update-Prompts, keine erzwungenen Restarts und keine Store-Submission für Änderungen am Web-Layer.

Standard-Update-Flow

  1. Die App prüft auf Updates

    Sobald die App in den Vordergrund tritt und alle 10 Minuten während der Nutzung, fragt der Updater Capgo nach dem neuesten Bundle des Channels.

    Beim Vordergrund

  2. Download im Hintergrund

    Das neue Bundle wird geladen, während der User die aktuelle Version weiter nutzt. Dank Delta-Updates werden nur geänderte Dateien heruntergeladen.

    Keine Unterbrechung

  3. Wechsel beim nächsten Resume

    Wenn der User die App verlässt, installiert der Updater das Bundle. Beim nächsten Start wird direkt die neue Version ausgeführt.

    Nächster Vordergrund

Sollen User die neue Version sofort beim Start sehen? Direct Update Modes wenden diese während des Splash Screens an.

Direct Updates ansehen

Doku zum Update-Verhalten

So funktioniert es

So bringen Production-Teams Fixes mit Capgo raus

Ein typisches Release für eine Capacitor App, die bereits in den Stores ist. Alle Befehle stammen aus der Capgo CLI Doku.

  1. Updater einmalig einrichten

    Starte den Setup-Wizard und stelle sicher, dass deine App nach dem Start notifyAppReady() aufruft. Ein Bundle, das diesen Aufruf nie ausführt, rollt sich automatisch zurück.

    npx @capgo/cli@latest init
    # in your app start-up code
    await CapacitorUpdater.notifyAppReady()
    notifyAppReady()-Docs
  2. Fix in einen Production-Slice hochladen

    Nutze --delta, damit Geräte nur geänderte Dateien laden, und --rollout, um mit einem kleinen Teil der Geräte zu starten. Alle anderen bleiben auf dem stabilen Bundle.

    npx @capgo/cli@latest bundle upload --channel production --delta --rollout 5
    Docs zu Progressive Rollouts
  3. Lass Capgo schlechte Rollouts stoppen

    Aktiviere Auto-Pause mit einem Schwellenwert für die Failure-Rate (500 Basispunkte entsprechen 5 %). Wenn die Fehler diesen Wert überschreiten, rollt Capgo das Rollout zurück. Überprüfe die neue Version während des Laufs in Observe.

    npx @capgo/cli@latest channel set production \
      --auto-pause-enabled \
      --auto-pause-failure-rate-bps 500 \
      --auto-pause-action rollback
    Observe-Doku
  4. Für alle freigeben

    Wenn die Zahlen stimmen, rolle das Bundle für alle Geräte im Channel aus. Falls nicht, setze die Rollout-Kohorte zurück auf stable.

    npx @capgo/cli@latest channel set production --rollout-promote
    # or, if something looks wrong
    npx @capgo/cli@latest channel set production --rollout-rollback
    Rollback-Docs

Optimiert für Production-Releases

Die volle Kontrolle für Teams, um häufig zu releasen, ohne User zu überraschen.

Delta-Updates

Mit --delta wird hochgeladen und Geräte laden nur die Dateien herunter, die sich seit dem aktuellen Bundle geändert haben. Große Assets werden nur einmal geladen.

  • Kleinere Downloads für User in langsamen oder begrenzten Netzen
  • Im Standardmodus werden Updates zwischen den Sessions angewendet, nicht mitten drin
Delta-Updates-Doku

--delta

Nur geänderte Dateien werden geladen

Progressive Rollouts mit Auto-Pause

Sende ein neues Bundle an einen zufälligen, festen Anteil eines Channels, während alle anderen auf dem stabilen Bundle bleiben. Erhöhe den Prozentsatz, promote ihn oder mache einen Rollback über das CLI oder die Console.

  • Auto-Pause kann einen Rollout pausieren oder zurückrollen, sobald die Fehlerquote deinen Schwellenwert überschreitet
  • Observe vergleicht die neue Version mit der vorherigen, bevor du die Exposure erhöhst
Docs zu Progressive Rollouts

1–5%

Ein typischer erster Rollout-Schritt

Automatischer Rollback

Jedes Update muss beweisen, dass es startet. Wenn ein neues Bundle notifyAppReady() nicht rechtzeitig aufruft, wechselt das Gerät zum letzten funktionierenden Bundle und markiert das neue als fehlgeschlagen.

  • Rollback wird ausgelöst, wenn notifyAppReady() nicht innerhalb des appReadyTimeout (standardmäßig 10 Sekunden) aufgerufen wird
  • Roll einen gesamten Channel über seine Historie auf jedes beliebige frühere Bundle zurück
notifyAppReady()-Docs

10s

Standardmäßiges appReadyTimeout vor dem automatischen Rollback

Store-Review-konforme Auslieferung

Capgo liefert den Capacitor Web-Layer: JavaScript, CSS und Assets. Das native Binary, Plugins, Berechtigungen, Entitlements und App-Store-Metadaten werden dabei nicht verändert. Da die Store-Review app-spezifisch ist, bleibst du für die Einhaltung der Richtlinien und die Freigabe verantwortlich.

  • Nutze ein natives Store-Release, wenn sich native Funktionen, Plugins, Berechtigungen oder App-Store-Metadaten ändern
  • Mach in den Reviewer-Notizen klar, wofür die App gedacht ist und wie der Web-Layer-Update-Pfad aussieht.
  • Prüfe vor jeder Einreichung die aktuellen Apple- und Google-Richtlinien.

Was Production-Teams damit machen

Tägliche Release-Arbeit, sobald Live Updates eingerichtet sind. Jede Karte führt zur Doku.

Kritische Bugfixes

Ein defekter Checkout- oder Login-Screen bekommt einen Web-Layer-Fix. Lade ihn hoch, und die Geräte holen es sich beim nächsten Update-Check.

Doku zum Update-Verhalten

Copy- und Inhaltsänderungen

Texte anpassen, Hilfe-Texte aktualisieren oder Bilder und andere Bundled Assets austauschen, ohne eine neue Binary zu bauen.

Doku zur nativen Kompatibilität

Release-Health in Observe

Vergleiche neue Bundles mit vorherigen: Fehlerquote, Launch- und WebView-Timing sowie Deployment-Marker pro Version.

Observe-Doku

Schnellerer Rollout durch Update-Notifications

Nachdem du das Bundle eines Channels geändert hast, sende eine Silent Update Notification, damit Geräte sofort prüfen statt erst beim nächsten Foreground.

Update-Benachrichtigung senden

Ältere Native Builds schützen

Blockiere Major Updates auf einem Channel, damit ein Bundle, das neue native code benötigt, niemals ein altes Binary erreicht.

Docs zu Version Targeting

Rollback über die Channel-Historie

Wähle einfach ein früheres Bundle im History-Tab des Channels aus, um es sofort wieder für alle Geräte auf diesem Channel live zu schalten.

Rollback-Docs

Infrastruktur, die bereits produktive Apps bedient

Capgo liefert seit 2021 Live Updates für produktive Apps aus.

Updates pro Monat
1 Mrd.+
Erreichte Geräte
90 Mio.+
Apps mit Capgo
4,7k+
Typische API Latenz
~50 ms

Mit Capacitor gebaute Apps

High-Traffic-Apps brauchen zuverlässige UI-Changes in Production

Apps für Wetter, Gesundheit oder Telekommunikation sind auf präzise Interfaces, Alerts und Navigation angewiesen. Production Updates ermöglichen das Ausrollen geprüfter Interface-Fixes, während die Adoption überwacht wird, bevor ein voller Rollout erfolgt.

Windy.com - Wettervorhersage App-Icon WETTER

Windy.com – Wettervorhersage

Wetter-App, bei der Karten, Warnungen und Navigations-Fixes präzise Production-Updates erfordern.

Google Play-Installationen
32,9 Mio.
Store-Bewertung
4.7
Conecte SUS App-Icon MEDIZIN

Conecte SUS

Public-Health-App, bei der Richtlinien und Service-Infos schnelle, vertrauenswürdige Updates benötigen.

Google Play-Installationen
27,7 Mio.
Store-Bewertung
4.6
App-Icon von Mi Orange TOOLS

Meine Orange

Telecom-Account-App, bei der sich Alerts und Account-Oberflächen häufig ändern.

Google Play-Installationen
9,3 Mio.
Store-Bewertung
4.2

Kundenstimmen

Das sagen Teams, die mit Capgo deployen

5.0/5 von Entwicklerteams bewertet 9,400+ Teams Bewertungen lesen
Porträt von Sergiu S

Sergiu S

Lead Developer, drivolino GmbH

„Das Capgo Capacitor Updater-Plugin hat komplett verändert, wie wir Updates ausliefern. Was früher Tage dauerte, dauert jetzt nur noch Minuten.“

Kapil

Gründer, NuTriQ

“Die Möglichkeit, produktive OTA-Updates sofort zu pushen, ohne auf die kompletten Review-Zyklen des App Store warten zu müssen, war ein enormer operativer Vorteil.”

Porträt von Michael Haberler

Michael Haberler

nethead emeritors

„Tolle Arbeit am Updater-Plugin. Bei mir läuft es einwandfrei, und Live Updates sind ein echter Beschleuniger für schnelle Testzyklen.“

FAQ

Fragen von Production-Teams

Wie Updates auf Devices landen und was bei Fehlern zu tun ist.

Wann erhalten Nutzer live update?

Standardmäßig prüft die App auf Updates, wenn sie in den Vordergrund kommt, und alle 10 Minuten, während sie offen bleibt. Das neue Bundle wird im Hintergrund heruntergeladen, installiert, sobald der Nutzer die App verlässt, und beim nächsten Start ausgeführt. Die autoUpdate-Einstellung ändert dieses Verhalten.

Doku zum Update-Verhalten

Können Devices einen dringenden Fix schneller erhalten?

Ja. Nachdem du das Bundle eines Channels geändert hast, sende eine Update-Benachrichtigung über die Konsole oder füge --send-update-notification beim bundle upload hinzu. Devices erhalten einen Silent Push und prüfen sofort. Das erfordert Capgo Notifications mit iOS- und Android-Push-Credentials. Die Zustellung ist Best Effort: Eine App, die offline ist oder beendet wurde, prüft beim nächsten Start.

Update-Benachrichtigung senden

Was passiert, wenn ein Update die App kaputt macht?

Wenn ein neues Bundle notifyAppReady() nicht innerhalb von 10 Sekunden aufruft (der Standard-appReadyTimeout), kehrt das Device zum letzten funktionierenden Bundle zurück und markiert das neue als fehlgeschlagen. Bei Bugs, die den App-Start nicht verhindern, kannst du den Progressive Rollout zurückrollen oder ein früheres Bundle aus der Channel-Historie wählen.

Rollback-Docs

Wie können wir zuerst nur an wenige Nutzer releasen?

Nutze den Upload mit --rollout, um das Bundle an einen zufälligen, festen Anteil des Channels zu senden, während der Rest auf der stabilen Version bleibt. Erhöhe den Prozentsatz, promote oder mache einen Rollback über CLI oder die Console. Auto-pause stoppt die Ausrollung automatisch, wenn die Fehlerquote einen Schwellenwert überschreitet.

Docs zu Progressive Rollouts

Was kann ein live update nicht ändern?

Live Updates ersetzen den Web-Layer: JavaScript, HTML, CSS und Assets. Native Plugins, Capacitor Upgrades, capacitor.config Änderungen sowie iOS- oder Android-Projektdateien erfordern ein Store-Release. Capgo prüft Bundles beim Upload auf native Kompatibilität, und Channels können Updates für ältere Binaries blockieren.

Doku zur nativen Kompatibilität

Veröffentliche deinen nächsten Fix als live update

Teste den kompletten Workflow mit deiner eigenen App im Trial: lade ein Bundle hoch, rolle es auf einige Geräte aus und mache einen Rollback.