Replit to Google Play: from mobile artifact to production release

Short answer: Replit builds Android apps, but does not publish them for you

Replit Agent can scaffold a native mobile artifact using Expo and React Native. You can preview it in Replit’s Android Emulator or Expo Go, then use Expo Application Services to produce a signed Android App Bundle.

Replit’s current documentation explicitly says guided Google Play publishing is not yet supported. You must configure the package identity, build the AAB, create the Play Console app, complete policy forms, test and obtain production access yourself or with a release operator.

Identify what kind of Replit project you actually have

Choose Expo, Capacitor or a dedicated native path

Test the hardest requirement before migrating the entire product.

Separate the phone client from the Replit backend

Replit’s mobile architecture has two deployed systems: a client installed from Google Play and a cloud server handling APIs, database, files, integrations and AI.

• Define which logic is safe on the client
• Keep privileged operations on the server
• Use a stable HTTPS production API URL
• Separate development and production endpoints
• Authenticate every protected request
• Validate authorization on the server, not only in the UI
• Version API changes that can break installed clients
• Design retry, timeout and offline behavior
• Monitor client and server with a shared request identifier

Choose the correct Replit deployment type

• Confirm the production run command
• Set health checks and a stable custom domain where useful
• Size CPU and memory for expected requests
• Test deployment restart and scale-from-zero behavior
• Keep scheduled work separate from request-serving APIs
• Record ownership and monthly cost alerts

Do not store production data on the deployment filesystem

Replit documents that the published app filesystem is not persistent and resets when you publish. A file that survives preview can disappear in production.

• Use PostgreSQL for structured persistent data
• Use Object Storage or an external object store for uploads
• Do not use local JSON or SQLite as the production source of truth
• Test upload, download and deletion after a redeploy
• Back up business-critical data outside the running instance
• Document restore and migration procedures
• Remove temporary files and enforce storage limits

Own the source, accounts and release credentials

• Export or synchronize source to a business-owned GitHub repository
• Protect the production branch
• Tag the commit used for every AAB
• Keep the Replit app under the business account
• Keep Expo/EAS under the business organization
• Create Google Play under the correct personal or organization account
• Store upload and service-account credentials securely
• Document who can rebuild, submit and recover access
• Verify a clean checkout builds outside one Replit session

Make the Expo build reproducible outside the preview

Expo Go and Replit’s emulator are development surfaces. Establish a clean build before starting the Play Console paperwork.

npm install
npx expo-doctor
eas login
eas init
eas build:configure
eas build --platform android --profile production

• Commit the dependency lockfile
• Resolve Expo SDK and package mismatches
• Separate development, preview and production configuration
• Keep private server values out of the mobile bundle
• Use a development build for unsupported Expo Go modules
• Record EAS project ID and owner
• Keep build logs and source commit together

Freeze the Android package identity early

• Set a unique package name such as com.company.product
• Confirm no existing Play listing needs a different identity
• Set app name, slug, scheme, version and Android version code
• Configure icon, adaptive icon, splash and orientation
• Choose supported phones, tablets and form factors
• Keep package ownership under the publishing business
• Do not lose the upload-key or Play App Signing relationship

The package name is the permanent identity of the Play listing. Changing it creates a different app.

Use the correct build artifact

Google Play requires new applications to use an Android App Bundle.

Use an EAS production profile that produces .aab. Test the distributed build through Play as well as any locally installed APK.

Audit authentication against the production domain

• Replace replit.dev callbacks with stable production URLs
• Do not confuse REPLIT_DEV_DOMAIN with the deployed domain
• Add Android scheme and universal/app links where needed
• Test email verification and password reset from a real device
• Test Google login with the production signing identity
• Handle expired, cancelled and denied login flows
• Restore the intended screen after authentication
• Provide reviewers working credentials without unavailable 2FA
• Add in-app account deletion when account creation exists

Keep secrets on the server

Replit Secrets encrypts server environment values, but any value embedded in the Expo client can be extracted from the installed application.

• Keep API keys with privileged access in Replit Secrets
• Proxy third-party calls through authenticated server routes
• Use public client keys only when the provider designs them to be public
• Rotate credentials that appeared in code, logs or chat
• Separate development and production secrets
• Restrict collaborator and deployment access
• Never print secrets during debugging
• Verify the production deployment actually receives required variables

Add Android permissions deliberately

• Request camera, microphone, location, contacts or files only when needed
• Explain the user-facing reason before the system prompt
• Handle denial and “don’t ask again” states
• Prefer scoped storage and narrow media access
• Avoid broad package visibility and all-files access
• Remove permissions inherited from unused libraries
• Test behavior on multiple Android versions
• Complete any Play permission declarations accurately
• Rebuild after native configuration changes

Implement the complete notification path

• Configure the Expo notifications plugin and project ID
• Add FCM v1 credentials for Android
• Request consent at a meaningful product moment
• Store tokens against user, device and environment
• Remove invalid tokens
• Send through a protected Replit server route
• Handle foreground, background and terminated states
• Route notification taps to valid app destinations
• Track provider tickets and delivery receipts
• Test the signed build on physical Android devices

Use Google Play Billing for digital goods

Digital content, features and subscriptions sold inside a Play-distributed Android app generally require Google Play Billing.

• Classify physical, real-world service and digital transactions
• Create stable Play product and subscription identifiers
• Use Play Billing directly or a trusted layer such as RevenueCat
• Keep entitlements on the server or purchase service
• Implement purchase acknowledgement
• Handle pending, cancellation, restore and account switching
• Process renewal, grace period, refund and revocation
• Test with Play license testers
• Give reviewers a complete paid path

Create the Play Console application correctly

1. Create the app with its default language and public name.
2. Select app versus game and free versus paid carefully.
3. Accept Play App Signing terms.
4. Use the same package name as the Expo production config.
5. Add developer contact information.
6. Complete the dashboard setup tasks before requesting production.

A free app cannot later be converted into a paid download. Monetization inside the app remains possible.

Complete every App content declaration

• Privacy policy
• App access and reviewer credentials
• Ads declaration
• Content rating questionnaire
• Target audience and children assessment
• News, health, financial or government declarations where relevant
• Data safety
• Permissions and sensitive API declarations
• Content rights and user-generated-content safeguards
• Account deletion URL and in-app path where required

These answers must reflect the installed client, Replit backend and every third-party SDK. Visible screens tell only part of the story.

Build the Data safety form from a real inventory

Google requires Data safety even for closed testing, except applications that remain exclusively on internal testing.

• List every data type leaving the device
• Include Replit API, database, storage and connector traffic
• Include analytics, crash, payment, advertising and notification SDKs
• Mark collection versus sharing accurately
• Record purpose, optionality and retention
• Explain encryption in transit and deletion
• Publish a privacy policy even when no user data is collected
• Update the form when code or SDK behavior changes

Build and submit the AAB with EAS

eas build --platform android --profile production
eas submit --platform android

• Create the Play Console app first
• Configure the production package name
• Create a narrowly scoped Google service account for EAS Submit
• Upload its JSON key to EAS credentials
• Build the production AAB from a known commit
• Check version code and target SDK
• Submit to internal testing or upload manually
• Revoke and replace exposed service-account keys

EAS Submit can create the first internal-track release, but the application remains a draft until the Play listing and required setup are complete.

Use internal and closed testing as release gates

• Test install and upgrade from Play
• Use Play pre-launch reports
• Check crashes and Android vitals
• Test low-memory, slow-network and offline states
• Test common OS versions and device sizes
• Collect and summarize tester feedback
• Fix issues before applying for production

Plan for the 12-testers/14-days requirement

New personal developer accounts created after November 13, 2023 must currently run a closed test with at least 12 opted-in testers for 14 continuous days before applying for production access.

• Confirm whether the specific developer account is subject to the rule
• Recruit real testers before the desired launch date
• Keep at least 12 continuously opted in
• Ask testers to use the core journeys
• Collect feedback through a documented channel
• Record changes made from the test
• Prepare honest production-readiness answers
• Do not promise a launch date that ignores this waiting period

Prepare the store listing and production rollout

• App name, short description and full description
• Icon, feature graphic, phone and tablet screenshots
• Category, tags and contact details
• Countries, pricing and availability
• Release notes
• Internal/closed track tester instructions
• Managed publishing choice
• Staged rollout percentage
• Pause criteria and rollback plan
• Support coverage for the first production days

Common Replit-to-Google-Play failure modes

What App Release Ops can own

Send these materials for a useful scope

• Replit project and mobile/web artifact type
• Business-owned source repository
• Expo account, project and SDK version
• App and EAS configuration
• Production Replit deployment URL and type
• Database, storage and connector inventory
• Latest EAS build or error logs
• Google Play developer account type and creation date
• Payment model, permissions and sensitive data
• Current Play Console setup or rejection

Official implementation references

• Replit: native mobile apps and Android publishing limits
• Replit: deployment persistence and troubleshooting
• Replit: secrets
• Expo: submit to Google Play with EAS
• Google Play: create and set up an app
• Google Play: Data safety
• Google Play: personal-account testing requirements
• Android: app signing

Related release paths

• Google Play publishing service
• Mobile app creation service
• Best mobile app builder comparison
• Production readiness audit
• Google Play publishing guide
• Mobile app monitoring
• Store monetization setup