Publish a Replit App to Google Play: Start the 14-Day Clock

Short answer: Replit will not put your app on Google Play — its publish flow targets the web and the Apple App Store. You build the Android release yourself with EAS (eas build --platform android), which returns a signed Android App Bundle (.aab), then you upload it with eas submit. The one setting that decides whether your launch takes two weeks or five is the track you submit to: eas submit's default lands your first release on the internal testing track, and internal testing time does not count toward Google's 12-tester requirement. Only closed testing counts. Set track: alpha, verify the build landed on Closed testing in Play Console, and the 14-day clock starts when your 12th tester opts in.

This guide covers the whole path: the account setup that has to happen first, the track trap and how to check it, the three opt-in mechanics that decide whether your 14 days actually count, and the target API deadline you need to check before you build. Every claim about Google's rules is linked to Play Console Help or the Android Developers site.

What Replit hands you, and what Google Play still needs

Replit's built-in store wizard targets the Apple App Store, and Replit's publish button deploys your project to the web. There is no Android button. So you step outside Replit and drive the Android release yourself — normally with EAS Build, Expo's cloud build service, which compiles in the cloud and works from Windows or Linux with no Android Studio and no keytool. EAS generates and stores the Android keystore for you.

Three things Google Play will insist on:

• An .aab, not an .apk. Google's own documentation is blunt: "From August 2021, new apps are required to publish with the Android App Bundle on Google Play." The default EAS production profile produces a bundle; if you configure a build profile to output an APK, Play will refuse it on a release track.
• A target API level that is current enough. From August 31, 2026, new apps and app updates must target Android 16 (API level 36) or higher, with an extension to November 1, 2026 available for developers who need more time. More on that below.
• A developer account that already exists. The $25 registration fee and the identity checks are not instant, and neither are they something you want to start on submission day.

None of these are Replit-specific. A Lovable build, a Bolt project, a Google AI Studio app or a hand-written Kotlin project all hit the same requirements. The building tool is irrelevant to Google; the developer account, the bundle and the closed test are what it looks at.

Register the developer account before you need it

Play Console's own getting-started flow lists six steps, and the fee sits at step three: sign up, accept the Developer Distribution Agreement, pay a US$25 one-time registration fee, choose an account type, verify your developer identity information (personal accounts), then meet the testing and device verification requirements.

Start this while you are still finishing the build. Google verifies contact details for new accounts with a one-time password during registration, and personal accounts go through identity verification — both take time you cannot compress on launch day. If the account type you register turns out to matter for the tester rule (personal accounts created after November 13, 2023 are covered by it; organisation accounts and older personal accounts are not), you want to discover that during registration, not after you have invited 12 people. The account-type question is covered in detail in Does an organisation account skip the 12-tester rule?

While the account is being verified, finish your Play Console app setup: name, package name, store listing, privacy policy, Data Safety declaration, content rating and app access. Closed testing cannot start before app setup is complete — Google states that the closed testing track's access requirement is "Complete app setup." Our Data Safety form walkthrough covers the declaration that stalls most first-time developers.

Which track does your eas submit build actually land on?

This is where vibe-coded launches lose days. Expo's documentation says it plainly: "If this is your app's first submission, the default eas submit command works out of the box and creates your app's first release on the internal testing track." Internal testing is a useful smoke test with up to 100 invited people. It is not closed testing, and only closed testing counts toward the 12 testers.

Expo's eas.json reference accepts exactly those four values (production, beta, alpha, internal) for submit.android.track. If your closed test lives on a track you renamed inside Play Console, upload to alpha and promote the release to your named track from the Console — the promotion step happens in the UI, not in the CLI.

Two traps hiding inside the track decision

Internal testers are locked out of your closed test. Google's test-setup documentation: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test. To access an open or closed test, the user must first opt out of the internal test and then opt in to the open or closed test." If you have already rallied 12 willing people and pointed them at the internal link, each of them now owes you an extra opt-out before their days on the closed test mean anything. Do not send anyone the internal link.

The opt-in link does not exist yet. Also from Google: "The opt-in link displays only when an app status is 'Published'. Apps in 'Draft' or 'Pending publication' status do not display an opt-in link." A brand-new app submitted through EAS sits in draft status until the store listing and setup tasks are finished — Expo warns about exactly this. So the practical order is: create the app, complete every setup task, publish the closed release, then invite. Inviting into a draft app produces a link that goes nowhere and a tester count stuck at zero, which we break down in why Play Console shows fewer testers than you invited.

How to confirm the build landed on closed testing

Do not trust the command output. Open Play Console, select your app, go to Test and release > Testing > Closed testing, open Manage track and check that your uploaded version code is listed under releases. If your version only appears under Internal testing, the 14-day clock has not started and no amount of waiting will change that. If the opt-in link you copied contains an internal-testing URL rather than your closed-test link, you copied it from the wrong tab — see testers see "app not available" for the fixes.

The three things that decide whether your 14 days count

Google's requirement: personal developer 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" before applying for production access. Three mechanics decide whether those days are real.

1. Testers must opt in through the official link. Adding an email address to a tester list makes someone invited, not counted. Each tester opens the shareable link from the closed testing Testers tab, signs in with the Google account on your list, and opts in — Google: "After clicking the opt-in link, testers receive an explanation of tester responsibilities and a link to opt in. Each tester needs to opt in using the link." Handing someone an APK file, a direct download or an internal-testing link contributes nothing to the requirement. Google Groups work too, but members must join the group before opting in.

2. The 14 days are consecutive, per tester. Google's FAQ answer is the one most developers read too late: "Testers who opt in, test for fewer than 14 days, and then opt out do not count toward the requirement. If a tester opts out and opts back in later, the 14 days must be consecutive to count toward the minimum requirement of 12 continuous opted-in testers." An opt-out does not shrink the group — it resets that person's clock. Google also instructs developers to "Inform your testers that they need to remain opted in to your closed test continuously for at least 14 days." Say it in the invitation message, in writing, before they install.

3. Twelve is a floor, not a target. Because one departure can restart a clock, run the test with a buffer: 14 or 15 opted in rather than exactly 12. If someone drops, the group never touches the floor, and you lose a person instead of a fortnight.

Uninstalling or never opening the app is the softer failure. Google lists "fewer than 12 opted-in testers or insufficient tester engagement during the testing period" as the reasons an application may come back asking you to continue testing — so ask testers to open the app a few times across the window, not just install it. Our post what counts as a closed tester covers the edge cases (emulators, shared devices, the same person on two apps).

What to do while the clock runs

Fourteen days is long enough to finish the work that usually blocks a first submission, and Google expects you to use it:

• Ship updates during the test. Uploading a new build to the closed track does not reset your 14 days — the requirement is about testers staying opted in, not about the binary staying frozen. Fix crashes as they surface.
• Collect feedback in writing. Google: "You must summarize your testing feedback when applying for production access." Keep a dated log from day one — what testers reported, what you changed — rather than reconstructing it the night you apply.
• Watch the dashboard, not just the calendar. The opted-in count is what Google reads at application time, so check it every couple of days. Our own tracking of this failure mode is in what resets the 14-day test.
• Prepare the production application. When the days are done you apply from the Dashboard, answering questions about your app's design, testing process and production readiness. Review "usually takes seven days or less, but can occasionally take longer." Our production-access application guide walks through the questions.

Two decisions come up mid-test and both are cheaper handled early. The first: if someone drops below the floor, replace them rather than waiting. Add the replacement to the tester list, send the opt-in link, and count their 14 days from the date they opted in — a late joiner does not inherit anyone else's elapsed days, so your application date moves to whatever 14-day window still leaves 12 people continuously opted in. That arithmetic is worth doing on paper the moment a tester disappears; developers who only check on day 13 discover a delay they could have planned around on day 4. The second: what to do about a tester who complains the app is broken. Fix it, push a new build to the closed track, and tell them to update — the track keeps running while builds change, so a crash report is not a reason to restart anything. Our 14-day clock rules post lists every action that does and does not restart the count.

Check the target API level before you start, not on submission day

Google's target API rule and the tester rule land in the same place: the upload. "Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play," with exceptions for Wear OS and Android Automotive OS (Android 15 / API 35 or higher), Android TV and Android XR (Android 14 / API 34 or higher), and an extension to November 1, 2026 for developers who need more time — Google notes the extension forms will be accessible in Play Console later this year.

The setting lives in your Android manifest: as Google puts it, "Each app specifies a targetSdkVersion (also known as the target API level) in the manifest file." In a Replit or Expo project that value comes from the app config your build reads, so check it in the file you control rather than in the Play Console after the fact. Two practical notes for this specific launch:

• A wrong target level fails at upload, not at review. The bundle is rejected when you submit it, which is early enough to fix and late enough to waste a day you had already booked — so confirm the value in your first build, before you invite anyone.
• The tester clock and the API deadline run on separate calendars. The 14 days start when your 12th tester opts in; the API deadline is a fixed date. If your closed test straddles August 31, 2026, the update you push during the test must already target 36 — an update built on an older target level will not be accepted, and a test that cannot accept builds is a test you cannot fix crashes in.

See the target API 36 requirement for the exact dates, the platform-specific floors and how the extension interacts with an app already in closed testing.

What 1,500+ closed-test campaigns show about the fortnight

OnTesters has analyzed 1,500+ closed-test campaigns across physical Samsung, Pixel, Xiaomi and OnePlus devices, Android 11–15 and testers in 80+ countries, matched with a tester in under 24 hours. Three patterns from that data matter to someone about to start a clock:

Read together: engagement across the window beats a headcount that never opens the app, shipping fixes mid-test correlates with a much stronger outcome than uploading once and waiting, and a rejection is a fixable state rather than a dead end.

How to read the table honestly. Every row comes from those campaigns, and "active days" means the tester stayed opted in and opened the app during the window — not that an invitation was emailed. These are our campaign outcomes, not Google's published statistics: Google does not release approval rates for production-access applications, and no figure on this page predicts what will happen to your app. What the pattern does support is a planning decision. If you are choosing between inviting exactly 12 people who may or may not open the app and running 14 or 15 who are told, in writing, to stay opted in for the full window, the second plan is the one our data describes. For what the fortnight costs either way, see our cost breakdown for closed testing.

Timeline: Replit project to live listing

The build is the short part. The fortnight is the fixed cost, and it only starts once the right track has the right build and the 12th tester has opted in — not when you upload, and not when you created the app.

Two things are worth scheduling against that table. First, the clock is the only row you cannot compress: everything above it can be done in a long weekend, and everything below it is Google's queue. Start the test the day your setup is complete, because the days you spend polishing screenshots with zero testers opted in are days you are simply not counting. Second, the rows overlap deliberately. Store listing work, screenshots, the privacy policy URL, the App access demo credentials and the feedback channel all belong in the same fortnight as the test — Google expects you to be acting on feedback while the test runs, not sitting beside a calendar.

If your timeline has already slipped — account under review, setup half-finished, a track that was published empty for a week — the delay is usually recoverable: none of those steps reset a clock that has not started. What you cannot recover is a fortnight spent on the wrong track, which is why the check in setting up closed testing in Play Console is worth doing before you invite the first person, and why our closed testing overview is the fastest way to see the whole sequence in one place.

Frequently Asked Questions

Does Replit publish Android apps to Google Play?

No. Replit's publish flow deploys your project to the web and its store wizard targets the Apple App Store. For Google Play you produce the Android App Bundle yourself, normally with eas build --platform android, and upload it with eas submit or manually through Play Console.

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

Because a first eas submit creates the app's first release on the internal testing track by default. Set submit.android.track to alpha in eas.json, or promote the release to closed testing inside Play Console, then confirm the version code appears under Testing > Closed testing > Manage track.

Does internal testing time count toward the 12-tester requirement?

No. Google's testing requirements count testers "opted in to your closed test" for the preceding 14 days. Internal testing has no such requirement and its days never move your 14-day clock. Worse, someone who opted into your internal test must opt out again before they can join the closed test.

Can I start the 14 days before my store listing is finished?

Not usefully. Closed testing requires completed app setup, and the tester opt-in link only appears when the app status is "Published" — apps in "Draft" or "Pending publication" do not display it. Finish the setup tasks first, then invite, then the days count.

What happens if one of my 12 testers opts out on day 10?

That tester's 14 days reset. Google's FAQ states that testers who opt out and opt back in later must be opted in for 14 consecutive days to count, and that fewer than 12 continuous opted-in testers does not meet the requirement. This is why running 14–15 testers instead of exactly 12 is the cheaper mistake.

How long does the whole Replit-to-Play process take?

Account registration and app setup can be done in a day or two. The 14-day closed test is fixed calendar time, and Google's production-access review "usually takes seven days or less, but can occasionally take longer." Realistically, two to four weeks from first upload to a live listing, depending on how quickly testers opt in.

Sources

Every rule in this article traces back to one of these primary sources — Google's own Play Console Help and Android Developers documentation, plus Expo's official EAS documentation for the build and submit commands:

• App testing requirements for new personal developer accounts — Play Console Help (12 testers, 14 continuous days, track requirements, tester engagement guidance, feedback summary, review timing)
• Set up an open, closed, or internal test — Play Console Help (opt-in link rules, internal-test opt-in exclusion, tester lists and Google Groups, sharing the release)
• Target API level requirements for Google Play apps — Play Console Help (August 31, 2026 API 36 deadline, platform exceptions, November 1, 2026 extension)
• Get started with Play Console — Play Console Help (US$25 one-time registration fee and the six account setup steps)
• Required information to create a Play Console developer account — Play Console Help (verified contact details and one-time password verification for new accounts)
• About Android App Bundles — Android Developers (new apps must publish with the Android App Bundle since August 2021)
• Submit to the Google Play Store with EAS Submit — Expo documentation (first submission defaults to the internal testing track; app stays in draft until setup is complete)
• Configuration with eas.json — Expo documentation (submit.android.track values and submission profile options)
• Automate submissions — Expo documentation (track mapping: internal, alpha, beta, production)
• Prepare your app for review — Play Console Help (what Google checks when a release is submitted)