How to Publish a Lovable App on Google Play

Google Play is often described as the easier store, and on the review side it usually is. The part that surprises Lovable builders is the calendar: for many new accounts, Google requires two weeks of closed testing before you can even apply for production. This guide is organized as a timeline so you can start the slow steps first.

Decide on your developer account type first

If you are publishing for a business, an organization account is usually the right choice anyway. Google's policies change, so confirm the current rules in the Play Console Help Center. The testing requirement is explained in detail in the 12-tester rule explained.

Week 0: Set up accounts and prepare the web app

• Register the Google Play developer account and complete verification.
• Deploy your Lovable app on a stable production domain.
• Prepare a privacy policy URL, app icon (512 x 512), feature graphic (1024 x 500) and phone screenshots.
• Add in-app account deletion if users can create accounts, and provide a web link for deletion requests as Google requires.
• Remove web-only elements that look odd in an app, such as "Get it on Google Play" badges.

Week 1: Package the Android app

Three packaging options work for Lovable apps:

1. WebView wrapper. A native Android shell loads your URL and adds native features: push notifications, offline screen, file uploads, back-button handling. A template such as WebViewGold gives you a ready Android Studio project without writing Kotlin.
2. Trusted Web Activity (TWA). Runs your site in Chrome full-screen, verified via Digital Asset Links. Good for PWAs; native features are more limited and depend on web APIs.
3. Capacitor. Bundles the built web files with native plugins. Most control, most maintenance.

Whichever you pick, three technical requirements apply:

• Android App Bundle (AAB) format is required for new apps.
• Target API level must be recent, roughly within a year of the latest major Android release. Check the current deadline in Play Console before building.
• Signing: enroll in Play App Signing and keep your upload key safe and backed up.

Android-specific pitfalls for Lovable apps: file inputs need explicit handling in a WebView, Google sign-in does not work in embedded WebViews (use the system browser or Custom Tabs plus a deep link back), and the hardware back button should navigate within the app rather than closing it.

Weeks 1 to 3: Store listing, policies and closed test

1. Create the app in Play Console and complete the Data safety form. Declare everything collected by Supabase auth, analytics, crash reporting and any SDKs. See privacy labels and the data safety form.
2. Complete the content rating questionnaire, target audience, ads declaration and app access instructions (provide a working demo login).
3. Upload the AAB to the closed testing track and invite at least 12 testers via email list or Google Group. They must opt in and stay opted in for 14 consecutive days.
4. Ask testers to actually use the app and send feedback; Google asks about your testing when you apply for production.
5. Fix issues and upload new builds during the test; this does not reset the opt-in period.

Week 3 to 4: Apply for production and roll out

• Apply for production access in Play Console and answer the questions about your test.
• Once approved, create a production release. Consider a staged rollout to a percentage of users first.
• Monitor Android vitals (crashes, ANRs) and pre-launch reports for device-specific issues.

If Google flags a policy issue, the message names the policy. Common fixes are covered in Google Play rejections and policy violations.

What to test on real Android devices

Android device diversity is larger than on iOS, and WebView behavior can differ by manufacturer and system version. Use your closed test productively and check at least:

• Login, logout and session restore after the app has been closed for a day.
• Social login through the system browser and the deep link back into the app.
• File and photo uploads from the camera and the gallery.
• Push notification permission prompt (required as a runtime permission on recent Android versions) and delivery when the app is closed.
• Behavior with no connection and with a slow mobile connection.
• Hardware back button on every main screen, including inside modals.
• Dark mode and large system font sizes, which often break layouts generated for desktop first.

Google's pre-launch report runs your build on a range of devices automatically and is worth reviewing before you apply for production.

Common mistakes with Lovable apps on Google Play

• Starting the closed test with fewer than 12 active testers, or testers who opt out, and losing days.
• Data safety answers that do not match what the SDKs actually collect.
• Uploading a debug build or a build targeting an outdated API level.
• Losing the upload key. With Play App Signing you can request a reset, but it takes time.
• Planning the iOS release separately; doing both together saves duplicate work. See publishing a Lovable app to the App Store.

If you prefer to hand off the build and submission work, appsubmitter.io sets up CI/CD, signs and submits Android and iOS builds in your own developer accounts and guides you through policy issues. To talk through your timeline, book a free intro call.