Publishing a Bolt.new App to the App Store and Google Play

Bolt.new from StackBlitz turns prompts into running full-stack projects in the browser. The result often looks like an app, but the App Store and Google Play need installable, signed binaries. The first step is to figure out what you actually have, because that decides everything that follows.

First, identify what Bolt generated

Open the project's file tree and package.json. You will usually find one of these:

Bolt has offered Expo-based mobile projects alongside web projects; check your project to see which kind you have. Most Bolt projects in the wild are web apps, so this guide spends more time on that path.

Path A: Bolt web app to native app

1. Move the code to a repository you own. Export or connect to GitHub so you are not dependent on the editor session.
2. Deploy to production hosting on your own domain. Bolt can deploy to a hosting provider; whichever you choose, the app needs a stable HTTPS URL. Preview URLs are not suitable for a store app.
3. Make the web app mobile-ready: responsive layout, safe-area handling, fast first load, no desktop-only interactions such as hover menus.
4. Wrap it in a native shell with features that justify an app: push notifications, offline screen, native navigation, device features where useful.
5. Sign, test and submit through TestFlight and the Play Console testing tracks.

The wrapping step is where many founders get stuck, because it involves Xcode, Android Studio, certificates and store-specific settings. WeSetupYourWebViewApp takes that off your plate: the team converts your web app into native iOS and Android apps, store-ready with full Xcode and Android Studio source code, within 72 hours. If you prefer to do it yourself, WebViewGold templates cover the same ground without coding.

Path B: Bolt Expo project to the stores

1. Move the project to your own machine or repository and install dependencies.
2. Set a unique bundle identifier (iOS) and package name (Android) in the Expo config.
3. Create an Expo account and configure EAS Build; let it manage credentials or provide your own.
4. Build for iOS and Android, install on real devices and fix what only shows up there: keyboard handling, permissions, safe areas.
5. Submit with EAS Submit or upload manually to App Store Connect and the Play Console.

Expect some cleanup: generated mobile projects sometimes include unused libraries, placeholder screens or permissions nobody needs. Remove them before review.

Bolt-specific pitfalls

• Keys in the frontend. Prompts like "add AI chat" can put API keys into client code. In a store app, those keys are extractable. Move calls behind a server function.
• Database rules left open. If your Bolt app uses Supabase, check that row-level security is enabled and tested with two accounts.
• Auth redirects. Login flows built for a browser may redirect to URLs that do not work inside a wrapped app. Some providers, such as Google sign-in, also block embedded web views, so plan a system-browser or native flow.
• Fragile generated code. Iterating with many prompts can leave duplicate components and dead code. A short cleanup pass reduces bugs that reviewers might hit.
• Payments. Selling digital content inside an iOS app generally falls under in-app purchase rules, which differ by region. Check Apple's current guideline 3.1.1 before adding Stripe checkout for digital goods.

Accounts and listing you need either way

• Apple Developer Program membership (USD 99 per year); organizations need a D-U-N-S number. See Apple developer accounts for companies.
• Google Play Console account (USD 25 one-time). Personal accounts created after November 13, 2023 need a closed test with at least 12 testers for 14 consecutive days, explained in the 12-tester rule.
• Privacy policy, support URL, app icon, screenshots from the real app, App Privacy details and the Google Play data safety form.
• In-app account deletion if users can create an account.
• A demo login for reviewers.

Which path should you choose?

If your Bolt project is a web app and its value is mainly content, forms, dashboards or bookings, wrapping is the fastest and cheapest route, and you keep one codebase for web and mobile. If your app depends on heavy device features, complex offline behavior or highly polished native interactions, an Expo or native build is the better long-term home. The same decision applies to other builders; three routes compared for Lovable apps walks through it in detail, and Lovable vs. Bolt vs. Base44 compares the builders themselves.

A phone-first test before you submit

Whichever path you take, test with real users before submitting. A Bolt prototype that impressed you in the browser can feel very different on a phone held in one hand on a train. Give five people a TestFlight or closed-track build and a single task, then watch where they hesitate. Typical findings:

• Tap targets that are too small or too close together.
• Forms where the keyboard covers the submit button.
• Loading states that look like the app has frozen on a slow connection.
• Navigation that relies on the browser's back button, which does not exist in the app.

Fix these before review. Reviewers use the app briefly, but they notice the same friction your users would.