Publish a Vibe-Coded App to Google Play: Tool by Tool

Yes, you can publish an app that AI wrote. Google has no policy category that rejects an app for how its code was written, and nothing in the Play Console asks who generated the source. What decides your route is the project your builder hands you: a web app, an Expo project, a Flutter project, or a native Kotlin one. Each needs a different step before Google Play will accept it, because Play does not review projects. It reviews a signed Android App Bundle (.aab).

Three things then apply to every one of those routes. If your Play Console account is a personal account created after November 13, 2023, a closed test with at least 12 testers opted in continuously for 14 days stands between you and production access. Two technical checks, target API level 36 and 16 KB memory page sizes, should happen before your first upload rather than after your first rejection. And if you only want the app on your own phone, Google opened a separate private channel on October 13, 2026 that needs no developer account at all. Current as of October 28, 2026.

What does your AI builder actually hand you?

The prompt is not the problem; the project file is. Every builder stops at one of four outputs, and each one needs a different step before Play Console accepts it. The table below maps the tools developers bring to us most often to the artifact they produce, the command or button that turns it into an .aab, and where that first upload lands.

Two details in that table decide whether your first fortnight counts, and both are explained below: where the build lands, and whether the app is more than a URL in a shell. If you want the long version of what an .aab actually is, it is covered in Google Play's App Bundle explained.

Does Google allow an app written by AI?

Yes. We found no Google policy that bans an app because AI wrote its code, and the Play Console submission flow has no field for it. The policies that catch weak AI-built apps are the general ones, and they judge the finished app, not its origin:

• Functionality. Google's policy states: "We do not allow apps that only have limited functionality and content." Its listed violations include apps that are static without app-specific functionality and apps designed to do nothing.
• Broken behavior. The same policy article prohibits apps that crash, force close, freeze, do not install, or install but do not load.
• Runtime AI output. If your app itself generates content with a model, Google's AI-Generated Content policy requires in-app reporting or flagging so users can report offensive output without leaving the app.

Honest limitation: Google has published guidance on quality, and guidance on AI-generated content inside apps, but we found no dated Google statement that treats AI-written source code as a review category of its own. Treat any claim that "Google rejects AI apps" as unsupported until Google says it.

There is also nothing you need to disclose. We found no Play Console field asking how the app was built, no declaration about AI assistance, and no review note that expects one. A reviewer sees the installed build, the listing, and the declarations you filed. In practical terms this means the useful preparation is ordinary: click every screen on a real phone, force a network failure, rotate the display, and install the .aab on a device you have never tested it on. Generated code tends to fail in predictable places, usually empty states, back navigation, and anything that touches storage or permissions after the app has been backgrounded. Those are the failures Google's functionality policy is written to catch, and none of them asks who wrote the code.

Why does the default track waste your first two weeks?

Look again at the last column of the table. Every builder's default first upload goes to internal testing. Google's own track table lists internal testing's access requirement as none, and lists production's requirement as a closed test with at least 12 opted-in testers continuously for 14 days. Internal testing time therefore moves no clock. The 14 days run from closed testing, and only from closed testing.

This is the single most expensive default in the toolchain, because it is invisible: the build uploads, testers install it, the dashboard looks busy, and the production application stays locked. The fix is one decision made before the first upload. Create the closed testing track first, upload the release there, share the opt-in link, and keep 12 testers opted in without a gap. The full sequence is in how to set up closed testing in Play Console, and why internal testing time does not count explains the track rules in detail.

AI Studio's publish button deserves a specific note here. It is genuinely useful, and it publishes to internal testing with room for up to 100 testers. That is a good smoke test for a build you have never run on a real phone. It is zero days toward production access.

What should you fix before the first upload?

Target API 36

Since August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play, with separate targets for Wear OS, Android Automotive, TV and XR. Google's help page documents an extension route to November 1, 2026 for developers who need more time to update an existing app; that form appears through the policy warning on the Policy status page. A brand-new app has no existing distribution to extend, so set targetSdkVersion 36 from the start. Check what your generated project uses before you build, not on submission day: the fix path is in the target API 36 rule.

16 KB memory page sizes

Google's compatibility requirement reads: all apps targeting Android 15 (API level 35) and higher must support 16 KB memory page sizes on 64-bit devices on Google Play, and starting February 1, 2027, updates that do not support 16 KB page sizes cannot be released. Your new app targets 36, so the requirement already applies to you. The check is quick: if your app only uses Java or Kotlin code, it already complies. If it bundles any native .so libraries, through an SDK as well as your own code, those libraries must be rebuilt with 16 KB alignment. AI Studio's Android output states that C and C++ code is not supported, which puts a pure AI Studio project in the compliant-by-default category. For everything else, the 16 KB page-size fix walks through the APK Analyzer check.

Functionality, if you wrapped a website

If your builder output a web app, you will wrap it in a Capacitor shell or package it as a Trusted Web Activity. Wrapping is legitimate and Lovable names it as one of its two routes to the stores. The risk is the functionality policy quoted above: a shell that only loads your URL, with nothing a browser could not do, is the shape of app Google's examples describe. Add what a browser cannot give, such as push notifications, camera access or offline storage, and test the installed build rather than the browser tab. A Trusted Web Activity adds one more requirement, a correctly served assetlinks.json, which is covered by the assetlinks.json repair guide.

Which Play Console forms does an AI-built app need?

Every one of these sits on the App content page and applies to you regardless of how the code was written. They are listed here because incomplete declarations are the most common reason a technically working build stalls before review.

The Data safety form is the one developers built with AI most often guess at, because the generated code contains SDKs the author never chose. The Data safety walkthrough covers how to read the project rather than the prompt. The full list of declarations Google expects is on its App content help page.

Where does the 14-day clock actually start?

When the .aab is on the closed testing track and testers have opted in. The sequence that makes the days count:

1. Complete app setup in Play Console, including the declarations above.
2. Create a closed testing track and upload the release to it, not to internal testing.
3. Create an email list or Google Group for testers and attach it to the release.
4. Send the opt-in link. Testers must opt in through Google Play, and 12 of them must stay opted in continuously for the preceding 14 days when you apply.
5. When the criteria are met, the production access application appears on your Dashboard. You answer questions about your app design, testing process and production readiness.

Two mechanics of the testers step are worth setting up correctly the first time. For a closed test you can manage testers by email address or by Google Group: Google allows up to 200 email lists, each holding up to 2,000 users, with up to 50 lists per track, and a Google Group route where only members of the groups you name can join. Either way you get one shareable opt-in link for the release, and that link is what your testers actually click. There is one trap if you have already been using internal testing: Google documents that a user who opts into your app's internal test is no longer eligible to receive an open or closed test until they opt out of the internal test first. If your 12 people installed the build from an internal testing link, have them opt out of internal before they opt into closed, or their closed-test opt-in will not register.

Two edges worth knowing before you start. A tester who opts out and opts back in restarts their own 14 consecutive days, so a buffer above 12 protects the count. And whether shipping a new build resets the window is its own question, answered in does updating your app reset the 14-day test. For what the application form asks and how to answer it, see production access questions.

Can you skip the test with the personal apps channel?

Not for a public listing, but you may not need one. Google's October 13, 2026 announcement says it directly: using Google AI Studio you can vibe code a custom Android app, and through Google Play you can launch these personal apps on your own device, keeping them private and separate from the public store catalog. You need only a standard Google account, no developer account, and the rollout starts in select markets including the United States for users aged 18 and over. Sharing with a close circle of friends and family is described as coming in the following months.

What that channel does not give you: a public Play listing, production access, or a shortened route to either. Google's own wording is that if you eventually want to share your app with the world, your app "will go through the same Trust and Safety reviews and quality standards as every professional developer." So the personal channel is the right answer to "I just want it on my phone," and it is not a bypass of the 12-tester gate. More detail is in the AI Studio app builder rules, and whether AI-built apps need the 12 testers at all is answered in do I still need 12 testers if my app was built with AI.

What do we see across 1,500+ closed-testing campaigns?

Based on our internal campaign records covering more than 1,500 closed-testing campaigns, the problems developers bring us about AI-built apps are rarely about the code. They are about the four checkpoints below. This is our own analysis of our own records, not Google data, and we are not publishing rates from it.

• The first upload went to internal testing, and the developer assumed the clock had started. It had not. This is the toolchain default described above.
• The app has a login, and App access has no working credentials. Google's review guidance tells developers to provide valid, working login credentials in Play Console so reviewers can test features. Generated apps almost always ship with authentication on.
• The target API level in the generated project is below 36, discovered at upload rather than before it.
• The build is a wrapper with nothing app-specific in it, which turns a policy question into a rewrite at the worst possible moment.

On the device side, the testers we match for these campaigns run physical Samsung, Pixel, Xiaomi and OnePlus hardware across Android 11 to 15 in more than 80 countries, and most campaigns are matched in under 24 hours. That matters here because a generated app that only ever ran in a browser-based emulator has usually never been opened on a mid-range phone with a small screen and a weak network, which is exactly what the closed test will surface.

Pre-submission checklist

1. Confirm the project your builder produced: native Kotlin, Expo, Flutter, or a web app. That single fact decides every step below.
2. Build the signed .aab from that project, not an APK, not a URL. New apps have been AAB-only on Google Play since August 2021.
3. Set targetSdkVersion to 36 before the first build. The requirement has applied to new apps since August 31, 2026, and the extension Google documents applies to existing apps that need more time to update.
4. Check for native .so libraries and confirm 16 KB alignment if any exist. Kotlin-only projects skip this; anything bundled through an SDK does not.
5. If the app is a web wrapper, add at least one capability a browser does not offer; if it is a TWA, verify assetlinks.json serves correctly.
6. Create the Play developer account and complete identity verification before you need it. Account checks are the step most likely to sit in a queue while your 14 days are ready to start.
7. Complete every App content declaration, with sign-in details that actually work. Reviewers test what you say they can reach.
8. Upload the first release to the closed testing track and attach your tester list. Confirm on the Testers tab that the list is attached to the release, not just created.
9. Verify 12 testers are opted in, then let the 14 days run without a gap. Re-check the count every few days rather than on day 13.
10. Answer the production access application truthfully, including how you summarized testing feedback. Google states that review is not a troubleshooting step, so fix what you know is broken before you apply.

Frequently asked questions

Can Google reject my app because AI wrote the code?

No policy we found does that. Google's content, functionality and quality policies apply to the finished app, and the submission flow has no field for how the source was produced. What gets rejected is an app that crashes, does little on its own, or breaks policy, whatever language or toolchain produced it.

Does an AI-built app need 12 testers and 14 days?

If your Play Console account is a personal account created after November 13, 2023, yes: Google requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. The requirement attaches to your developer account, not to the tool that produced the app.

Can I publish directly from Lovable, Bolt or Replit?

None of the three has a button that submits to Google Play. Lovable outputs a web app and names a PWA or a Capacitor wrapper as the routes out. Bolt's mobile projects are Expo projects that you build and submit with EAS. Replit has no Android publish flow, so the EAS path is yours to run. Rork and FlutterFlow are the exceptions in the table above, with their own Play upload flows.

Why did my build land on internal testing instead of closed testing?

Because that is the default. EAS Submit creates a brand-new app's first release on internal testing, AI Studio publishes to internal testing, and FlutterFlow's first deployment is uploaded there by hand. Internal testing does not count toward the 12-tester requirement, so move the release to a closed testing track and start the 14 days there.

Do I need to support 16 KB page sizes for a new app?

Yes, if you target API 35 or higher, which a new app must since August 31, 2026. A Kotlin-only app already complies. If your build bundles native libraries, direct or through an SDK, check their ELF alignment and rebuild them if needed.

Can I just install my AI Studio app on my own phone instead?

Yes, over USB from the browser, and for a private install Google's personal apps channel lets you run an AI Studio app on your own device with no developer account. Neither route creates a public listing, and neither replaces the closed test when you later want one.

Does the personal app channel count as a Play listing?

No. Google describes it as private and separate from the public store catalog, available in select markets to users 18 and over. Graduating to a public release means a developer account and the same reviews every professional developer faces.

Sources

• App testing requirements for new personal developer accounts - Google Play Console Help: 12 testers, 14 continuous days, track requirements.
• Target API level requirements for Google Play apps - Google Play Console Help: API 36 from August 31, 2026, extension to November 1, 2026.
• Support 16 KB page sizes - Android Developers: compatibility requirement and February 1, 2027 enforcement date.
• Functionality, Content, and User Experience - Google Play Developer Policy: limited functionality and broken functionality clauses.
• AI-Generated Content - Google Play Developer Policy: in-app reporting requirement for apps that generate content.
• Inspect app versions on the Latest releases and bundles page - Google Play Console Help: AAB requirement for new apps since August 2021.
• Prepare your app for review - Google Play Console Help: App content page, sign-in details, content ratings, target audience.
• Content rating requirements for apps, games and the ads served on both - Google Play Console Help: rating questionnaire.
• Provide information for Google Play's Data safety section - Google Play Console Help.
• Understanding Google Play's app account deletion requirements - Google Play Console Help.
• New on Google Play: more ways to create, discover, and play - Google, October 13, 2026: personal apps, no developer account required.
• Build Android apps in Google AI Studio - Google AI for Developers: generated project structure, publish to internal testing, platform limitations.
• Expo for mobile apps - Bolt documentation: mobile prompt requirement, EAS build and publish steps.
• Lovable documentation FAQ - web app output, no React Native generation, PWA and Capacitor routes.
• Google Play Store deployment - FlutterFlow documentation: service account setup, first AAB upload, release promotion.
• How to publish your Rork app to Google Play Store - Rork documentation: native Kotlin output, Build AAB for Play.
• Submit to the Google Play Store with EAS Submit - Expo documentation: default first release on internal testing, production profile produces .aab.