Zum Hauptinhalt springen

Version-Targeting

Jeder nativen Version nur die Bundles senden, die sie ausführen kann

Nutzer aktualisieren über den Store in ihrem eigenen Tempo, sodass mehrere native Versionen Ihrer App gleichzeitig live sind. Capgo prüft die nativen Abhängigkeiten jedes Bundles, blockiert Updates anhand von Versionsregeln und kann jede native Version zu ihrem eigenen Channel routen.

Native Kompatibilität vor dem Upload prüfen

Die Bundle-Kompatibilität vergleicht die nativen Packages in deinem Projekt mit dem Live-Bundle im Channel. Nutze --fail-on-incompatible in der CI, um einen Upload zu stoppen, der ein neues Binary benötigt.

Doku zur nativen Kompatibilität

Native Mindestversion für jedes Bundle festlegen

Stelle den Channel auf die Metadata-Strategie und lade mit --auto-min-update-version hoch. Geräte, deren native Version unter der Mindestversion des Bundles liegt, überspringen das Update und behalten ihr aktuelles Bundle.

Version-Targeting-Docs

Updates über Semver-Grenzen hinweg blockieren

--disable-auto-update major, minor oder patch verhindert, dass ein Gerät ein Bundle außerhalb seiner nativen Versionslinie erhält. Diese Regeln vergleichen nur Versionsnummern. Sie prüfen nicht die native code.

Update-Typen und Versions-Blocking

Ein Channel pro native Version

Setze defaultChannel in der Capacitor-Config jedes Native Builds, z. B. v2 oder v3. Jede Versionslinie bekommt ihre eigenen Bundles, und eine ältere Versionslinie kann auf ihrem letzten funktionierenden Bundle bleiben.

Version-Targeting-Docs

So funktioniert es

So shippen Teams mit mehreren Native-Versionen mit Capgo

Ein CI-Setup, bei dem die live update-Lane und die Store-Lane parallel laufen. Alle untenstehenden Commands stammen aus der Capgo CLI-Doku.

  1. Prüfen, ob der Commit einen Native Build braucht

    build needed vergleicht deine native Packages mit dem Channel. Es gibt yes aus und endet mit code 1, wenn ein Store-Release nötig ist, und mit no, wenn ein live update ausreicht.

    npx @capgo/cli@latest build needed com.example.app --channel production
    build needed Referenz

  2. Channel auf Metadata-Strategie umstellen

    Einmal einrichten. Von nun an enthält jedes Bundle eine minimale Native Build-Version, sodass Geräte mit älteren Versionen das Bundle einfach überspringen.

    npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update metadata
    Version-Targeting-Docs

  3. Tägliche Live Updates hochladen

    Lass --auto-min-update-version bei jedem Upload gesetzt. --fail-on-incompatible bricht den Job ab, wenn das Bundle native code braucht, die der Channel nicht hat.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version \
  --fail-on-incompatible
    Doku zur nativen Kompatibilität

  4. Bundle für ein neues natives Release hochladen

    Sobald die neue Binary ausgeliefert wird, lade ihr Bundle ohne --fail-on-incompatible hoch. Capgo setzt die Untergrenze höher, sodass ältere Builds es überspringen, und spätere Checks vergleichen gegen die neuen nativen Packages.

    npx @capgo/cli@latest bundle upload --channel production \
  --auto-min-update-version
    Native- und OTA-Channel-Workflow

Appflow-Migration

Kommst du von Ionic Appflow?

Appflow hat Live Updates für dich den nativen Versionen zugeordnet. In Capgo bekommst du dasselbe Ergebnis mit Channels und Version-Regeln:

  1. Erstelle für jede native Version einen Channel, z. B. v1 und v2.
  2. Setze defaultChannel in der Capacitor-Config jedes Native Build auf den passenden Channel.
  3. Lade jedes Bundle in den Channel der nativen Version hoch, für die es gebaut wurde.
  4. Lass --auto-min-update-version bei Uploads aktiv, damit ein Bundle, das ein neueres natives code braucht, ältere Builds überspringt.
Appflow-Migration-Guide
Channel pro native Version 
// capacitor.config.ts in your 2.x native builds
plugins: {
  CapacitorUpdater: {
    defaultChannel: 'v2',
  },
},

# ship a fix to 2.x users only
npx @capgo/cli@latest bundle upload --channel v2 \
  --auto-min-update-version

# 1.x devices stay on their channel's current bundle

Typische Szenarien

Ein neues natives Plugin

Dein 2.0-Binary fügt ein Kamera-Plugin hinzu. Lade das Bundle, das es verwendet, mit --auto-min-update-version hoch; 1.x-Geräte überspringen es, bis Nutzer 2.0 installieren.

Doku zur nativen Kompatibilität

Schrittweise Einführung

Sende ein Bundle mit --rollout an einen Teil eines Channels, beobachte Installations- und Fehlerdaten und promote es oder mach einen Rollback.

Docs zu Progressive Rollouts

Eine alte Version einstellen

Hör auf, in den v1-Channel hochzuladen. Geräte darauf behalten ihr letztes funktionierendes Bundle, während v2 weiterhin Updates erhält.

Version-Targeting-Docs

Jede native Versionslinie verweist auf ihren eigenen Channel

Ein Beispiel-Layout mit drei nativen Versionen im Einsatz.

  • Native 3.x
    v3
    Neue Bundles
  • Native 2.x
    v2
    Nur Fixes
  • Native 1.x
    v1
    Keine neuen Bundles

Features für v3, Fixes für v2 und nichts für v1. Geräte auf v1 behalten ihr letztes funktionierendes Bundle.

Mit Capacitor gebaute Apps

Public Apps müssen alte und neue Native-Versionen unterstützen

Apps für Behörden, Gesundheit oder Wetterberichte müssen oft ältere Android-Versionen und verschiedene Gerätegenerationen unterstützen. Mit Version Targeting bleibt jeder Native Build auf dem neuesten kompatiblen Web Bundle, ohne dass alle Nutzer denselben Update-Pfad nutzen müssen.

e-Título-App-Icon SOZIAL

e-Título

Civic-Identity-App mit Anforderungen an breite Gerätekompatibilität.

Google Play-Installationen
54,9 Mio.
Store-Bewertung
4.8
Conecte SUS App-Icon MEDIZIN

SUS verbinden

Health-App, bei der ältere und neuere native Shells unterschiedliche Web-Bundles brauchen könnten.

Google Play-Installationen
27,7 Mio.
Store-Bewertung
4.6
Windy.com – Wettervorhersage-App-Icon WETTER

Windy.com – Wettervorhersage

Wetter-App, bei der Gerätefähigkeiten und Kartenperformance je nach Version variieren können.

Google Play-Installationen
32,9 Mio.
Store-Bewertung
4.7

Kundenstimmen

Das sagen Teams, die mit Capgo deployen

5.0/5 von Entwicklerteams bewertet 9,400+ Teams Bewertungen lesen

no-tone @ Webincode

Entwickler, Webincode

„Geräte-IDs zu bestimmten Gruppen hinzuzufügen und Änderungen nur an diese Gruppen zu pushen, ist ein echter Gamechanger.“

Nate van Jole

CTO, Privat

„Das Setup war in weniger als einem Tag erledigt. Mit Channel-basierten Rollouts kann ich erst auf meinem eigenen Gerät testen, bevor etwas bei den Production-Usern ankommt.“

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.“

FAQ

Fragen zu Versionen im Live-Betrieb

Für Teams, deren Nutzer die Store-App zu unterschiedlichen Zeitpunkten aktualisieren.

Was passiert mit Nutzern, die die native App nie aktualisieren?

Sie bekommen weiterhin Bundles, die mit ihrer nativen Version kompatibel sind. Mit der Metadata-Strategie wird ein Bundle, dessen minimale native Version über ihrer liegt, übersprungen – sie bleiben auf ihrem aktuellen Bundle.

Version-Targeting-Docs

Reicht --disable-auto-update als Major-Änderung aus, um Abstürze zu verhindern?

Nein. Version-Rules vergleichen nur Versionsnummern; eine native Änderung in einem Minor- oder Patch-Release wird also trotzdem ausgeliefert. Nutze --fail-on-incompatible oder --auto-min-update-version, die deine nativen Packages prüfen.

Doku zur nativen Kompatibilität

Woher weiß die CI, ob eine Änderung ein Store-Release braucht?

Führe build needed oder bundle releaseType gegen den Channel aus. Beide vergleichen die Metadata der nativen Packages. Da sie nicht jede Änderung unter ios/, android/ oder capacitor.config sehen, solltest du diese Pfade auch in Git absichern.

OTA oder Native Build in der CI wählen

Wir wechseln von Ionic Appflow. Können wir versionsspezifische Updates beibehalten?

Ja. Nutze pro Native-Version einen eigenen Channel mit defaultChannel oder die Metadata-Strategie mit --auto-min-update-version. Der Appflow-Migration-Guide führt dich durch das Setup.

Appflow-Migration-Guide

Was, wenn bereits ein inkompatibles Bundle veröffentlicht wurde?

Setze den Channel in der History auf das letzte kompatible Bundle zurück oder erzwinge das integrierte Bundle und liefere den Native Build aus. notifyAppReady() rollt ein Bundle, das nicht startet, zurück, ist aber kein Ersatz für kompatible native code.

Rollback-Docs

Stelle sicher, dass jedes native Bundle die passende Version nutzt

Richte die Metadata-Strategie und einen Compatibility-Check in deiner CI während der 14-tägigen Testphase ein. Keine Kreditkarte nötig.