Getting Your Lovable App on Google Play

Android is the easier store. Everybody says that, and it’s mostly true, which is why it’s so annoying when a founder tells us they’ve been “almost on Google Play” for five weeks.

The review itself isn’t usually the problem. Google is a lot more relaxed than Apple about apps that are mostly a website. What slows people down is everything before the review: the account, the testers, the signing key, and picking a way to package a Lovable app that you won’t regret in three months.

Three ways to package it

A Trusted Web Activity (TWA). This is Chrome running your site full screen, with no address bar, inside an Android app shell. Google built it for exactly this case. You generate the project with Bubblewrap (npx @bubblewrap/cli init --manifest https://yourapp.com/manifest.json), host an assetlinks.json file at /.well-known/ on your domain so Android trusts it, and build an .aab. If your Lovable app is already a decent PWA, you can have a working build in an afternoon.

The downside is that it is still your website. No real push notifications beyond what web push gives you, no native camera flows, and if assetlinks.json is wrong the address bar comes back and the app looks broken. We’ve seen that last one more times than we’d like. The SHA-256 fingerprint in that file has to be the one from Play App Signing, not your local upload key, and the Play Console hides it under Setup, then App signing.

Capacitor. Your Lovable build gets bundled into a native Android project, and you get plugins for push, camera, haptics, deep links, biometrics. This is the middle ground and what we use most for founders who want “a real app” without a rewrite. You keep shipping web code from Lovable, and the native bits sit around it.

It’s not free, though. You now own an Android Studio project, Gradle versions, a minSdkVersion, and a build that someone has to run every time you want an update in the store. Lovable doesn’t do that part for you.

A native rebuild in Flutter or React Native. More work, more money, a much better app. We’d only push this if the app is something people open ten times a day, or if offline use matters.

For a first Android release, we’d pick Capacitor for most Lovable apps and TWA for content-heavy ones like directories, booking pages and dashboards that people check occasionally. TWA is the one we’d talk people out of most often, oddly, because founders start with it to save money and then want push notifications two weeks after launch.

The 12-tester rule nobody reads about until it’s too late

If you make a new personal Google Play developer account, Google won’t let you publish to production straight away. You have to run a closed test with at least 12 testers who stay opted in for 14 days in a row. Then you apply for production access, and Google asks you questions about the test.

This catches almost everyone. One founder we worked with had the build ready, store listing done, screenshots made, and then found out they needed 12 Android users from their own network. They had 7. Most of their friends were on iPhones. It took nine extra days to find the rest, mostly from a WhatsApp group of an old university class, and two testers dropped out on day 10, which reset nothing but did cause a scare.

A few things that help:

• Register as an organization account if you have a company. It needs a D-U-N-S number, which is free but slow to get, and organization accounts skip the 12-tester requirement.
• Start the closed test the same day your build installs at all. It doesn’t need to be finished. Testers just need to stay opted in.
• Ask testers to actually open the app a few times. Google asks how testers engaged, and “they installed it” is a weak answer.

The account costs $25 once. Identity verification can take a couple of days, sometimes longer if the name on your ID doesn’t match the account name exactly.

Things that get Android builds rejected

Rejections on Google Play for Lovable apps are rarer than on Apple, but we see the same three over and over.

The data safety form doesn’t match the app. If your app has Supabase auth, you collect email addresses. If you use any analytics, you collect device identifiers. Founders tick “no data collected” because they think of the database as theirs, and the review flags it.

There’s no account deletion path. If users can sign up in your app, Google requires a way to delete the account both inside the app and from a web link you put in the Play Console. Lovable apps almost never have this out of the box. It’s a small feature, maybe an hour with an edge function, but you have to build it.

Login walls with no test credentials. If the whole app sits behind sign in, give the reviewer a working demo account in the App access section. Otherwise they see a login screen and reject it for not being able to review.

Before you start

Make sure your Lovable app works properly on a cheap Android phone, not just the Chrome device toolbar. Mid-range Samsungs with the keyboard open are where layouts with 100vh fall apart, and you’ll find that out from a one-star review otherwise.

And if your backend is still on Lovable Cloud, think about whether you want to move it to your own Supabase before launch. Mobile apps make people more careful about who holds their data, and it’s easier to switch before you have Play Store users than after.

If you want someone else to deal with the Gradle files and the tester spreadsheet, that’s what we do. Tell us about your app on the contact page.