Lovable-App im App Store veröffentlichen: PWA vs. Capacitor vs. Neubau und Richtlinie 4.2 vermeiden (2026)

Wenn du wissen willst, wie du eine Lovable-App im App Store veröffentlichst, solltest du zuerst eines wissen: Lovable kann das nicht für dich erledigen. In der Lovable-Dokumentation zum Veröffentlichen steht, dass „Lovable Web-Apps baut und das Veröffentlichen immer unter einer Web-URL deployt“ und dass es „keinen eingebauten Workflow gibt, der dein Projekt verpackt und im App Store oder bei Google Play einreicht“. Im Folgenden findest du die drei realistischen Optionen, was jede kostet und welche Schritte eine verpackte Lovable-App vor Richtlinie 4.2 bewahren.

Kann man eine Lovable-App direkt im App Store veröffentlichen?

Nein. Stand Oktober 2026 veröffentlicht Lovable auf einer lovable.app-Subdomain oder einer eigenen Domain. Um in einen Store zu kommen, musst du die App außerhalb von Lovable verpacken und über deinen eigenen Developer-Account einreichen.

Die Lovable-Dokumentation nennt zwei Workarounds: die veröffentlichte Website zu einer installierbaren PWA machen oder „deine veröffentlichte URL außerhalb von Lovable mit Capacitor in eine native Hülle verpacken“ und diese Hülle selbst einreichen. Außerdem stellt die Dokumentation zwei Dinge klar. Lovable erzeugt keine React-Native-Projekte, und die Lovable-Mobile-App dient nur dazu, Projekte vom Smartphone aus zu bauen. Sie „macht aus deinem Projekt keine native App für Endnutzer“.

PWA vs. Capacitor-Wrapper vs. Neubau: Welchen Weg solltest du wählen?

Wähle eine PWA, wenn du keinen Store-Eintrag brauchst, Capacitor, wenn du einen Eintrag brauchst und echte native Funktionen ergänzen kannst, und einen nativen Neubau, wenn sich deine App wie ein Mobile-first-Produkt anfühlen und verhalten muss.

Die Gebühren stammen von der Anmeldeseite des Apple Developer Program („99 USD pro Mitgliedschaftsjahr. Preise können je nach Region variieren“) und aus der Google Play Console-Hilfe („eine einmalige Registrierungsgebühr von 25 US$“). Bei Google Play müssen neue private Konten außerdem einen geschlossenen Test mit 12 Testern über 14 Tage durchführen, bevor sie Produktionszugriff erhalten. Unser Leitfaden zum geschlossenen Testen behandelt diesen Schritt.

Wie verpackst du eine Lovable-App mit Capacitor?

Exportiere den Lovable-Code nach GitHub, baue ihn lokal, füge Capacitor hinzu und lass webDir auf die Build-Ausgabe zeigen. Öffne dann die nativen Projekte in Xcode und Android Studio und archiviere sie.

1. Verbinde GitHub in Lovable. Die Synchronisierung läuft in beide Richtungen und legt immer ein neues privates Repository an, sodass du in Lovable weiter bearbeiten kannst, während du lokal an der nativen Hülle arbeitest.
2. Klone das Repo, führe npm install und danach npm run build aus. Prüfe, wohin Vite die Ausgabe schreibt, meist nach dist. Capacitor benötigt dort im Stammverzeichnis eine index.html mit einem <head>-Tag.
3. Installiere Capacitor und die Plattformen mit den Befehlen im Codeblock unten, entnommen aus der Capacitor-Dokumentation zum Einstieg.
4. Setze in capacitor.config den Wert webDir auf dist. Setze server.url nicht auf deine Live-Lovable-Domain: Laut der Capacitor-Konfigurationsreferenz ist das „nicht für den Einsatz in der Produktion gedacht“.
5. Füge native Plugins hinzu (Push, Haptik, Teilen, Biometrie, lokale Benachrichtigungen) sowie native App-Icons und Splash-Screens.
6. Führe nach jedem Web-Build npx cap sync aus, archiviere dann in Xcode und lade den Build in App Store Connect hoch. Unsere Checkliste für die App-Store-Einreichung deckt den Rest ab.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Reiche über deinen eigenen Apple-Account ein. Richtlinie 4.2.6 lehnt Apps ab, die mit einem App-Generierungsdienst erstellt wurden, sofern sie nicht „direkt vom Anbieter der App-Inhalte eingereicht“ werden. Unser Leitfaden zu Richtlinie 4.3 und 4.2.6 erklärt, was das für KI-gebaute Apps bedeutet.

Wie vermeidest du mit einer verpackten Lovable-App eine Ablehnung nach Richtlinie 4.2?

Sorge dafür, dass die App Dinge kann, die die Website nicht kann. Richtlinie 4.2 verlangt „Funktionen, Inhalte und eine Benutzeroberfläche, die sie über eine neu verpackte Website hinausheben“, und 4.2.2 schließt Apps aus, die hauptsächlich „Web-Clippings, Content-Aggregatoren oder eine Sammlung von Links“ sind.

Nutze diese Checkliste vor dem Einreichen:

• Der Web-Build ist im Binary gebündelt und öffnet sich auch ohne Netzwerkverbindung, mit zwischengespeicherten Daten oder einem richtigen Offline-Bildschirm.
• Die Navigation nutzt eine Tab-Leiste unten statt eines Hamburger-Menüs, und es gibt keine reinen Web-Footer oder Cookie-Banner.
• Anmeldung, Registrierung und Passwort-Zurücksetzen laufen komplett in der App. Nichts schickt Nutzer nach Safari.
• Mindestens ein Kern-Workflow nutzt das Gerät, etwa Kameraaufnahmen, lokale Benachrichtigungen auf Basis der eigenen Nutzerdaten, Widgets oder Biometrie.
• Externe Links zu Spendenseiten, Shops oder Social Media sind entfernt oder auf ein Minimum reduziert.
• Die Hinweise für App Review erklären, warum die App auf dem Smartphone nützlich ist, und enthalten einen Demo-Login.

Was ist passiert, als andere webbasierte Apps nach 4.2 abgelehnt wurden?

Öffentliche Threads zeigen dasselbe Muster: Reviewer lehnen eine UI ab, die sich nach Web anfühlt, sowie Links nach Safari, und kleine native Funktionen allein ändern ihre Entscheidung nicht.

Im Dezember 2020 berichtete ein Entwickler im Ionic Forum, dass seine App für Vereinsmitgliedschaften abgelehnt wurde mit „Deine App bietet ein eingeschränktes Nutzungserlebnis, da sie sich nicht ausreichend vom mobilen Browsen unterscheidet“, gefolgt von „die meisten Inhalte der App verlinken nach Safari“. InAppBrowser zu entfernen und die Offline-Unterstützung zu verbessern reichte nicht, auch die zweite Einreichung wurde abgelehnt. Der dritte Versuch wurde genehmigt, nachdem der Entwickler den Startbildschirm mit Listen und Bildkarten im nativen Stil neu gebaut, mehr News-Inhalte direkt in der App ergänzt und die meisten externen Links entfernt hatte.

Im Januar 2026 berichtete ein Entwickler in den Apple Developer Forums, dass eine Termin-App als „nicht ausreichend verschieden vom Surfen im Web“ abgelehnt wurde, obwohl sie bereits Push-Benachrichtigungen, Core Location und Kontaktzugriff nutzte. Geplant war, Haptik, Quick Actions und eine tiefere Kalenderintegration hinzuzufügen, und gefragt wurde, was als „nativer“ gilt. Zum Zeitpunkt dieses Artikels hat der Thread keine Antworten und kein bestätigtes Ergebnis.

Der Vergleich: Der erste Entwickler kam durch, weil er verändert hat, was die App ist (Inhalte in der App, native Layouts, keine Links nach außen). Der zweite hat nur Geräte-APIs ergänzt und war weiterhin unsicher. Investiere deinen Aufwand in das Kernerlebnis, nicht in eine längere Liste von Berechtigungen.

Wann solltest du neu bauen statt verpacken?

Baue nativ neu, wenn der Hauptwert deiner App aus Web-Inhalten besteht oder wenn du für dieselbe UI bereits zwei 4.2-Ablehnungen bekommen hast.

Ein durchgerechnetes Beispiel: Ein Lovable-Buchungstool für ein Yogastudio zeigt eine Kursliste, ein Buchungsformular und einen Stripe-Checkout-Link. Unverändert verpackt trifft es alle drei 4.2-Warnsignale: Web-UI, ein Link nach außen und keine Offline-Nutzung. Als PWA kann es heute ohne Zusatzkosten live gehen. Für einen Store-Eintrag behältst du das Lovable-Backend, baust Kursliste und Buchungsablauf mit nativen Screens neu, ergänzt lokale Erinnerungen vor jedem Kurs und wickelst die Zahlung im Rahmen von App-Review-Richtlinie 3.1 ab. Backend und Datenmodell übernimmst du. Neu geschrieben wird die UI.

Wenn du eine zweite Meinung möchtest, welcher Weg zu deinem Lovable-Projekt passt: Die Services von The App Guy umfassen Verpacken, Neubau und Store-Einreichung, oder schreib eine E-Mail an yagyeshsrbobde@gmail.com.