Ein Fehler im Release, und das nächste Review dauert womöglich Tage. Over-the-Air-Updates versprechen Abhilfe: Bei Apps auf Basis von Expo oder Capacitor lässt sich der JavaScript-Teil direkt aktualisieren, ohne neuen Store-Build. Für Teams, die mit Claude Code in kurzen Zyklen arbeiten, ist das verlockend. Doch Apple und Google setzen klare Grenzen, und ein unbedachtes Update kann im schlimmsten Fall die App kosten. Hier erfahren Sie, was erlaubt ist, wie die Technik funktioniert und wie Sie Updates sicher ausrollen.
Was technisch aktualisiert werden kann
Eine Expo- oder Capacitor-App besteht aus zwei Schichten: dem nativen Teil mit Plugins, Berechtigungen und SDKs und dem Web- beziehungsweise JavaScript-Teil mit Oberfläche und Logik. OTA-Updates tauschen nur die zweite Schicht aus. Neue native Module, zusätzliche Berechtigungen oder geänderte SDK-Versionen erfordern immer einen neuen Store-Build.
Bei Expo regelt die runtimeVersion, welche Updates zu welchem nativen Build passen. Ein Update für eine falsche Runtime kann zu Abstürzen führen, weil der Code native Funktionen erwartet, die es im installierten Build nicht gibt. Capacitor-Lösungen wie Capgo oder die Live Updates von Ionic Appflow arbeiten mit ähnlichen Kanälen und Versionsbindungen. Native Apps in Swift oder Kotlin kennen dieses Prinzip nicht, Flutter-Apps nur über Drittanbieter.
Was Apple und Google erlauben
Apple erlaubt das Nachladen von interpretiertem Code wie JavaScript unter Bedingungen: Das Update darf den Hauptzweck der App nicht ändern, keine neuen Store-Funktionen umgehen und muss die Review-Richtlinien weiterhin einhalten. Ein Hotfix für einen Fehler oder eine angepasste Formulierung ist unkritisch. Ein OTA-Update, das eine komplett neue Funktion freischaltet oder digitale Käufe an In-App-Kauf vorbei ermöglicht, verstößt gegen die Regeln.
Google Play untersagt in seinen Richtlinien zum Missbrauch von Geräten und Netzwerken, dass Apps ausführbaren Code außerhalb von Google Play nachladen, nimmt aber Code aus, der in einer virtuellen Maschine oder einem Interpreter läuft. In beiden Fällen gilt: Je näher ein Update an einem Bugfix ist, desto sicherer bewegen Sie sich.
Ein sicherer Update-Prozess
Mit einem klaren Ablauf bleiben OTA-Updates ein Werkzeug für schnelle Korrekturen statt einer Risikoquelle:
- Legen Sie in der CLAUDE.md fest, welche Änderungen per OTA ausgeliefert werden dürfen und welche einen Store-Build brauchen.
- Lassen Sie Claude Code vor jedem Update prüfen, ob sich native Abhängigkeiten oder Berechtigungen geändert haben.
- Veröffentlichen Sie das Update zuerst auf einem Staging-Kanal und testen Sie es auf echten Geräten.
- Rollen Sie es anschließend schrittweise aus, etwa an zehn Prozent der Nutzer, und beobachten Sie das Crash-Reporting.
- Halten Sie eine Rollback-Möglichkeit bereit, um bei Problemen sofort auf die vorherige Version zurückzuwechseln.
Fallstricke im Alltag
Ein häufiger Fehler ist, dass Updates zu früh geladen und angewendet werden, etwa mitten in einem Bezahlvorgang. Besser ist es, Updates im Hintergrund herunterzuladen und beim nächsten Start anzuwenden. Kritische Fixes können Sie mit einem Hinweis an den Nutzer verbinden.
Ebenso wichtig ist die Nachvollziehbarkeit. Jedes OTA-Update sollte einer Git-Version zugeordnet sein und Source Maps für das Crash-Reporting mitbringen. Sonst wissen Sie bei einem Absturz nicht, welcher Code tatsächlich lief. Claude Code kann diese Zuordnung in der Release-Pipeline automatisieren.
Klären Sie außerdem, wer ein OTA-Update freigeben darf. Weil kein Store-Review dazwischenliegt, sollte mindestens eine zweite Person den Diff geprüft haben. Ein geschützter Branch und eine manuelle Freigabe in der CI verhindern, dass ein von Claude Code erzeugter Zwischenstand versehentlich bei allen Nutzern landet.
Strategie statt Dauerlösung
OTA-Updates ersetzen keinen regelmäßigen Store-Release. Sie sind ideal für Hotfixes und kleine Anpassungen, nicht für neue Produktversionen. Wer große Änderungen am Review vorbei ausliefert, riskiert Ablehnungen bei späteren Builds.
Die AI Code Engineers von neooutput richten OTA-Kanäle, Rollout-Strategien und Monitoring für Ihre Expo- oder Capacitor-App ein. appsubmitter verbindet das mit einer Release-Pipeline, die Store-Builds und OTA-Updates sauber trennt. Lassen Sie uns in einem kostenlosen 15-Minuten-Erstgespräch klären, welche Strategie zu Ihrer App passt.
Häufige Fragen
Brauche ich für ein OTA-Update ein erneutes Review?
Nein, OTA-Updates durchlaufen kein Store-Review. Genau deshalb müssen Sie selbst sicherstellen, dass sie innerhalb der Regeln bleiben, die für den geprüften Build gelten.
Funktionieren OTA-Updates auch für WebView-Apps?
Bei einem WebView-Wrapper, der eine Website lädt, ändern Sie ohnehin die Website. Auch hier gilt aber, dass die App nach dem Review nicht grundlegend ihren Zweck ändern darf.
Kann ich mit OTA-Updates eine fehlerhafte Store-Version retten?
Wenn der Fehler im JavaScript-Teil liegt und die App noch bis zum Update-Check startet, ja. Stürzt die App sofort beim Start im nativen Teil ab, hilft nur ein neuer Store-Build.