Ein großer Vorteil einer Lovable-App im WebView: Sie ändern etwas in Lovable, veröffentlichen, und die App zeigt die neue Version sofort an. Doch nicht jede Änderung darf und kann auf diesem Weg erfolgen. Manche Anpassungen erfordern zwingend einen neuen Build mit Store-Prüfung, andere sind technisch möglich, verstoßen aber gegen die Regeln. Hier lesen Sie, wo die Grenze verläuft und wie Sie einen Release-Prozess aufsetzen, der schnell bleibt und trotzdem keine Ablehnungen riskiert.
Was ohne neuen Build live gehen kann
Lädt Ihre App die Lovable-Oberfläche von Ihrer Domain, sind Änderungen an Texten, Layouts, Bildern, Formularen, Daten und Geschäftslogik im Frontend nach dem Veröffentlichen sofort sichtbar. Dasselbe gilt für Änderungen in Supabase, etwa neue Tabellen, Edge Functions oder Rechte. Fehlerbehebungen erreichen Nutzer damit in Minuten statt Tagen.
Apple erlaubt Web-Inhalte, die sich ändern, schreibt aber in Guideline 2.5.2 vor, dass Apps keinen Code nachladen dürfen, der Funktionen oder den Zweck der App wesentlich verändert. Eine Rezept-App, die sich über Nacht in ein Glücksspielangebot verwandelt, verstößt gegen die Regeln. Weiterentwicklung im Rahmen des geprüften Zwecks ist dagegen üblich.
Praktisch heißt das: Neue Seiten, zusätzliche Felder, ein überarbeiteter Onboarding-Ablauf oder eine neue Auswertung sind unproblematisch. Kritisch wird es erst, wenn die App plötzlich in eine ganz andere Kategorie fällt, etwa durch Glücksspiel, medizinische Diagnosen oder Inhalte für Erwachsene, oder wenn Funktionen freigeschaltet werden, die im Review absichtlich verborgen waren. Solche versteckten Funktionen gelten bei Apple als schwerer Verstoß.
Wann ein neuer Build zwingend ist
Alles, was im nativen Teil der App steckt, erfordert eine neue Version im Store. Dazu gehören App-Name, Icon und Splashscreen, neue Berechtigungen wie Kamera oder Standort samt Begründungstexten, neue native Funktionen wie Push oder In-App-Käufe, ein Wechsel der Start-URL, Aktualisierungen von SDKs sowie Anforderungen der Stores an neue iOS-SDK-Versionen oder Android-Target-API-Level.
Auch wenn Ihre Web-Änderung neue Daten erhebt, etwa durch ein Analysewerkzeug, müssen App Privacy und Data safety angepasst werden. Das geht ohne Build, wird aber oft vergessen.
Eine einfache Faustregel hilft im Alltag: Braucht die Änderung eine neue Datei im Xcode- oder Android-Projekt oder einen neuen Eintrag in den Store-Angaben, dann ist sie ein Fall für einen Release. Alles andere darf über die Web-App laufen.
Ein Release-Prozess, der beides abdeckt
Diese Routine hat sich bei Lovable-Apps bewährt:
- Trennen Sie eine Staging-Umgebung von der Produktions-URL, damit nicht jede Änderung in Lovable sofort bei allen App-Nutzern ankommt.
- Testen Sie Web-Änderungen vor dem Veröffentlichen in der App auf iOS und Android, nicht nur im Desktop-Browser.
- Prüfen Sie bei jeder Änderung, ob sie Berechtigungen, Datenerhebung oder den Zweck der App berührt, und planen Sie in diesem Fall einen Store-Release.
- Bündeln Sie native Änderungen in regelmäßigen Releases, etwa monatlich, und automatisieren Sie Build und Upload.
- Halten Sie die Web-App rückwärtskompatibel, denn nicht alle Nutzer installieren neue App-Versionen sofort.
Stolpersteine bei Web-Updates
Caching ist der häufigste Grund für Verwirrung: Nutzer sehen eine alte Version, weil der WebView Dateien zwischenspeichert oder ein Service Worker veraltete Daten ausliefert. Vite erzeugt zwar Dateinamen mit Hash, die index.html sollte jedoch nicht lange gecacht werden. Ein zweiter Punkt ist die Kopplung an native Funktionen. Ruft Ihre Web-App eine native Schnittstelle auf, die erst in einer neueren App-Version existiert, muss sie prüfen, ob diese vorhanden ist, und sonst einen Fallback anbieten.
Für kritische Fälle lohnt sich ein Mechanismus, der Nutzer bei zu alter App-Version zum Update auffordert.
Dokumentieren Sie in einem kurzen Änderungsprotokoll, welche Web-Version wann live ging. Bei Supportanfragen können Sie dann schnell nachvollziehen, welchen Stand ein Nutzer gesehen hat.
Updates ohne Reibung
Mit WebViewGold bleiben Web-Updates unmittelbar, während native Neuerungen über neue Builds kommen. appsubmitter.io automatisiert diese Builds mit fastlane und Ihrer CI und reicht sie in Ihrem Konto ein. Sprechen Sie mit uns in einem kostenlosen 15-Minuten-Erstgespräch über Ihren Release-Rhythmus.
Häufige Fragen
Muss ich Apple über Web-Änderungen informieren?
Nein, solange der Zweck der App gleich bleibt und keine neuen nativen Funktionen hinzukommen. Bei größeren Änderungen am Funktionsumfang ist ein regulärer Store-Release der saubere Weg.
Wie lange dauert ein neuer Build durch das Review?
Apple prüft Updates häufig innerhalb von ein bis zwei Tagen, Google oft ähnlich schnell. Bei neuen Konten oder heiklen Kategorien kann es länger dauern.
Kann ich Live-Updates auch mit Capacitor nutzen?
Es gibt Dienste für Live-Updates von Web-Bundles in Capacitor-Apps. Sie unterliegen denselben Regeln: Änderungen am Zweck oder an nativen Funktionen gehören in einen Store-Release.