A Replit-built mobile app can feel ready when the preview works, but Apple and Google do not review your preview. They review signed app packages, store listings, privacy declarations, screenshots, and real-device behavior. This guide shows how to move working Replit mobile code toward a realistic App Store and Google Play submission.
Early proof: the gap between a Replit build and a live mobile app
Replit helps you move quickly from idea to working code. Publishing adds a production layer: platform accounts, signing, store assets, compliance forms, device testing, and review risk.
| Area | Replit helps with | Apple and Google still require |
|---|---|---|
| Code | Source code, fast editing, preview testing | Production config, stable versions, real-device testing |
| Build output | Development behavior or preview | Signed iOS .ipa and Android .aab packages |
| App identity | Project name and app config | Bundle identifier, package name, developer account ownership |
| Store assets | Often not included by default | Icon, screenshots, descriptions, support URL, privacy policy URL |
| Review readiness | Functional prototype | Privacy labels, Data Safety form, age rating, review notes, policy compliance |
The practical interpretation is simple: a working Replit app is the starting point, not the finish line. The publishing workflow turns source code into packages that Apple and Google can install, inspect, and review.
A realistic flow looks like this:
- Replit source code and browser preview
- Production cleanup and real-device testing
- Expo EAS or native build setup
- Android
.aaband iOS.ipa - Store listings, screenshots, and privacy forms
- App Store and Google Play review
For many founders, this takes several days to a few weeks. The timeline depends on account verification, build errors, missing assets, policy questions, and review timing. Packaging the app is not the same as getting it approved.
Prepare your Replit project before store builds
Clean up prototype leftovers
Before you create an .aab or .ipa, treat the app like a production product. Reviewers and early users will notice rough edges that were easy to ignore in a preview.
- Export the Replit project or connect it to source control.
- Confirm whether the project is Expo-based or plain React Native.
- Remove placeholder screens, sample content, test users, debug logs, and hardcoded credentials.
- Replace development API keys with production or staging keys.
- Test the main flow outside Replit's browser preview.
- Install the app on at least one physical device before submission.
This cleanup often takes longer than expected. Even a small app can need several hours of environment fixes, asset cleanup, and real-device testing before it is safe to package.
Know whether your app is Expo or plain React Native
Many Replit mobile projects use Expo, which makes cloud builds through EAS more straightforward. If your app is Expo-compatible, Expo's guide to building projects for app stores is a practical starting point.
Plain React Native or non-Expo projects may need Android Studio, Xcode, Gradle fixes, CocoaPods, native module configuration, or a migration to Expo and EAS. Plan for more debugging if the app uses custom native modules, camera access, push notifications, maps, payments, or older SDK versions.
Set up developer accounts early
You need store accounts before final submission, and sometimes before signing can be completed. Create them early so verification does not block your launch.
| Account | You need it for | Watch out for |
|---|---|---|
| Apple Developer Program | App IDs, signing, App Store Connect submission | Verification can take time |
| Google Play Console | Android app creation, .aab upload, release tracks, Data Safety form | Policy checks still happen during review |
| Expo account | EAS Build, cloud build history, credentials management | Project ownership should match your team workflow |
Apple Developer Program pricing and Google Play Console registration fees can change by country or policy. Check the current official pages before budgeting.
Also review whether your app touches payments, health data, location, children's content, user-generated content, financial data, AI features, or sensitive permissions. These categories are publishable, but they usually require more careful disclosures and review notes.
Create production assets before submission
Store assets are not just marketing polish. They help reviewers understand the app and help users decide whether to install it.
Common requirements include a large square app icon, screenshots, app descriptions, support contact details, and a live privacy policy URL. Exact image sizes, character limits, and screenshot rules can change, so verify them inside App Store Connect and Google Play Console before final upload.
Prepare these items before you submit:
- App icon that meets each store's current size and transparency rules.
- Final screenshots captured from the production build or a close matching build.
- Short and full descriptions that describe the app as it works today.
- Privacy policy URL that is live and specific to your app.
- Support URL or support email that reaches your team.
- Review notes with demo login details, test payment instructions, or special setup.
The practical takeaway: prepare assets while engineering is finishing, but capture final screenshots after the app flow is stable. If screenshots show broken, hidden, or unavailable features, fix the app or remove those screenshots.
Build and upload your Replit app
Build the Android App Bundle with EAS
For an Expo-based Replit project, Expo Application Services is often the cleanest path to Google Play. Google Play production releases generally use an Android App Bundle, not a Replit preview or development APK.
Configure EAS for production builds
Install or configure EAS Build and connect it to the exported project. Create a production profile, then confirm the Android package name, app version, and version code.
Run the Android cloud build
Run a production Android build to generate an
.aabfile. If the build fails, common causes include SDK mismatches, incompatible native modules, missing environment variables, or Gradle configuration issues.Upload to Google Play Console
Create or open the app in Play Console, choose a release track, and upload the
.aab. Google's guide to creating and setting up your app explains the console flow.
Before review, confirm the package name, version code, release track, countries, tester access, and policy forms. A mismatch can force a rebuild and re-upload.
Build the signed iOS .ipa
iOS publishing is often more sensitive because signing must match your Apple Developer account. The app needs a bundle identifier, App ID, distribution certificate, and provisioning profile.
Confirm the bundle identifier
The bundle identifier in your app config must match the App ID registered with Apple. For example,
com.company.appnamemust be consistent across your project and App Store Connect.Use distribution signing assets
Create or let EAS manage the distribution certificate and provisioning profile. Development-only certificates or simulator builds are not valid for App Store submission.
Run the iOS production build
Run an iOS production build to create a signed
.ipa. You can upload it to App Store Connect for TestFlight or App Review.
EAS can reduce the need to manage a local Mac build setup, but it does not remove every dependency. You may still need to fix native module issues, SDK incompatibilities, signing mismatches, missing capabilities, or Apple account permissions.
Finish listings, compliance, and review checks
Write metadata that matches the final build
Your listing should describe the actual uploaded app, not a future version. Reviewers may compare screenshots, descriptions, permissions, and in-app behavior.
| Listing element | Practical note |
|---|---|
| App name | Keep it clear and within current store limits |
| Short description or subtitle | State the core value quickly |
| Full description | Avoid unsupported claims or future promises |
| Keywords | Use relevant terms only |
| Screenshots | Capture from the final build or matching release build |
| Links | Confirm privacy policy and support links are live |
Misleading metadata can delay approval. If your screenshot shows a feature reviewers cannot access, explain it in review notes or remove it.
Declare privacy, SDKs, and permissions accurately
Privacy forms should reflect what your app and its SDKs actually collect. Do not rely only on what users see on screen.
Audit services such as Firebase Auth, analytics tools, payment SDKs, AI APIs, maps, camera modules, push notifications, and crash reporting. Complete App Store privacy labels and Google Play Data Safety forms based on real app behavior.
Also remove unused Android permissions and iOS permission prompts for camera, location, contacts, microphone, or photos. Template apps and generated projects sometimes include permissions the final product does not need.
Expect operational failure modes
A successful build does not guarantee approval. Common delays include failed EAS builds, SDK incompatibilities, signing mismatches, rejected privacy forms, unclear review notes, missing account deletion flows, broken links, and review queues.
Treat submission like a release process, not a single button click. Build in time for at least one rebuild, one metadata correction, and one policy clarification.
Pre-submit checklist
Use this checklist before pressing submit:
- Install the app from a clean state on a real device.
- Complete onboarding, login, core task flow, logout, and account deletion if applicable.
- Confirm production API keys, database rules, and payment settings.
- Check that screenshots match the final build.
- Open privacy policy and support links in a browser.
- Verify App Store privacy labels and Google Play Data Safety answers.
- Remove unused permissions and permission prompts.
- Confirm signing, bundle identifier, package name, version number, and build number.
- Add review notes with demo login details and test instructions.
Open App Store Connect and Google Play Console in a clean browser window before submission. Look for placeholder text, missing contact details, incorrect age ratings, broken screenshots, and stale review notes.
