Kanäle

Ein Live-Update-Kanal verweist auf eine bestimmte JS-Bundle-Build Ihres Apps, die an alle Geräte weitergegeben wird, die auf das Abhören dieses Kanals für Updates konfiguriert sind. Wenn Sie den Capgo Live-Updates SDK in Ihrer App installieren, überprüfen alle auf diesem Kanal konfigurierten native Binärdateien bei jedem App-Start nach verfügbaren Updates. Sie können die Build, auf die ein Kanal verweist, jederzeit ändern und können auch auf vorherige Builds zurückkehren, wenn nötig.

Kanäle bieten keine Vertraulichkeit

Kanäle steuern die Aktualisierungsberechtigung, nicht die Paketgeheimhaltung. Selbst wenn ein Kanal privat ist oder die Selbstzuweisung deaktiviert ist, sollte ein unverschlüsselter Paketupload auf Capgo immer noch als öffentliches Asset behandelt werden, das an Kunden weitergegeben wird. Die Verschlüsselung schützt den Übertragungsweg und die Authentizität der Updates, aber verschickte Pakete können immer noch umgekehrt entwickelt werden, wenn genügend Anstrengung aufgewendet wird, weil das öffentliche Schlüsselteil des Clients Teil ist. Siehe Live-Update-Verschlüsselung für Details.

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

Wenn ein Gerät nach einer Aktualisierung sucht, entscheidet Capgo, welcher Kanal in dieser strengen Reihenfolge (mit höchster Priorität zuerst) verwendet wird:

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

Schnelles Kanalwechseln mit setChannel()

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

Zuvor setChannel() speicherte der Kanal-Übertrag in der Backend-Datenbank (wie Dashboard oder API-Änderungen) und Geräte mussten auf Datenreplikation (bis zu 2 Minuten) warten, bevor der neue Kanal anerkannt wurde. Die neue Verhaltensweise liest nur vom Backend (für die Überprüfung) und speichert lokal, was die Kanalwechsel sofortig macht.

Hinweis: Even if a channel becomes disallowed after being set locally, the backend will still validate the channel during update checks, so security is maintained.

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

3. Capacitor-Konfiguration defaultChannel (Standardbauart für Testversionen) – Wenn diese in capacitor.config.* und keine Zwangs-/Überlagerung vorhanden ist, startet die App auf diesem Kanal (z.B. beta, qa, pr-123). Für TestFlight-/Internetaufgaben gedacht, damit Tester automatisch auf einem Vorkassenkanal landen. Produktionsaufgaben lassen dies normalerweise ungesetzt.
4. Standardkanal im Cloud (Hauptpfad ~99% der Nutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endnutzer (keine Zwangs-, keine Überlagerung, keine Konfigurationsstandardkanal) hier angeschlossen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen—kein neuer Binary. Wenn Sie plattform-spezifische Standards (z.B. eine iOS-only, eine Android-only, eine Electron-only) haben, landet jeder Gerät auf dem Standard, der seiner Plattform entspricht. Wenn Sie den Cloud-Standard ungesetzt lassen, ist das erlaubt; in diesem Fall muss das Gerät Schritt 1–3 entsprechen, um Updates zu erhalten.

Gute Praxis:

• Behandeln Sie 1–3 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten sich echte Nutzer in ihn einfließen. Wenn Sie keinen setzen, seien Sie bei der Anbindung der Nutzer (typischerweise via defaultChannel In der Konfiguration oder in Geräteüberschreibungen).
• Nur konfigurieren defaultChannel In Binaries, die Sie explizit an Tester weitergeben. Wenn es unbelegt bleibt, bleibt die Produktionslogik zentral im Dashboard.
• Verwenden setChannel() Sparsam in der Produktion—hauptsächlich für QA oder gezielte Diagnosen.

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

Zusammenfassung: Zwang > Überschreiben > Konfiguration defaultChannel > Cloud Standard.

Standardverhalten des Kanals

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als allgemeiner Pfad für neue Geräte. Ohne einen davon erhalten nur Geräte, die sich an gezwungenen Zuordnungen, Überschreibungen oder einem defaultChannel In der Capacitor-Konfiguration erhalten 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 Überwritungen wird hierhin angehängt.
• Plattform-spezifische Standards – Wenn Sie Kanäle nach Plattformen aufteilen (z.B. nur iOS aktiviert, nur Android aktiviert und nur Electron aktiviert), markieren Sie jeden als Standard für seine Plattform. iOS-Geräte gehen zum iOS-Standard, Android-Geräte gehen zum Android-Standard und Electron-Anwendungen gehen zum Electron-Standard. ios-production Denken Sie daran, dass der Cloud-Standard und "in" denselben Entscheidungsschicht besetzen. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert in Ihrer __CAPGO_KEEP_0__-Konfiguration nicht duplizieren – lassen Sie ihn leer für Produktionsbuilds. Reserve " für Binärdateien, die Sie absichtlich an Tester oder QA ausliefern, wenn Sie möchten, dass sie auf einem Nicht-Produktionskanal starten, auch wenn der Cloud-Standard anders ist. android-production – Wenn ein Kanal nur iOS aktiviert ist electron-production – Wenn ein Kanal nur Android aktiviert ist

– Wenn ein Kanal nur Electron aktiviert ist defaultChannel in capacitor.config.* both occupy the same decision layer. If you set a cloud default, you don’t need to duplicate the value in your Capacitor config—leave defaultChannel für defaultChannel für

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

Kanal einrichten

Während der Einrichtung 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 zusätzliche Kanäle später hinzuzufügen:

1. Gehen Sie zur “Kanäle”-Sektion des Capgo-Dashboards
2. Klicken Sie auf den “Neuen Kanal”-Button
3. Geben Sie einen Namen für den Kanal ein und klicken Sie auf “Erstellen”

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie ist es, Kanäle Ihren Entwicklungsstufen zuzuordnen, wie z.B.:

• 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 Ihres Apps, die Benutzer von den App-Stores erhalten

Kanal in Ihrer App einrichten

Nachdem Sie die Kanäle erstellt haben, müssen Sie Ihre App so einrichten, dass sie auf den richtigen Kanal hört. In diesem Beispiel verwenden wir den Development Kanal.

Öffnen Sie Ihr capacitor.config.ts (oder capacitor.config.json)-Dokument. Unter der plugins Abschnitt, setzen Sie optional defaultChannel für Testversionen (intern / QA). Für Produktionsversionen 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.
    },
  },
};

Ziehen Sie als Nächstes Ihre Web-App und führen Sie sie aus, um die aktualisierte Konfigurationsdatei in Ihre iOS-, Android- und Electron-Projekte zu kopieren. Wenn Sie diesen Synchronisierungsstep überspringen, werden Ihre native Projekte weiterhin diejenige Kanal verwenden, für den sie zuvor konfiguriert waren. npx cap sync Wichtige Hinweise

Kanalwahl-Reihenfolge: Zwang > Überschreiben (

/ Dashboard) > KonfigurationsetChannel > Cloud-Standard. defaultChannel Verwenden Sie dies nur in Test-/Internen Builds; lassen Sie es für die Produktion aus, damit die Benutzer den Cloud-Standard (wenn gesetzt) anstelle der Doppelung der Routen in der native Konfiguration folgen.

Sie können dennoch einen Gerät zwangssetzen (festlegen) oder eine Überschreitung anwenden – diese überschreiben sofort den Konfigurationswert. defaultChannel Kanalnamen sind case-sensitive.

Kanaloptionen und Strategien

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

Kanäle haben mehrere Optionen, die steuern, wer Updates erhalten kann und wie Updates geliefert werden. Die wichtigsten sind unten aufgeführt. Diese können Sie 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, Androidoder Electron Geräte pro Kanal.
• Deaktivieren Sie die automatische Downgrade unter native: Verhindert die Übermittlung eines Updates, wenn das Geräte-App-Verzeichnis neuer ist als das Kanal-Bundle (z. B. Gerät auf 1.2.3, während der Kanal 1.2.2 hat).
• Zulassen Sie Entwicklungsbuilds: Ermöglichen Sie Updates für Entwicklungsbuilds (nützlich für Tests).
• Zulassen Sie Emulatordienste: Ermöglichen Sie Updates für Emulatoren/Simulator (nützlich für Tests).
• Zulassen Sie die Selbstzuweisung des Geräts: Lassen Sie die App zu diesem Kanal umschalten, wenn sie am Laufen ist, mithilfe von setChannel Wenn deaktiviert, setChannel versagt für diesen Kanal.

Auto-Update-Strategien 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 zulässig.
• minor: Blockieren Sie Updates zwischen verschiedenen Minor-Versionen (z.B. 1.1.0 → 1.2.0) und Hauptversionen. Patches-Updates sind weiterhin zulässig. Hinweis: Blockiert nicht 0.1.0 → 1.1.0.
• patch: Sehr streng. Erstellt nur Zuwächse bei 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: Erfordert eine Mindestversion von Update-Metadaten in jedem Bundle. Konfigurieren Sie dies über CLI mit oder . Wenn fehlend, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis dies gesetzt ist. --min-update-version none: Zulässt alle Updates entsprechend der semver-Kompatibilität. --auto-min-update-versionDetails und Beispiele finden Sie unter Auto-Update-Strategie in /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy.
• Disable Auto-Update-Strategien Learn more details and examples in Disable updates strategy at /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategy..

Learn more details and examples in Disable updates strategy at /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() aus Ihrer App

Der setChannel() Methode ermöglicht es Ihrer App, die Kanäle programmatisch während der Laufzeit 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
• Feature-Flag-Implementierungen
• 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
});

How setChannel() Funktioniert (v5.34.0+ / v6.34.0+ / v7.34.0+ / v8.0.0+)

Wann setChannel() gerufen wird:

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. Speicherung in der lokalen Datenbank: Wenn die Überprüfung erfolgreich ist, wird der Kanal in der lokalen Speicherung des Geräts gespeichert als defaultChannel
3. Instanteffekt: Die nächste Aktualisierungskontrolle verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Weshalb dies wichtig ist: In älteren Versionen, setChannel() hat den Kanal-Übertrag in der Backend-Datenbank gespeichert (gleichbedeutend mit Dashboard- oder API-Änderungen). Geräte mussten auf die Backend-Replikation (bis zu 2 Minuten) warten, bevor die Kanal-Änderung wirksam wurde. Jetzt, setChannel() liest nur vom Backend (für die Validierung) und speichert lokal, wodurch Kanalwechsel sofort wirksam werden.

Sicherheitshinweis: Even wenn sich die Rechte eines Kanals nach der lokalen Festlegung ändern (z.B. Selbstzuweisung ist deaktiviert), wird das Backend den Kanal während der Update-Überprüfungen noch immer validieren, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanal-Änderungsmethoden:

Method	Wirkungszeit	Gespeichert in	Verwendungsfall
setChannel() aus Plugin	Instant	Gerät nur (lokal)	Benutzerinitiierte Kanalwechsel in-app
Übersichtsgerät-Überschreibung	bis zu 2 min	Hintergrund-Datenbank	Administratorinitiierte Änderungen für bestimmte Geräte
API Kanalzuweisung	bis zu 2 min	Hintergrund-Datenbank	Automatisierte Hintergrundintegrationen

Für die beste Benutzererfahrung bei der Erstellung von Kanalwechsel-UIs, verwenden Sie immer die Methode des Plugins. setChannel() Mindestversionen für lokale Kanalwechsel:

Mindestversionen für lokale Kanalwechsel: 5.34.0, 6.34.0, 7.34.0oder 8.0.0 (abhängig von Ihrer Hauptversion). Jede Minor-Version-Nummer entspricht derselben Funktionsmenge bei allen Hauptversionen (z.B. X.34.0 enthält dieselben Funktionen, egal ob X 5, 6, 7 oder 8 ist). Siehe Plugin-Installation zur Versionsbezeichnung.

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:

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

Dies wird Ihre gebauten Web-Assets hochladen und das neue Bundle als aktives Build für den Development Kanal setzen. Jeder App, die auf diesen Kanal eingestellt ist, erhält die Aktualisierung beim nächsten Mal, wenn sie nach einer aktualisiert suchen.

Sie können auch Builds zu Kanälen aus der ‘Bundles’-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie ‘Zu Kanal zuweisen’ aus, 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 mehreren Kanälen zugewiesen werden.

Wenn Sie Ihre Bundles versionieren, empfehlen wir die Verwendung von semantischer Versionierung mit Capgo’s Semver-Tester und Prä-Release-Identifikatoren für kanal-spezifische Builds. Zum Beispiel könnte eine Beta-Version wie folgt versioniert sein: 1.2.3-beta.1.

Diese Vorgehensweise hat mehrere Vorteile:

• Sie kommuniziert offensichtlich die Beziehung zwischen Builds. 1.2.3-beta.1 ist offensichtlich eine Prä-Release von 1.2.3.
• Sie ermöglicht die Wiederholung von Versionsnummern über Kanäle hinweg, was Verwirrung vermeidet.
• Sie ermöglicht klare Rückerstattungspfade. Wenn Sie von 1.2.3wissen Sie, wohin Sie zurückrollen müssen. 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.4usw.

Mit semver mit Voreinstellungen für vorherige Versionen ist eine empfohlene Vorgehensweise, aber nicht streng erforderlich. Der Schlüssel besteht darin, eine Versionsierungsschematik zu finden, die die Beziehungen zwischen Ihren Builds klar kommuniziert und mit Ihrem Teams Entwicklungsprozess übereinstimmt.

Rückgängigmachen eines Live-Updates

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ückgreifen. Aus der Sektion “Kanäle” im Dashboard:

1. Klicken Sie auf den Namen des Kanals, auf den Sie zurückgreifen möchten
2. Finden Sie den Build, auf den Sie zurückgreifen möchten, und klicken Sie auf das Krönchen-Symbol
3. Bestätigen Sie die Aktion

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

Automatisierung der Bereitstellung

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

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

Zurücksetzen auf ein Gerät

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 hören
3. Hochladen Sie eine Build und zuweisen Sie sie diesem Kanal
4. Starten Sie die App und warten Sie auf die Aktualisierung!

Für eine detailliertere Anleitung, sehen Sie sich die Live-Updates deployen guide. Froh über die Aktualisierung!

Erweiterte Kanalnutzung: Benutzersegmentierung

Kanäle können für mehr als nur 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

Lernen Sie, 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.

Weiter geht es von Kanälen

Wenn Sie Kanäle um die Kanalsteuerung und die geplante Rollout zu planen, verbinden Sie es mit Kanäle für die Implementierungsdetails in Kanäle, Kanäle für die Implementierungsdetails in Kanäle, Beta-Testlösung für den Produktworkflow in Beta-Testlösung, Versionziel-Lösung für den Produktworkflow in Versionziel-Lösung, und Capgo Umgebungsbest Practices: Staging mit einem Mobile-App-ID für den praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobile App ID.