A practical walkthrough for getting your Bolt.new project out of the browser, into GitHub and your local environment, and onto the path toward an iOS build with EAS and Xcode.
Bolt.new runs in the browser using WebContainers, which is fantastic for speed but is not where iOS apps get built. To ship to iOS you must get the project out of the browser.
Exporting puts your code under version control and onto your own machine, where the real Expo/React Native and Xcode tooling lives.
This is the bridge step. Everything App Store-related happens after the code leaves Bolt.new.
This guide assumes you've generated an Expo/React Native project, since that's the only Bolt.new output with a realistic path to iOS.
Bolt.new supports connecting your project to GitHub. Authorize the connection so it can create or push to a repository.
Putting the project in GitHub gives you version history, collaboration, and a clean source of truth for your build pipeline.
Choose a private repository if your project contains anything sensitive. You'll be adding backend keys and configuration soon.
Confirm the push succeeded by checking the repository in GitHub. Make sure the full project structure made it across, not just a partial snapshot.
On your machine, clone the repository. This is where the project transitions from a browser sandbox to a real local environment.
For iOS work you'll ultimately want macOS, since Xcode only runs on a Mac. You can do earlier steps elsewhere, but plan for a Mac at the finish line.
Install Node.js and the Expo tooling locally. WebContainers provided these in the browser; now you need them natively.
Open the project in your editor of choice and get familiar with the structure before changing anything.
Run your package manager's install command in the project folder. This resolves all dependencies on your machine.
Start the Expo development server to confirm the project runs locally. If it fails here, fix it before going near the iOS build.
Watch for version mismatches. AI-scaffolded projects sometimes pin dependency versions that need a small nudge to align with current Expo releases.
A clean local run is your green light. It means the project is portable beyond Bolt.new's environment.
Install Expo Go on your iPhone and run the project from your local dev server. Scan the QR code to load it on the device.
This confirms the app behaves on real iOS hardware, not just in a browser preview. Differences here are common and worth catching early.
For features Expo Go can't run, you'll need a development build. That's a normal step as your app grows beyond basic components.
Treat this as your real-world checkpoint before investing in full production builds.
Set up EAS (Expo Application Services) in your project. EAS Build compiles your React Native app into a native iOS binary in the cloud.
This is the step that turns JavaScript code into an actual .ipa. Bolt.new never did this — it only produced source code.
To build for iOS, you'll need Apple Developer credentials for signing. EAS can manage much of the credential handling for you.
Run an iOS build through EAS and confirm it completes. A successful build is your first real iOS artifact.
For submission and any deep native inspection, Xcode on a Mac is the tool. App Store Connect is where your listing, metadata, and TestFlight builds live.
Upload your build and distribute it via TestFlight to test with real users before public release. This is standard Apple workflow.
If you need to adjust native settings, entitlements, or capabilities, that work happens in the native project — not in Bolt.new.
This stage is the unavoidable native finish line. Plan time for Apple's review process as well.
Once exported, your project should live and evolve in your own repo and tooling, not back inside Bolt.new for major changes.
You can still use AI assistance, but a real codebase benefits from proper branches, code review, and CI.
Keep your secrets out of source control and in environment configuration. This matters more as the project becomes production-bound.
The overall pattern is clear: Bolt.new for fast scaffolding, then GitHub plus Expo/EAS plus Xcode for the durable iOS lifecycle.
Many teams want to keep using Bolt.new for quick iteration even after exporting. That's fine, but decide where the source of truth lives first.
The cleanest pattern is to treat your GitHub repository as canonical once you've moved to local tooling. Use Bolt.new for experiments, then bring changes back through normal pull requests.
If you push from both Bolt.new and your local environment without coordination, you invite merge conflicts and overwritten work. Pick one primary direction for changes and stick to it.
For larger features, it's usually simpler to build locally where you have full control over dependencies, native config, and your build pipeline. Reserve Bolt.new for the lightweight, conversational changes it does best.
Document the workflow for your team so everyone knows which environment owns which kind of change. A little process here prevents a lot of confusion later.
The moment your project leaves the browser, secrets management becomes your job. Generated scaffolds sometimes leave example keys or placeholder values directly in source files.
Before your first push, scan the project for anything sensitive. API keys, backend URLs, and tokens should live in environment configuration, not in committed code.
Add a proper ignore file so local environment files never reach the repository. This is easy to overlook when a project starts life in a sandbox that handled configuration for you.
For builds, your secrets need to exist in the build environment too. EAS supports environment configuration so your production builds point at the right backend without hardcoding values.
Getting this right early is far cheaper than rotating leaked keys later. Treat the export as the moment to put secrets on a disciplined footing.
Once your code lives in GitHub, you can automate the parts of the pipeline that benefit from consistency. Continuous integration is where this pays off.
A basic CI setup can install dependencies, run your linter, and run tests on every pull request. That alone catches a lot of the rough edges common in AI-scaffolded projects.
You can also connect builds to your workflow so that merging triggers an EAS build. This keeps your iOS artifacts reproducible rather than depending on one person's machine.
Keep the pipeline simple at first. A single workflow that installs, checks, and builds is enough to make the project feel like a real codebase rather than a one-off generation.
The goal is durability. Bolt.new is great for the first sprint, but CI is what keeps the project healthy across the months of iteration that follow.
No. Bolt.new runs in the browser and can't compile or sign iOS apps. You must export to your own environment and use Expo/EAS and Xcode.
Exporting to GitHub and running locally can happen on various systems, but Xcode and final App Store submission require a Mac. EAS can offload the cloud build itself.
AI-generated projects sometimes pin versions that need adjusting. Align them with current Expo releases and reinstall before building for iOS.
GitHub gives you version history, collaboration, and a clean integration point for your build pipeline and CI. A zip is a one-time snapshot.
From EAS Build (or a local native build), not from Bolt.new. Bolt.new only produces source code.