Publish a v0 App to Google Play: AAB and 12 Testers

Short answer: v0 gives you a web app — Google still wants an Android build and 12 testers

v0 builds React and Next.js apps and ships them as websites: its quickstart ends at a Publish action that creates a Vercel production deployment. There is no Android export in that flow — v0 produces no APK and no AAB. To get on Google Play you supply the Android side yourself, and the standard path is Capacitor, which wraps the same app in a native Android shell and generates the bundle Play Console accepts.

The 12-tester requirement then hits you exactly like it hits a natively coded app, because it attaches to your Play Console account, not to your toolchain. Google's wording: developers with personal accounts created after November 13, 2023 "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" (Play Console Help). Building with AI changes nothing about that sentence. There is one private-distribution route Google opened in October 2026 — personal library apps — but it accepts apps built in Google AI Studio, so a v0 project does not qualify (the mechanics).

What v0 actually gives you for Android — and what it doesn't

A v0 project is a full-stack web app: React and Next.js with shadcn/ui components, iterated through chat and Design mode, with database and service integrations you install from the project settings — Neon, Supabase, Upstash, Blob, Stripe, and the Vercel AI Gateway (v0 quickstart). Those API keys are managed as environment variables inside Vercel, from the project settings, not pasted into components.

What v0 does not produce: an Android project, a keystore, a store listing, or any artifact you can upload to Play. Its documented ship path ends at a web deployment. So the remaining work is threefold — turn the web app into an Android build, meet Play's technical bar (an app bundle targeting API level 36), and pass the account-level testing gate that every new personal account faces.

Three routes from a v0 app to Google Play

There are three honest ways to get there. They differ in how much of your v0 code survives.

• Capacitor WebView shell — recommended for most v0 apps. Your React code runs unchanged inside a native Android WebView. You get a real AAB, native features through plugins (camera, push, filesystem), and one codebase. This is the route the rest of this article walks through.
• React Native or Expo rewrite — genuinely native, but it's a port, not a wrapper. Your Next.js components, Tailwind classes, and server routes do not carry over. Worth it only if you need deep native UX; the EAS build mechanics are covered in our Replit guide.
• PWABuilder / Trusted Web Activity — the no-code-change wrapper. It is a legitimate route, but treat engagement seriously: our sister-site deep dive on TWA rejections found no Google rule targeting shell apps specifically — the same engagement bar applies to every wrapper.

Step 1: Wrap the v0 app with Capacitor

Capacitor's own docs list Android as one of its three officially supported targets, and the only core requirement beyond that is "NodeJS 22 or higher". Start from your v0 project's GitHub repository — v0 syncs a project to GitHub from its settings — and work locally.

1. npm install @capacitor/core @capacitor/android
2. npx cap init — it asks for an app ID (your reverse-domain package name, such as com.yourname.yourapp) and the display name
3. npx cap add android
4. npx cap sync android

Choose the app ID carefully: it becomes your Play package name, and Google's docs are blunt about its permanence — "Once you upload an artifact, the package name for that app is fixed and cannot be changed" (set up a test track).

Step 2: Decide what the Android app loads — bundled files or the live Vercel URL

This decision shapes everything after it, and it is specific to web-app builders. Capacitor's config has a server.url option that "tells the WebView to load content from an external URL instead of the bundled app assets" (Capacitor remote-update guide). In practice your Android binary does one of two things:

• Bundled: export your app's static files into the directory Capacitor ships inside the AAB. The app opens its own copy and works offline — but anything that needs the Vercel server (API routes, auth callbacks, Stripe, the AI Gateway) breaks, because that server is not in the bundle.
• Live URL: point server.url at your Vercel production deployment. Every server feature keeps working, because requests hit the real backend, and your API keys stay on Vercel — nothing secret is embedded in the AAB.

For a typical v0 app — database, auth, payments, AI calls — the live URL is the only option that preserves what you built. The costs are real: the app "needs an active network connection every time it launches", and because every installed copy always loads the latest deployment, a bad web push can break the version your testers installed on day one of the closed test.

Step 3: Build the AAB Google will accept

Open android/ in Android Studio and check the target level. Google's rule since August 31, 2026: "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play" (target API level requirements). Capacitor's template generates a recent target, but before your first upload confirm compileSdk and targetSdk in android/app/build.gradle read 36 or higher.

Then generate the signed bundle: Android Studio → Build → Generate Signed Bundle / Android App Bundle, creating a keystore if you don't have one. Keep that keystore somewhere recoverable — every future update to this app is signed with the same key. The output .aab is what Play Console takes; an APK is fine for testing on your own phone, but Play wants the bundle.

Step 4: Create the Play Console record and start the closed test

Create the app record first — name, free-or-paid, package name — then finish app setup: privacy policy, Data safety, content rating, target audience, store listing. Google opens closed testing only "after completing your app setup" (testing requirements). The Data safety form must describe what your Vercel backend collects, not what the WebView renders: account emails from Supabase auth, analytics events, anything your integrations store.

If the app has a sign-in wall, add working test credentials in Play Console — reviewers log in with what you provide, and a shell they cannot get into becomes a review problem. The mechanics are in test credentials for reviewers.

Now the closed track: Testing → Closed testing → create the track, upload the AAB, add testers by email list or Google Group, publish the release, and copy the opt-in link — for a first release, the link can take a few hours to start working. One trap costs people their clock: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test" (Google, track setup docs). Nobody on your 12 should touch internal testing first.

Step 5: Hold 12 testers for 14 days, then apply

The count is checked the moment you apply, per tester: "At least 12 testers must be opted in to your closed test when you apply for production access, and they must have been opted in continuously for the preceding 14 days" (Google). A tester who opts out and returns restarts their own 14 days. A new build does not.

Engagement is the other half, and it is where web-app shells get sloppy. Based on our analysis of 1,500+ closed-testing campaigns, the weakest windows we see belong to apps whose entire experience sits behind one live server: when the backend is slow or a deploy breaks a flow, testers can't do anything, and the "how did testers engage" answers on the application form get thin. Keep the Vercel deployment stable for the whole window — ship fixes, don't re-architect — and give testers two or three concrete tasks. What engagement means in practice is covered in do testers need to open the app every day.

When the window closes, Apply for production appears on the Dashboard. The form asks three groups of questions — about the closed test, the app, and production readiness — and our walkthrough of every question shows what a useful answer looks like. Google states that "Review usually takes seven days or less, but can occasionally take longer." If the answer is more testing, the stated reasons are "having fewer than 12 opted-in testers or insufficient tester engagement during the testing period" — the closed test keeps running and you apply again.

What can still get a v0 app rejected

The fear every WebView developer has is the policy line about webviews. The actual clause, from Google's Spam policy: "We don't allow apps whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator" (Spam policy). You are wrapping your own deployment, so you have that permission — the clause targets people who wrap other people's sites. Permission is not the bar; quality is.

• Reviewers can't get in — provide working test credentials before they start, not after a rejection.
• Data safety that doesn't match the backend — the form asks what you collect, and a Supabase auth table with user emails is collected data.
• An app that does nothing beyond opening a bookmarked page — add the native pieces a phone user expects (push notifications, share intents, a real offline fallback) so the store listing and the product agree.
• A dead live URL — if the Vercel plan lapses or the domain changes mid-test, the app in testers' hands becomes a blank screen, and the closed test goes with it.

On the shell-specific panic: when developers asked Google directly in July 2026 whether wrapper apps were being targeted, a Gold Product Expert answered that Trusted Web Activity apps "are [not] being uniquely targeted or rejected by Google Play" (thread and analysis). The rule that decides your application is the same one that decides a native app's: 12 real testers, 14 continuous days, honest answers.

FAQ

Does a v0 app need 12 testers for 14 days? Yes, if your Play Console account is a personal one created after November 13, 2023. The requirement is tied to the account, not the app's origin, so a v0 app, a native Kotlin app, and a Replit app from the same account all run the same closed test. Organization accounts, and personal accounts created before that date, are exempt.

Can v0 build my APK or AAB for me? No. v0's documented ship path ends at a Vercel production deployment; it has no Android build step. Capacitor generates the Android project from your existing code, and Android Studio (or a cloud build service) produces the signed AAB.

Is a WebView app allowed on Google Play? Yes. Google's Spam policy prohibits webview wrappers of websites "without permission from the website owner or administrator" — wrapping your own app is the permitted case. Everything else applies as it does to any app: policy compliance, working credentials for reviewers, honest Data safety declarations, and real tester engagement during the closed test.

Will my Supabase, Stripe, and AI Gateway integrations work inside the Android app? They work if the app loads your live Vercel URL, because requests still hit the same backend with the same environment variables. If you bundle a static export instead, every feature that depends on server-side code stops working inside the app.

Do my testers need an internet connection? Yes — a shell that loads the live deployment is unusable offline. Say so in your tester instructions, and keep the deployment stable for the entire 14-day window.

Where do I get 12 testers? Most developers start with people they know, then widen to communities and mailing lists — email lists versus Google Groups are compared in our guide. If you would rather hand the window to a service, that is what our closed testing service does.