Why you can't publish a Lovable app to Google Play directly
Lovable is an AI builder that turns natural-language prompts into a working web app — React frontend, Supabase backend, deployed to a live URL. That's exactly what makes it fast. It's also why it stops at the door of the Play Store.
Google Play doesn't distribute websites. It distributes Android App Bundles — .aab files that have to be compiled, cryptographically signed, and uploaded through the Play Console. Lovable never produces that file. There's no "Export to Android" button, and there never will be, because that's simply not what the platform is for.
This isn't a Lovable limitation specifically. The exact same gap exists with Bolt, Replit, Base44, v0, Vercel and Netlify. They all hand you a URL. Turning that URL into a store-ready Android app is a separate job that none of them do for you. So the real question isn't "can I publish my Lovable app to Google Play?" — you can. It's "what's the shortest path from a live Lovable URL to an .aab Google will accept?"
What you actually need before you start
Before a single line of your app reaches the Play Store, you need four things in place:
- A stable production URL. Your Lovable project, published, on a custom domain you control. Reviewers load this URL, so it has to be live and reliable — not a preview link.
- A Google Play Console account. A one-time $25 registration fee (not annual). Use an organization account if you have a registered business — it skips the testing requirement below.
- A signed Android App Bundle (.aab). The compiled, signed artifact Google ingests. This is the piece Lovable can't give you.
- Store-listing assets. App name, short and full descriptions, an icon, a feature graphic, at least two screenshots, a content rating questionnaire, and — non-negotiable — a privacy policy URL.
Items 1, 2 and 4 you handle yourself. Item 3 is where you choose a method.
The three ways to turn a Lovable app into an Android app
There are exactly three technical paths. They differ in effort, cost, and how likely they are to survive review.
1. Trusted Web Activity / build platform — recommended for most
A Trusted Web Activity (TWA) runs your published web app inside a real Android shell with no browser chrome — it looks and behaves like a native app, and Google fully supports the pattern. The output is a genuine signed .aab you own. This is the model SaasToStore is built on: paste your Lovable URL, configure the app, and it compiles a signed .aab you download and keep — no Android Studio, no certificate wrangling, and crucially no monthly subscription. It's one-time pay-per-build, so the app is yours, not rented.
2. Capacitor — for developers who want native plugins
Capacitor (by the Ionic team) is the open-source route. You export your Lovable project to GitHub, install Capacitor, copy your build into the native container, add plugins, then compile and sign in Android Studio. Deepest access to native APIs, and free — but you manage the keystore, package identifier, signing config and every Google feedback loop yourself.
3. Hand-built native / React Native — rarely necessary
Rebuilding natively gives maximum control and performance. For a Lovable app that already works as a responsive web app, it also means rebuilding everything you already have. Most teams never need this.
For 90% of Lovable founders, path 1 ships to the store in days. Path 2 is the developer's option. Path 3 is for when nothing else fits.
Step-by-step: from Lovable to live on Google Play
Here's the full sequence, assuming the recommended TWA/build-platform route.
Lock down your production URL
Make your app pass Google's “minimum functionality” bar
Generate your signed .aab
com.yourbrand.app), icon, splash screen — and generate the bundle. Keep the signing key safe: it's tied to your app's identity on Google Play forever.Create your app in the Play Console and complete the listing
Clear the closed-testing requirement (the part nobody warns you about)
Apply for production access and roll out
How long does it actually take?
| Scenario | Realistic timeline |
|---|---|
| Building the web app in Lovable | Hours |
| Generating a signed .aab (build platform) | Minutes to an hour |
| Completing the store listing | A few hours |
| Org account → first production review | ~1–3 days |
| New personal account → first review | ~14 days (closed-testing gate) + review |
The bottleneck is almost never the build. It's the Play Console account type and the testing window. Decide on an organization account before you start if you can.
What about the Apple App Store?
If you also want iOS, the shape is similar but the specifics differ:
- Apple Developer Program: $99/year (versus Google's one-time $25).
- You submit an .ipa through App Store Connect.
- Guideline 4.2 is Apple's minimum-functionality rule — same principle as Google's, enforced a bit more strictly. Push, biometrics and deep linking generally clear it.
- Review typically takes 24–72 hours, but organization verification can take 2–4 weeks, so start it early.
The rejection reasons that catch vibe-coders off guard
Most rejections are configuration problems, not architecture problems — which means they're fast to fix once you know them:
- Minimum functionality (policy 4.3 / Spam). A bare wrapper with no native features. Fix: add push, biometrics, deep links.
- Missing or inaccessible privacy policy. Required on both stores. Fix: publish one and link it.
- Payments for digital goods via Stripe. Apple and Google both require their own billing for digital content and subscriptions. Stripe is fine for physical goods and services, but using it for in-app digital purchases gets you rejected. Plan monetization around this from day one.
- Undeclared permissions. iOS needs purpose strings in
Info.plist; Android needs declarations inAndroidManifest.xml. Missing entries are an instant flag.
Read every rejection notice in full — both stores name the exact policy you tripped, which makes the fix easy to scope. Then patch, rebuild, and resubmit.
Do I have to resubmit every time I update my Lovable app?
No — and this is one of the best things about the TWA/wrapper model. Because the app loads your live URL, any change you publish in Lovable appears in the installed app automatically, with no new store submission. You only resubmit when something in the native shell changes: the app name, icon, package identifier, or a newly requested device permission. Routine content and UI updates ship instantly.
The fastest path, summarized
- Publish your Lovable app to a stable custom domain.
- Use a build platform to generate a signed .aab you own.
- Add 2–3 real native features so you clear minimum-functionality.
- Register an organization Play Console account if you possibly can — it skips the 14-day testing gate.
- Complete the listing, run the closed test if required, then submit.
SaasToStore was built for this last mile. Paste your Lovable URL, get a signed native build for the Play Store — plus Windows, macOS and Linux installers — with push notifications and biometric login available, one-time payment, no subscription, the build is yours. iOS is on the way. You bring the app you already made; SaasToStore puts it in front of the people it's for.
→ Run the free PWA check on your Lovable URL · See pricing
This article is for informational purposes and reflects Google Play and Apple App Store requirements as of 2026; store policies change, so confirm current rules in the official Play Console and App Store Connect documentation before submitting.