Lovable-, Bolt- oder Bubble-App in den App Store bringen

Von Alejandro Morillo · Veröffentlicht 1. Oktober 2026 · 11 Min. Lesezeit

Du hast mit einem KI-App-Builder etwas gebaut, es läuft im Browser, und jetzt fragen die Ersten: „Gibt's das auch im App Store?" Wie du dorthin kommst, hängt davon ab, was der Builder tatsächlich erzeugt – eine Web-App, ein React-Native-Projekt oder eine native App, die im Tool selbst entsteht.

Dieser Artikel prüft anhand der offiziellen Dokumentation, was Lovable, Bolt und Bubble für Mobile anbieten, vergleicht die realistischen Wege in den App Store und zu Google Play und geht die Review-Regeln und Login-Fallen durch, die KI-gebaute Apps besonders oft treffen.

Funktionen und Preise der Anbieter: Stand Oktober 2026, sie können sich ändern – jeder Abschnitt verlinkt die Quelle. Die Apple-Zitate stammen aus den App Review Guidelines mit Stand 8. Juni 2026, im englischen Original. Eine Freigabe kann niemand garantieren – App Review entscheidet im Einzelfall.

Die kurze Antwort

Tool	Was es baut	Native Mobile-Ausgabe?	Kürzester Weg in die Stores
Lovable	Web-Apps (React; neue Projekte auf TanStack Start)	Nein – Lovable „does not generate React Native projects"	Die veröffentlichte Web-App verpacken oder den Code exportieren und Capacitor ergänzen
Bolt	Web-Apps oder Expo-Apps (React Native), wenn du von Anfang an eine Mobile-App verlangst	Ja, über Expo	Mit Expos EAS-CLI auf deinem Rechner bauen und einreichen
Bubble	Web-Apps, dazu native Apps in einem eigenen Mobile-Editor (Public Beta)	Ja, auf React-Native-Basis, in Bubble gebaut	Aus dem Bubble-Editor deployen, mit kostenpflichtigem Mobile-Plan

Was die Tools für Mobile bieten (Stand Oktober 2026)

Lovable

Lovables FAQ ist eindeutig: Lovable baut Web-Anwendungen, die du mobilfreundlich gestalten kannst, und es „does not generate React Native projects". Für die Stores nennt die FAQ zwei Wege: die veröffentlichte App zur Progressive Web App machen oder sie mit einem Tool wie Capacitor verpacken und einreichen.

Zwei Details sind für den Store-Weg wichtig:

Der Stack hat sich 2026 geändert. Neue Projekte nutzen TanStack Start mit Server-Side Rendering, und zwar seit dem 13. Mai 2026. Ältere Projekte laufen auf React + Vite.
Das ändert, wie du sie verpacken kannst. Laut Lovables Seite zu Hosting und Eigentum erzeugen ältere React-+-Vite-Apps statische Dateien, die jeder statische Host ausliefern kann, während TanStack-Start-Apps Server-Code ausführen. Einen statischen Build kannst du in eine native Hülle packen; eine server-gerenderte App muss von dort geladen werden, wo sie läuft.

Den Code kannst du als ZIP oder per Git exportieren. Die Lovable-App in den Stores ist ein Editor fürs Handy – kein Weg, dein Projekt als App zu veröffentlichen.

Bolt

Bolts Seite zur Expo-Integration erklärt: Wenn du eine Mobile-App verlangst, nutzt Bolt Expo – eine Codebasis für iPhone, Android und Web. Die Vorschau öffnest du, indem du einen QR-Code mit der App Expo Go scannst.

Veröffentlicht wird außerhalb von Bolt: Code herunterladen, Node.js und Git installieren, ein Expo-Konto anlegen, dann die EAS-CLI nutzen – eas build --platform ios --auto-submit schickt einen iOS-Build an TestFlight, eas build --platform android erzeugt eine Datei, die du in der Google Play Console hochlädst. Eigene Entwicklerkonten bei Apple und Google brauchst du in jedem Fall.

Zwei Warnungen von derselben Seite: Für das Web angelegte Projekte „do not easily switch over to mobile" – schreib also gleich im ersten Prompt „mobile app"; und den Slug der App kannst du nach dem ersten Build nicht mehr ändern. Expos Build-Dienst hat eine kostenlose Stufe mit 15 Android- und 15 iOS-Builds pro Monat in einer Warteschlange mit niedriger Priorität; bezahlte Pläne beginnen bei 19 $ pro Monat (Expo-Preise).

Bubble

Bubbles nativer Mobile-Editor ist laut Handbuch in der Public Beta. Die nativen Apps basieren auf React Native, und Builds werden direkt aus dem Editor eingereicht, ohne Xcode oder Android Studio.

Deine Web-Oberfläche wird nicht übernommen. Bubbles Leitfaden Native vs. Web erklärt, dass native Apps betriebssystemspezifische Komponenten nutzen – die Mobile-Screens baust du also separat. Datenbank und Backend teilen sich Web und Mobile.
Veröffentlichen kostet. Bauen und auf dem Gerät testen ist kostenlos; TestFlight, Google-Play-Tests und die Stores brauchen einen Mobile-Plan. Reine Mobile-Pläne beginnen bei 42 $ pro Monat bei jährlicher Zahlung (49 $ monatlich) mit 5 Store-Builds pro Monat nach den ersten drei Monaten; Web-+-Mobile-Pläne beginnen bei 59 $ pro Monat bei jährlicher Zahlung (Preise, Plandetails).
Es nutzt deine eigenen Konten. Für iOS legst du in deinem Entwicklerkonto einen App-Store-Connect-API-Schlüssel an, und Bubble lädt die Builds zu App Store Connect hoch (iOS-Anleitung). Für Android lädst du die erste .aab manuell hoch; danach erlaubt ein Service-Account-Schlüssel Bubble den Upload (Google-Play-Anleitung).
Over-the-Air-Updates decken die meisten Änderungen ab, ohne neue Store-Einreichung.

Drei Wege in die Stores

Weg 1: Die native Ausgabe des Tools

Verfügbar bei Bolt (Expo-Projekte) und Bubble (nativer Editor). Du bekommst eine React-Native-App mit nativer Navigation und Gerätefunktionen. Der Haken: Es ist eine zweite App. Lebt dein Produkt schon im Web, pflegst du ab jetzt zwei Frontends.

Weg 2: Die veröffentlichte Web-App verpacken

Eine native Hülle (WKWebView auf iOS, WebView auf Android) lädt deine Live-Website. Das funktioniert mit allen drei Tools, auch mit Lovables server-gerenderten Projekten, und jedes Web-Deployment landet ohne Store-Update in der App.

Der Haken ist das Review-Risiko: Eine Hülle, die nur eine Website zeigt, ist genau das, worauf Guideline 4.2 zielt. Sie braucht eine App-typische Navigation, einen sauberen Offline-Zustand und einen nützlichen ersten Screen – siehe unseren Artikel zu Guideline 4.2. Auch die Login-Abläufe brauchen Aufmerksamkeit (siehe unten).

Weg 3: Code exportieren und selbst bauen

Bei einem Lovable-Projekt auf React + Vite oder einem Bolt-Webprojekt ergänzt du den exportierten Code um Capacitor: npx cap init, webDir auf deinen Build-Ordner setzen, npx cap add ios / android, npx cap sync, dann in Xcode (auf einem Mac) und Android Studio bauen. In diesem Setup bündelt Capacitor deine gebauten Dateien in die App. Bei Lovables TanStack-Start-Projekten ist das kein einfacher Schritt, weil sie einen laufenden Server brauchen. (Bei einem Bolt-Expo-Projekt ist Weg 3 gleich Weg 1 – EAS ist der Build-Schritt.)

Volle Kontrolle – und ab dann gehören Signaturzertifikate, native Updates und Store-Builds dir.

Vergleich

	Lovable	Bolt (Webprojekt)	Bolt (Expo-Projekt)	Bubble
Native Ausgabe des Tools	Nein	Nein	Ja (Expo)	Ja, Public Beta
Veröffentlichte App verpacken	Ja	Ja	Nicht nötig	Ja, für die Web-App
Export + Capacitor	React + Vite: ja; TanStack Start: braucht einen Server	Ja	–	Nein – Bubble-Apps laufen nur auf Bubble (Handbuch)
Wer reicht ein	Du	Du	Du (EAS + deine Konten)	Du (deine API-Schlüssel)
Web-Änderungen in der App	Hülle: sofort; gebündelt: neuer Build	Wie Lovable	Neuer Build oder OTA-Update	OTA für die meisten Änderungen
Hauptrisiko	4.2 bei Hüllen; Login-Weiterleitungen	Wie Lovable	Neuaufbau als Mobile-Projekt	Neuaufbau der Oberfläche; Beta-Status

App-Store-Regeln, die KI-gebaute Apps treffen

4.2 Minimum Functionality

„Your app should include features, content, and UI that elevate it beyond a repackaged website."

Das gilt für jede verpackte Web-App, egal welches Tool sie gebaut hat. Die Lösungen – Navigation unten, Offline-Zustand, kein Browser-Verhalten, ein nützlicher erster Screen – stehen in unserem Artikel zu Guideline 4.2.

4.2.6 Einreichen aus dem eigenen Entwicklerkonto

„Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content."

KI-App-Builder sind App-Generierungsdienste in diesem Sinn. Reiche aus deinem Apple-Developer-Konto ein (99 USD pro Mitgliedsjahr, laut Apple), nicht aus dem eines Dienstes oder einer Agentur. Alle drei Wege lassen das zu.

4.3 Spam und App-Vorlagen

Ähnliche Prompts erzeugen ähnliche Apps. Guideline 4.3(b): „Don't submit apps that are indistinguishable from what's already widely available." Und 4.3(a) schließt mehrere Bundle IDs derselben App aus – eine App pro Stadt oder Kunde ist der Lehrbuchfall. Sieht deine App noch aus wie die Startvorlage des Builders, ändere das zuerst.

5.1.1(v) Konto-Löschung

„If your app supports account creation, you must also offer account deletion within the app."

KI-Builder erzeugen Registrierungen schnell; die Löschung wird leicht vergessen. Apples Seite zur Konto-Löschung ergänzt: Deaktivieren reicht nicht, und wenn die Löschung auf deiner Website abgeschlossen wird, muss die App direkt auf diese Seite verlinken. Google Play verlangt einen Weg in der App und einen Web-Link für Löschanfragen (Play-Richtlinie). Bei Supabase braucht das Löschen eines Nutzers den service_role-Schlüssel – das gehört in eine Edge Function, niemals in den Browser.

Guideline 2.1 verlangt „demo account info (and turn on your back-end service!)", wenn deine App einen Login hat. Leg einen Reviewer-Account ohne E-Mail-Bestätigung und ohne 2FA an, mit realistischen Daten, und trag ihn in App Store Connect ein.

Legt Google-Login das Hauptkonto der Nutzer an, verlangt Guideline 4.8 zusätzlich eine gleichwertige Login-Option, die die Datenerhebung begrenzt und es erlaubt, die E-Mail-Adresse privat zu halten – etwa „Mit Apple anmelden". Apps, die ausschließlich ihr eigenes Kontosystem nutzen, sind ausgenommen.

Datenschutzerklärung und Offenlegung

5.1.1(i): „All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." App Store Connect verlangt außerdem Angaben zum App-Datenschutz, auch zu eingebundenem Fremdcode, und Google Play das Formular zur Datensicherheit samt Link zur Datenschutzerklärung. Schickt deine App personenbezogene Daten an eine KI-API, greift 5.1.2(i): Du musst die Weitergabe „with third-party AI" offenlegen und vorher ausdrücklich um Erlaubnis fragen. Liste auf, was dein generierter Code tatsächlich aufruft.

Lovables eingebautes Backend basiert auf Supabase, und viele Bolt-Projekte nutzen Supabase ebenfalls. Zwei Dinge gehen kaputt, wenn die Web-App in eine native Hülle wandert.

E-Mail-Links öffnen den Browser, nicht die App

Bestätigungs- und Magic-Link-Mails leiten auf deine Site URL oder eine freigegebene redirectTo-URL weiter (Supabase-Redirect-URLs). Auf dem Handy öffnet der Link den Browser – der Nutzer ist dann dort angemeldet, nicht in deiner App. Zwei Lösungen:

Registriere einen Deep Link (eigenes URL-Schema, Universal Link oder App Link) und trag ihn unter Additional Redirect URLs ein, wie Supabases Anleitung zu Mobile Deep Linking beschreibt.
Oder stell auf sechsstellige E-Mail-Codes um, indem du {{ .Token }} ins E-Mail-Template einfügst. Der Nutzer tippt den Code in der App ein und verlässt sie nie.

Google-OAuth in einer WebView ist gesperrt

Googles OAuth-2.0-Richtlinien (aktualisiert August 2026): „A developer must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer's control." Eine WKWebView oder Android-WebView ist so ein eingebetteter User-Agent; Nutzer sehen den Fehler 403 disallowed_useragent. Googles iOS-Anleitung nennt den Fall ausdrücklich: Entwickler „may encounter this error when opening authorization requests in WKWebView."

Was stattdessen funktioniert:

System-Browser für OAuth. Öffne die Anmeldung in SFSafariViewController oder ASWebAuthenticationSession auf iOS bzw. einem Chrome Custom Tab auf Android (Googles Empfehlung) und kehr über einen freigegebenen Deep Link zurück. Capacitors Browser-Plugin nutzt auf iOS SFSafariViewController.
Native Google-Anmeldung mit Supabases signInWithIdToken (Supabase-Anleitung zu Google). Standard bei Expo-Projekten; in einer Hülle braucht es nativen Code.
Kein Google-Login in der App – E-Mail + Passwort oder E-Mail-Codes. Am einfachsten, und 4.8 ist damit vom Tisch.

Teste auf einem echten Gerät über TestFlight; die Browser-Vorschau zeigt das Problem nicht.

Besonderheiten bei Google Play

Einmalige Registrierungsgebühr von 25 US-Dollar (Play-Console-Hilfe).
Private Konten, die nach dem 13. November 2023 erstellt wurden, müssen einen geschlossenen Test „with a minimum of 12 testers who have been opted in continuously for at least 14 days" durchführen, bevor sie Produktionszugriff beantragen können (Testanforderungen). Plan zwei Wochen ein.
Die Spam-Richtlinie verbietet Apps, deren Hauptzweck es ist, „provide a webview of a website without permission from the website owner" (Richtlinie). Deine eigene Website zu verpacken ist in Ordnung, eine fremde nicht.

Checkliste vor dem Einreichen

Weg gewählt: native Ausgabe des Tools, Hülle oder eigener Capacitor-/Expo-Build
Apple-Developer-Program- und Google-Play-Console-Konto auf deinen Namen (4.2.6)
App-typische Navigation, Offline-Screen, nützlicher erster Screen (4.2)
Sieht nicht aus wie die Startvorlage des Builders; eine App, nicht eine pro Kunde oder Stadt (4.3)
Konto-Löschung in der App; Web-Link zur Löschung für Google Play (5.1.1(v))
Reviewer-Demo-Account ohne E-Mail-Bestätigung und 2FA, in App Store Connect eingetragen (2.1)
„Mit Apple anmelden" oder gleichwertig, falls Google-Login das Hauptkonto anlegt (4.8)
Supabase-Additional-Redirect-URLs enthalten den Deep Link deiner App – oder E-Mail-Codes statt Links
Google-Anmeldung auf einem Gerät getestet; kein OAuth in der WebView
Datenschutzerklärung in der App und im Store-Eintrag; App-Datenschutzangaben und Datensicherheitsformular ausgefüllt; KI-Datenweitergabe offengelegt (5.1.2(i))
Nur Berechtigungen, die du nutzt, jeweils mit klarem Begründungstext
Google Play: geschlossener Test mit 12 Testern über 14 Tage (neue private Konten)

Wo AppThunder ins Spiel kommt

AppThunder deckt Weg 2 ab: Es baut iOS- und Android-Apps um deine veröffentlichte Web-App herum, in der Cloud – eine Capacitor-basierte Hülle, die deine Live-Website lädt, ohne Programmieren. Das funktioniert gleich für eine Lovable-App (auch TanStack-Start-Projekte), ein Bolt-Webprojekt oder eine Bubble-Web-App.

Enthalten: natives App-Icon und Splash-Screen, Abfragen für Kamera- und Standort-Berechtigung mit Begründungstexten (nur wenn du sie aktivierst), eine gebrandete Offline-Seite, die automatisch neu lädt, eine untere Tab-Leiste für deine Website per Copy-Paste-Snippet (ein Web-Snippet, keine native Tab-Leiste), Thunder Analytics und ein Guideline Checker, der typische Review-Probleme – fehlende Datenschutzseite, Login-Wand, fehlende Konto-Löschung – vor dem Einreichen markiert. Builds werden mit deinen eigenen Apple- und Google-Zugangsdaten signiert, iOS-Builds landen in deinem eigenen App Store Connect (TestFlight) – du reichst also aus deinem eigenen Konto ein, wie 4.2.6 es verlangt. Du bekommst .ipa- und .aab-Dateien. Bezahlte Pläne beginnen bei 39 € pro Monat netto; Builder und Vorschau sind kostenlos.

Was es nicht macht: Es verwandelt deine App nicht in React Native und ändert deinen Login-Ablauf nicht – nutzt deine Website Google-Anmeldung oder Supabase-E-Mail-Links, brauchst du trotzdem eine der Lösungen oben. Demo-Account, Datenschutzerklärung und Store-Eintrag erstellst du selbst, und eigene Entwicklerkonten brauchst du auch. Eine Freigabe kann kein Tool garantieren.

FAQ

Kann Lovable eine native iOS-App exportieren? Nein. Laut Lovables FAQ (Stand Oktober 2026) baut Lovable Web-Apps und erzeugt keine React-Native-Projekte. In die Stores kommst du, indem du die veröffentlichte App verpackst oder den exportierten Code um Capacitor ergänzt.

Kann ich eine Bubble-App mit dem kostenlosen Plan in die Stores bringen? Nein. Bauen und Testen sind kostenlos, aber TestFlight, Google-Play-Tests und die Stores erfordern einen kostenpflichtigen Mobile-Plan (Stand Oktober 2026).

Lehnt Apple eine App ab, weil sie mit KI gebaut wurde? Es gibt keine Regel gegen KI-gebaute Apps. Das Review bewertet das Ergebnis: ob es mehr ist als eine umverpackte Website (4.2), ob es sich von Bestehendem unterscheidet (4.3) und wer einreicht (4.2.6).

Warum scheitert „Mit Google anmelden" in meiner verpackten App? Google blockiert OAuth-Anfragen aus eingebetteten WebViews. Öffne die Anmeldung im System-Browser und kehr per Deep Link zurück, nutze die native Google-Anmeldung oder biete in der App einen E-Mail-Login an.

Brauche ich einen Mac? Nur, wenn du iOS selbst mit Xcode baust. Expos EAS, Bubble und Cloud-Wrapper-Dienste bauen in der Cloud.