Publish a Lovable, Bolt or Bubble App to the App Store

By Alejandro Morillo · Published 1 October 2026 · 12 min read

You built something with an AI app builder, it works in the browser, and now people ask: "Is it in the App Store?" How you get there depends on what the builder actually produces — a web app, a React Native project, or a native app built inside the tool.

This guide checks what Lovable, Bolt and Bubble offer for mobile according to their own docs, compares the realistic paths to the App Store and Google Play, and covers the review rules and auth traps that hit AI-built apps.

Vendor features and prices are as of October 2026 and can change — each section links the source. Apple quotes are from the App Review Guidelines, last updated June 8, 2026. Nobody can guarantee an approval: App Review decides case by case.

The short answer

Tool	What it builds	Native mobile output?	Shortest path to the stores
Lovable	Web apps (React; new projects on TanStack Start)	No — Lovable "does not generate React Native projects"	Wrap the deployed web app, or export the code and add Capacitor
Bolt	Web apps, or Expo (React Native) apps if you ask for a mobile app from the start	Yes, via Expo	Build and submit with Expo's EAS CLI on your machine
Bubble	Web apps, plus native apps in a separate mobile editor (public beta)	Yes, React Native-based, built in Bubble	Deploy from the Bubble editor on a paid mobile plan

What each tool offers for mobile (as of October 2026)

Lovable

Lovable's FAQ is direct: Lovable builds web applications you can make mobile-friendly, and it "does not generate React Native projects". For the stores it names two paths: turn the published app into a Progressive Web App, or wrap it with a tool like Capacitor and submit that.

Two details matter for the store route:

The stack changed in 2026. New projects use TanStack Start with server-side rendering since May 13, 2026. Older projects run on React + Vite.
That changes how you can package it. Lovable's hosting and ownership page says older React + Vite apps "build to static files that any static host can serve", while TanStack Start apps "run server code". A static build can be bundled into a native shell; a server-rendered app has to be loaded from where it runs.

You can export the code as a zip or via Git. The Lovable mobile app is an editor for your phone, not a way to ship your project.

Bolt

Bolt's Expo integration page explains that when you ask for a mobile app, Bolt uses Expo, so one codebase targets iPhone, Android and web. You preview it by scanning a QR code with the Expo Go app.

Publishing happens outside Bolt: download the code, install Node.js and Git, create an Expo account, then use the EAS CLI — eas build --platform ios --auto-submit sends an iOS build to TestFlight, eas build --platform android produces a file you upload in the Google Play Console. You need your own Apple and Google developer accounts.

Two warnings from the same page: projects created for web "do not easily switch over to mobile", so say "mobile app" in your first prompt; and the app's slug can't be changed after the first build. Expo's build service has a free tier with 15 Android and 15 iOS builds per month in a low-priority queue; paid plans start at $19/month (Expo pricing).

Bubble

Bubble's native mobile editor is in public beta, per its manual. Its native apps are built on React Native, and builds are submitted from the editor without Xcode or Android Studio.

Your web UI doesn't carry over. Bubble's native vs. web guide says native apps use OS-specific components, so you build the mobile screens separately. Database and backend are shared.
Publishing needs a paid plan. Building and on-device testing are free; TestFlight, Google Play testing and the stores need a mobile plan. Mobile-only plans start at $42/month billed annually ($49 monthly), with 5 store builds per month after the first three months; Web + Mobile plans start at $59/month billed annually (pricing, plan details).
It uses your own accounts. For iOS you create an App Store Connect API key in your developer account, and Bubble uploads builds to App Store Connect (iOS guide). For Android, you upload the first .aab manually; after that a service-account key lets Bubble upload builds (Google Play guide).
Over-the-air updates cover most changes without a new store submission.

Three paths to the stores

Path 1: The tool's own native output

Available for Bolt (Expo projects) and Bubble (native editor). You get a React Native app with native navigation and device APIs. The trade-off: it's a second app. If your product already lives on the web, you now maintain two front ends.

Path 2: Wrap the deployed web app

A native shell (WKWebView on iOS, WebView on Android) loads your live site. This works for all three tools, including Lovable's server-rendered projects, and every web deploy reaches the app without a store update.

The trade-off is review risk: a wrapper that only shows a website is exactly what Guideline 4.2 targets. It needs app-style navigation, a proper offline state and a useful first screen — see our Guideline 4.2 guide. Auth flows need attention too (see below).

Path 3: Export the code and build it yourself

For a Lovable React + Vite project or a Bolt web project, add Capacitor to the exported code: npx cap init, point webDir at your build folder, npx cap add ios / android, npx cap sync, then build in Xcode (on a Mac) and Android Studio. In this setup, Capacitor bundles your built files into the app. For Lovable's TanStack Start projects that isn't a drop-in step, because they need a running server. (For a Bolt Expo project, path 3 is path 1 — EAS is the build step.)

Full control — and from then on you own signing certificates, native updates and store builds.

Comparison

	Lovable	Bolt (web project)	Bolt (Expo project)	Bubble
Native output from the tool	No	No	Yes (Expo)	Yes, public beta
Wrap the deployed app	Yes	Yes	Not needed	Yes, for the web app
Export + Capacitor	React + Vite: yes; TanStack Start: needs a server	Yes	—	No — Bubble apps run only on Bubble (manual)
Who submits	You	You	You (EAS + your accounts)	You (your API keys)
Web changes reach the app	Wrapper: instantly; bundled: new build	Same	New build or OTA update	OTA for most changes
Main risk	4.2 for wrappers; auth redirects	Same	Rebuilding as a mobile project	Rebuilding the UI; beta status

App Store rules that hit AI-built apps

4.2 Minimum functionality

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

This applies to every wrapped web app, whichever tool built it. The fixes — bottom navigation, offline handling, no browser behaviour, a useful first screen — are in our Guideline 4.2 article.

4.2.6 Submit from your own developer account

"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."

AI app builders are app generation services in this sense. Submit from your Apple Developer account (99 USD per membership year, per Apple), not a service's or an agency's. All three paths allow that.

4.3 Spam and template-like apps

Similar prompts produce similar apps. Guideline 4.3(b): "Don't submit apps that are indistinguishable from what's already widely available." And 4.3(a) rules out multiple Bundle IDs of the same app — one app per city or client is the textbook case. If your app still looks like the builder's starter template, change that first.

5.1.1(v) Account deletion

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

AI builders generate sign-up flows fast; deletion is easy to forget. Apple's account deletion page adds that deactivating isn't enough, and that if deletion finishes on your website, the app must link directly to that page. Google Play asks for an in-app path and a web link for deletion requests (Play policy). With Supabase, deleting a user requires the service_role key, so it belongs in an edge function, never in the browser.

Guideline 2.1 asks you to "include demo account info (and turn on your back-end service!) if your app includes a login". Create a reviewer account without email confirmation or 2FA, with realistic data, and enter it in App Store Connect.

If Google sign-in sets up the user's primary account, Guideline 4.8 also requires an equivalent login option that limits data collection and lets users keep their email private, such as Sign in with Apple. Apps that exclusively use their own account system are exempt.

Privacy policy and data disclosure

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 also requires app privacy details, including third-party code you integrate, and Google Play requires the Data safety form plus a privacy policy link. If your app sends personal data to an AI API, 5.1.2(i) applies: you must disclose sharing "with third-party AI" and get explicit permission first. List what your generated code actually calls.

Lovable's built-in backend is built on Supabase, and many Bolt projects use Supabase too. Two things break when the web app moves into a native shell.

Email links open the browser, not the app

Confirmation and magic-link emails redirect to your Site URL or an allow-listed redirectTo URL (Supabase redirect URLs). On a phone, tapping the link opens the browser, so the user is signed in there, not in your app. Two fixes:

Register a deep link (custom scheme, universal link or app link) and add it to Additional Redirect URLs, as Supabase's mobile deep linking guide describes.
Or switch to six-digit email codes by adding {{ .Token }} to the email template. The user types the code in the app and never leaves it.

Google OAuth in a WebView is blocked

Google's OAuth 2.0 policies (updated August 2026): "A developer must not direct a Google OAuth 2.0 authorization request to an embedded user-agent under the developer's control." A WKWebView or Android WebView is such a user-agent; users get a 403 disallowed_useragent error. Google's iOS guide names it: developers "may encounter this error when opening authorization requests in WKWebView."

What works instead:

System browser for OAuth. Open sign-in in SFSafariViewController or ASWebAuthenticationSession on iOS, or a Chrome Custom Tab on Android (Google's recommendation), and return through an allow-listed deep link. Capacitor's Browser plugin uses SFSafariViewController on iOS.
Native Google Sign-In with Supabase's signInWithIdToken (Supabase Google guide). Standard for Expo projects; in a wrapper it needs native code.
No Google login in the app — email + password or email codes. Simplest, and it keeps 4.8 out of the picture.

Test on a real device via TestFlight; the browser preview won't show the problem.

Google Play specifics

One-time registration fee of US$25 (Play Console help).
Personal accounts created after November 13, 2023 must run a closed test "with a minimum of 12 testers who have been opted in continuously for at least 14 days" before applying for production (testing requirements). Plan two weeks.
The spam policy bans apps whose primary purpose is to "provide a webview of a website without permission from the website owner" (policy). Wrapping your own site is fine; someone else's isn't.

Checklist before you submit

Path chosen: tool's native output, wrapper, or your own Capacitor/Expo build
Apple Developer Program and Google Play Console accounts in your name (4.2.6)
App-style navigation, offline screen, useful first screen (4.2)
Doesn't look like the builder's starter template; one app, not one per client or city (4.3)
Account deletion in the app; web deletion link for Google Play (5.1.1(v))
Reviewer demo account without email confirmation or 2FA, entered in App Store Connect (2.1)
Sign in with Apple or equivalent if Google login creates the primary account (4.8)
Supabase Additional Redirect URLs include your app's deep link — or email codes instead of links
Google sign-in tested on a device; no OAuth inside the WebView
Privacy policy in the app and store listing; App Privacy details and Data safety form done; AI data sharing disclosed (5.1.2(i))
Only permissions you use, each with a clear purpose string
Google Play: closed test with 12 testers for 14 days (new personal accounts)

Where AppThunder fits

AppThunder covers path 2: it builds iOS and Android apps around your deployed web app in the cloud — a Capacitor-based shell that loads your live site, no coding. It works the same for a Lovable app (including TanStack Start projects), a Bolt web project or a Bubble web app.

Included: native app icon and splash screen, camera and location permission prompts with purpose strings (only if you enable them), a branded offline screen that reloads automatically, a bottom tab bar for your site via a copy-paste snippet (a web snippet, not a native tab bar), Thunder Analytics, and a Guideline Checker that flags common review issues — missing privacy page, login wall, missing account deletion — before you submit. Builds are signed with your own Apple and Google credentials, and iOS builds go to your own App Store Connect (TestFlight), so you submit from your own account as 4.2.6 requires. You get .ipa and .aab files. Paid plans start at €39/month net; the builder and preview are free.

What it doesn't do: it doesn't turn your app into React Native, and it doesn't change your login flow — if your site uses Google sign-in or Supabase email links, you still need one of the fixes above. It doesn't create your demo account, privacy policy or store listing, and you need your own developer accounts. No tool can guarantee an approval.

FAQ

Can Lovable export a native iOS app? No. As of October 2026, Lovable's FAQ says it builds web apps and does not generate React Native projects. You reach the stores by wrapping the published app or adding Capacitor to the exported code.

Can I publish a Bubble app to the stores on the free plan? No. Building and testing are free, but TestFlight, Google Play testing and the stores require a paid mobile plan, as of October 2026.

Will Apple reject an app because it was built with AI? There's no rule against AI-built apps. Review judges the result: whether it does more than a repackaged website (4.2), whether it's distinguishable from what already exists (4.3), and who submits it (4.2.6).

Why does "Sign in with Google" fail in my wrapped app? Google blocks OAuth requests from embedded WebViews. Open sign-in in the system browser and return via a deep link, use native Google Sign-In, or offer email login in the app.

Do I need a Mac? Only for building iOS yourself with Xcode. Expo's EAS, Bubble and cloud wrapper services build in the cloud.