Teams, die ausliefern Capacitor Live Updates immer wieder dieselbe Frage stellen, nachdem Apple-Review-E-Mails erwähnen Remote-code-Ausführung: blockiert das Capgo?
Für die meisten Capacitor Apps: Nein. Capgo ersetzt das Web-Bundle, das deine App bereits nutzt. Es lädt kein Swift, keine Frameworks oder Bytecode herunter und macht dein Produkt nicht zu einem Mini-App-Store. Die von Apple genannten Regeln sind real, beziehen sich aber auf ein anderes Verhalten als signiertes JavaScript, das an WKWebView oder JavaScriptCore geliefert wird.
Dies ist technische Orientierung, keine Rechtsberatung. Lies Apples veröffentlichte Texte und konsultiere einen Anwalt für deine App.
Die drei Texte, die Reviewer zitieren
App-Review-Richtlinie 2.5.2
Richtlinie 2.5.2 besagt, dass Apps nicht „code herunterladen, installieren oder ausführen dürfen, was Funktionen oder Features der App, einschließlich anderer Apps, einführt oder ändert.“
Review-Teams nutzen diesen Satz, wenn sie Folgendes sehen:
dlopen,dlsym, oder ähnliches dynamisches Laden,performSelector:und andere Runtime-Hooks auf private APIs, oder- Remote-Skripte, deren Aufgabe es ist, das native Verhalten nach der Freigabe zu ändern.
Das ist das Remote-code-Execution- Muster in Ablehnungsbescheiden. Es ist kein Verbot für jedes Byte, das nach der Installation heruntergeladen wird.
ADPLA Abschnitt 3.3.1(B) (interpretiert als code)
Der Apple Developer Program Lizenzvereinbarung Abschnitt 3.3.1(B) erlaubt es, interpretierten code herunterzuladen, wenn er:
- den Hauptzweck der App nicht ändert,
- Signing, Sandboxing oder andere OS-Sicherheitsfeatures nicht umgeht, und
- keinen Store oder Storefront für andere Apps erstellt.
Die Web-Layer von Capacitor ist bauartbedingt ein interpretierter code. Capgo tauscht diese Layer aus, nachdem deine User die geprüfte Binary aus dem App Store installiert haben.
ADPLA Abschnitt 3.3.1(C) (zusätzliche Features)
Abschnitt 3.3.1(C) bietet eine weitere Schutzmaßnahme: Ohne die vorherige schriftliche Genehmigung von Apple oder eine zulässige 3.3.9(A) Nutzung von In-App-Käufen darf eine App keine zusätzlichen Funktionen oder Features über andere Distributionswege als den App Store, Custom App Distribution oder TestFlight bereitstellen, freischalten oder aktivieren.
Ob ein bestimmtes OTA-Bundle diese Grenze überschreitet, ist eine rechtliche Entscheidung Ihres Teams. Capgo trifft diese nicht für Sie. Die Compliance-Checkliste nennt 3.3.1(C), damit Sie jedes Release bewerten können.
Guideline 4.7 und die Klarstellung vom November 2025
Apples Guideline-Update vom 13. November 2025 präzisierte Richtlinie 4.7 für Apps, die HTML5 und JavaScript anbieten – Mini-Apps, Minispiele, Chatbots, Plug-ins und ähnliche Software – die nicht in der Binary eingebettet sind..
Wenn Nutzer viele verschiedene Software-Erlebnisse in Ihrer App durchsuchen oder starten, benötigen Sie eventuell die Katalog-, Indexierungs- und Altersfreigabe-Mechanismen von 4.7. Die Inhaberschaft der Bundles ist hierbei nicht entscheidend. Die das du auslieferst tut.
Capgo ist ein Delivery-Channel für deine Bundles auf deine Channels. Er ist für sich genommen kein Marktplatz. Wenn dein Produkt ein White-Label-Host oder eine Mini-App-Plattform ist, nimm 4.7 ernst, bevor du dich auf OTA verlässt.
Was Capgo tatsächlich ausliefert
| Schicht | Capgo Verhalten |
|---|---|
| Native Binary | Unverändert. Neue Plugins, Berechtigungen und Entitlements erfordern einen Store-Build. |
| Web-Assets | Signiertes JavaScript, HTML, CSS, Fonts, Bilder und statische Dateien ersetzen das In-App-Bundle. |
| Ausführung | Läuft innerhalb der WebView oder JavaScriptCore-Engine, die Apple bereits mit deinem Shell-App genehmigt hat. |
| Verschlüsselung | Optionale End-to-End-Verschlüsselung sorgt dafür, dass Bundle-Inhalte während der Übertragung und Speicherung für Capgo unlesbar bleiben. |
Capgo hilft dir, Web-Layer-Fixes in Minuten zu deployen, fehlerhafte Bundles auf einem Channel zurückzurollen und native Releases auf dem App Store Pfad zu halten. Tausende Produktions-Apps nutzen diese Trennung, ohne Live Updates in einen Remote Native Loader zu verwandeln.
Praktische Regeln für dein Team
- Nutze OTA für Bugs, UI, Copy und Verbesserungen innerhalb der von Apple geprüften App.
- Reiche eine neue Binary ein, wenn sich code, SDKs, Berechtigungen oder Entitlements ändern.
- Nutze Live Updates nicht, um Preismodelle zu ändern, Features freizuschalten oder den Zweck der App zu ändern.
- Document how updates work in App Review notes when asked.
- Lies den vollständigen Apple Remote code und Capgo Abschnitt vor deinem nächsten Release.
Für die Produktübersicht (Channels, Rollback, Signing) starte bei Capacitor Live Updates. Für einen Deep Dive in die Richtlinien nutze das Compliance-Dokument oben oder den älteren Guide in Erlaubt Apple Live Updates?.
