Kanäle

Wenn Sie das __CAPGO_KEEP_0__ Live-Updates __CAPGO_KEEP_1__ install the Capgo Live Updates SDK A Live Update channel points to a specific JS bundle build of your app that will be shared with any devices configured to listen to that channel for updates.

Kanäle bieten keine Vertraulichkeit

Kanäle steuern die Aktualisierungsberechtigung und nicht die Vertraulichkeit der Pakete. Selbst wenn ein Kanal privat ist oder die Selbstzuweisung deaktiviert ist, sollte ein unverschlüsselter Paketupload an Capgo immer noch als öffentliches Asset behandelt werden, das an die Clients geliefert wird. Die Verschlüsselung schützt den Transportweg und die Authentizität der Updates, aber die gelieferten Pakete können immer noch mit genügend Anstrengung von der verteilt Anwendung rückgekoppelt werden, weil der öffentliche Schlüssel Teil der Client ist. Siehe Live-Update-Verschlüsselung für Details.

Wie ein Gerät einen Kanal auswählt (Priorität)

Wenn ein Gerät nach einer Aktualisierung sucht, entscheidet Capgo in dieser strengen Reihenfolge (höchste Priorität zuerst), welchen Kanal zu verwenden ist:

1. Zwingende Gerätemap (Dashboard) – Pinnen Sie einen bestimmten Geräte-ID an einen Kanal. Verwenden Sie dies für dringende Debugging oder kontrollierte Tests mit einem einzelnen echten Benutzer. Dies gewinnt immer.
2. Cloud-Übernahme (per-Gerät) über Dashboard oder API – Erstellt, wenn Sie den Gerätekanal im Dashboard oder über API ändern. Verwenden Sie dies für QA-Benutzer, die zwischen Feature/PR-Kanälen wechseln oder um ein Benutzerproblem nachzubilden. Eine erneute Installation des Binärs löscht es nicht; die Löschung der Geräte-Einträge tut es.

Schnelles Kanalwechsel mit setChannel()

Ab der Pluginversion 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 abhängig von Ihrer Hauptversion, setChannel() funktioniert es anders: Es kontaktiert den Backend-Server, um zu überprüfen, ob der Kanal zulässig ist (Überprüfung, ob Selbstzuweisung für diesen Kanal aktiviert ist), dann speichert es den Kanal lokal auf dem Gerät als defaultChannelDies bedeutet, dass der neue Kanal sofort wirksam wird für die nächste Aktualisierung überprüfung—keine Wartezeit.

Zuvor wurde der Kanal-Übertrag an das Backend-Datenbank (wie Dashboard oder __CAPGO_KEEP_0__ Änderungen) gespeichert und die Geräte mussten auf Daten-Replikation (bis zu 2 Minuten) warten, bevor der neue Kanal erkannt wurde. setChannel() saved the channel override to the backend database (like Dashboard or API changes), and devices had to wait for data replication (up to 2 minutes) before the new channel was recognized. The new behavior only reads from the backend (for validation) and stores locally, making channel switches instant.

Hinweis: Even wenn ein Kanal nach der lokalen Einstellung verboten wird, wird das Backend den Kanal während der Update-Überprüfungen noch immer validieren, sodass die Sicherheit aufrechterhalten wird.

Wichtig: Wenn Kanal-Änderungen über das Dashboard oder API vorgenommen werden, besteht immer noch ein Replikations-Lag von bis zu 2 Minuten, bevor alle Edge-Server die Änderung widerspiegeln. Für einen sofortigen Kanal-Wechsel verwenden Sie setChannel() aus Ihrer App code—es validiert mit dem Backend und setzt den Kanal lokal für sofortigen Effekt.

3. Kanal-Konfiguration Capacitor (Test-Build-Standard) – Wenn vorhanden in defaultChannel und keine Zwangs-/Übertragung existiert, startet die App auf diesem Kanal (z.B. Zurückgelassen für TestFlight/interne Builds, damit Tester automatisch auf einem Vorkabel-Kanal landen. Produktion Builds lassen dies normalerweise ungesetzt. capacitor.config.* Kanal-Wechsel sind sofort möglich, wenn Sie beta, qa, pr-123aus Ihrer App __CAPGO_KEEP_0__—es validiert mit dem Backend und setzt den Kanal lokal für sofortigen Effekt.
4. Cloud Standardkanal (Hauptpfad ~99% der Benutzer) – Wenn Sie in der Dashboard ein Standardkanal markieren, werden alle normalen Endnutzer (kein Zwang, keine Übernahme, keine Konfiguration von defaultChannel) hier angewiesen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binärdatei. Wenn Sie plattform-spezifische Standards haben (z.B. ein iOS nur, ein Android nur, ein Electron nur), landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Das Ignorieren des Cloud-Standards ist erlaubt; in diesem Fall muss das Gerät auf Schritte 1–3 abgestimmt sein, um Updates zu erhalten.

Empfehlung:

• Behandeln Sie 1–3 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten sich echte Benutzer in ihn einfließen. Wenn Sie ihn nicht setzen, sollten Sie sich bewusst sein, wie Benutzer sich anbinden (typischerweise via defaultChannel Konfiguration oder per-Geräte-Übernahmen).
• Konfigurieren Sie defaultChannel nur in Binärdateien, die Sie explizit an Tester verschicken. Das Ignorieren des Cloud-Standards hält die Produktionslogik zentral im Dashboard.
• Verwenden Sie setChannel() sparlich in der Produktion – hauptsächlich für QA oder gezielte Diagnosen.

Wenn ein Kanal für die Plattform (iOS/Android/Electron-Schalter) deaktiviert ist, wenn er sonst ausgewählt worden wäre, springt der Auswahlprozess darüber hinweg und geht weiter mit der Liste.

Zusammenfassung: Zwang > Übernahme > Konfiguration defaultChannel > Cloud-Standard.

Standardkanalverhalten

Ein Cloud-Standard setzen ist optional, aber es dient normalerweise als Default-Pfad für neue Geräte. Ohne einen solchen, werden nur Geräte berücksichtigt, die auf zwingenden Zuweisungen, Überschreibungen oder einem defaultChannel in der Capacitor-Konfiguration erhalten Sie Updates. Wenn Sie sich entscheiden, Standards zu markieren, beachten Sie diese Muster:

• Einzelstandard (am häufigsten) – Wenn ein Kanal iOS, Android und Electron aktiviert hat, wird er zum einzigen Standard; jedes Gerät ohne Überschreibungen wird hier hinzugefügt.
• Plattform-spezifische Standards – Wenn Sie die Kanäle nach Plattform aufteilen (z.B. ios-production Nur mit iOS aktiviert. android-production mit nur Android aktiviert, und electron-production Mit nur Electron aktiviert), markieren Sie jedes als Standard für seine Plattform. iOS-Geräte gehen auf die iOS-Standard, Android-Geräte gehen auf den Android-Standard und Electron-Anwendungen gehen auf den Electron-Standard.

Denken Sie daran, dass die Cloud-Standard- und defaultChannel in capacitor.config.* beide besetzen denselben Entscheidungsschicht. Wenn Sie eine Cloud-Standard-Einstellung setzen, müssen Sie den Wert in Ihrer Capacitor-Konfiguration nicht duplizieren—lassen Sie ihn einfach defaultChannel leer für Produktionsbuilds. Bewahren Sie Platz für defaultChannel für Binärdateien, die Sie absichtlich an Tester oder QA weitergeben, wenn Sie ihnen einen nicht-produktiven Kanal starten möchten, selbst wenn der Cloud-Standard anders ist.

Sie können die Standards jederzeit im Dashboard ändern. Wenn Sie eine Standard ändern, folgen neue Geräte sofort den neuen Routen und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Check-in.

Einrichten eines Kanals

Während des Einrichtungsprozesses erstellen Sie den ersten Kanal (die meisten Teams nennen ihn „Produktion“), aber nichts ist gesperrt – Sie können den Kanal jederzeit umbenennen oder löschen. Um später weitere Kanäle hinzuzufügen:

1. Gehe zu der “Kanäle”-Sektion der Capgo-Oberfläche
2. Klicken Sie auf die Schaltfläche „Neuer Kanal“
3. Bitte geben Sie einen Namen für den Kanal an und klicken Sie auf „Erstellen“

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie besteht darin, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie zum Beispiel:

• Development - für die Überprüfung von Live-Updates auf lokalen Geräten oder Emulatoren
• QA - für Ihre QA-Team, um Updates vor einer breiteren Veröffentlichung zu überprüfen
• Staging - für die endgültige Überprüfung in einem Produktionsumfeld
• Production - für die Version Ihrer App, die die Benutzer von den App-Stores erhalten

Konfigurieren Sie den Kanal in Ihrer App

Mit Ihren Kanälen erstellt, müssen Sie Ihre App so konfigurieren, dass sie auf den entsprechenden Kanal hört. In diesem Beispiel verwenden wir den Development Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json)-Datei. Unter der plugins Abschnitt, optional setzen Sie defaultChannel für Testbuilds (intern / QA). Für Produktionsbuilds bevorzugen Sie die Unterdrückung, damit Geräte die Cloud-Standard verwenden, es sei denn, dies wird explizit überschrieben.

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  plugins: {
    CapacitorUpdater: {
      // For a QA/TestFlight build – testers start on the Development channel automatically.
      defaultChannel: 'Development',
      // Production builds usually omit this so users attach to the Cloud Default channel.
    },
  },
};

Nächste, bauen Sie Ihre Webanwendung und führen Sie npx cap sync um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungsstep überspringen, werden Ihre native Projekte weiterhin den für sie zuvor konfigurierten Kanal verwenden.

Vorsicht

Reihenfolge der Kanalauswahl: Force > Override (setChannel / Dashboard) > Konfiguration defaultChannel > Cloud-Standard.

Verwenden defaultChannel nur in test/internen Builds; löschen Sie es für die Produktion, damit die Benutzer die Cloud-Standard (wenn gesetzt) anstelle der Routing-Duplikation in der native Konfiguration folgen.

Sie können ein Gerät noch zwingen (festlegen) oder eine Überprüfung später anwenden – diese übernehmen sofort die Konfigurationswert.

Kanalnamen sind case-sensitive.

Kanaloptionen und Strategien

Kanäle haben mehrere Optionen, die steuern, wer Updates erhalten kann und wie Updates geliefert werden. Die wichtigsten sind unten aufgeführt. Sie können diese von der Webanwendung, der CLI, oder der öffentlichen API konfigurieren.

• Standardkanal: Optional markieren Sie den Kanal oder die plattform-spezifischen Kanäle, die neue Geräte anbinden. Siehe “Standardkanalverhalten” für Routing-Szenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Deaktivieren Sie die automatische Downgrade unter native: Verhindert die Sendung eines Updates, wenn das Geräte-native-App-Version neuere ist als der Kanal-Bundle (z.B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Zulassen von Entwicklungsbuilds: Genehmigen Sie Updates für Entwicklungsbuilds (nützlich für die Tests).
• Zulassen von Emulatoren: Genehmigen Sie Updates für Emulatoren/Simulatoren (nützlich für die Testung).
• Zulassen der Selbstzuweisung von Geräten: Lassen Sie die App zu diesem Kanal umschalten, sobald sie bereit ist. setChannel Wenn deaktiviert, setChannel wird dies für diesen Kanal fehlschlagen.

Automatische Updatestrategien deaktivieren

Verwenden Sie dies, um festzulegen, welche Arten von Updates der Kanal automatisch liefern wird. Optionen:

• major: Blockieren Sie Updates zwischen verschiedenen Hauptversionen (0.0.0 → 1.0.0). Kleine und Patches-Updates sind weiterhin erlaubt.
• minor: Blockieren Sie Updates zwischen verschiedenen Minor-Versionen (z.B. 1.1.0 → 1.2.0) und Hauptversionen. Patches-Updates sind weiterhin erlaubt. Hinweis: Blockiert nicht 0.1.0 → 1.1.0.
• patch: Sehr streng. Erstellt nur Zuwächse von Patches-Versionen innerhalb derselben Haupt- und Minor-Version. Beispiele: 0.0.311 → 0.0.314 ✅, 0.1.312 → 0.0.314 ❌, 1.0.312 → 0.0.314 ❌.
• metadata: Erfordern Sie eine Mindestversion von Update-Metadaten in jedem Bundle. Konfigurieren Sie dies über CLI mithilfe von oder --min-update-version Disable Auto Update strategies --auto-min-update-version. Wenn fehlt, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis er gesetzt wird.
• none: Alle Updates entsprechend semver-Kompatibilität zulassen.

Weitere Details und Beispiele finden Sie in Disable updates strategy unter /docs/cli/commands/#disable-updates-strategy.

Beispiel (CLI):

# Block major updates on the Production channel
npx @capgo/cli@latest channel set production com.example.app \
  --disable-auto-update major

# Allow devices to self-assign to the Beta channel
npx @capgo/cli@latest channel set beta com.example.app --self-assign

Mit setChannel() von Ihrer App

Der setChannel() Methode ermöglicht es Ihrer App, den Kanal programmatisch während der Ausführung zu wechseln. Dies ist insbesondere nützlich für:

• QA/Debug-Menüs, bei denen Tester zwischen Kanälen wechseln können
• Beta-Programm-Opt-in-Flüsse
• Funktionsschaltflächenimplementierungen
• A/B-Test-Szenarien

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Switch to the beta channel
await CapacitorUpdater.setChannel({ channel: 'beta' });

// Optionally trigger an immediate update check after switching
await CapacitorUpdater.setChannel({
  channel: 'beta',
  triggerAutoUpdate: true
});

Wie setChannel() funktioniert (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Wenn setChannel() wird aufgerufen:

1. Hintergrundvalidierung (nur Lesen)Ein Anfrage wird an den Capgo-Backend gesendet, um zu überprüfen, ob der Kanal zugelassen ist (Überprüfung der Selbstzuweisungsrechte)
2. Lokale SpeicheraktualisierungWenn die Validierung erfolgreich ist, wird der Kanal im Gerätespeicher als defaultChannel
3. Sofortwirkung: Die nächste Aktualisierungskontrolle verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Warum das wichtig ist: In älteren Versionen, setChannel() speicherte die Kanalüberschreibung im Backend-Datenbank (ebenso wie Dashboard oder API-Änderungen). Geräte mussten auf die Backend-Replikation warten (bis zu 2 Minuten), bevor die Kanaländerung wirksam wurde. Jetzt, setChannel() liest nur vom Backend (für die Validierung) und speichert lokal, was die Kanalwechsel sofortig macht.

Sicherheitshinweis: Even wenn sich die Berechtigungen eines Kanals nach der lokalen Festlegung ändern (z.B. Selbstzuweisung ist deaktiviert), wird das Backend den Kanal während der Aktualisierungskontrollen nochmals validieren, was die Sicherheit aufrechterhält.

Vergleich der Kanaländerungsverfahren:

Methode	Effektzeit	Gespeichert in	Verwendungszweck
setChannel() aus Plugin	Instant	Gerät nur (lokal)	Benutzerinitiierte Kanalwechsel in der App
Übersichtsgerät-Überschreibung	Höchstens 2 min	Hintergrund-Datenbank	Administrator-geführte Änderungen für spezifische Geräte
API Kanalzuweisung	Höchstens 2 min	Hintergrund-Datenbank	Automatisierte Hintergrundintegrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs mit Kanalwechseln, verwenden Sie immer die Funktion des Plugins. setChannel() Methode.

Mindestversionen für den lokalen Kanalwechsel: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von Ihrer Hauptversion). Jeder Minor-Version-Nummer entspricht demselben Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, unabhängig davon, ob X 5, 6, 7 oder 8 ist). Siehe Plugin-Installation für Versionsetiketten.

Zuweisung einer Bundle zu einem Kanal

Um eine Live-Update zu deployen, müssen Sie ein neues JS-Bundle-Build hochladen und es einem Kanal zuweisen. Sie können dies in einem Schritt mit dem Capgo CLI durchführen:

npx @capgo/cli@latest bundle upload --channel=Development

This wird Ihre gebauten Web-Assets hochladen und die neue Sammlung als aktives Build für das Development Kanal. Jede Anwendung, die auf das Kanal lauscht, erhält die Aktualisierung beim nächsten Mal, wenn sie nach einer aktualisiert.

Sie können auch Builds auf Kanäle zuweisen, indem Sie im “Bundles”-Abschnitt des Capgo-Dashboards auf das Menüsymbol neben einem Build klicken und “Zuweisen an Kanal” auswählen, um den Kanal für dieses Build auszuwählen.

Bundle-Versionierung und Kanäle

Es ist wichtig zu beachten, dass Bundles in Capgo global für Ihre App sind und nicht spezifisch auf einzelne Kanäle beschränkt sind. Das gleiche Bundle kann auf mehrere Kanäle zugewiesen werden.

Bei der Versionsierung Ihrer Bundles empfehlen wir die Verwendung von semantischen Versionen semver mit Voreinstellungen für kanalbezogene Builds. Zum Beispiel könnte eine Beta-Version als 1.2.3-beta.1.

Diese Vorgehensweise hat mehrere Vorteile:

• Es kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Voreinstellung für 1.2.3.
• Es ermöglicht die Wiederverwendung von Versionsnummern über Kanäle hinweg, Verwirrung reduziert.
• Es ermöglicht klare Rückschrittschritte. Wenn Sie von 1.2.3wissen Sie 1.2.2 ist die vorherige stabile Version.

Hier ist ein Beispiel dafür, wie Sie Ihre Bundle-Versionen mit einer typischen Kanal-Konfiguration ausrichten können:

• Development Kanal: 1.2.3-dev.1, 1.2.3-dev.2usw.
• QA Kanal: 1.2.3-qa.1, 1.2.3-qa.2usw.
• Staging Kanal: 1.2.3-rc.1, 1.2.3-rc.2usw.
• Production Kanal: 1.2.3, 1.2.4Ich kann nicht finden, was zu übersetzen ist. Bitte geben Sie den Text ein, den Sie übersetzen möchten.

Mit semver und Prärelaunch-Identifikatoren ist eine empfohlene Vorgehensweise, aber nicht strikt erforderlich. Der Schlüssel ist es, eine Versionsverwaltung zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt.

Ein Live-Update rückgängig machen

Wenn Sie ein Live-Update bereitstellen, das einen Fehler enthält oder anderweitig rückgängig gemacht werden muss, können Sie leicht auf einen vorherigen Build zurückkehren. Aus der "Kanäle"-Sektion der Oberfläche:

1. Klicken Sie auf den Namen des Kanals, den Sie rückgängig machen möchten
2. Wählen Sie das Build, das Sie rückgängig machen möchten, und klicken Sie auf das Krönchen-Icon
3. Bestätigen Sie die Aktion

Die ausgewählte Build wird sofort wieder die aktive Build für diesen Kanal. Apps erhalten die zurückgerollte Version beim nächsten Mal, wenn sie nach einer Aktualisierung suchen.

Automatisierung von Bereitstellungen

Für fortgeschrittene Workflows können Sie Ihre Live-Update-Deployments als Teil Ihres CI/CD-Pipelines automatisieren. Indem Sie Capgo in Ihren Buildprozess integrieren, können Sie neue Bundles automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

Check out die CI/CD-Integration Dokumentation, um mehr über die Automatisierung von Capgo-Live-Updates zu erfahren.

Auf einem Gerät bereitstellen

Jetzt, da Sie die Kanäle verstehen, sind Sie bereit, Live-Updates auf echten Geräten zu deployen. Der grundlegende Prozess ist:

1. Installieren Sie das Capgo SDK in Ihrer App
2. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu lauschen
3. Hochladen eines Builds und ihm den Kanal zuweisen
4. Starten Sie die App und warten Sie auf das Update!

Für eine detailliertere Anleitung siehe die Live-Updates bereitstellen Leitfaden. Viel Erfolg beim Aktualisieren!

Erweiterte Kanalnutzung: Benutzersegmentierung

Kanäle können nicht nur für Entwicklungsstufen verwendet werden. Sie sind ein mächtiges Werkzeug für die Benutzersegmentierung, das Funktionen wie:

• Funktionsschalter für verschiedene Benutzerstufen
• A/B-Test
• Schrittweise Einführung neuer Funktionen
• Beta-Test-Programme

Erhalten Sie Informationen, wie Sie diese erweiterten Anwendungsfälle in unserem Leitfaden umsetzen können: Wie Sie Benutzer nach Tarif und Kanälen segmentieren und Funktionsschalter und A/B-Test durchführen.