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 die Capgo Live-Updates SDK in Ihrer App installieren, überprüfen alle native Binärdateien, die auf diesen Kanal konfiguriert sind, bei jedem Start der App 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 Updateberechtigung, 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 die verschickten Pakete können immer noch mit genügend Anstrengung rückgängig gemacht werden, weil der öffentliche Schlüssel Teil des Clients 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, welchen Kanal in dieser strengen Reihenfolge (mit höchster Priorität zuerst) zu verwenden ist:

1. Zwingende Gerätemap (Dashboard) – Ein bestimmtes Geräte-ID manuell 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) über Dashboard oder API – Erstellt, wenn Sie den Gerätekanal im Dashboard oder über API ändern. Verwenden für QA-Benutzer, die zwischen Feature- / PR-Kanälen wechseln oder um ein Benutzerproblem nachzustellen. Eine erneute Installation des Binärs löscht ihn nicht; die Löschung der Geräte-Einträge tut es.
3. Plugin setChannel() lokaler Kanal – Erstellt, wenn die App setChannel() und der Backend bestätigt, dass der Zielkanal die Selbstzuweisung zulässt. Der ausgewählte Kanal wird lokal auf dem Gerät gespeichert, wirkt sofort und wird nicht im Geräte-Übernahme-UI angezeigt.

Schnelles Kanalwechseln mit setChannel()

Ab Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 des Plugins (abhängig von Ihrer Hauptversion) setChannel() arbeiten Sie anders: Es kontaktiert den Backend-Server, um zu überprüfen dass der Kanal zugelassen 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 bei der nächsten Aktualisierung überprüft wird—keine Wartezeit für die Replikation. Zuvor

speicherte das Plugin den Kanal-Übertrag in der Backend-Datenbank (wie Dashboard oder __CAPGO_KEEP_0__-Änderungen) und Geräte mussten auf die Datenreplikation (bis zu 2 Minuten) warten, bevor der neue Kanal anerkannt wurde. Die neue Funktionalität liest nur vom Backend (für die Überprüfung) und speichert lokal, was eine sofortige Kanaländerung ermöglicht. 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.

Da es sich um eine lokale Funktion handelt, wird in der __CAPGO_KEEP_0__-Oberfläche kein Eintrag im Geräte-Überschreibungs-Verzeichnis erstellt. Die Geräte-Überschreibungs-UI zeigt nur Überschreibungen an, die aus der Oberfläche oder dem öffentlichen __CAPGO_KEEP_1__ erstellt wurden. setChannel() Hinweis: Auch wenn ein Kanal nach lokaler Einstellung verboten wird, wird der Backend-Server den Kanal während der Update-Überprüfungen noch immer validieren, sodass die Sicherheit gewährleistet ist. create a Device Override entry in the Capgo dashboard. The Device Override UI only shows overrides created from the dashboard or the Public API.

Wenn Kanaländerungen über die Oberfläche oder __CAPGO_KEEP_0__ vorgenommen werden, besteht ein Reproduktionsverzug von bis zu 2 Minuten, bevor alle Edge-Server die Änderung widerspiegeln. Für sofortige Kanalwechsel verwenden Sie aus Ihrer App __CAPGO_KEEP_0__—es validiert mit dem Backend und setzt den Kanal lokal für sofortigen Effekt.

__CAPGO_KEEP_0__-Konfiguration When channel changes are made via the Dashboard or API, there is still a replication lag of up to 2 minutes before all edge servers reflect the change. For instant channel switching, use setChannel() from your app code—it validates with the backend, then sets the channel locally for immediate effect.

4. Capacitor-Konfiguration defaultChannel (Standardkonfiguration für Testbuilds) – Wenn vorhanden in capacitor.config.* und keine force/override/local-Kanal existiert, startet die App auf diesem Kanal (z.B. beta, qa, pr-123). Für TestFlight/Innentests geeignet, damit Tester automatisch auf einem Vorabversionskanal landen. Produktionsbuilds lassen dies normalerweise ungesetzt.
5. Cloud-Standardkanal (Hauptpfad ~99% der Nutzer) – Wenn Sie einen Standardkanal im Dashboard markieren, werden alle normalen Endnutzer (keine force, keine Dashboard/API-Übernahme, kein Plugin-Local-Kanal, keine Konfiguration defaultChannel) hier angeschlossen. Ändern Sie ihn, um sofort auszurollen oder zurückzurufen – kein neuer Binärdatei. 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 der Cloud-Standard ungesetzt bleibt, ist dies erlaubt; in diesem Fall muss das Gerät auf Schritte 1–4 abgestimmt sein, um Updates zu erhalten.

Gute Praxis:

• Behandeln Sie 1–4 als Ausnahmen / Testebenen; wenn Sie einen Cloud-Standard setzen, sollten sich echte Nutzer in ihn einfließen. Wenn Sie keinen setzen, sollten Sie bewusst sein, wie Nutzer sich angeschlossen haben (typischerweise über defaultChannel in der Konfiguration oder per-Geräte-Übernahmen).
• Konfigurieren Sie defaultChannel nur in Binärdateien, die Sie explizit an Tester verschicken. Wenn Sie es ungesetzt lassen, bleibt die Produktionslogik zentral im Dashboard.
• Verwenden Sie 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 worden wäre, springt die Auswahlprozess darüber hinweg und geht weiter mit der Liste.

Zusammenfassung: Force > Dashboard/API Override > Plugin setChannel() lokaler Kanal > Config defaultChannel > Cloud Standard.

Standardverhalten des Kanals

Die Festlegung eines Cloud-Standards ist optional, aber es dient normalerweise als Default-Pfad für neue Geräte. Ohne einen solchen, erhalten nur Geräte, die sich auf zwingenden Zuordnungen, Überschreibungen oder einem defaultChannel in der Capacitor-Konfiguration, Updates.

• Wenn Sie sich entscheiden, Standards zu markieren, beachten Sie diese Muster: Einzelner Standard (am häufigsten)
• – Wenn ein Kanal iOS, Android und Electron aktiviert hat, wird er zum einzigen Standard; jedes Gerät ohne Überschreibungen wird hier angeschlossen. Plattform-spezifische Standards ios-production – Wenn Sie Kanäle nach Plattformen (z.B. mit nur iOS aktiviert) aufteilen, android-production With nur Android aktiviert und electron-production With nur Electron aktiviert, markieren Sie jede als Standard für ihre 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 der Cloud-Standard und defaultChannel beide denselben Entscheidungsschicht besetzen. Wenn Sie einen Cloud-Standard setzen, müssen Sie den Wert nicht in Ihrer __CAPGO_KEEP_0__-Konfiguration duplizieren—lassen Sie 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 Binärdateien, die Sie absichtlich an Tester oder QA liefern, wenn Sie möchten, dass sie auf einem Nicht-Produktionskanal starten, selbst wenn der Cloud-Standard anders ist. defaultChannel Sie können Standards jederzeit im Dashboard ändern. Wenn Sie einen Standard austauschen, folgen neue Geräte sofort den neuen Routen und bestehende Geräte folgen den normalen Vorrangregeln beim nächsten Mal, wenn sie sich anmelden.

Einrichten eines Kanals

Abschnitt mit dem Titel „Einrichten eines Kanals“

Gehe zur „Kanäle“-Sektion im __CAPGO_KEEP_0__-Dashboard

1. Go to the “Channels” section of the Capgo dashboard
2. Klicken Sie auf den Button „Neuen Kanal“
3. Ein Namen für den Kanal eingeben und auf „Erstellen“ klicken

Kanalnamen können alles sein, was Sie möchten. Eine gängige Strategie besteht darin, 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 konfigurieren

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 Ihre capacitor.config.ts Auswählen (oder capacitor.config.jsonunter der plugins Sektion, optional für defaultChannel Testversionen (intern / QA). Für Produktionsversionen bevorzugen Sie die Unterdrückung, damit die Geräte die Cloud-Standard verwenden, es sei denn, dies wird explizit überschrieben. Zwischenablage kopieren

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.
    },
  },
};

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 Vorsicht

Reihenfolge der Kanalauswahl: Zwang > Dashboard/__CAPGO_KEEP_0__ Geräteüberschreibung > Plugin

Channel selection order: Force > Dashboard/API device override > Plugin setChannel() lokale Kanal > 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 Wiederholung der Routen in der native Konfiguration folgen.

Sie können dennoch eine Geräte zwingen (festlegen) oder eine Überschreibung später anwenden – diese überschreiben 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 Routen-Szenarien.
• Plattformfilter: Aktivieren oder deaktivieren Sie die Lieferung an iOS, Android, oder Electron Geräte pro Kanal.
• Unter Native deaktivieren: Verhindert das Senden eines Updates, wenn die Geräte-App-Version neuere ist als die Kanal-Bundle-Version (z.B. Gerät auf 1.2.3 und Kanal auf 1.2.2).
• Entwicklungsbuilds zulassen: Ermöglicht Updates für Entwicklungsbuilds (nützlich für Tests).
• Emulatortechnik zulassen: Ermöglicht Updates für Emulatoren/Simulatoren (nützlich für Tests).
• Geräte selbst zuweisen lassen: Lässt die App auf diesem Kanal umschalten, wenn sie dies zum Laufzeitbetrieb benötigt. setChannelWenn deaktiviert, setChannel fehlschlägt für diesen Kanal.

Auto-Update-Strategien deaktivieren

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

• major: Blockiert ein Ziel-Bundle, dessen Hauptversion höher ist als die Geräte-App-Basis (version_build). Beispiel: 1.2.3 -> 2.0.0 ist blockiert; 1.2.3 -> 1.9.0 ist erlaubt.
• minor: Blockt ein Zielbundle, dessen Haupt- oder Minorversion sich von version_buildBeispiel: 1.2.3 -> 1.3.0 ist blockiert; 1.2.3 -> 1.2.4 ist erlaubt.
• patch: Striktster Modus. Blockt jede Änderung an der Haupt-, Minor- oder Patchnummer. Nur Suffix-Änderungen sind erlaubt, während MAJOR.MINOR.PATCH bleibt identisch. Beispiele: 1.0.0-beta.1 -> 1.0.0-beta.2 ist erlaubt, 1.0.0+build.1 -> 1.0.0+build.2 ist erlaubt, 1.0.0 -> 1.0.1 ist blockiert.
• metadata: Erfordert eine Mindestaktualisierungsversionsmetadata auf jedem Bundle. Konfigurieren Sie über CLI --min-update-version oder --auto-min-update-version. Wenn fehlt, wird der Kanal als fehlerhaft markiert und Updates werden abgelehnt, bis er gesetzt wird.
• none: Alle Updates entsprechend der semver-Kompatibilität zulassen Diese Strategien vergleichen das Zielbundle des Kanals mit der native Basis, die als.

, nicht mit dem aktuellen heruntergeladenen Bundle, das als version_buildMehr Details und Beispiele finden Sie unter /docs/__CAPGO_KEEP_0__/commands/#disable-updates-strategie. version_name.

Beispiel (cli):

Example (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

Abschnitt mit dem Titel „Mit setChannel() aus Ihrer App verwenden“

Die setChannel() Methode

• erlaubt
• Ihrem
• App
• programmatisch

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
});

wechseln

bei setChannel() Laufzeit.

1. Dies: Eine 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 Zwischenablage: Wenn die Überprüfung erfolgreich ist, wird der Kanal als defaultChannel
3. Instanteffekt: Die nächste Aktualisierungsprüfung verwendet den neuen Kanal sofort (keine Wartezeit für die Replikation)

Weshalb das wichtig ist: In älteren Versionen setChannel() den Kanal-Übertrag in der Backend-Datenbank (ebenso wie Dashboard oder API-Änderungen) gespeichert. Die Geräte mussten auf die Backend-Replikation (bis zu 2 Minuten) warten, bevor der Kanal-Wechsel wirksam wurde. Jetzt setChannel() nur von dem Backend gelesen (für die Überprüfung) und lokal gespeichert, was den Kanal-Wechsel sofort wirksam macht.

Anzeige im Dashboard: Ein mit dem Plugin gesetzter Kanal macht das Gerät nicht als Geräte-Übertragung im Capgo-UI sichtbar. Nur Kanalzuweisungen, die aus dem Dashboard oder dem öffentlichen API erstellt wurden, werden dort aufgelistet. Verwenden Sie das Dashboard oder API , wenn Sie eine admin-sichtbare Übertragung benötigen.

Sicherheitshinweis: Wenn sich die Berechtigungen eines Kanals nach der lokalen Einstellung ändern (z.B. Selbstzuweisung ist deaktiviert), wird der Backend die Validierung des Kanals während der Update-Überprüfungen durchführen, um die Sicherheit aufrechtzuerhalten.

Vergleich der Kanaländerungsverfahren:

Methode	Wirkungszeit	Persistiert	Angezeigt in Geräte-UI	Verwendungsfall
setChannel() aus Plugin	Echtzeit	Gerät nur (lokal)	Nein	Benutzerinitiierte Kanalwechsel in der App
Übersichtsgerät-Überschreibung	Höchstens 2 min	Hintergrund-Datenbank	Ja	Administrator-gesteuerte Änderungen für bestimmte Geräte
API-Kanalzuweisung	Höchstens 2 min	Hintergrund-Datenbank	Ja	Automatisierte Hintergrundintegrationen

Für die beste Benutzererfahrung bei der Erstellung von UIs für den Wechsel zwischen Kanälen, verwenden Sie immer die Methode des Plugins. setChannel() Für die beste Benutzererfahrung bei der Erstellung von UIs für den Wechsel zwischen Kanälen, verwenden Sie immer die Methode des Plugins.

Mindestversionen für die lokale Kanalumstellung: 5.34.0, 6.34.0, 7.34.0, oder 8.0.0 (abhängig von Ihrer Hauptversion). Jede Minor-Version-Nummer entspricht demselben Funktionsumfang in allen Hauptversionen (z.B. X.34.0 enthält die gleichen Funktionen, egal 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:

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

Sie können auch Builds auf Kanäle aus der 'Bundles'-Sektion des Capgo-Dashboards zuweisen. Klicken Sie auf das Menüsymbol neben einem Build und wählen Sie 'Auf Kanal zuweisen', um den Kanal für diesen 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 Versionsnummerierung Ihrer Bundles empfehlen wir Ihnen die Verwendung von semantischen Versionen mit Capgo’s Semver-Tester und Präfixen für channel-spezifische Builds. Zum Beispiel könnte eine Beta-Version wie folgt versioniert sein 1.2.3-beta.1.

Diese Vorgehensweise hat mehrere Vorteile:

• Es klärt die Beziehung zwischen Builds auf. 1.2.3-beta.1 ist offensichtlich eine Vorschau von 1.2.3.
• Es ermöglicht die Wiederholung von Versionsnummern über Kanäle hinweg, was Verwirrung vermeidet.
• Es ermöglicht klare Rollback-Pfade. Wenn Sie von 1.2.3, wissen 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 synchronisieren können:

• Development Kanal: 1.2.3-dev.1, 1.2.3-dev.2Kanal:
• QA Kanal: 1.2.3-qa.1, 1.2.3-qa.2Kanal:
• Staging Kanal: 1.2.3-rc.1, 1.2.3-rc.2Kanal:
• Production Mit 1.2.3, 1.2.4Kanal:

Kanal: semver mit Vorklauselidentifikatoren ist eine empfohlene Vorgehensweise, aber nicht streng erforderlich. Der Schlüssel ist es, eine Versionsierungsschablone 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 ein 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. Finden Sie den Build, den Sie rückgängig machen 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ückgeholte Version beim nächsten Mal, wenn sie nach einer Aktualisierung suchen.

Automatisierung der Bereitstellung

Für fortgeschrittene Workflows können Sie Ihre Live-Update-Deployments als Teil Ihres CI/CD-Pipelines automatisieren. Durch die Integration von Capgo in Ihren Build-Prozess können Sie neue Bundle automatisch hochladen und ihnen Kanäle zuweisen, sobald Sie bestimmte Branches pushen oder neue Releases erstellen.

Besuchen Sie 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 die Capgo- SDK in Ihrer App
2. Konfigurieren Sie die App, um auf Ihren gewünschten Kanal zu hören
3. Hochladen Sie ein Build und zuweisen Sie es diesem Kanal
4. Starten Sie die App und warten Sie auf die Aktualisierung!

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

Erweiterte Kanalnutzung: Benutzersegmentierung

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

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

Weitermachen Sie mit Kanälen

Wenn Sie " Channels " zum Planen der Kanalrouten und der schrittweisen Veröffentlichung verwenden, verbinden Sie es mit " Channels " für die Implementierungsdetails in " Channels " für die Implementierungsdetails in " Beta-Testlösung " für das Produktworkflow in " Beta-Testlösung " für das Produktworkflow in "Versionziel-Lösung" und Capgo Umgebungsbest Practices: Staging mit einem Mobilgerät-App-Id für den praktischen Kontext in Capgo Umgebungsbest Practices: Staging mit einem Mobilgerät-App-Id