How to Publish a Replit App to Google Play (and the App Store)

You built an app on Replit, it works, and there is a big blue Publish button sitting in the corner. So you press it, and now you have a live URL ending in .replit.app. That is a website. It is not on Google Play, and pressing that button again will not put it there.

This guide covers what actually happens between a working Replit project and a listing on the Play Store, including the part Replit does not do for you.

The short version

• Replit’s Publish button deploys your app to the web. It does not submit anything to a store.
• Replit’s built-in store flow hands off to Expo Launch, and that wizard currently targets the App Store. There is no equivalent one-click path to Google Play.
• For Google Play you go through EAS, which builds your app in the cloud and hands you a signed .aab, the format Play requires.
• You do not need a Mac, Android Studio, or Xcode. Every build runs on someone else’s machine.
• Costs: $25 once for a Google Play developer account, $99 a year for Apple.
• Then the real wall: if your Play account is personal and was created after 13 November 2023, you need 12 testers opted in for 14 continuous days before you can go to production.

First, work out what you actually built

This decides everything that follows, and most people get it wrong.

If you built a mobile app in Replit, you have a React Native project running on Expo. That is a real native app. It can go to both stores properly, and the rest of this guide applies directly.

If you built a web app, which is what most Replit projects are, you have a website. Getting a website into an app store means wrapping it, and that is a different job with real rejection risk. We cover that near the end, because you should understand the risk before you spend a week on it.

The quick test: if your project previews on your phone through the Expo Go app, it is a mobile app. If it opens in a browser tab, it is a web app.

Step 1: Test it on a real phone first

Before you think about stores, get the app onto an actual device. Replit gives you this for free through Expo Go: install the app, scan the QR code, and your project runs on your phone with real touch gestures.

Shake the device to open the Expo Go menu and hit Reload to pull in your latest changes. Do this early and often. An app that looks fine in the browser preview and falls apart on a real phone is the single most common thing that derails a first submission, and it is far cheaper to find out now than after a review rejection.

Step 2: Understand what Replit’s Publish button does

Replit’s Publishing screen asks for a domain, shows you what is being published, lets you set who can access it, and offers a security scan. Then it publishes.

Watch the pipeline it runs: Provision, Security checks, Build, Bundle, Promote.

Every one of those steps is about deploying your app to the internet. None of them talk to Google Play or Apple. When it finishes you have a working, publicly reachable app at a .replit.app address, which is genuinely useful, and it is also the thing people mistake for being published.

It is worth doing anyway. A live URL is what you point testers at, what you use for a privacy policy, and what your store listing links to.

Step 3: The App Store path, which Replit does automate

If your project is a mobile app, Replit offers to take you the rest of the way to Apple. It tells you up front what you need: an active Apple Developer account, and after publishing you can test on TestFlight before submitting for review.

Starting that hands you over to Expo Launch, which walks through the steps in order: choose your Expo project, sign in with Apple, choose the Apple app, configure certificates, and launch.

Note the first step in that list is “Targeting the App Store”. That is the whole scope of this wizard today. It is a genuinely smooth path to Apple, and it does nothing for Google Play.

The Apple sign-in step needs an account that is enrolled in the Apple Developer Program, not just a free Apple ID. Expo is explicit that your password is not stored and only a proof of it is sent to Apple using the Secure Remote Password protocol.

Certificates are the part people dread, and this is the one place the tooling genuinely saves you. Expo generates and stores the signing credentials for you, so you never manually create a distribution certificate or a provisioning profile.

Step 4: The Google Play path, which you drive yourself

Here is where the guide earns its keep, because this is the store most indie developers actually need and there is no button for it.

You use EAS, Expo’s build service. Three things to know before you start:

• Builds run in Expo’s cloud, so your machine does not matter. Windows and Linux are fine, including for iOS, because Apple builds run on Expo’s hosted macOS machines.
• EAS generates and stores your Android keystore, so the file that comes back is already signed.
• The free tier is capped at roughly 15 builds per platform per month. That is plenty for a first launch and worth knowing before you burn builds on typos.

The sequence:

1. Configure the project. Run eas build:configure. This creates eas.json next to your package.json, which is where your build and submit settings live.
2. Build for Android. Run eas build --platform android. It queues a cloud build that takes roughly 10 to 15 minutes. You can watch progress on the Expo dashboard.
3. Collect your .aab. What comes back is an Android App Bundle, already signed. Google Play requires new apps to be published as app bundles rather than APK files, so this is the format you want. If you set the build type to APK you will get a file Play refuses on a release track.
4. Upload the first build by hand. This trips people up: your first bundle has to be uploaded manually in Play Console. Automated submission only works once the app exists there.
5. Automate after that. Once set up, eas submit --platform android uploads for you. It needs a Google service account key so EAS can talk to your Play account on your behalf.

One trap worth calling out. There is an option to chain building and submitting together, and it sends the build to the internal testing track by default. Internal testing is not closed testing. It will not count toward the 12 testers requirement, and developers regularly lose days to that assumption. Set the track explicitly.

While you are here, check your target API level. From 31 August 2026, new apps and updates need to target API 36. That deadline is close, and a build targeting an older level will be blocked at upload.

Step 5: The 14-day wall nobody warns you about

You have an .aab, you have uploaded it, and you assume you are nearly done. You are not.

If your Google Play developer account is a personal account created after 13 November 2023, you must run a closed test with at least 12 testers opted in for 14 continuous days before you can apply for production access. Organisation accounts and older personal accounts are exempt.

Three details that decide whether those 14 days count:

• Testers must opt in through the official Play opt-in link. Sideloading your APK to a friend does nothing.
• The days must be continuous. If your tester count drops below 12, the clock does not politely pause.
• Testers who install and never open the app are the quiet killer. Google looks at engagement, not just install counts.

This is the stage where most Replit-built apps stall, because building the app was the fun part and finding twelve strangers who will keep it installed for two weeks is not. We wrote about the policy in detail in Google Play: 12 Testers for 14 Days, and about the mistakes that reset the clock in the closed testing guide.

What if you built a web app, not a mobile app?

Then you are wrapping a website, and you need to know what each store thinks about that, because they disagree sharply.

Google is more permissive than the rumours suggest. The policy people quote actually says Google does not allow apps whose primary purpose is to drive affiliate traffic to a website, or to provide a webview of a website without permission from the website owner. If it is your own app and your own site, that specific clause is not aimed at you.

The rule that will catch you is a different one: minimum functionality. Google does not allow apps with only limited functionality and content, and expects apps to have a basic degree of adequate utility as mobile apps. The risk is not that your app contains a webview. The risk is that it is thin. An app that is a login screen and a scrolling page will struggle. One that does something real, works offline in places, and behaves like an app will generally be fine.

Apple is much stricter, and this is the important asymmetry. Guideline 4.2 says your app should include features, content, and UI that elevate it beyond a repackaged website. Guideline 4.2.2 says apps should not primarily be web clippings. In practice a thin wrapper that sails through Google Play review gets rejected by Apple.

There is also guideline 4.2.6, which is worth reading twice if you are considering paying a service to wrap your site: apps created from a commercialised template or app generation service are rejected unless submitted directly by the provider of the app’s content.

So if you built a web app and you want to be on a store, target Google Play first and treat the App Store as a later project once your app has more native substance. That is not a shortcut, it is what the two policies actually say.

What it costs

• Google Play developer account: $25, one time, never renewed.
• Apple Developer Program: $99 a year, and you keep paying it to stay on the store.
• Replit and EAS: both have free tiers that will get a first app shipped.

If you are only shipping to one store to start with, the maths is not subtle. Google Play costs a quarter of one year of Apple and never charges you again.

Common questions

1. Does Replit’s Publish button put my app on Google Play?

No. Replit’s Publish deploys your app to the web at a .replit.app address. It runs provisioning, security checks, build, bundle and promote steps, all of which are about hosting your app online. Getting onto Google Play is a separate process that produces an Android App Bundle and uploads it through Play Console.

2. Can I publish a Replit app to Google Play without a Mac or Android Studio?

Yes. EAS builds run in Expo’s cloud, so nothing compiles on your machine. It works from Windows and Linux, and even iOS builds run on Expo’s hosted macOS machines. You need the paid store accounts, but no local build tooling.

3. What file does Google Play need from a Replit app?

An Android App Bundle, the .aab file. Google Play requires new apps to be published as app bundles rather than APKs. Running eas build with the Android platform produces one, already signed with a keystore that EAS generates and stores for you.

4. Do I still need 12 testers if my app was built on Replit?

Yes. The requirement is tied to your Google Play developer account, not to how the app was built. If it is a personal account created after 13 November 2023, you need 12 testers opted in for 14 continuous days of closed testing before you can apply for production access. How you built the app makes no difference.

5. Will a Replit web app wrapped as an Android app get rejected?

Not automatically. Google’s webview policy targets apps that wrap a site without the owner’s permission, which does not describe your own app. The bigger risk is the minimum functionality policy, which rules out apps with limited functionality and content. A thin wrapper is the problem, not the wrapper itself. Apple is considerably stricter, so a wrapped web app is far more likely to pass Google Play than the App Store.

6. Why did my Replit app go to internal testing instead of closed testing?

Because the chained build and submit option sends builds to the internal track by default, and internal testing is not closed testing. Only closed testing counts toward the 12 testers for 14 days requirement. Set the track explicitly in your submit settings, and check in Play Console which track your build actually landed on.

7. What target API level does my app need in 2026?

From 31 August 2026, new apps and app updates must target API 36 to be published on Google Play. If your build targets an older level, the upload is blocked. Check this before you start a release cycle rather than on submission day.

The order that actually works

1. Build it on Replit and test it on a real phone with Expo Go.
2. Publish on Replit so you have a live URL for your listing and your privacy policy.
3. Register your Google Play developer account early, because the $25 and the identity checks take time you will not want to spend later.
4. Build an .aab with EAS and upload the first one manually.
5. Start closed testing immediately, because the 14 days run in the background while you finish your store listing.
6. Apply for production access once the 14 days are genuinely complete.
7. Consider the App Store afterwards, using Replit’s built-in wizard, if your app has enough native substance to clear Apple’s bar.

The build is the part everyone worries about, and it is now the easy part. The part that decides whether your app ships is the fortnight of closed testing at the end, which is exactly where Testers Community exists to help.