How to publish your no-code app to Google Play

To publish a no-code app on Google Play: register a developer account ($25 once), open the exported Android Studio project, create a signing key, build a signed app bundle (AAB), create the app in Play Console, fill in the listing and the data-safety form, upload the bundle to a testing track, then promote it to production. First review of a new account's first app takes from a day to about a week. Here is each step with the details that matter.

1. Register as a developer

At play.google.com/console, pay the one-time $25 fee and verify your identity (ID document, sometimes a phone). Personal accounts created recently must run a closed test with at least 12 testers for 14 days before production access is granted — plan for that. Organisation accounts skip it but need a D-U-N-S number.

2. Open the exported project

Unzip the export, open the folder in Android Studio, let Gradle sync. The project pins its own Gradle and Android Gradle Plugin versions, so it builds without changes. Press Run once on a real phone to confirm it behaves like the preview.

3. Set the identity

Check applicationId in app/build.gradle.kts — this is your app's permanent name on Play and cannot change later. Use reverse-domain style, com.yourbusiness.appname. Set versionCode to 1 and versionName to "1.0".

4. Create a signing key

Build → Generate Signed Bundle → Create new keystore. Choose a strong password and back the keystore file up somewhere safe; every future update must be signed with it. Enrol in Play App Signing when asked — Google keeps the final key and your upload key can be reset if lost.

5. Build the app bundle

Generate Signed Bundle → Android App Bundle → release. You get app-release.aab. Play requires AAB, not APK, for new apps.

6. Create the app in Play Console

Name, default language, app or game, free or paid (free cannot become paid later). Then the dashboard's setup checklist walks you through:

• Privacy policy URL — required. A short page saying what the app collects (often nothing) is enough; put it on any website you control.
• App access — if any part needs a login or PIN (an owner view), provide test credentials.
• Ads — declare honestly. Generated apps contain no ad SDK unless you add one.
• Content rating — a questionnaire; most business apps rate Everyone.
• Target audience — pick 18+ or 13+ unless the app is for children, which brings extra policy.
• Data safety — see below.

7. The data-safety form

Answer from the exported manifest and what the app actually does. Typical honest answers: a local-only tracker collects no data; an app that sends enquiries by WhatsApp does not itself collect data (the message leaves via another app); an app with a backend collects whatever the form fields are. Declaring more than you collect is as much a problem as declaring less — reviewers compare the form with the binary.

8. Store listing

• Title up to 30 characters; the real app name, with a keyword if it fits ("Fade Lab – Barber Booking").
• Short description 80 characters; the one-line promise.
• Full description up to 4,000; what it does, for whom, the key features, no keyword stuffing.
• Icon 512×512 PNG; feature graphic 1024×500; at least 2 phone screenshots, ideally 4–8 — take them from the running app.

9. Upload to a testing track

Testing → Closed testing → create a release, upload the AAB, add testers by email list. Share the opt-in link. Once the 14 days and 12 testers are met (personal accounts), apply for production access.

10. Production

Create a production release from the same bundle, choose countries, review the summary, roll out. New apps and updates are reviewed; expect one to seven days the first time and hours thereafter.

Rejections that catch first-timers

After launch

Each year Play raises the required target SDK; rebuild and re-upload when Android Studio prompts. Updates are the same flow with versionCode incremented. Changes made in the builder — export again, open, bump the version, build, upload — take about fifteen minutes.