FAQ

Falls deine Fragen hier nicht beantwortet werden, frag einfach! Du kannst entweder ein Issue eröffnen oder auf Discord nachfragen.

Was ist „code push“?

Code push, auch bekannt als „over-the-air updates“ (OTA), ist ein Cloud-Service, der es Capacitor Entwicklern ermöglicht, Updates für ihre Apps in der Produktion bereitzustellen. Capgo funktioniert aktuell auf Android, iOS und Electron.

„Code Push“ ist eine Anlehnung an den Namen eines Deployment-Features, das in der React Native Community von Microsoft und Expo, von denen keines Capacitor unterstützt.

Müssen Capgo CLI Majors mit meinem Plugin oder der Capacitor Version übereinstimmen?

Nein. Nutze immer die neueste Capgo CLI (npx @capgo/cli@latest). Die CLI und Capgo Console folgen ihrer eigenen Versionierung und bleiben mit jeder unterstützten Major-Version des Updater-Plugins kompatibel. Capgo Plugins folgen Capacitor Majors; siehe Capgo Versionierung für LTS-Tags wie @lts-v7.

Was ist der Unterschied zwischen einem Bundle und einem Release?

Wir verwenden den Begriff „Release“, um das Vorbereiten einer Binärdatei für die App Stores zu beschreiben. Um später ein Bundle zu generieren, muss Capgo die exakte Binärdatei kennen, die an die App Stores ausgeliefert wurde.

Wir verwenden den Begriff „Bundle“ für einen Patch, der auf ein Release angewendet werden kann, um es auf neue code zu aktualisieren. Der npx @capgo/cli@latest bundle upload Der Befehl wird verwendet, um ein Bundle aus deinem neuen lokalen code zu erstellen, das dann an deine Nutzer ausgeliefert wird.

Gibt es Einschränkungen bei den Dateipfaden für Delta-Updates?

Ja:

• Zero-Byte-Dateien: Die CLI Logs Ignoring empty file... und schließen leere Dateien aus den Delta-Files aus. Der Upload schlägt dabei nicht fehl, sodass eine leere Datei das resultierende Bundle ändern kann, ohne dein Deployment zu stoppen. Vermeide Zero-Byte-Dateien in Delta-Bundle-Pfaden.
• Pfade mit Leerzeichen: Delta-Uploads brechen frühzeitig mit einer klaren Fehlermeldung ab, wenn ein Bundle-Pfad ein Leerzeichen enthält. Benenne Dateien oder Verzeichnisse um, um Leerzeichen vor dem Upload eines Delta-Updates zu entfernen.

Siehe Delta-Updates für Setup-Details.

Wie sieht die Roadmap aus?

Unsere Project Boards sind ebenfalls öffentlich einsehbar unter: https://github.com/orgs/Cap-go/projects

Unser Team arbeitet auch öffentlich, sodass du jederzeit sehen kannst, woran wir gerade arbeiten. Gerne beantworten wir deine Fragen zu unserer Roadmap oder unseren Prioritäten über Github Issues oder Discord.

Kann ich Capgo im Team nutzen?

Ja! Alle Pläne unterstützen unbegrenzt viele Entwickler. Wir limitieren pro Organisation lediglich die App-Metriken (MAU, Speicher und Bandbreite).

Siehe Teams für weitere Informationen.

Speichert Capgo meinen Quell-code?

Nein. Die Capgo Server sehen niemals deinen Quell-code. Wenn du npx @capgo/cli@latest bundle upload ausführst, speichert Capgo eine Zip-Datei des minifizierten/kompilierten code – genau das code, das auch ein Browser erhält, nicht deinen Quell-code.

Für zusätzliche Sicherheit hast du zwei Optionen:

• Ende-zu-Ende-Verschlüsselung: Verschlüssele dein Bundle vor dem Upload, um es bei der Speicherung und Übertragung zu schützen und zu verhindern, dass Dritte ohne deinen Private Key gültige verschlüsselte Updates erstellen. Dies verhindert nicht das Reverse Engineering der ausgelieferten Web-Assets, da der Public Key in der App enthalten ist.
• Upload via externer URL: Speichere das Bundle auf deinem eigenen Server und gib Capgo lediglich den Download-Link mit der Option --external <url>

Siehe auch unsere Datenschutzerklärung: https://capgo.app/privacy

Sind Bundle-Dateien private Daten?

Nein. Bundle-Dateien sind öffentliche Web-Assets, die von deinen App-Nutzern heruntergeladen werden sollen. Jeder, der die Bundle-URL kennt, kann diese Dateien abrufen; Capgo weist Nutzer während des Setups und in der Dokumentation darauf hin.

Der Zugriff auf Bundle-Dateien gilt nicht als Data Breach. Speichere keine Secrets, Credentials, personenbezogenen Daten oder regulierte Daten in deinem App-Bundle. Für höchste Sicherheitsanforderungen solltest du End-to-End-Verschlüsselung nutzen, aber die ausgelieferten App code und Assets aus Sicht des Security-Reportings weiterhin als öffentlich behandeln.

Kann ich Capgo aus meinem CI-System nutzen?

Ja. Capgo ist explizit für die Nutzung in CI-Systemen gedacht. Wir haben einen Guide dazu veröffentlicht: Android- und Github Actions und iOS, sowie für GitLab. Andere CI-Systeme funktionieren ähnlich.

Bei Problemen mit GitHub oder über Discord kannst du dich jederzeit gerne melden.

Wie unterscheidet sich das von Firebase Remote Config oder Launch Darkly?

Code Push ermöglicht das Hinzufügen neuer code / Ersetzen von code auf dem Gerät. Firebase Remote Config und Launch Darkly sind Konfigurationssysteme. Sie erlauben es, die App-Konfiguration zu ändern, ohne eine neue Version ausrollen zu müssen. Sie sind nicht als Ersatz für code gedacht.

Wie groß ist der Dependency-Footprint dadurch?

Ich habe es vor Kurzem nicht gemessen, aber ich erwarte, dass die code Push-Library weniger als ein Megabyte zu Capacitor Apps hinzufügt. Wir wissen, wie wir das verkleinern können, sobald dies Priorität hat. Falls die Größe ein Blocker für dich ist, lass es uns bitte wissen!

Funktioniert Capgo auf dem iOS 18.4 Simulator?

Nein. Aufgrund eines Upstream-Issues, der den iOS 18.4 Simulator betrifft, läuft Capgo dort nicht zuverlässig. Bitte teste auf einem echten Gerät oder nutze eine andere iOS Simulator-Version.

Details findest du im React Native Issue: facebook/react-native#50510

Funktioniert code Push auch bei großen Anwendungen?

Ja. Es gibt kein Limit für die Größe der App, die mit einem code Push aktualisiert werden kann. Wie untenangegeben, kann Capgo jeden JS code in deiner App unabhängig von der Größe ändern.

Hinweis: Eine größere Dateigröße erschwert den Download der Updates für die Nutzer. Wir empfehlen, die App so klein wie möglich zu halten.

Wofür kann ich Capgo code Push nutzen?

We’ve seen a variety of uses, including:

• Notfall-Fixes für Production-Apps.
• Bugfixes für Nutzer, die noch ältere App-Versionen verwenden.
• Kontinuierliche Updates (z. B. jede Stunde).

Beachte, dass die meisten App Stores das Ausrollen von code verbieten, die das Verhalten der App signifikant ändern. Siehe dazu unten für weitere Informationen.

Was zählt als „MAU“ für Capgo?

Eine MAU ist ein Monthly Active Device. Ein eindeutiges Gerät, das Capgo innerhalb eines rollierenden 30-Tage-Zeitraums kontaktiert, zählt als eine MAU für diese native App-ID. Dasselbe physische Gerät, das mit zwei verschiedenen nativen App-IDs verwendet wird, zählt für jede App-ID einmal; es erfolgt keine Deduplizierung über die IDs hinweg.

Wenn sich Ihre Flavors nur in der Web-Layer oder im Update-Routing unterscheiden, verwenden Sie eine native App-ID mit Channels. Das hält die Flavors unter einer Capgo App und vereinfacht Releases. Verwenden Sie separate native App-IDs, wenn ein Flavor eine eigene Bundle-ID, Signing Identity, Entitlements oder einen eigenen Store-Eintrag benötigt.

Unter iOS, v7.25.0+ behält die zufällige, app-spezifische Device-ID durch normale Reinstalls via Keychain bei. Auf Android verwenden Sie v7.50.1+ (oder v5.50.1+ und v6.50.1+ auf diesen Release-Linien); die ID wird nur wiederhergestellt, wenn Android Backup/Restore die App-Einstellungen beibehält. Das Deaktivieren des Backups, das Ausschließen dieser Einstellungen oder das Löschen der App-Daten erzeugt eine neue Device-ID. Ein App-Update erzeugt keine neue Device-ID.

Deaktiviere für Test- und Development-Builds die Auslieferung an Development-Builds und Emulatoren auf Production-Channels. Das steuert die Auslieferung, nicht die MAU: Ein Gerät kann weiterhin gezählt werden, wenn es Capgo kontaktiert. Um es aus der Production-Nutzung herauszuhalten, deaktiviere Live Updates und rufe keine Capgo-Endpoints in Production auf. Siehe Native Builds ohne Live Updates testen für die genauen Einstellungen.

Wofür können wir Capgo code Push nicht verwenden?

Capgo kann keine nativen code wie Java, Kotlin, Objective-C, Swift, native Plugins oder native Konfigurationen ändern. Solche Änderungen erfordern ein neues natives App-Release. Infos zum Store-Review findest du hier: App Store und Google Play Richtlinien.

Kann ich Änderungen an capacitor.config.ts via Capgo aktualisieren?

Nein. Kurz gesagt: Capgo kann den generierten Web-Build-Ordner senden, inklusive HTML, CSS, JavaScript, Assets und reinen JavaScript-Package-Änderungen, die in diesem Output gebündelt sind. Änderungen an capacitor.config.tsder nativen Plugin-Konfiguration, nativen Package-Installs oder -Upgrades sowie allem, was das iOS- oder Android-Projekt über npx cap sync oder npx cap copy aktualisieren muss, erfordern ein natives App-Release.

Die Capacitor Konfigurationsdatei wird zur nativen Build-Zeit gelesen und in die native App-Binary kompiliert. Wenn du deine Capacitor Konfiguration ändern musst, musst du:

1. Aktualisieren capacitor.config.ts lokal
2. Native App neu bauen (npx cap sync gefolgt von einem Native Build)
3. Die neue Binary in den App Stores einreichen

Reicht Capgo die Apps für mich in die Stores ein?

Capgo Build kann ein vorbereitetes natives iOS- oder Android-Projekt kompilieren und signieren und das signierte Ergebnis bei konfiguriertem Setup an App Store Connect oder Google Play übermitteln. Du kannst deine bestehende CI für private Dependencies, Web Builds, Capacitor Sync und eigene native Vorbereitungen beibehalten; Capgo erhält das vorbereitete native Projekt für den Native Build Schritt.

Siehe Capgo Build und Referenz der Build-Konfiguration für Workflow- und Store-Submission-Optionen.

Was speichert Capgo auf der Festplatte und wo?

Der Capgo Updater (beim Build in deine App eingebunden) speichert das zuletzt heruntergeladene Bundle im einzigen Verzeichnis, in dem capacitor das Laden von code erlauben. Auf Android liegt es in /data/user/0/com.example.app/code_cache/capgo_updater obwohl die Basis dieses Pfads vom Android-System vorgegeben wird und sich zur Laufzeit dynamisch ändern kann. Auf iOS-Geräten liegen die Daten unter Library/Application Support/capgo.

Die Capgo CLI-Tools (z. B. npx @capgo/cli@latest bundle upload) werden auf der Festplatte in den npm Caches installiert; deine Logins liegen in deinem Home-Verzeichnis unter ~/.capgo.

Wie hängt das mit Capacitor Hot Reload zusammen?

Capacitor’s Hot Reload ist nur für die Entwicklung gedacht. Code Push ist für die Produktion.

Hot Reload ist ein Feature von Capacitor, mit dem du code während der Entwicklung direkt auf dem Gerät ändern kannst. Dafür muss die Capacitor App mit einem Proxy gebaut werden, um eine Verbindung zu deinem lokalen Rechner herzustellen.

Code push ist ein Feature, mit dem du code auf Geräten in der Production ändern kannst. Je nach Plattform nutzen wir dafür verschiedene Techniken.

Welche Arten von Änderungen unterstützt Capgo code push?

Capgo kann jeden JS code in deiner App ändern. Dazu gehören App-code und generierte code. Du kannst auch Abhängigkeiten in package.json aktualisieren, solange keine nativen code Änderungen erforderlich sind.

Wir planen derzeit nicht, native code (z. B. Java/Kotlin auf Android oder Objective-C/Swift auf iOS) zu unterstützen. Das Tool warnt dich, falls native code geändert wurden, da diese nicht im Bundle enthalten sind.

Wird Web unterstützt?

Code push ist für Web nicht nötig, da Web-Apps bereits so funktionieren. Wenn ein Nutzer eine Web-App öffnet, wird bei Bedarf die neueste Version vom Server geladen.

Falls du einen Use Case für code push im Web hast, lass es uns wissen!

Funktioniert das auf iOS, Android, Mac, Windows, Linux usw.?

Ja.

Bisher haben wir uns auf Android, iOS und Electron konzentriert, und code Push ist auf allen drei Plattformen produktionsreif.

Welche OS-Versionen unterstützt Capgo?

Capgo unterstützt dieselben Android-Versionen wie Capacitor.

Capacitor unterstützt aktuell Android API Level 22+ und iOS 13.0+: https://capacitorjs.com/docs/main/reference/support-policy

Welche Capacitor Versionen werden von Capgo unterstützt?

Capgo unterstützt derzeit nur aktuelle Stable Releases von Capacitor. Wir könnten auch ältere Capacitor Versionen unterstützen, haben aber bisher die notwendige Infrastruktur für die langfristige Wartung nicht aufgebaut. Wir planen, in Zukunft mehr Capacitor Versionen zu unterstützen, einschließlich spezieller Versionen für unsere Enterprise-Kunden. https://github.com/Cap-go/capgo/issues/1100

Capgo verfolgt Capacitor Stable Releases und aktualisiert diese meist innerhalb weniger Stunden nach Release. Unser System für diese Updates ist automatisiert und benötigt nur wenige Minuten. Vor dem Publishing auf unsere Server führen wir zusätzlich einen manuellen Verifizierungsschritt durch.

Wie wirkt sich das auf den Review-Prozess oder die Richtlinien des App/Play Stores aus?

Capgo liefert Änderungen nur an den Capacitor Web-Layer: HTML, CSS, JavaScript und Assets, die bereits in der WebView der App laufen. Es werden keine native Binaries, nativen Plugins, Permissions, Entitlements, Signings oder Store-Metadaten geändert.

Nutze ein natives Store Release für jede native Änderung und für wesentliche Änderungen, die den geprüften Zweck oder die Funktionalität der App beeinflussen könnten. Halte Live Updates innerhalb der App-Experience, die du eingereicht und den Nutzern gegenüber offengelegt hast.

Kann Capgo zu einer Ablehnung der Apple Remote code Execution führen?

Nein, das ist nicht möglich. Capgo installiert oder führt keine nativen code, dynamischen Bibliotheken, Frameworks oder Plugins aus und kann auch nicht aufrufen dlopen, dlsym, performSelector:, oder method_exchangeImplementations(). Es ersetzt lediglich JavaScript, HTML, CSS und statische Assets innerhalb des WebViews oder der JavaScriptCore-Engine, die bereits in der geprüften Binary enthalten sind.

Wenn der App Review Guideline 2.5.2 oder „Remote-code-Ausführung“ anführt, betrachte nicht Capgo als Ursache. Lies den Review-Hinweis und prüfe das native Projekt sowie andere SDKs auf das Laden von Executables oder die Nutzung privater API. Ein früherer Review-Hinweis zu Dynamic Linking im Capgo Splash-Screen Auto-Hide-Pfad war ein Bug in jenem nativen Plugin, nicht bei Live Updates, und dieser Link wurde entfernt.

Beeinflusst Apples Durchsetzung der Remote-code-Ausführung Capgo?

Nein. Capgo kann keine Ablehnung aufgrund von Remote-code-Ausführung verursachen. Siehe Kann Capgo zu einer Ablehnung der Apple-Remote-code führen?. Capgo ist für den interpretierten Web-Layer in Capacitor Apps konzipiert. Es installiert oder führt nach dem Review keine nativen code aus. Apple prüft jede App basierend auf ihren eigenen Fakten, und Capgo kann kein Ergebnis garantieren.

Apples App-Review-Richtlinie 2.5.2 besagt, dass Apps nicht „code herunterladen, installieren oder ausführen dürfen, was Funktionen oder die Funktionalität der App einführt oder ändert.“ Review-Teams berufen sich auf diese Regel sowie auf den Apple Developer Program License Agreement Abschnitt 3.3.1(B) bezüglich ausführbarer code, wenn sie Apps ablehnen, die Remote-Ressourcen nutzen, um das Verhalten nach der Freigabe zu ändern. Typische Beispiele sind dlopen, dlsym, performSelector:, oder Remote-Skripte, die auf private APIs zugreifen.

Dieselbe Lizenzvereinbarung erlaubt interpretierte code herunterzuladen, wenn es:

• den Hauptzweck der App nicht ändert,
• Signing, Sandboxing oder andere OS-Sicherheitsfeatures nicht umgeht, und
• keinen Store oder Marktplatz für andere Apps erstellt.

Abschnitt 3.3.1(C) schränkt die Bereitstellung, Freischaltung oder Aktivierung zusätzlicher Funktionen über Vertriebswege außerhalb des App Store, Custom App Distribution oder TestFlight ein, es sei denn, Apple hat vorab schriftlich zugestimmt oder die Aktivität ist gemäß Abschnitt 3.3.9(A) (In-App-Kauf API). Wie diese Klausel auf ein bestimmtes interpretiertes code OTA-Bundle angewendet wird, ist eine Rechtsfrage für Ihr Team und Ihren Rechtsbeistand.

Capgo ersetzt das JavaScript, HTML, CSS und die statischen Assets, die bereits in der WebView oder der JavaScriptCore-Engine Ihrer App laufen. Es liefert keine nativen Binärdateien, maschinellen code, dynamischen Bibliotheken oder Plugins. Richtlinie 4.7 (präzisiert in November 2025) gilt, wenn Ihre App HTML5- und JavaScript-Mini-Apps, Minispiele, Chatbots, Plug-ins oder ähnliche Software anbietet, die nicht in der Binärdatei eingebettet ist. Wenn Nutzer innerhalb Ihrer App mehrere verschiedene Software-Erlebnisse durchsuchen oder starten können, prüfen Sie die zusätzlichen 4.7-Anforderungen mit Ihrem Rechtsbeistand. Ein einzelnes Produkt, das sein eigenes, geprüftes Web-Bundle über Kanäle aktualisiert, ist ein anderes Nutzererlebnis, aber nur Apple entscheidet, ob Ihre Metadaten dieser Beschreibung entsprechen.

Veröffentlichen Sie native Funktionen, Berechtigungen, Entitlements und wesentliche Funktionsänderungen über ein normales App Store Binary. Nutzen Sie Capgo für Fixes und Verbesserungen auf der Web-Ebene, die innerhalb der eingereichten App bleiben. Siehe Apple Remote code Execution und Capgo für eine ausführlichere Compliance-Aufschlüsselung oder den Blog-Walkthrough für Guideline 2.5.2, ADPLA 3.3.1(B) und die Klarstellung zu Guideline 4.7 aus 2025.

Garantiert Capgo die Freigabe im App Store oder bei Google Play?

Nein. Apple und Google prüfen jede App und jedes Release nach den jeweiligen Gegebenheiten, und Capgo kann keine Garantie für eine individuelle Freigabe oder das Ergebnis des Reviews übernehmen. Ihr Team bleibt verantwortlich für die Inhalte der App, Offenlegungen, den Umfang der Updates und die Einhaltung der aktuellen Store-Richtlinien.

Für die Review- und Release-Planung lesen Sie am besten direkt die offiziellen Richtlinien: Apple App Store Review Guidelines und Google Play Richtlinie zu Geräte- und Netzwerkmissbrauch.

Kann ich Capgo in meinem Land nutzen?

Wir versuchen nicht, den Zugriff auf Capgo aus bestimmten Ländern einzuschränken.

Uns ist bewusst, dass in einigen Ländern Einschränkungen für den Zugriff auf bestimmte URLs bestehen. Capgo nutzt aktuell Cloudflare Cloud für das Hosting, einschließlich R2 Storage und Cloudflare Workers.

Folgende URLs werden von Capgo verwendet:

• https://api.capgo.app — verwendet von den npx @capgo/cli CLI-Tools zur Interaktion mit den Capgo Servern sowie dem Capgo Updater auf den Geräten der Nutzer, um nach Updates zu suchen.
• https://*.r2.cloudflarestorage.com — verwendet von den npx @capgo/cli CLI-Tool zum Upload und Download von Bundles

Wenn alle diese URLs in deinem Land erreichbar sind, sollte Capgo funktionieren.

Falls Ihre Region den Zugriff auf eine dieser URLs blockiert, lassen Sie es uns wissen. Wir finden gemeinsam eine Lösung, zum Beispiel über Proxy-Server.

Kann ich Capgo selbst hosten?

Ja. Enterprise unterstützt lizenzierte Self-Hosted Capgo Deployments, wenn Sie das Updater-Backend in Ihrer eigenen Infrastruktur betreiben müssen. Siehe Self-Hosted Updater für das Deployment-Modell und die Endpoints.

Benötigt code Push eine Internetverbindung?

Ja. Man könnte zwar einen Server betreiben, um Updates unabhängig vom öffentlichen Internet zu verteilen, aber eine Form von Netzwerkverbindung ist nötig, um die Updates auf die Geräte zu übertragen.

Wie wirkt sich fehlende Netzwerkverbindung auf Capgo aus?

Der Capgo Updater (der in deiner App enthalten ist, wenn du sie mit Capgo buildest) ist so konzipiert, dass er auch bei Netzwerkproblemen resilient bleibt.

Beim Standard-Updateverhalten benachrichtigt die App beim Start den Capgo Updater. Dieser startet einen separaten Thread, um eine Netzwerk-Anfrage an die Capgo Server zu senden und nach einem Update zu fragen. Wir nutzen bewusst einen separaten Thread, um andere Prozesse der App nicht zu blockieren. Falls die Anfrage fehlschlägt oder ein Timeout auftritt, versucht der Updater es beim nächsten App-Start einfach erneut.

Capgo CLI-Tools (z. B. npx @capgo/cli@latest bundle upload) benötigen eine Netzwerkverbindung. Wenn du Capgo nutzt, um deine App zu distribuieren, solltest du sicherstellen, dass dein CI-System eine Netzwerkverbindung hat.

Was passiert, wenn ein Nutzer lange Zeit kein Update macht und ein Update verpasst?

Unsere Implementierung sendet immer ein Update, das speziell auf das anfragende Gerät zugeschnitten ist, und aktualisiert den Nutzer stets auf die neueste verfügbare Version. Wenn ein Nutzer also eine Weile kein Update macht, „verpasst“ er die dazwischenliegenden Updates einfach.

Der Update-Server kann so angepasst werden, dass er je nach Bedarf Ihrer App entweder die nächste inkrementelle Version oder die aktuellste Version liefert. Lassen Sie uns wissen, falls alternative Update-Verhaltensweisen für Sie wichtig sind.

Wie hängt Capgo mit Capacitor zusammen?

Capgo ist ein Plugin für Capacitor, das code Push hinzufügt. Capgo ist kein Ersatz für Capacitor. Sie können weiterhin die Capacitor Tooling nutzen, die Sie bereits kennen und schätzen.

Wir verfolgen die jeweils aktuellste stabile Version von Capacitor und passen unser code Push-Plugin entsprechend an.

Wann erfolgen Updates?

Standardmäßig prüft der Capgo Updater beim App-Start auf Updates. Er läuft in einem Background-Thread und blockiert nicht den UI-Thread. Updates werden installiert, während der Nutzer die App verwendet, und beim nächsten App-Neustart angewendet.

Es ist auch möglich, den Capgo Updater manuell über das @capgo/capacitor-updater Package, mit dem Updates jederzeit ausgelöst werden können, auch per Push-Benachrichtigung.

Der Capgo Updater ist so konzipiert, dass die App ganz normal weiterläuft, wenn das Netzwerk nicht verfügbar ist oder der Server nicht erreichbar ist. Falls Sie jemals ein Update von unseren Servern löschen, läuft die App bei all Ihren Clients weiterhin einwandfrei.

Wir haben die Möglichkeit zum Rollback von Patches hinzugefügt. Der einfachste Weg ist, um Änderungen rückgängig zu machen, einfach ein vorheriges Bundle an Ihren Channel anzuhängen.

Muss ich meine app_id geheim halten?

Nein. Die app_id ist in Ihrer App enthalten und kann problemlos öffentlich sein. Sie können sie in die Versionsverwaltung einchecken (sogar öffentlich), ohne sich Sorgen machen zu müssen, dass jemand anderes darauf zugreift.

Jemand, der Ihre app_id hat, kann zwar die neueste Version Ihrer App von den Capgo Servern abrufen, kann aber keine Updates an Ihre App senden oder auf andere Aspekte Ihres Capgo Accounts zugreifen.

Welche Informationen werden an Capgo Server gesendet?

Die vollständige Dateninventur, das Endpoint-Verhalten und die Datenschutzkontrollen sind dokumentiert unter Compliance.

Setzen Sie statsUrl: '' um explizite Berichte über Updater-Statistiken zu deaktivieren. Sie können auch an statsUrl an einen Proxy oder Endpoint, den du kontrollierst; siehe Umgang mit Statistiken in Self-Hosted-Infrastrukturen. Update-Checks benötigen weiterhin eine app-spezifische Geräte-ID, damit Capgo das richtige Update auswählen und die monatlich aktiven Geräte messen kann.

Der Liste der Unterauftragsverarbeiter ist unsere aktuelle, öffentliche Referenz für Anbieter, Verarbeitungsorte, Transfermechanismen und die Änderungshistorie.

Kann ich Capgo für HIPAA-relevante Apps nutzen?

Ja, aber Ihr Compliance-Verantwortlicher muss das passende Deployment-Modell wählen. Capgo Cloud wird derzeit nicht als HIPAA-konformer, gehosteter Statistik-Prozessor angeboten. Standardmäßig sind die Updater-Daten gerätespezifisch und nicht mit einem bekannten App-Nutzer verknüpft – viele Teams nutzen dieses Modell erfolgreich.

Für strengere Anforderungen können Sie den Plugin-Traffic geolokalisieren, Statistiken deaktivieren, indem Sie statsUrl auf einen leeren String setzen, nur den Statistik-Endpoint selbst hosten oder eine lizenzierte Self-Hosting-Option nutzen. Rufen Sie CapacitorUpdater.setCustomId(...) nicht mit einer E-Mail, User-ID, Patienten-ID, Mitarbeiter-ID oder einem anderen Wert auf, der die Updater-Telemetrie einer Person zuordnen könnte.

Siehe HIPAA-Compliance für das vollständige technische Setup und die Auswirkungen auf die Observability bei deaktivierten Statistiken.

Kann ich Capgo live update-Daten in Europa speichern?

Ja. Apps, die EU-Data-Residency für den Capgo Cloud Plugin-Traffic benötigen, können die Updater-Endpoints auf den EU-Host setzen:

• updateUrl: https://plugin.eu.capgo.app/updates
• statsUrl: https://plugin.eu.capgo.app/stats
• channelUrl: https://plugin.eu.capgo.app/channel_self

Verwenden Sie alle drei EU-URLs gemeinsam, damit Update-Checks, Statistiken und die automatische Channel-Zuweisung denselben regionalen Datenpfad nutzen. Da diese Werte in capacitor.config.tsbenötigen produktive Mobile Apps ein Native Build, bevor bestehende Installationen die neuen Endpunkte nutzen können.

Siehe Datenstandort für exakte Capacitor und Electron Beispiele.

Welche Plattformen unterstützt Capgo?

Aktuell unterstützt Capgo Android, iOS und Electron. Alle sind produktionsreif.

Die Nutzung von Capgo für iOS, Android oder Electron kann unabhängig voneinander erfolgen. Du kannst deine Channel-Strategie für Android, eine für den App Store gebaute ipa oder für Electron-Channels nach Bedarf festlegen.

Capgo kann (relativ einfach) für Desktop- oder Embedded-Targets erweitert werden. Falls dies für dich wichtig ist, lass es uns bitte wissen.

Wie interagiert Capgo mit Play Testing Tracks oder Apple TestFlight?

Die App Stores nutzen jeweils eigene Mechanismen, um Apps an begrenzte Nutzergruppen zu verteilen (z. B. „internes Testing“, „Closed Beta“ usw.). Dies sind Methoden, um Nutzer zu segmentieren und spezifische App-Versionen an die jeweiligen Gruppen auszuliefern.

Leider erlauben nicht alle diese Mechanismen Drittanbietern zu erkennen, ob eine App über einen bestimmten Test Track oder via TestFlight installiert wurde. Daher haben wir keine verlässliche Einsicht in die Zusammensetzung dieser Gruppen und können den Zugriff auf Capgo Patches basierend darauf nicht zuverlässig steuern. https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Wenn du die Verfügbarkeit von Capgo Bundles segmentieren möchtest, gibt es 4 Optionen:

1. Nutze für jede Gruppe einen eigenen Channel. Das ist der einfachste Weg, erfordert aber das Management mehrerer Channels. Eventuell nutzt du bereits Dev- und Prod-Channels mit unterschiedlicher Verfügbarkeit. So kannst du Dev-Channels updaten, testen und anschließend separat die Prod-Channels updaten. Wir empfehlen die Nutzung von Branches/Tags in deiner Versionsverwaltung, um den Überblick über die Quellen der jeweiligen Releases zu behalten.
2. Verwalte deine eigene Liste an Opt-in-Nutzern, deaktiviere automatische Updates und triggere Updates gezielt für bestimmte User über das @capgo/capacitor-updater Package. Das funktioniert bereits heute, erfordert aber die eigene Verwaltung deiner Opt-in-Liste.
3. Capgo ermöglicht einen eigenen Opt-in-Mechanismus pro Gerät (ähnlich wie Test Tracks oder TestFlight, nur plattformunabhängig). So kann dein QA-Team für ein Bundle opten, bevor es für die breite Öffentlichkeit freigegeben wird.
4. Nutzt Progressive Rollouts um ein Candidate-Bundle an eine zufällige, konsistente Teilmenge eines Channels auszuliefern. Setze den Rollout von 0–100 % oder nutze --rollout-percentage-bps für 0,01 %-Schritte; konfiguriere die Cache-Dauer von 60 Sekunden bis 365 Tagen sowie eine optionale Auto-Pause-Policy. Dies wählt keine benannte Device-Gruppe aus.

Abrechnung

Wie kann ich meinen Plan upgraden oder downgraden?

Du kannst deinen Plan jederzeit in deinem Dashboard upgraden oder downgraden: https://console.capgo.app/settings/organization/plans. Upgrades werden sofort wirksam. Downgrades gelten zum Ende deines aktuellen Abrechnungszeitraums.

Was passiert, wenn ich mein MAU-Limit erreiche?

Capgo schickt dir E-Mails bei 50 %, 70 %, 90 % und 100 % deines MAU-Limits. Sobald das Limit erreicht ist, werden Live Updates bis zum Ende des Abrechnungszeitraums blockiert. Upgrade auf einen höheren Plan oder kaufe Credits, um Updates wieder bereitzustellen. Siehe Capgo Preise und pricing.md für die verschiedenen Plan-Stufen.

Bieten Sie Rückerstattungen an?

Sofern gesetzlich nicht anders vorgeschrieben, sind gezahlte Abonnementgebühren nicht erstattungsfähig. Bestimmte Rückerstattungsanträge können nach alleinigem Ermessen von Capgo geprüft werden. Kontaktieren Sie den Support falls Sie glauben, dass Sie Anspruch darauf haben.

Wann wird mein Abrechnungszeitraum zurückgesetzt?

Abrechnungszeiträume werden jeden Monat automatisch an dem Tag zurückgesetzt, an dem Sie Capgo zum ersten Mal abonniert haben. Wenn Sie beispielsweise am 15. des Monats abonniert haben, wird Ihr Abrechnungszeitraum jeden Monat am 15. zurückgesetzt.

Wie kann ich mein Abonnement kündigen?

Du kannst dein Abo jederzeit in deinem Dashboard kündigen: https://console.capgo.app/settings/organization/plans

Kann ich für ein ganzes Jahr im Voraus bezahlen?

Ja. Du kannst die jährliche Abrechnung in deinen Organisation-Plan-Einstellungen wählen.

Was zählt zum Speicher und können wir die Aufbewahrungsdauer ändern?

Der Speicherplatz umfasst gespeicherte historische Bundles und deren Delta-Assets über alle Channels hinweg. In den App-Einstellungen kannst du die Aufbewahrung für nicht genutzte Bundles pro App steuern. Bundles, die mit einem aktiven Channel oder Rollout verknüpft sind, bleiben geschützt, damit sie für das Deployment und Rollbacks verfügbar bleiben.

Erhöht die regionale Replikation den Speicher- oder Bandbreitenverbrauch?

Nein. Ein Bundle wird nur einmal für den Speicherplatz gezählt, unabhängig von den Regionen, die es ausliefern. Auch die Bandbreite wird durch die Regionen nicht vervielfacht: siehe Wie wird die Bandbreite berechnet?.

Wie wird die Bandbreite berechnet?

Die Bandbreite berücksichtigt nur die Dateien, die ein Gerät tatsächlich von Capgo herunterlädt:

• Delta-Updates: when you upload with --delta, lädt ein Gerät nur die Dateien herunter, die sich seit der bereits installierten Version geändert haben. Nur diese Dateien zählen. Unveränderte Dateien, wie große Bilder oder Fonts, werden nicht erneut heruntergeladen und verursachen keine Kosten. Siehe Delta-Updates.
• Edge-Cache: Wenn eine angeforderte Datei oder ein vollständiges ZIP bereits im Edge-Cache liegt, verbraucht dieser Download kein Bandbreiten-Kontingent. Dies gilt sowohl für Delta-Dateien als auch für vollständige ZIPs.
• Fortgesetzte Downloads: Wird ein Download unterbrochen, setzt das Gerät den Vorgang an der entsprechenden Stelle fort. Bereits heruntergeladene Teile werden nicht erneut heruntergeladen oder mitgezählt.
• Full zip: bundles uploaded without --deltahochgeladen wurden, oder Geräte mit einer Plugin-Version ohne Delta-Support, laden das vollständige ZIP herunter. Dies wird nur angerechnet, wenn es nicht aus dem Edge-Cache ausgeliefert wird.

To keep bandwidth low, upload with --delta und speichere große Assets, die sich selten ändern, unter stabilen Dateipfaden.

Was beinhaltet das Enterprise SLA?

Enterprise beinhaltet eine monatliche Verfügbarkeitsgarantie von 99,9 % für die Produktionsplattform. Sollte diese nicht eingehalten werden, sieht der Service-Credit-Plan je nach monatlicher Verfügbarkeit 10 % bis 30 % vor. Die initialen Support-Reaktionszeiten sind: P1: eine Stunde, 24/7/365; P2: zwei Geschäftsstunden; P3: ein Arbeitstag; und P4: zwei Arbeitstage. Lies das Enterprise SLA für die vollständigen Bedingungen.

Statistiken und Analysen

Die Statistiken in deinem Dashboard werden jeden Tag um Mitternacht UTC aktualisiert. Die Statistiken basieren auf einzelnen MAUs die im rollierenden 30-Tage-Zeitraum aktiv waren.

Wie die Device ID generiert wird

Die Device ID wird beim ersten Start auf dem Gerät generiert. Sie dient dazu, Installationen pro Gerät zu deduplizieren, damit wir nach installierten Nutzern (z. B. Monthly Active Users) abrechnen können, statt nach der Gesamtzahl der Patches oder Patch-Installationen.

MAU ist eine bessere Preisbasis für Capgo als die Anzahl der Installationen, da sie genauer ist und die tatsächlichen Kosten von Capgo pro Gerät widerspiegelt.

Persistenz der Device ID:

• iOS: Ab v7.25.0+ wird die Device ID im Keychain gespeichert und bleibt auch nach einer normalen Neuinstallation erhalten.
• Android: Nutze v7.50.1+ (oder v5.50.1+/v6.50.1+ in diesen Release-Lines). Die Device ID wird nur wiederhergestellt, wenn Android Backup/Restore die App-Präferenzen beibehält.
• Electron: Die Device ID wird im Secure Storage gespeichert.
• Hinweis zu Android: Das Deaktivieren des Backups, das Ausschließen der relevanten Präferenzen oder das Löschen der App-Daten führt zu einer neuen Device ID. Bei Android v7.25.0 bis v7.50.0 kann auch bei aktiviertem Backup nach einer Neuinstallation eine neue Device ID generiert werden.

Die Device ID ist app-spezifisch und unterstützt die Live Update Bereitstellung sowie die MAU-Deduplizierung; sie ist kein Identifier für Werbung oder Cross-App-Tracking.

Device IDs werden gelistet, nachdem die App über die Updater- oder Stats-Endpoints bei Capgo eingecheckt hat. Ein Gerät muss keinen Patch installieren, um in der Device-Liste zu erscheinen.

Warum weicht meine Geräteanzahl von meinen MAUs ab?

Die Device-Liste und die MAUs basieren auf unterschiedlichen Signalen.

Die Device-Liste zeigt die aktuellsten Metadaten für jedes Gerät an, wie Device ID, Plattform, Plugin-Version, OS-Version, Native Version, Channel, installiertes Bundle und das Request-Land (sofern verfügbar). Das Request-Land ist der letzte gültige zweistellige code Code aus einem von Cloudflare verarbeiteten Request für dieses Gerät, nicht der GPS- oder App-Standort. Requests ohne gültiges Land überschreiben den letzten gültigen Wert nicht. Capgo aktualisiert diese Metadaten beim Check-in der App, aber wiederholte Check-ins mit identischen Metadaten ändern den Eintrag oder den Zeitstempel der letzten Aktualisierung eventuell nicht.

MAUs zählen eindeutige aktive Geräte innerhalb des Abrechnungszeitraums. Diese Aktivität kann steigen, selbst wenn die Device-Metadaten gleich bleiben, weshalb die Geräteanzahl und die MAUs voneinander abweichen können.

Wie kann ich unterschiedliche Updates pro Plattform nutzen?

Du kannst für jede Plattform einen eigenen Channel erstellen und plattformspezifische Updates in jedem Channel deaktivieren.

Deaktiviere im iOS-Channel die Android-Updates und im Android-Channel die iOS-Updates.

Lade dann ein Bundle in jeden Channel hoch, um für jede Plattform ein unterschiedliches Update zu haben.

Wenn du das gleiche Update für beide Plattformen benötigst, kannst du ein Bundle mit mehreren Channels verknüpfen. Du musst das Bundle nicht duplizieren.

Weiterlesen in den FAQ

Wenn du es nutzt FAQ um die Auslieferung von live update zu planen, verbinde sie mit Capgo Live Updates für den Produkt-Workflow in Capgo Live Updates, Übersicht für die Implementierungsdetails in der Übersicht, Funktionen für die Implementierungsdetails in den Features, Update-Verhalten für die Details in Update Behavior, und Update-Typen Details zur Implementierung findest du unter Update Types.