Kurze Antwort: Ja, Apple erlaubt Live Updates, mit Einschränkungen. Du kannst neues JavaScript, HTML und CSS in eine iOS-App pushen, ohne ein neues App Store Review zu durchlaufen – solange das Update den Kernzweck der App nicht verändert. Das Herunterladen von nativem code ist nicht erlaubt.
Mit Capgo: Capgo Live Updates liefern nur die Web-Schicht (JavaScript, HTML, CSS, Assets) einer Capacitor-App. Apples Regeln erlauben dies, wenn das Update den Hauptzweck der App beibehält, keinen code-Storefront erstellt und die OS-Sicherheit nicht umgeht. Native Änderungen müssen weiterhin über einen Store-Release erfolgen.
Die meisten Missverständnisse entstehen durch die Vermischung zweier Dinge: Live Updates von interpretiertem code (erlaubt) und das Herunterladen von neuem ausführbarem code (nicht erlaubt). Diese Seite zitiert die Regeln, zeigt die Grenze auf und erklärt, wie Apple dies durchsetzt.
Dies ist keine Rechtsberatung. Es beschreibt, wie die Regeln aktuell lauten und wie tausende Apps sie in der Produktion nutzen.
Was Apples Regeln wirklich sagen
Zwei Texte sind relevant. Der erste ist App Store Review Guideline 2.5.2:
Apps sollten in ihren Bundles selbstständig sein und dürfen keine Daten außerhalb des zugewiesenen Container-Bereichs lesen oder schreiben. Sie dürfen auch kein code herunterladen, installieren oder ausführen, das Funktionen oder die Funktionalität der App einführt oder ändert, einschließlich anderer Apps.
Für sich allein klingt das nach einem Verbot. Die Ausnahme findet sich im zweiten Text, Abschnitt 3.3.1(B) der Apple Developer Program Lizenzvereinbarung, die jeder Entwickler signiert:
Interpretierter code darf auf eine App heruntergeladen werden, aber nur solange dieser code: (a) den Hauptzweck der App nicht verändert, indem er Funktionen oder Funktionalitäten bereitstellt, die nicht dem beabsichtigten und beworbenen Zweck der im App Store eingereichten App entsprechen, (b) keinen Store oder Storefront für andere code oder Apps erstellt und (c) Signing, Sandbox oder andere Sicherheitsfunktionen des Betriebssystems nicht umgeht.
Die Regel lautet also nicht „kein heruntergeladenes code“. Sondern „kein heruntergeladenes nativ code, und interpretiertes code nur unter drei Bedingungen“.
Die Web-Schicht einer Capacitor-App besteht aus JavaScript, HTML und CSS, die in WKWebView, was Apples eigene WebKit-Engine ist. Das wird code interpretiert, fällt also unter die Ausnahme. Guideline 4.7 weist in dieselbe Richtung: Apple erlaubt Apps ausdrücklich, HTML5- und JavaScript-Inhalte auszuführen, die nicht in der Binary eingebettet sind.
Wo die Grenze verläuft
| Erlaubt mit einem live update | Nicht erlaubt mit einem live update |
|---|---|
| Bugfixes in JavaScript, HTML oder CSS | Download von Swift, Objective-C oder kompilierten Binaries |
| UI-Änderungen, Textanpassungen oder neue Screens in deinem bestehenden Web-Stack | Die App in ein anderes Produkt verwandeln (z. B. Notiz-App wird zum Casino) |
| A/B-Tests und schrittweise Rollouts von Web-code | Features freischalten, die vor dem App Review verborgen sind |
| Bilder, Übersetzungen, Config aktualisieren | Einen Store bauen, der andere Apps oder code installiert |
| Ein fehlerhaftes Release zurückrollen | iOS-Sandbox, Signierung oder Berechtigungen umgehen |
Capgo liefert nur die linke Spalte. Es ersetzt das Web-Bundle in deiner App. Alles, was nativ ist, z. B. ein neues Capacitor-Plugin, eine neue Berechtigung oder ein SDK-Upgrade, braucht weiterhin ein reguläres App-Store-Release. Die von Capgo Version-Targeting stellt sicher, dass ein Bundle, das neue native code braucht, nie ein altes Binary erreicht.
Wie Apple das durchsetzt
Apple bewertet die Substanz, nicht die Technologie. Niemand fliegt raus, weil er einen Tippfehler over the air behebt. Das Muster, gegen das Apple vorgeht, ist eine App, die als das eine durchs Review kommt und danach zu etwas anderem wird. Das ist ebenso Guideline 2.3.1 (keine versteckten oder undokumentierten Features) wie 2.5.2.
In der Praxis:
- Veröffentliche, was du eingereicht hättest – nur schneller.
- Stelle sicher, dass jedes Update dem Zweck deiner App Store-Beschreibung entspricht.
- Schick große Feature-Launches durchs App Review und nutze Live Updates für Fixes und Iterationen zwischen Releases.
- Nutze live update niemals, um Verhalten freizuschalten, das die Reviewer nicht gesehen haben.
Wenn du dich daran hältst, sind Live Updates ein ganz normaler Teil des iOS-App-Releases. React-Native-Teams machen das seit Jahren mit CodePush und Expo Updates, und Capacitor-Teams tun es mit Capgo.
Welche Stacks können das unter iOS?
Ob deine App Over-the-Air-Updates auf iOS ausliefern kann, hängt von einer Frage ab: Wird deine App-Logik zur Laufzeit interpretiert? JavaScript und andere interpretierte code: ja. Swift, Objective-C und C++, zu maschinellem code kompiliert: nein. AOT-kompilierte Frameworks wie Flutter gehen nur über einen Interpreter.
iOS-live update-Kompatibilität nach Stack
| Stack | So läuft code auf iOS | Live Updates erlaubt? | Tooling |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS in WKWebView (WebKit) | Ja | Capgo |
| Ionic (auf Capacitor) | Wie Capacitor | Ja | Capgo |
| Cordova | JavaScript in WKWebView | Ja | Capgo nach der Migration zu Capacitor, Legacy-Cordova-Plugins |
| React Native / Expo | JavaScript-Bundle auf Hermes oder JavaScriptCore | Ja, nur JavaScript | Expo Updates, selbst gehostete CodePush-Alternativen |
| NativeScript | JavaScript auf einer eingebetteten Engine | Ja, nur JavaScript | Eingeschränkt, meist Eigenbau |
| Flutter | Dart, AOT kompiliert zu code-Maschinencode | Nur über einen Interpreter | Shorebird (Dart-Interpreter für Patches) |
| Natives Swift / Objective-C | code-Maschinencode | Nein für nativen code; ja für JavaScript in WebKit oder JavaScriptCore | Remote-Konfiguration und servergesteuerte UI |
| .NET MAUI / Xamarin | C#, AOT kompiliert zu code-Maschinencode | Nein | Nur Remote Config |
| Kotlin / Compose Multiplatform | Kotlin/Native kompiliert zu Maschinen-code | Nein | Nur Remote Config |
| Unity / Unreal | C# via IL2CPP oder C++, kompiliert | Nein für code, ja für Content | Asset-Bundles, skriptbasierte Inhalte (Lua) |
| Web-Wrapper (Remote-URL) | Website, in einer WebView geladen | Immer live, aber Review-Risiko | Keine erforderlich, siehe Hinweis unten |
Capacitor, Ionic und Cordova: voll unterstützt
Die Web-UI und die JavaScript-Geschäftslogik Ihrer App laufen in WKWebView, während die native Hülle und Plugins nativ bleiben. Abschnitt 3.3.1(B) der Apple Developer Program License Agreement erlaubt heruntergeladenen interpretierten code nur, wenn er den Hauptzweck der App beibehält, keinen code-Storefront erstellt und die OS-Sicherheit nicht umgeht. Richtlinie 4.7 regelt separat Apps, die HTML5- und JavaScript-Mini-Apps anbieten, und stellt zusätzliche Anforderungen.
Ein live update ersetzt das Web-Bundle. Die native Hülle, Plugins und Berechtigungen bleiben die, die Apple geprüft hat. Deshalb ist Capgo von Design aus konform: Es kann die native code nicht ändern, selbst wenn Sie es wollten. Neue native Plugins oder Berechtigungen erfordern weiterhin eine App Store-Veröffentlichung.
React Native und Expo: JavaScript ja, native Module nein
React Native führt Ihr JavaScript-Bundle auf Hermes oder JavaScriptCore aus. Dieses Bundle ist interpretierter code und kann über die Luft aktualisiert werden – genau dafür wurden Expo Updates und Microsoft CodePush (2025 eingestellt) entwickelt. Teams, die CodePush verlassen benötigen einen Ersatz.
Jede Änderung an nativen Modulen, der React Native-Version oder Info.plist benötigt ein neues Binary.
Flutter: nur über einen Interpreter
Auf iOS kompiliert Flutter Dart vorab zu ARM-Maschinencode. Das Herunterladen neuer Maschinencode ist verboten, daher kann Standard-Flutter keine Live Updates nutzen. Shorebird löst dies, indem es gepatchtes Dart-code in einem Interpreter ausführt, was unter die Ausnahme für interpretierte code fällt. Mehr dazu in Live Updates für Flutter-Apps.
Native Swift, .NET MAUI, Kotlin Multiplatform: keine nativen code Updates
Diese Stacks erzeugen native Maschinencode. Sie können keine ersetzenden nativen code herunterladen. Eine native App kann jedoch interpretierte code herunterladen und ausführen, z. B. JavaScript über JavaScriptCore, wenn sie die Bedingungen von Apple erfüllt. Was man auch per Over-the-Air ändern kann, sind Daten: Remote Config, Feature Flags für bereits geprüfte Features, servergesteuerte UI, Bilder und Texte.
Unity und Game Engines: Content ja, code nein
Game-code wird kompiliert. Asset-Bundles (Level, Art, Balancing-Daten) sind Inhalte und können heruntergeladen werden. Eingebettete Skriptsprachen wie Lua sind interpretierte code und unterliegen denselben Regeln wie JavaScript.
Remote-URL-Wrapper: live, aber riskant für die Prüfung
Eine App, die nur Ihre Website in einer WebView lädt, wird „aktualisiert“, jedes Mal wenn Sie die Site deployen. Das Problem ist nicht Richtlinie 2.5.2, sondern Richtlinie 4.2 (minimale Funktionalität): Apple lehnt Apps ab, die nur eine Website in einem Frame sind. Das Bündeln der Web-App mit Capacitor, das Hinzufügen nativer Features und die Nutzung von Live Updates vermeiden das.
Was kein Stack auf iOS kann
Egal, welches Framework du nutzt, eine live update kann nicht:
- Native code, Frameworks oder dynamische Bibliotheken herunterladen
- Neue Berechtigungen oder Entitlements hinzufügen
- Die App in etwas verwandeln, das die App Store-Beschreibung nicht abbildet
- Funktionen aktivieren, die der App Review verborgen blieben
Wie es weitergeht
- Antwort für Android: Erlaubt Google Live Updates ohne Play Store-Review?
- Durchsetzung im Detail: Wie Apple OTA-Update-Einschränkungen durchsetzt
- Genehmigungsprozess: Capacitor OTA-Updates: Leitfaden zur App-Store-Genehmigung
- Echte Ablehnungsgeschichten: App-Store-Ablehnungen: echte Horrorgeschichten
Fixes heute releasen, nicht erst nach dem Review
Capgo Live Updates Pushe JavaScript-, HTML- und CSS-Änderungen in wenigen Minuten in deine Capacitor App – mit Channels, Rollbacks, Delta Updates und End-to-End-Verschlüsselung. Open Source und selbst hostbar.
bunx @capgo/cli@latest initFolge dem Quickstart um dein erstes Update zu senden.
