A step-by-step guide to using Bolt.new to scaffold an Expo/React Native prototype, then moving it into the Expo and Xcode pipeline to actually run on iOS.
Let's set expectations before you type a single prompt. Bolt.new will not hand you a native Swift app. It generates web and JavaScript code, and through Expo/React Native it can scaffold a cross-platform mobile project.
So the realistic goal of this guide is a working prototype: an Expo/React Native app you can preview, then run on an iPhone via Expo Go or a real iOS build.
The final App Store-ready binary still comes from the Expo + EAS + Xcode pipeline, not from Bolt.new itself.
Think of Bolt.new as the fast scaffolding stage. The native build and submission happen downstream, and we'll point you to where that handoff occurs.
Open Bolt.new in your browser and sign in. You don't need to install anything locally because it runs in StackBlitz WebContainers.
Before prompting, write down what your app does in one or two sentences. Clear intent gives the AI a much better starting structure.
Be explicit that you want a mobile app using Expo and React Native. For example: 'Create an Expo React Native app with tab navigation, a home screen listing tasks, and an add-task screen.'
Naming the framework matters. If you just say 'make an app,' you may get a web-only React project that's harder to take to iOS.
Submit your prompt and let Bolt.new scaffold the project. It will create files, install dependencies, and start a dev server in the browser.
When generation finishes, open the file tree. Look for an Expo project structure — an app entry, screen components, and a package.json that references Expo and React Native dependencies.
Read the generated code rather than trusting it blindly. AI output is a first draft; confirm the navigation library, the component structure, and that it's genuinely a React Native project and not a web React app.
If the result is web-only, refine your prompt and regenerate. Tell the AI specifically to use React Native components like View, Text, and FlatList instead of HTML elements.
Now use the chat loop to build out screens. Ask for one focused change at a time — 'add a details screen,' then 'wire navigation from the list to details.'
Smaller, scoped prompts produce cleaner diffs and are easier to verify than one giant request.
After each change, check the preview and skim the modified files. Catch problems early before they compound across the codebase.
Keep your styling consistent. If the AI mixes web styling conventions into a React Native project, correct it explicitly so the prototype stays portable to mobile.
The in-browser preview is great for web, but real iOS testing needs the project on your machine. Export or download the project from Bolt.new, or connect it to a GitHub repository.
Clone or unzip it locally and open a terminal in the project folder. You'll want Node.js and the Expo tooling installed on your machine for the next steps.
Run the install command for your package manager so dependencies resolve locally. WebContainers handled this in the browser, but now you need a real local install.
Confirm the project actually starts with the Expo dev server locally before going further. If it won't start on your machine, fix that before touching iOS builds.
Install the Expo Go app on your iPhone from the App Store. This lets you run an Expo project on a real device without a full native build.
Start the Expo development server in your project. It will display a QR code you can scan to open the app inside Expo Go.
This is the fastest way to see your Bolt.new-generated prototype running on actual iOS hardware. It's still a development preview, not a standalone app.
Note the limitation: Expo Go can't run arbitrary native modules that aren't included in it. For those you'll need a development build, which is the bridge to the next stage.
When you're ready for a standalone iOS build, use EAS (Expo Application Services). EAS Build compiles your project into an iOS app in the cloud, so you don't have to maintain a full local native toolchain.
You'll configure the project for EAS and run a build targeting iOS. This is where the project stops being a web preview and becomes an actual iOS binary.
To build for a device or the App Store, you need an Apple Developer Program account for signing credentials. EAS can help manage those credentials during the build.
This step is squarely outside Bolt.new. Bolt.new gave you the code; EAS and Apple's systems give you the shippable app.
For final submission, you'll work with Xcode and App Store Connect. Even with EAS handling the build, the App Store pipeline runs through Apple's tooling.
Use App Store Connect to set up your app listing, metadata, and TestFlight for beta testing. TestFlight lets you distribute builds to testers before public release.
If you need to open or inspect the native project directly, Xcode on a Mac is where you do it. This is the non-negotiable native stage Bolt.new can't replace.
The takeaway: Bolt.new accelerates the front end of the journey, but a true iOS release always lands in Expo/EAS and Xcode.
Don't assume the in-browser preview equals iOS readiness. Web preview behavior and real device behavior can differ, especially for native components.
Don't skip the code review. Treat generated code as a starting point and verify navigation, state management, and dependencies.
Don't expect to skip Apple's requirements. The Developer Program enrollment, signing, and review process apply no matter how the code was generated.
Finally, keep prompts mobile-specific throughout. The more consistently you steer Bolt.new toward Expo/React Native, the smoother the handoff to the native pipeline will be.
Setting realistic expectations on time saves a lot of frustration. The Bolt.new scaffolding stage is genuinely fast — you can have a clickable prototype in the browser within an afternoon.
The slower parts live downstream, and they are the same parts every React Native team deals with. Setting up Node and Expo locally, aligning dependencies, and getting a first device preview can take an hour or two the first time.
The EAS build and Apple credential setup is the step most people underestimate. Budget extra time for your first iOS build, since signing and configuration almost always need a round or two of fixes.
Apple's review process adds its own wait once you submit. It is usually measured in days, not minutes, and you can't compress it.
The practical takeaway: Bolt.new compresses the early creative work dramatically, but it does not compress the native pipeline. Plan your schedule around the downstream stages, not the prototype.
A fast prototype is only useful if it tells you the truth about your idea. Be deliberate about what the prototype is meant to prove.
If you're validating a user flow, focus prompts on screens and navigation and don't over-invest in backend wiring yet. A clickable flow is enough to test with stakeholders.
If you're validating feasibility of a specific native feature, the prototype must reach a development build early, because that's where native limitations surface. A browser preview can hide the exact thing you need to test.
Label the prototype as a prototype when you share it. Stakeholders who see a polished preview sometimes assume the app is nearly done, which sets unfair expectations for the native work ahead.
Used honestly, a Bolt.new prototype is a cheap way to fail fast or commit with confidence. Used as a stand-in for the finished app, it quietly overstates progress.
No. Bolt.new generates the code. To get an installable iOS app you move an Expo/React Native project into EAS Build and Apple's pipeline, which handle compilation and signing.
You can offload the heavy build to EAS in the cloud, but App Store submission and any deep native work generally involve Xcode and App Store Connect, and Xcode requires a Mac.
Your prompt likely didn't specify Expo/React Native. Re-prompt and explicitly request an Expo React Native project using native components like View and Text.
Expo Go lets you preview your project on a real iPhone quickly without a full native build. It's great for development but can't run custom native modules it doesn't include.
Yes. Code signing and App Store submission require Apple Developer Program enrollment regardless of how the app was generated.