Fix: Capgo Default Channel aktualisiert keine Geräte

Änderung des Cloud-Defaults in Capgo leitet brandneue Geräte sofort um. Bestehende Installationen können auf ihrem alten Channel bleiben, bis sie sich erneut melden – das erklärt viele Fälle, in denen der Capgo-Cloud-Default-Channel Geräte nicht aktualisiert.

Arbeite die Prüfungen nacheinander ab. Bestätige zuerst die Gerätezuordnung, dann prüfe den App-Build, den Sync-Status, die Rollout-Regeln, die Logs und die Rollback-Einstellungen.

Inhaltsverzeichnis

• Schritt 1: Bestätigen, dass das Gerät dem Default Channel zugewiesen ist
• Schritt 2: App, Native Runtime und Update-Kompatibilität prüfen
• Schritt 3: Prüfen, ob das Deployment den Default Channel wirklich erreicht hat
• Schritt 4: Sync erzwingen und Device-Logs prüfen
• Schritt 5: Rollout-Regeln, Version Gates und Auto-Rollback prüfen
• Schritt 6: Mit Echtzeit-Analytics den genauen Fehlerpunkt finden
• Schritt 7: Verhindern, dass der Default Channel veraltet
• FAQ
• Fazit

Schritt 1: Bestätigen, dass das Gerät dem Default Channel zugewiesen ist

Ziel ist herauszufinden, welche Regel aktuell den Channel des Geräts bestimmt. Ein Cloud Default greift nur, wenn das Gerät nicht bereits durch eine stärkere Zuweisung belegt ist.

Öffne das Capgo Dashboard und sieh dir das betroffene Gerät an. Prüfe den aktuellen Channel, die App ID, die Version und den Zeitpunkt des letzten Check-ins. Vergleiche diese Werte mit einem Gerät, das das erwartete Update erhalten hat. Dieser Vergleich macht das Problem oft schnell sichtbar.

Die Channel-Auswahl folgt einer festen Reihenfolge. Ein forced Channel hat oberste Priorität. Als Nächstes kommt ein Dashboard- oder API Device Override. Danach ein lokaler Channel, den die App setzt. Anschließend greifen die Capgo ChecksdefaultChannelin der nativen App-Konfiguration. Der Cloud Default dient als Fallback.

Diese Reihenfolge bedeutet, dass ein Gerät einen geänderten Cloud Default ignorieren kann, ohne dass im Dashboard ein Fehler auftritt. Ein Test-Build kann zum Beispiel noch einen lokalen Channel aus einem früheren Test haben. Die App nutzt diesen lokalen Wert so lange, bis du ihn löschst.

Nutze das Capgo Updater-Debugging-Guide wenn der aufgelöste Channel leer oder unerwartet ist. Das deckt den Fall ab, in dem die App keinen nutzbaren Default hat und das Gerät keinen Override besitzt.

Prüfe als Nächstes deine Capacitor Konfiguration. Ein typisches Setup enthält etwa einen Channel wie diesen:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

Das Feld ist optional. Wenn du es weglässt, kann das Gerät den Cloud Default erben. Das funktioniert gut für Production-Builds, weil das Channel-Routing in der Capgo Cloud bleibt. Wenn du es angibst, achte darauf, dass der Wert mit dem Channel übereinstimmt, auf den du tatsächlich deployst.

Suche nun in der App code nach lokalen Overrides. Ein Aufruf vonsetChannel()ändert den lokalen Cache. Das erstellt keinen Backend Device Override. Das Dashboard zeigt daher eventuell keinen Override an, obwohl die App weiterhin den lokalen Channel nutzt.

Lösche diesen lokalen Wert, wenn das Gerät zum normalen Routing zurückkehren soll. Nutze die Plugin-Methode, die die Channel-Zuweisung des Geräts entfernt, oder entferne den code, der den Channel setzt, und installiere die App für einen sauberen Test neu.

Das Wichtigste in Kürze: Ein geänderter Cloud Default kann eine stärkere Device-, App- oder lokale Channel-Zuweisung nicht ersetzen.

Schritt 2: App, Native Runtime und Update-Kompatibilität prüfen

Ziel ist der Nachweis, dass die installierte App das von dir hochgeladene Bundle akzeptieren kann. Ein korrekter Channel kann trotzdem kein Update an eine inkompatible native Runtime ausliefern.

Beginnen Sie mit der App-ID. Die auf dem Gerät installierte App muss dieselbe App-Identität verwenden wie das Projekt, in dem Sie das Bundle hochgeladen haben. Eine Abweichung kann wie ein Channel-Problem aussehen, da das Gerät die falsche Capgo-App prüft.

Vergleichen Sie dann die native Runtime-Version mit den Kompatibilitätsregeln des Bundles. Capgo Live Updates können JavaScript, CSS und Web-Assets ändern. Sie können jedoch keine native Plugin hinzufügen oder native Projekt-code nach dem App-Release ändern. Native Änderungen erfordern weiterhin einen neuen Store-Build.

Betrachten Sie die native Runtime als den Rahmen um das Web-code. Wenn das neue Bundle eine native API erwartet, die die installierte App nicht hat, sollte Capgo es nicht anwenden. Erstellen und laden Sie eine kompatible native Version hoch, bevor Sie dieses Bundle testen.

Prüfen Sie die Version und Plattform der installierten App. Testen Sie ein Android-Bundle zuerst auf Android. Testen Sie ein iOS-Bundle auf iOS. Stellen Sie außerdem sicher, dass das Bundle die richtige App-Version anspricht, wenn Ihr Channel Version Gates verwendet.

Nach dem ÄnderndefaultChannel, führen Sie den Sync-Befehl aus dem Projektstammverzeichnis aus:

npx cap sync

Dieser Schritt kopiert die aktualisierte Konfiguration in die nativen Projekte. Das Bearbeiten voncapacitor.configohne Synchronisierung lässt die native App auf ihrer alten Channel-Einstellung. Ein frischer Build aus diesem veralteten nativen Projekt wird dasselbe Ergebnis reproduzieren.

Für einen sauberen Test baue die App nach dem Sync neu. Verlasse dich nicht auf eine alte Binary auf deinem Handy. Deinstalliere sie, wenn du den gecachten lokalen Channel-Status entfernen musst, installiere dann den neuen Build und prüfe den Channel erneut.

Der Capgo Dokumentation zum Update-Verhalten erklärt, wann der Updater nach einem Bundle sucht. Nutze dieses Timing beim Testen. Starte die App oder bringe sie wieder in den Vordergrund und lass den Check zu Ende laufen, bevor du entscheidest, dass das Update fehlgeschlagen ist.

Prüfe auch das Native-Version-Gate des Bundles. Ein Bundle kann im richtigen Channel liegen und trotzdem nicht verfügbar sein, weil seine minimale App-Version nicht zur App-Version auf dem Gerät passt. Schau dir die Release-Details im Dashboard an, statt anzunehmen, dass der neueste Upload für jede Installation gilt.

Wenn die App diese Checks besteht, hast du den Fehler bereits eingegrenzt. Die nächste Frage ist, ob das Release den Ziel-Channel überhaupt erreicht hat.

Schritt 3: Prüfen, ob das Deployment den Default Channel wirklich erreicht hat

Ziel ist zu bestätigen, dass das Bundle in dem Channel existiert, den das Gerät auflöst. Ein Bundle in einen Channel hochzuladen, macht es nicht in jedem Channel verfügbar.

Öffne den Channel in der Capgo Cloud. Prüfe das aktive Bundle, seine Version und den Deployment-Status. Vergleiche den Channel-Namen mit dem Wert, den die App zurückgibt. Achte auf kleine Unterschiede wieproductiongegenüberprod. Channel-Namen müssen exakt übereinstimmen.

Wenn du über CI/CD deployst, prüfe die Ausgabe des Befehls in dem Job, der das Bundle hochgeladen hat. Vergewissere dich, dass App-ID und Channel korrekt an CLI übergeben wurden. Eine Pipeline kann erfolgreich hochladen und dabei versehentlich einen Staging-Channel ansteuern.

Prüfe als Nächstes den Status des Bundles. Ein Draft oder ein inaktives Release ist im Dashboard zwar sichtbar, aber für Devices nicht verfügbar. Falls der Channel ein Staged Rollout nutzt, erfüllt das betroffene Device eventuell nicht die Rollout-Regel.

Nutze ein bekanntes Test-Device mit einer klaren Rolle. Pinne zum Beispiel ein Device auf einen Test-Channel und lass ein anderes auf dem Cloud Default. Lade eine harmlose Änderung hoch und vergleiche die Check-in-Einträge. So eliminierst du das Raten beim Testen.

Die Live-OTA-Engine von Capgo ist für Änderungen in der Web-Layer ausgelegt. Sie kann ein JavaScript-Bundle, CSS oder ein Asset-Update ausliefern, ohne auf ein neues Store-Review zu warten. Diese Geschwindigkeit hängt davon ab, dass das Release im exakten Channel aktiv ist, den das Device abfragt.

Falls du den Cloud Default gerade erst geändert hast, beachte das Timing der Devices. Neuinstallationen nutzen den neuen Pfad sofort. Bestehende Devices wechseln meist erst beim nächsten Update-Check. Das Schließen und erneute Öffnen der App kann diesen Check auslösen, kann aber einen gepinnten Channel nicht überschreiben.

Prüfe jetzt das Ergebnis direkt in der App. RufegetChannel()auf, nachdem der Updater gestartet ist. Logge den zurückgegebenen Channel zusammen mit der App-Version und der Bundle-Version. Das ist hilfreicher, als nur das Dashboard zu prüfen, denn es zeigt, wovon das Device ausgeht.

Rechne mit einer Verzögerung, wenn die App nur beim Start oder beim Wechsel in den Vordergrund prüft. Teste nicht mit einem Screen, der den Updater nie startet. Setze den Check für einen kurzen Test-Build in einen bekannten Startup-Pfad und entferne zusätzliches Logging vor dem Release.

Wenn der zurückgegebene Channel stimmt, aber kein Bundle ankommt, gehe zu den Kompatibilitäts- und Rollout-Regeln über. Wenn der Channel falsch ist, gehe zurück zu Schritt 1 und lösche die Zuweisung, die Vorrang vor dem Cloud Default hat.

Schritt 4: Sync erzwingen und Device-Logs prüfen

Ziel ist es, einen veralteten lokalen Zustand von einem serverseitigen Delivery-Problem zu unterscheiden. Ein neuer Check-in liefert neue Hinweise.

Stelle zuerst sicher, dass das Gerät Netzwerkzugriff hat. Eine erfolgreiche App-Session beweist nicht, dass der Updater seinen Endpoint erreichen kann. Firmenfilter, VPN-Regeln, Captive Portals oder eine abgelaufene Session können die Update-Anfrage blockieren.

Bringe die App als Nächstes in den Vordergrund. Warte, bis der Updater-Check abgeschlossen ist. Falls deine App ein Update-Status-Event bereitstellt, logge dieses Event zusammen mit dem aktuellen Channel. Logge nicht nur „update started“. Du musst wissen, ob die App ein Bundle gefunden, heruntergeladen, verifiziert, installiert oder abgelehnt hat.

Nutze die Device-Logs von Capgo, um die erste fehlgeschlagene Stufe zu finden. Der erste Fehler ist meist hilfreicher als die abschließende „update failed“-Meldung. Ein fehlender Channel deutet auf das Routing hin. Eine Ablehnung wegen Inkompatibilität weist auf die native Runtime oder das Version-Gate hin. Ein Download-Fehler deutet auf den Netzwerkzugriff oder die Bundle-Anfrage hin.

Eine Neuinstallation ist ein nützlicher Test, verändert aber die Beweislage. Sie kann den lokalen Channel-Status löschen. Führe sie erst durch, nachdem du den aktuellen Channel und Logs erfasst hast, nicht vorher.

Für eine wiederholbare Prüfung, notiere diese Werte in einer Log-Zeile:

• App-ID und native App-Version
• Aufgelöster Channel ausgetChannel()
• Zeitpunkt der letzten Updater-Prüfung
• Vom Server gefundene Bundle-Version
• Ergebnis der Installation oder Ablehnung

Diese kleine Aufzeichnung hilft, wenn das Gerät einem Tester gehört, der das Problem nicht auf Abruf reproduzieren kann. Sie gibt deinem CI-Team auch ein klares Signal für automatisierte Smoke-Tests.

Nutze das offizielle Capgo Capacitor Updater-Quellcode-Repository, wenn du das Plugin-API-Verhalten untersuchen musst. Achte insbesondere auf den Unterschied zwischen einer lokalen Channel-Änderung und einer Gerätezuweisung im Dashboard.

Pro-Tipp: Erfasse den aufgelösten Channel, bevor du ihn löschst. Andernfalls behebst du möglicherweise den Status und verlierst den Hinweis, der den Fehler erklärt hat.

Schritt 5: Rollout-Regeln, Version Gates und Auto-Rollback prüfen

Ziel ist es, zu prüfen, ob Capgo das Bundle absichtlich zurückgehalten oder zurückgesetzt hat. Ein fehlendes Update ist manchmal eine Sicherheitsregel, die wie vorgesehen funktioniert.

Öffnen Sie die Channel-Einstellungen und prüfen Sie alle Regeln, die an das Release gebunden sind. Achten Sie auf Mindest-App-Versionen, Rollout-Prozentsätze, Gerätefilter und Bedingungen, die mit dem Release verknüpft sind. Ein Gerät außerhalb der Regel bleibt bei seinem aktuellen Bundle, selbst wenn der Channel korrekt ist.

Prüfen Sie auch das Versionsformat. Capgo verwendet semantische Versionierung, um Releases zu vergleichen. Ein Versions-Gate, das für Menschen korrekt aussieht, kann sich anders verhalten, wenn App oder Bundle ein unerwartetes Format verwenden. Halten Sie das Format über native Builds und OTA-Releases hinweg konsistent.

Prüfen Sie dann das Rollback-Verhalten. Ein automatisches Rollback kann ein Gerät nach einem fehlgeschlagenen Health-Check zu einem früheren Bundle zurückversetzen. Das Dashboard kann das ältere aktive code anzeigen, während das erwartete Release vorhanden, aber nicht verfügbar ist.

Löschen Sie ein verdächtiges Bundle nicht, bevor Sie seine Events geprüft haben. Die Löschung entfernt nützliche Beweise. Notieren Sie zuerst die Bundle-Version, den Channel, den Rollout-Status und den Rollback-Grund. Entscheiden Sie dann, ob Sie das Release pausieren oder eine bekannte gute Version veröffentlichen.

Verwenden Sie einen gestuften Channel für riskante Änderungen. Senden Sie das Bundle zuerst an eine kleine Testgruppe. Beobachten Sie Adoptions- und Fehler-Signale. Sobald das Release wie erwartet funktioniert, erweitern Sie den Rollout. So verhindert man, dass eine fehlerhafte Web-Layer-Änderung gleichzeitig auf jedes aktive Gerät trifft.

Ein Rollback repariert nur code, die OTA ändern kann. Wenn der Fehler von einem fehlenden nativen Plugin oder einer inkompatiblen nativen API stammt, brauchst du einen neuen Store-Build. Das Senden eines älteren JavaScript-Bundles fügt das native Element nicht hinzu, das der App fehlt.

Wenn du eine Regel inspizierst, stell dir drei Fragen:

• Erfüllt dieses Gerät die App-Versionsbedingung?
• Liegt das Gerät in der Rollout-Gruppe?
• Hat ein Health Check oder eine manuelle Aktion es zu einem älteren Bundle zurückgesetzt?

Capgo ist hier nützlich, weil dasselbe Channel-Modell einen gestuften Release tragen, einen Rollback unterstützen und Update-Aktivitäten in einem Workflow anzeigen kann. Halte den Regelsatz klein. Eine kurze Policy ist leichter zu auditieren als ein Stapel von Ausnahmen, die während eines Incidents erstellt wurden.

Wenn du API-basierte Checks brauchst, die Capgo öffentliche API Dokumentation beschreibt Ressourcen für Geräte, Channels und Bundles. Verwende sie, um die Server-Ansicht mit dem zu vergleichen, was die App meldet. Dieser Vergleich kann einen veralteten Dashboard-Filter oder eine durch Automatisierung erstellte Gerätezuweisung aufdecken.

Ein Rollback ist ein Guardrail, kein Ersatz für Tests. Halte in jedem Produktions-Channel ein bekanntes, funktionierendes Bundle bereit.

Schritt 6: Mit Echtzeit-Analytics den genauen Fehlerpunkt finden

Das Ziel ist es, „nicht aktualisiert“ nicht mehr als einen einzigen Fehler zu behandeln. Analytics kann zeigen, ob das Gerät nie gecheckt hat, kein qualifiziertes Bundle gefunden hat, beim Download fehlgeschlagen ist oder später zurückgerollt wurde.

Beginnen Sie mit der betroffenen Gerätegruppe. Filtern Sie nach App-Version, Plattform, Channel und Bundle-Version. Suchen Sie nach einem Muster. Wenn nur ein alter App-Build fehlschlägt, liegt das Problem möglicherweise an einer nativen Kompatibilitätsprüfung. Wenn jedes Gerät in einem Channel fehlschlägt, prüfen Sie den Channel oder die Deployment.

Vergleichen Sie die Adoption über die Zeit. Eine flache Linie nach dem Release deutet auf Routing- oder Eligibility-Probleme hin. Ein Anstieg, gefolgt von einem Abfall, deutet auf Installationsfehler oder Rollbacks hin. Ein langsamer Anstieg bedeutet möglicherweise einfach, dass die Geräte die App noch nicht geöffnet haben.

Verwenden Sie Zeitstempel sorgfältig. Die Ereigniszeit im Dashboard kann von der lokalen Zeit des Users abweichen. Ordnen Sie das Update-Ereignis dem letzten Check-in des Geräts zu. Das hilft, wenn ein Tester sagt, das Update sei fehlgeschlagen, bevor die App tatsächlich gecheckt hatte.

Analytics hilft Ihnen auch, eine Channel-Änderung sicher zu testen. Ändern Sie nur eine Variable auf einmal. Halten Sie das Bundle konstant, während Sie das Routing testen. Halten Sie dann das Routing konstant, während Sie ein neues Bundle testen. Wenn Sie beide ändern, kann die Datenquelle nicht zeigen, welche Änderung das Problem gelöst hat.

Für einen Incident speichern Sie einen kleinen Evidenzsatz:

• Die Geräte-ID oder das interne Test-Label
• Aufgelöster Channel
• Native App-Version
• Erwartetes Bundle und installiertes Bundle
• Zeit des letzten Check-ins
• Rollback- oder Ablehnungsereignis

Die Echtzeit-Ansicht von Capgo ist am nützlichsten, wenn Ihr Release-Prozess Updates über CI/CD sendet. Ein Deployment-Job kann ein Bundle hochladen, während ein Monitoring-Schritt prüft, ob Testgeräte den vorgesehenen Channel und das Bundle melden. So wird eine manuelle Beschwerde zu einem Release-Gate.

Verknüpfen Sie Analytics-Daten mit Release-Records. Tragen Sie die Commit- oder Build-Referenz in Ihre Deployment-Notizen ein. Wenn zwei Bundles ähnliche Versionslabels haben, zeigt die Build-Referenz, welches code tatsächlich aktualisiert wurde.

Wenn nur bestehende Geräte nach einer Cloud-Default-Änderung fehlschlagen, warten Sie auf deren nächsten Check-in, bevor Sie weitere Einstellungen ändern. Eine neue Installation dient als nützliche Kontrolle. Sie zeigt, ob der Default-Pfad für Geräte ohne alten lokalen Zustand funktioniert.

Schritt 7: Verhindern, dass der Default Channel veraltet

Das Ziel ist es, Channel Drift sichtbar zu machen, bevor er Nutzer beeinträchtigt. Eine kleine Release-Checkliste kann die meisten Wiederholungsfälle verhindern.

Wähle ein Routing-Modell für jede App-Umgebung. Für die Produktion kannst du den Channel weglassendefaultChannelund Capgo Cloud den Default steuern lassen. Für einen Test-Build kannst du einen expliziten Channel setzen. Gefährlich wird es bei einer Mischung aus alten lokalen Overrides, veralteter Native Config und einem neuen Cloud Default, den niemand prüft.

Fügenpx cap syncnach Konfigurationsänderungen in den Build-Pfad ein. Lass den Build fehlschlagen, wenn der Sync-Schritt scheitert. Der Befehl ist simpel, aber das Überspringen kann den Channel von gestern fest in die heutige native Binary einbrennen.

Füge nach dem Deployment einen Smoke Test hinzu. Das Testgerät sollte die App starten,getChannel()aufrufen, das erwartete Bundle prüfen und das Ergebnis protokollieren. Die Verifizierung ist oft der fehlende Schritt in OTA-Workflows. Ein Upload allein beweist kaum etwas.

Halte den lokalen Channel code hinter einem klaren Feature-Flag. Wenn ein Test-Helper ihn aufruft,setChannel()stelle sicher, dass Production-Builds ihn nicht versehentlich enthalten. Bedenke, dass der lokale Cache möglicherweise nicht als Dashboard-Override auftaucht; deshalb kann die UI nicht jedes Problem erkennen.

Nutze eine Release-Checkliste wie diese:

1. Bestätige die App ID und die native Version.
2. Wähle den Ziel-Channel aus.
3. Lade das Bundle in diesen Channel hoch.
4. Bestätige, dass das Bundle aktiv ist.
5. Führe den Smoke-Test auf dem Gerät durch.
6. Prüfe den zurückgegebenen Channel mitgetChannel().
7. Beobachte die Adoption, bevor du den Rollout ausweitest.

Halte den Rollback-Schutz für Produktionsreleases aktiv. Ein häufiges Fehlermuster ist es, ohne klaren Channel oder Rollback-Plan zu deployen. Dadurch bleiben dem Team weniger sichere Wege, ein fehlerhaftes Bundle zu stoppen.

Capgo arbeitet mit einem Abo pro Organisation und bietet eine 14-tägige Testphase. Nutze die Testphase, um deinen Release-Flow mit echten App-Builds zu testen, nicht nur, um ein Dashboard zu inspizieren. Probiere eine gestufte Bereitstellung, einen Rollback-Test und einen automatisierten Channel-Check aus.

Sicherheit gehört auf dieselbe Checkliste. Schütze CI/CD-Tokens. Beschränke, wer den Cloud Default ändern kann. Halte Produktions-Deployment-Credentials aus lokalen Skripten heraus. Eine unbefugte Channel-Änderung kann wie ein veraltetes Gerät aussehen, bis du den Audit-Trail prüfst.

Für Teams, die häufig releasen, halte den Prozess einfach. Ein Befehl zum Deployen. Ein bekanntes Testgerät. Eine klare Channel-Regel. Tracken, übernehmen, zurückrollen.

Das Wichtigste in Kürze: Verhindere veraltete Routing-Pfade, indem du die Config synchronisierst, versteckte lokale Overrides vermeidest, den aufgelösten Channel testest und Rollbacks bereit hältst.

FAQ

Warum aktualisiert der Capgo Cloud Default Channel bestehende Geräte nicht?

Bestehende Geräte behalten ihren alten Channel möglicherweise bis zur nächsten Update-Prüfung. Ein lokaler Channel, ein Dashboard-Override oder eine erzwungene Zuordnung kann auch Vorrang vor dem Cloud Default haben. Bestätige den aufgelösten Channel des Geräts mitgetChannel(), entferne stärkere Zuordnungen und bringe die App in den Vordergrund.

Ändert das Ändern des Capgo Cloud Default jeden installierten App?

Nein, eine Änderung des Cloud-Default überschreibt nicht sofort den Channel aller installierten Apps. Neue Geräte können den neuen Default sofort nutzen. Bestehende Installationen müssen sich erst einchecken, bevor sie wechseln können, und wechseln auch dann nicht, wenn eine stärkere Channel-Regel oder eine lokale Override gilt.

Was bewirkt npx cap sync bei einer Capgo-Channel-Änderung?

npx cap synckopiert die aktualisierte Capacitor-Konfiguration in die nativen Projekte. Wenn dudefaultChanneländerst, aber den Sync überspringst, kann der nächste native Build immer noch die alte Channel-Einstellung enthalten. Führe den Befehl aus dem Projektstammordner aus, baue dann eine frische Test-Binary und installiere sie.

Erstellt setChannel eine Device-Override in Capgo?

Nein,setChannel()ändert den lokal von der App gespeicherten Channel. Es wird keine Backend-Device-Override erstellt, daher zeigt das Capgo-Dashboard das Gerät möglicherweise nicht als übersteuert an. Lösche die lokale Zuweisung, wenn das Gerät zur Standard-Weiterleitung zurückkehren soll, und verifiziere das Ergebnis mitgetChannel().

Kann Capgo native code über ein OTA-Bundle aktualisieren?

Nein, Capgo OTA-Updates gelten nur für Web-Layer-code wie JavaScript, CSS und Assets. Ein natives Plugin, eine Berechtigung oder eine native API Änderung erfordert einen neuen Store-Build. Wenn das Bundle native code erwartet, die der installierten App fehlen, kann das Update abgelehnt werden, selbst wenn der Channel korrekt ist.

Fazit

Starte mit dem aufgelösten Channel, nicht mit dem Dashboard-Standard. Prüfe die Zuweisungen, führenpx cap syncaus, prüfe das Bundle gegen die native Runtime und sieh dir die Device-Logs an, bevor du Rollout-Regeln änderst. Füge dann einen kleinen Post-Deploy-Test in Capgo hinzu, dergetChannel()aufruft und das erwartete Bundle bestätigt.