Publishing a Replit App to the App Store and Google Play

Replit Agent can take a description and produce a running app with a backend, database and hosting in one place. That convenience is also what makes the step to the App Store and Google Play confusing: the app already "runs on Replit", so what exactly gets submitted? This guide answers that, then lists the pitfalls specific to Replit-hosted projects.

What you are actually shipping

A store app is a signed binary installed on the phone. For a Replit project there are two realistic shapes:

• Web app plus native shell. Your Replit app keeps running on the server as today. A native iOS and Android app loads it, adds push notifications, offline handling and native navigation, and is what you submit.
• Native or cross-platform client. If your Replit project is an Expo or React Native app, you build it into native binaries. Its backend may still run on Replit.

Most Replit Agent projects are web apps (often a Node or Python backend with a React frontend), so the first shape is the common one.

Step 1: Get off the preview URL

The URL you see while working in the Replit workspace is a development preview. It can change, stop when the workspace is idle and is not meant for users. Before anything goes into a store:

1. Create a deployment. Replit offers several deployment types, such as autoscaling, reserved VM and static deployments; their names and pricing change, so check the current documentation. Choose based on whether your app needs a server that is always available and how it handles background work.
2. Connect a custom domain. The store app should point to a domain you control, so you can move hosting later without shipping a new app.
3. Use production secrets. Set environment variables for the deployment separately from development, and make sure the production database is not the same one you experiment with.
4. Measure cold starts. If your deployment scales to zero, the first request after a quiet period can be slow. Inside an app that looks like a frozen screen. Show a loading state or choose a deployment type that stays warm.

Step 2: Fix the mobile-specific weaknesses

Apps generated quickly are usually tested on a laptop. On a phone, check:

• Layouts at 360 to 430 pixels wide, with the on-screen keyboard open.
• Touch targets of at least roughly 44 points; no hover-only menus.
• Safe areas so headers and bottom bars do not collide with the notch or gesture bar.
• File uploads from the camera and photo library.
• Session persistence: users expect to stay logged in after closing the app.
• Login providers that block embedded web views, such as Google sign-in, which needs a system-browser or native flow.

Step 3: Choose how to produce the native apps

WeSetupYourWebViewApp covers the first option: the team converts your web app into native iOS and Android apps, store-ready with full Xcode and Android Studio projects, within 72 hours. For the trade-offs between wrapping and native, read WebView app vs. native app.

Step 4: Store accounts and declarations

• Apple Developer Program (USD 99 per year). Companies enroll as organizations with a D-U-N-S number; see Apple developer accounts for companies.
• Google Play Console (USD 25 one-time). Personal accounts created after November 13, 2023 need a closed test with at least 12 testers for 14 consecutive days before production.
• Privacy policy and support URL served from your domain.
• App Privacy details and the Google Play data safety form, including data your backend sends to AI providers or analytics tools.
• In-app account deletion if users can register.
• A reviewer demo account and short notes.

Replit-specific pitfalls that cause trouble later

• Secrets in frontend code. Agents sometimes call AI or payment APIs directly from the browser. In an app, anyone can extract those keys. Move such calls to your backend.
• Single environment. Developing directly against production data is risky once real users depend on the app. Separate them before launch.
• No monitoring. Set up error tracking and an uptime check on the deployment. When the server is down, the app is down, and reviewers or users will see it first.
• Agent edits after release. Every change the agent deploys reaches app users instantly. Use a staging deployment and test there first.
• Policy-sensitive features. Digital subscriptions sold inside an iOS app generally fall under in-app purchase rules, which vary by region; check the current guidelines before going live with web checkout.

When Google Play rejects or flags the app, the Google Play rejection fix-it guide lists the usual causes. For iOS-specific submission help, appsubmitter.io sets up signing and submission in your own accounts and guides you through rejections. The general process is the same as for any site, described in how to convert a website into an iOS and Android app.