Hast du dir jemals gewünscht, eine Änderung direkt an einen bestimmten Nutzer für sofortiges Feedback zu senden – ohne dass dieser einen neuen Build via TestFlight oder Google Play herunterladen und installieren muss?
Kunden haben oft Verbesserungen angefragt, die ich schnell umsetzen konnte. Aber um die Ergebnisse zur Validierung zu liefern, musste ich entweder ein Update an alle Nutzer ausrollen (riskant bei experimentellen Änderungen) oder einen speziellen Build für den Kunden erstellen (mühsam für uns beide).
Was fehlte, war Flexibilität. Entwickler wollten unterschiedliche Updates an verschiedene Nutzergruppen ausliefern können – etwa an nicht-technische Stakeholder, die QA oder bei Bedarf an die gesamte Userbase.
Es gab keine Möglichkeit für einen Production-Build, zu einer Work-in-Progress-Version zu wechseln, Feedback einzuholen und dann wieder zur Production zurückzukehren.
Das ist es, was Channel-Surfing ermöglicht. Eine auf dem Gerät eines Nutzers installierte App kann Update-Channels zur Laufzeit wechseln. So wird eine Production-App zu einem flexiblen Raum für Reviews und Iterationen statt zu einem starren Endpunkt. Das ist besonders nützlich für nicht-technische Stakeholder, die mit Production-Apps arbeiten, da sie Änderungen testen und direkt in der bereits installierten App Feedback geben können.
Update-Channels verstehen
Update-Channels sind der Weg, wie Capgo Updates gezielt an bestimmte Builds ausspielt. Jeder Build ist einem Channel zugeordnet, und dieser Channel bestimmt, welche Updates empfangen werden.
Du kannst zum Beispiel Updates in einen preview Channel pushen, ohne Nutzer in productionzu beeinflussen. Früher erforderte ein Channel-Wechsel die Installation eines anderen Native Build oder das manuelle Ändern der Device-Zuweisungen über das Dashboard.
Channels in Capgo ermöglichen es dir:
- Bestimmte Nutzergruppen mit unterschiedlichen Features anzusprechen
- A/B-Tests durch Zuweisung von Nutzern zu verschiedenen Channels durchzuführen
- Neue Features schrittweise auszurollen
- Beta-Testprogramme erstellen
- Produktionsfehler bei einzelnen Usern debuggen
Falls du mit Update-Channels nicht vertraut bist, die Capgo Channels Dokumentation erklärt diese im Detail.
Was ist Channel Surfing?
Channel Surfing erlaubt es einer installierten App, ohne Neuinstallation aus verschiedenen Update-Streams zu ziehen. Eine installierte App kann die Update-Channels zur Laufzeit wechseln und erhält weiterhin Updates vom neu gewählten Channel, bis die App deinstalliert oder auf einen anderen Channel gewechselt wird.
In der Praxis bedeutet das, dass ein Product Owner oder QA einen production Build zum Beispiel auf einen preview Channel schalten kann, um die neuesten Änderungen zu testen. Nach dem Testen wechselt man einfach wieder zurück zu production Es ist keine Neuinstallation oder ein separater Preview-Build nötig.
Technisch gesehen funktioniert Channel Surfing dadurch, dass die App dem Update-Client mitteilt, welchen Channel sie nutzen soll. Diese Auswahl kann zur Laufzeit geändert werden und bleibt aktiv, bis sie gelöscht oder ersetzt wird.
So implementierst du Channel Surfing
Bevor du Channel Surfing ausprobieren kannst, muss dein Projekt für Capgo Live Updates konfiguriert sein. Folge dazu dem Capgo Quickstart-Guide.
Für Channel Surfing musst du lediglich im Capgo Dashboard die Option „Allow devices to self associate“ für jeden Kanal aktivieren, zu dem du wechseln möchtest. Weitere code Änderungen oder Config-Anpassungen sind nicht nötig.
Im Kern wird Channel Surfing durch einen einzigen API Call gesteuert:
import { CapacitorUpdater } from '@capgo/capacitor-updater';
await CapacitorUpdater.setChannel({ channel: 'your-channel' });Dies legt den Kanal fest, der bei der Abfrage nach Updates über Capgo verwendet wird. Mehr über den setChannel API erfahren.
Sofortiges Channel-Switching (v5.34.0+)
Ab der Plugin-Version 5.34.0, 6.34.0, 7.34.0 oder 8.0.0 (abhängig von deiner Major-Version), setChannel() funktioniert es anders und deutlich schneller:
- Backend-Validierung (read-only): Eine Anfrage wird an das Capgo Backend gesendet, um zu prüfen, ob der Channel erlaubt ist
- Lokales Storage-Update: Wenn die Validierung erfolgreich ist, wird der Channel im lokalen Storage des Geräts gespeichert
- Sofortige Wirkung: Der nächste Update-Check nutzt sofort den neuen Channel
Früher: setChannel() wurde der Channel-Override in der Backend-Datenbank gespeichert (wie bei Dashboard- oder API Änderungen). Geräte mussten auf die Backend-Replikation warten (bis zu 2 Minuten), bevor der neue Channel erkannt wurde. Das neue Verhalten liest nur vom Backend (zur Validierung) und speichert lokal, wodurch Channel-Wechsel sofort erfolgen.
Kompletter Channel-Switching-Flow
Für eine bessere User Experience möchte man meist mehr tun, als nur den Channel zu wechseln und auf den nächsten App-Restart zu warten. Ein gängiger Ansatz ist, sofort nach Updates zu suchen, diese bei Verfügbarkeit herunterzuladen und die App neu zu laden, damit der User direkt auf dem Update des gewählten Channels landet.
Ein typischer Flow sieht so aus:
- Channel ändern (
setChannel) - Auf Update prüfen (
getLatest) - Update abrufen und anwenden (
download,setodernext) - App bei Bedarf neu laden (
reload)
Hier ist ein vollständiges Beispiel:
import { CapacitorUpdater } from '@capgo/capacitor-updater';
async function switchChannel(selectedChannel: string) {
try {
// 1. Set the updates channel (with optional auto-update trigger)
await CapacitorUpdater.setChannel({
channel: selectedChannel,
triggerAutoUpdate: true // Immediately check for updates
});
console.log(`Switched to channel: ${selectedChannel}`);
// If you want more control, handle the update manually:
// const latest = await CapacitorUpdater.getLatest();
// if (latest.url) {
// const bundle = await CapacitorUpdater.download({
// url: latest.url,
// version: latest.version
// });
// await CapacitorUpdater.set({ id: bundle.id });
// }
} catch (error) {
console.error('Failed to switch channel:', error);
}
}
// Switch to the beta channel
switchChannel('beta');Wie du diesen Flow strukturierst, liegt ganz bei dir. Du kannst diese Schritte auf mehrere Interaktionen aufteilen oder alle auf einmal ausführen. Unabhängig von der Struktur musst du Fehlerbehandlung einplanen. Netzwerkprobleme oder ein ungültiger Channel können das Anwenden eines Updates verhindern.
Die einzige Voraussetzung: Self-Assignment aktivieren
Das ist der einzige Schritt, den du tun musst, um Channel-Switching zu ermöglichen. Bevor deine App zu einem Channel wechseln kann, der setChannel()nutzt, musst du Self-Assignment für diesen Channel im Capgo Dashboard aktivieren:
- Besuchen Sie die Channels Abschnitt in deinem Capgo Dashboard
- Klicke auf den Kanal, den du verwalten möchtest
- Aktivieren „Geräten erlauben, sich selbst zuzuordnen“
- Änderungen speichern
Das ist alles. Keine Config-Änderungen in deiner App nötig. Keine defaultChannel ...muss konfiguriert werden. Aktiviere einfach Self-Assignment für die Channels, zwischen denen Nutzer wechseln können.
Wenn diese Einstellung deaktiviert ist, schlägt jeder Versuch fehl, setChannel() mit diesem Kanal aufzurufen, und das channelPrivate Event wird gefeuert.
Verfügbare Kanäle auflisten
Du kannst die Liste der verfügbaren Channels für das Self-Assignment abrufen:
const { channels } = await CapacitorUpdater.listChannels();
console.log('Available channels:', channels.map(c => c.name));
// Use this to build a channel selector UIEs werden nur Channels zurückgegeben, bei denen das Self-Assignment aktiviert ist.
Den aktuellen Channel abrufen
Prüfe, welchem Channel das Gerät aktuell zugewiesen ist:
const { channel } = await CapacitorUpdater.getChannel();
console.log('Current channel:', channel);Zurück zum Default Channel
Um den Channel-Override zu entfernen und zum Standard zurückzukehren:
await CapacitorUpdater.unsetChannel({});Dadurch wird das Gerät von jedem spezifisch zugewiesenen Channel entkoppelt, sodass es auf den defaultChannel in deiner Config oder den Cloud-Default zurückfällt.
So testest du das Channel-Switching
Um das Channel-Switching live zu sehen, benötigst du einen Release Build – @capgo/capacitor-updater das API ist für Release Builds ausgelegt. In Debug-Builds lädt die App JavaScript meist von einem Development-Server, wodurch der normale Update-Flow umgangen wird.
Voraussetzungen
Die einzige Voraussetzung für Channel Surfing ist das Aktivieren von „Geräten erlauben, sich selbst zuzuordnen“ auf jedem Channel, zu dem ein Wechsel erlaubt werden soll. In deiner App sind keine Config-Änderungen nötig.
Einen Test-Build erstellen
Baue deine App wie gewohnt:
bun run build && npx cap syncErstelle dann deine Native Builds mit Xcode oder Android Studio oder nutze deine CI/CD-Pipeline. Die App startet auf dem Channel, der in deinem Capgo Dashboard als Cloud-Default gesetzt ist.
Updates auf verschiedene Channels veröffentlichen
Sobald die App installiert ist, veröffentliche Updates auf verschiedene Channels:
# Publish to preview channel
npx @capgo/cli@latest bundle upload --channel preview
# Publish to production channel
npx @capgo/cli@latest bundle upload --channel productionNavigiere von dort aus in der App zu deiner Channel-Surfing-UI und löse den Channel-Wechsel aus. Die App sollte das Update vom ausgewählten Channel abrufen und mit dem neuen Update neu laden.
Eine Channel-Switcher-UI bauen
Channel Surfing sollte meist nur einem begrenzten Nutzerkreis zugänglich sein, nicht allen App-Nutzern. Du könntest zum Beispiel einen Button nur für authentifizierte Mitarbeiter bereitstellen, der die App auf den Preview-Channel umschaltet.
Hier ist eine Beispiel-React-Komponente für einen Channel-Switcher:
import { useState, useEffect } from 'react';
import { CapacitorUpdater } from '@capgo/capacitor-updater';
export function ChannelSwitcher() {
const [currentChannel, setCurrentChannel] = useState<string>('');
const [availableChannels, setAvailableChannels] = useState<string[]>([]);
const [isLoading, setIsLoading] = useState(false);
useEffect(() => {
loadChannelInfo();
}, []);
async function loadChannelInfo() {
const { channel } = await CapacitorUpdater.getChannel();
setCurrentChannel(channel || 'default');
const { channels } = await CapacitorUpdater.listChannels();
setAvailableChannels(channels.map(c => c.name));
}
async function handleChannelSwitch(channel: string) {
setIsLoading(true);
try {
await CapacitorUpdater.setChannel({
channel,
triggerAutoUpdate: true
});
setCurrentChannel(channel);
// App will update in background or on next restart
} catch (error) {
console.error('Failed to switch channel:', error);
} finally {
setIsLoading(false);
}
}
return (
<div>
<p>Current channel: {currentChannel}</p>
<div>
{availableChannels.map(channel => (
<button
key={channel}
onClick={() => handleChannelSwitch(channel)}
disabled={isLoading || channel === currentChannel}
>
Switch to {channel}
</button>
))}
</div>
</div>
);
}OTA-Update Fallstricke
Keiner dieser Punkte bezieht sich speziell auf das Channel-Switching, aber sie werden meist schnell offensichtlich, sobald man beginnt, zur Laufzeit zwischen Channels zu wechseln.
Version-Mismatches zur Laufzeit
Updates in Capgo sind an native App-Versionen gebunden. Wenn die native Version eines Updates nicht mit der installierten App übereinstimmt, wird das Update nicht heruntergeladen oder angewendet. Beim Channel-Switching äußert sich das meist so, dass die App zwar den Channel wechselt, aber kein Update angewendet wird, obwohl eines für diesen Channel existiert.
Das bedeutet meist, dass das Update von einer anderen nativen App-Version veröffentlicht wurde. Stelle sicher, dass das Bundle deines Channels mit der auf dem Gerät installierten nativen Version kompatibel ist.
Updates entfernen oder rückgängig machen
Wenn eine App bereits ein Update für einen Channel heruntergeladen hat, entfernt das Löschen dieses Updates im Capgo Dashboard es nicht von den Geräten, die es bereits besitzen. Das Löschen stoppt lediglich zukünftige Downloads.
Der zuverlässigste Weg, ein fehlerhaftes Update rückgängig zu machen, ist das Veröffentlichen eines funktionierenden Updates auf demselben Channel. Dadurch wird ein neues Update ganz oben in der History des Channels erstellt, das Clients als neueste Version behandeln und stattdessen anwenden.
Capgo bietet zudem einen Rollback-Mechanismus, der Clients anweisen kann, ein vorheriges stabiles Update erneut anzuwenden oder auf das im Build eingebettete Update zurückzugreifen.
Überlegungen zur Datenmigration
Durch das Wechseln der Channels ändert sich das JavaScript-Bundle, das die App ausführt. Wenn deine App auf Migrationen oder Datenstrukturen angewiesen ist, die nicht channelübergreifend kompatibel sind, kann das Hin- und Herwechseln Probleme verursachen.
Wenn beispielsweise ein Beta-Update eine Datenbank-Migration durchführt, erkennt die Production-Version das neue Schema eventuell nicht. Entwickler sollten sicherstellen, dass Updates sicher zwischen den Channels wechselbar sind, oder das Wechseln bei Bedarf auf eine Richtung beschränken.
Warum Channel-Surfing die mobile Iteration verbessert
Channel-Surfing ist besonders nützlich, wenn du Änderungen schnell in einer Production-Umgebung überprüfen musst.
Schnelle Validierung
Stell dir einen dringenden Bugfix vor, der vor dem breiten Rollout validiert werden muss. Mit Channel-Surfing kann die Änderung auf eine kleine Gruppe ausgewählter Nutzer isoliert werden, die sie prüfen können, bevor sie in Production geht.
Stakeholder-Review
Ein Product Owner oder QA kann den installierten Production-Build auf einen anderen Update-Channel umschalten, den Fix oder das Feature verifizieren und dann nach Abschluss wieder zurückwechseln.
Effizientes Testen
Dies erleichtert es, nicht-technische Stakeholder in den Review- und Entscheidungsprozess einzubinden und den Workflow flüssig zu halten. Ein einziger Production-Build wird so zu einem flexiblen Tool für Tests, Feedback und Validierung.
Anwendungsfälle
- QA-Testing: QA-Teams können zwischen Feature-Branches wechseln
- Beta-Programme: Nutzer wählen den Beta-Channel für Early Access
- Stakeholder-Review: Product Owner prüfen Änderungen vor dem Release
- A/B-Testing: Nutzer für Experimente verschiedenen Channels zuweisen
- Debugging: Spezielle Nutzer für die Fehlerdiagnose in einen Debug-Channel schieben
Vergleich: Methoden zum Channel-Wechsel
| Methode | Effektzeit | Speicherort | Anwendungsfall |
|---|---|---|---|
setChannel() vom Plugin |
Sofort | Nur Gerät (lokal) | In-App Channel-Wechsel durch User |
| Dashboard Device Override | Bis zu 2 Min. | Backend-Datenbank | Admin-gesteuerte Änderungen für Geräte |
| API Channel-Zuweisung | Bis zu 2 Min. | Backend-Datenbank | Automatisierte Backend-Integrationen |
Für die beste User Experience beim Bau von Channel-Switching-UIs nutze immer die setChannel() method.
Best Practices
- Zugriff einschränken: Channel Surfing ist meist für den internen Gebrauch – nicht für alle User freigeben
- Fehler behandeln: Fehler beim Channel-Wechsel immer sauber abfangen
- Kompatibilität prüfen: Sicherstellen, dass Updates auf verschiedenen Channels mit der installierten Native Build Version kompatibel sind
- Channels dokumentieren: Eine klare Dokumentation darüber führen, wofür welcher Channel gedacht ist
- Nutzung überwachen: Tracking, welche Geräte auf welchen Channels sind (für das Debugging)
Ressourcen
Fazit
Channel Surfing verändert die Art und Weise, wie du deine Capacitor App iterierst. Statt Production-Builds als starre Endpunkte zu betrachten, werden sie zu flexiblen Tools für Tests, Validierung und schnelle Iterationen.
Durch das instant Channel Switching in den neuesten Plugin-Versionen läuft alles nahtlos ab – User können den Channel wechseln und erhalten sofort Updates vom neuen Channel, ohne Wartezeit.
Egal, ob du Bugfixes mit Stakeholdern validierst, Beta-Programme ausführst oder Probleme mit spezifischen Usern debuggst: Channel Surfing gibt dir die Flexibilität, das richtige Update zur richtigen Zeit an den richtigen User zu liefern.
Weiter geht's mit Channel Surfing für Capgo: So wechselst du Update-Channels zur Laufzeit
Wenn Sie ... verwenden Channel Surfing für Capgo: So wechselst du Update-Channels zur Laufzeit nutzt, um das Channel-Routing und Staged Rollouts zu planen, verbinde es mit Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Channels für die Implementierungsdetails in Channels, Beta-Testing-Lösung für den Produkt-Workflow in der Beta-Testing-Lösung, und Version-Targeting-Lösung für den Produkt-Workflow in der Version-Targeting-Lösung.
