How to Convert a Bolt.new Project into an Android App (APK/AAB)

Short answer: Bolt.new builds and deploys webapps — there is no “Download APK” button and never will be, because Bolt runs entirely in your browser and can't run the Android toolchain. The reliable path to Android is: publish your Bolt project to a live URL (Bolt's one-click hosting or Netlify), then wrap that URL into a signed Android APK/AAB with a cloud wrapper build — about ten minutes end to end, and the first build is free. If Bolt generated an Expo/React Nativeproject instead of a web app, that's a different situation, and I'll be straight with you about it below.

What Bolt.new actually gives you (and doesn't)

Bolt.new is StackBlitz's AI app builder. You describe an app, it writes the code and runs it live in a browser-based container. For most prompts the output is a web application — typically Vite + React with Tailwind — and as of mid-2026 you can ship it three ways: click Publishand get a live URL on Bolt's own hosting (a *.bolt.host subdomain, with custom domains on paid plans), deploy to Netlify, or download the whole project as a ZIP and host it anywhere.

What Bolt cannot do is compile an Android app. Bolt's environment is WebContainers — a virtual machine inside a browser tab. There's no Android SDK, no Gradle, no Java toolchain, no keystore, and no way to install them. So even when Bolt's mobile mode generates an Expo (React Native) project, it can only preview it through the Expo Go app on your phone; producing an actual signed binary has to happen somewhere else. That “somewhere else” is what this post is about.

One more honest framing before the steps. A live URL — even a polished PWA — is not something you can upload to Google Play. Play accepts signed app bundles (AAB), not URLs, and an Add-to-Home-Screen prompt is not store presence. That gap between “my app is live at a URL” and “my app is an installable, store-ready package” is exactly the gap a wrapper build closes. It's the same story for every AI web builder — we've written the Lovable version and the Replit version of this guide, and the physics are identical.

The clean path: publish, then wrap

1. Publish your Bolt project. In the Bolt editor, click Publish (or deploy to Netlify). You need a stable HTTPS URL that loads without the Bolt editor around it. If you can, put it on a domain you control — wrapped apps point at a URL forever, and owning the domain means you can move hosting later without shipping an app update.
2. Sanity-check it on a phone browser first. Open the URL on your actual phone. The wrapper faithfully shows your web app — if a layout is broken at 390px wide, it will be broken in the app too. Fix it in Bolt, hit Publish again, re-check.
3. Create a wrapper build. In Code2Native, paste the URL, set your app name and package ID (something like com.yourapp.mobile — it's permanent once on Play, so choose carefully), and upload one 512×512 icon. Every density variant, the splash screen, and a release keystore are generated for you.
4. Build. A few minutes later you have a signed APK (install directly on any Android phone) and a signed AAB (the format Google Play requires). Push notifications via OneSignal, hardware back button, offline screen, and tel:/mailto: handling are wired in. Device APIs a browser tab can't give you — that's the point of the shell.
5. Ship it.Send the APK to testers today, or upload the AAB to Google Play under your own developer account ($25 one-time fee to Google). Note that new personal Play accounts must run a closed test with real testers before production — there's a $249 add-on if you want that requirement handled for you.

The part I like most about this route for Bolt specifically: Bolt projects change constantly— you re-prompt, it rewrites half the app. Because the wrapped app renders your live URL, every time you hit Publish in Bolt, every installed phone gets the new version instantly. No rebuild, no store review, no “update available” nag.

The honest exception: Bolt gave you an Expo project

Bolt's mobile mode generates Expo/React Native projects, previewed by scanning a QR code with Expo Go. If that's what you have, I need to be explicit: React Native and Expo source builds are not a live path on our platform.They're on our waitlist, and I won't pretend otherwise — our live source pipeline covers Flutter, native Android (Gradle), and Capacitor projects that include an android/ folder. An Expo export is none of those.

Your real options with an Expo project today: use Expo's own EAS Build cloud service to compile it (that's the intended path for Expo code, and it works), or — if what you built is honestly a web-shaped app that didn't need to be React Native — re-prompt Bolt for a web build, publish it, and wrap the URL. A surprising number of “mobile apps” people generate are forms, feeds, and dashboards that lose nothing as a wrapped web app and gain a much simpler shipping story.

Your options, side by side

The DIY route is real and free, and if you want to learn the Android toolchain it's a fine project — our free-conversion guide walks through both it and the wrapper route in detail. The catch for Bolt users specifically: a Capacitor build bundles your web files into the binary, so every Bolt re-prompt means export, rebuild, re-sign, and re-upload. Against a tool whose whole appeal is iteration speed, that's a bad fit.

Who should do what

Wrap your published URL if:

• Your Bolt project is a web app that's live (or five minutes from live) at a URL.
• You're still iterating in Bolt and want installed users on the latest version automatically.
• You want Google Play presence: you need a signed AAB, and a URL alone will never be one.
• You want push notifications — the single biggest thing a browser tab can't reliably give you on mobile.

Take a different route if:

• You have an Expo project and it must stay React Native — use Expo's EAS Build. Our RN/Expo support is waitlist-only and I won't sell you a path that isn't live.
• You need deep native features — Bluetooth, background geolocation, heavy offline sync. A WebView shell is the wrong architecture; build native or Flutter.
• You only need a handful of desktop users to reach the app — a plain URL or PWA may honestly be enough. Don't buy a wrapper you don't need.

And iOS? Honest answer: partially

Android is the strong path here — signed, store-ready, minutes. On iOS we build an unsigned .ipa on real Apple silicon (Pro tier and up) that you re-sign with your own Apple Developer certificate and submit yourself. We never ask for your Apple ID, and we do not submit to the App Store for you — anyone who promises App Store publishing without your own Apple account involved deserves your suspicion. If you just want iPhone home-screen presence without certificates at all, a zero-signing Web Clip does that. Ship Android first; decide on iOS with real user data.

FAQ