Bolt.new is quick to a first version: a prompt, a preview, a Publish button. Getting from there to an app people install from the App Store is a different job, and which job depends on what kind of Bolt project you have.
Two kinds of Bolt project
Bolt builds two things, and its own documentation warns that projects created for the web do not easily switch over to mobile. If you did not ask for a mobile app in your first prompt, you have a web project.
| A web project | An Expo project | |
|---|---|---|
| What it is | A web app that runs in the browser | A React Native app for iOS and Android from shared code |
| Publishes to | A free bolt.host address, or a custom domain on paid plans | An EAS build you run yourself, then TestFlight and App Store Connect |
| On your phone | No iOS build of any kind | A preview in Expo Go, through a QR code |
Where Bolt stops
For a web project, the tempting shortcut is a native shell around the published address. It runs into Apple’s Guideline 4.2: a WebView around your-app.bolt.host is a repackaged website by definition.
For an Expo project, the code is real, but the last mile is not Bolt’s. Its documentation lays it out: install the EAS CLI locally, run the iOS build with automatic submission, wait for TestFlight, then submit from App Store Connect for public release.
In Bolt
- A prompt“Make a mobile app”
- An Expo projectReact Native code
- Expo Go previewa QR code, on your phone
- GitHubcommits synced
After Bolt: yours to do, or AirBuild’s once you bring it
- The buildthe EAS CLI on your computer
- TestFlighttry it on an iPhone
- The listingscreenshots, privacy answers, review notes
- App Reviewanswer, fix, resubmit
App Review is a conversation
A reviewer asks why the app needs a permission, or points at a screen that does nothing, and you fix it and submit again. That loop is the part the tools leave to you. Once you bring the project to AirBuild, the AI team has that conversation for you, and you see every step.
- Submitthe build and the listing
- The reviewer askssay, why the calendar?
- Fixa purpose string, a screenshot
- Resubmitwith the reply attached
If the reviewer asks again, round it goes
How bringing it works
Leave the link
Join the waitlist with your published
bolt.hostaddress or the GitHub repository Bolt syncs to, and a sentence about what the iOS app should do and who it is for. Expo projects are welcome; the repository is the better link for those.Your AI team builds it again in SwiftUI
AirBuild’s product, design and engineering agents read what your app does, its screens and its flows, and build a native iOS app from them with Apple’s own frameworks. Your Bolt project stays untouched; you keep editing and publishing it in Bolt.
Try it on your iPhone, then App Review
The app reaches your phone through TestFlight so you can try it and ask for changes in plain language. When it is ready, AirBuild prepares the App Store listing, submits, tracks the review, replies to the reviewers, fixes what they raise and resubmits.
What carries over
| Part of your app | What happens to it |
|---|---|
| Screens and flows | Rebuilt as SwiftUI views with iOS navigation: tab bars, stacks, sheets and the back gesture. An Expo project maps the same way, screen for screen. |
| Copy, colors and branding | Carried over. The app should feel like yours, not like a template. |
| Data and backend | Stays where it is. Tell us what your app talks to, Supabase, Firebase or an API, and we plan the iOS app around it. |
| Your Bolt project | Unchanged, and still yours to edit and publish in Bolt. |
What to have ready
- The published link of your Bolt project, or its GitHub repository if it is an Expo project or has pages behind sign-in.
- An Apple Developer Program membership, or a plan to enroll before the app is submitted.
- One paragraph on what the iOS app should do first. It does not have to be everything the web app does.
- A privacy policy URL. Apple asks for one, and App Store Connect will not accept a submission without it.
Questions
Can Bolt.new publish an app to the App Store?
Not by itself. A Bolt web project publishes to a bolt.host address. A Bolt Expo project gives you React Native code, and Bolt’s documentation says you then need a paid Apple Developer account and the EAS CLI on your own computer to build and submit it.
My Bolt project is a web app. Can I wrap it for iOS?
You can, but Guideline 4.2 says an app should include features, content and UI that elevate it beyond a repackaged website. A shell around your bolt.host address is exactly that, and is often rejected.
My Bolt project already uses Expo. Why bring it to AirBuild?
Because Bolt stops at the code. Running the build, filling in the App Store listing and App Review are on you. AirBuild builds the app again as native SwiftUI and handles App Review from submission to resubmission.
What happens to my backend?
It stays where it is. Tell us what your app talks to, Supabase, Firebase or an API, when you join the waitlist, and we plan the iOS app around it rather than moving your data.
Do I need a Mac or Xcode?
Neither. AirBuild runs your AI team on a Mac or in the cloud, and the app reaches your iPhone through TestFlight. You do need an Apple Developer Program membership to publish.
Who owns the iOS app’s code?
You do. Your Bolt code stays yours, and so does the SwiftUI project AirBuild builds from it.