Lovable-App in den App Store und Google Play Store bringen

Lovable erzeugt aus Prompts eine funktionierende Web-Anwendung auf Basis von React, Vite und meist Supabase. Eine Datei, die Sie direkt bei Apple oder Google hochladen können, entsteht dabei nicht. Dieser Fahrplan zeigt, welche Schritte zwischen Ihrer Lovable-App und einem Eintrag in beiden Stores liegen, und wo Projekte in der Praxis ins Stocken geraten.

Phase 1: Konten und Zuständigkeiten klären

Bevor jemand eine Zeile nativen Code anfasst, sollten die Konten stehen. Sie gehören Ihrem Unternehmen, nicht einem Dienstleister.

• Apple Developer Program: 99 US-Dollar pro Jahr. Für ein Unternehmenskonto benötigen Sie eine D-U-N-S-Nummer; deren Beantragung kann einige Tage bis Wochen dauern. Details dazu in unserem Artikel zum Apple-Entwicklerkonto für Unternehmen.
• Google Play Console: einmalig 25 US-Dollar. Google verlangt eine Identitätsprüfung; für Organisationen ebenfalls eine D-U-N-S-Nummer.
• Rollen vergeben: Externe Helfer erhalten Zugriff über Benutzerrollen, nicht über Ihre Zugangsdaten.

Phase 2: Den Weg zur nativen App wählen

Unsere Einschätzung: Für die meisten Lovable-Projekte ist ein Wrapper der sinnvolle erste Schritt, weil er die Web-App als einzige Codebasis beibehält. Mit WebViewGold setzen Sie das ohne Programmierung selbst um; wer es abgeben möchte, nutzt WeSetupYourWebViewApp. Den ausführlichen Vergleich finden Sie unter Capacitor vs. WebView-Wrapper vs. Neubau.

Phase 3: Die Web-App app-tauglich machen

Apple lehnt Apps nach Richtlinie 4.2 (Minimum Functionality) ab, wenn sie nur eine umverpackte Website sind. Bereiten Sie Ihre Lovable-App deshalb gezielt vor:

1. App-Nutzer landen direkt im Login oder Dashboard, nicht auf der Marketingseite.
2. Cookie-Banner, Website-Footer und „App herunterladen“-Hinweise werden in der App ausgeblendet.
3. Mindestens eine echte native Funktion mit Nutzen: Push-Benachrichtigungen, Kamera, Teilen, Biometrie oder Offline-Inhalte.
4. Kontolöschung direkt in der App, sofern Nutzer Konten anlegen können (Richtlinie 5.1.1).
5. Falls Sie Login über Google oder andere Drittanbieter anbieten, prüfen Sie die Vorgaben von Richtlinie 4.8 zu einer gleichwertigen datenschutzfreundlichen Login-Option wie „Sign in with Apple“.
6. Verkaufen Sie digitale Inhalte, klären Sie die aktuellen Regeln zu In-App-Käufen (Richtlinie 3.1.1). Diese unterscheiden sich inzwischen je nach Region; prüfen Sie den aktuellen Stand.

Phase 4: Builds, Tests und Store-Einträge

iOS: Der Build entsteht in Xcode, wird signiert und in App Store Connect hochgeladen. Über TestFlight testen Sie mit echten Geräten, bevor Sie zur Prüfung einreichen. Hinterlegen Sie für das Review ein funktionierendes Demo-Konto.

Android: Neue Apps werden als Android App Bundle (AAB) hochgeladen und müssen ein aktuelles Android-API-Level adressieren. Wichtig für die Zeitplanung: Private Entwicklerkonten, die nach dem 13. November 2023 erstellt wurden, müssen vor dem Produktionszugang einen geschlossenen Test mit mindestens 12 Testern über 14 aufeinanderfolgende Tage durchführen. Organisieren Sie diese Tester frühzeitig. Mehr dazu im Artikel zur 12-Tester-Regel.

Beide Stores: Screenshots in den geforderten Größen, Beschreibung, Datenschutzerklärung als URL, Support-Kontakt, Alterseinstufung sowie die Datenschutzangaben (App Privacy bei Apple, Data Safety bei Google). Diese Angaben müssen zu dem passen, was Ihre App und eingebundene Dienste wie Analytics oder Supabase tatsächlich verarbeiten.

Realistischer Zeitplan

Die Zeiten sind Erfahrungswerte und schwanken. Starten Sie die Kontoeinrichtung deshalb parallel zur technischen Arbeit.

Häufige Stolperfallen

• Das Konto läuft auf eine Privatperson oder Agentur statt auf Ihr Unternehmen.
• Login-Links und OAuth-Weiterleitungen funktionieren in der WebView nicht, weil Redirect-URLs in Supabase fehlen.
• Der Reviewer kommt ohne Demo-Konto nicht über den Login hinaus.
• Datenschutzangaben vergessen Drittanbieter wie Analytics oder Fehler-Tracking.
• Updates der Web-App ändern Funktionen, die im Review beschrieben wurden, ohne dass dies abgestimmt ist.

Nach dem Launch: Updates richtig planen

Ein Vorteil des Wrapper-Wegs: Änderungen an Ihrer Lovable-App erscheinen sofort in beiden Apps, ohne neue Einreichung. Das ist bequem, verlangt aber Disziplin.

• Inhalte und Fehlerbehebungen können Sie wie gewohnt über die Web-App ausrollen.
• Grundlegende Funktionsänderungen, etwa ein neues Bezahlmodell oder ein komplett anderer Zweck der App, sollten Sie nicht still über die Web-App einführen. Die Store-Richtlinien erwarten, dass die App dem geprüften Stand und der Beschreibung im Store entspricht.
• Native Änderungen wie neue Push-Kategorien, Berechtigungen oder SDK-Updates erfordern einen neuen Build und eine neue Prüfung.
• Pflichtupdates der Plattformen kommen regelmäßig: Google verlangt in jährlichem Rhythmus ein aktuelles Ziel-API-Level, Apple neue Xcode- und SDK-Versionen. Planen Sie dafür feste Wartungsfenster ein.

Testen Sie jede größere Änderung an der Web-App zusätzlich in der iOS- und Android-App, bevor sie live geht. Was im Desktop-Browser funktioniert, kann in der WebView an Datei-Uploads, Pop-ups oder Weiterleitungen scheitern.

Unterstützung bei der Einreichung

Viele Teams scheitern nicht am Code, sondern an Signierung, Konten und Ablehnungen. appsubmitter.io richtet CI/CD ein, signiert und reicht Ihre iOS- und Android-Builds in Ihren eigenen Entwicklerkonten ein und begleitet Sie durch Rückfragen und Ablehnungen. Wenn Sie Ihren konkreten Fall besprechen möchten, können Sie ein kostenloses Erstgespräch buchen. Allgemeine Hilfe zur Veröffentlichung finden Sie auch in unserem Leitfaden zur App-Store-Veröffentlichung.