If Bolt.new gives you a web app when you wanted iOS, the fix is steering it to Expo/React Native and understanding that the native build always finishes in the Expo and Xcode pipeline.
You asked Bolt.new for an iOS app and got a web app — HTML elements, web routing, and a browser-only structure. This is the single most common surprise for Apple developers trying the tool.
The confusion is understandable but the root cause is simple. Bolt.new is fundamentally a web app builder running in browser-based WebContainers.
It does not produce native Swift, and by default it leans toward web frameworks like React.
The good news: there's a legitimate mobile path through Expo/React Native, and most of the fix is about steering the tool correctly.
Bolt.new's home turf is the web. WebContainers run Node.js in the browser, which is ideal for web stacks and instant previews.
When your prompt is vague — 'build me an app' — the AI defaults to what it does most easily, which is a web React app.
There is no native Swift output at all, so 'iOS app' can't mean a SwiftUI project here. The closest realistic target is a cross-platform React Native app via Expo.
So the mismatch is partly a prompt issue and partly a fundamental capability boundary you need to understand.
Rewrite your prompt to name the framework. Say 'Create an Expo React Native mobile app,' not just 'create an app.'
Ask for React Native primitives explicitly: View, Text, ScrollView, FlatList, and React Navigation — not divs and web routing.
State the target out loud: 'This should run on iOS via Expo.' The more specific you are, the better the scaffold.
If the first attempt still produces web output, regenerate with even more direct instructions. Prompt precision is your main lever here.
Open package.json and check the dependencies. A real mobile project references Expo and react-native, not just react and a web bundler.
Look at the components. If you see HTML tags like div and span instead of View and Text, you still have a web app.
Check for an Expo configuration file and an app entry consistent with Expo. Its presence is a strong signal you're on the right track.
If the project is web-only, don't try to patch it piecemeal. Re-prompt for a clean Expo scaffold instead.
Here's the part no prompt can fix: Bolt.new will never output a native Swift Xcode project. That's not a bug, it's the tool's scope.
Even a perfect Expo/React Native scaffold is still not a compiled iOS app. It's source code that must be built by Apple's toolchain.
If your requirement is genuinely native Swift, Bolt.new is the wrong tool, and you should use Xcode directly.
Clarifying your real requirement early saves hours. Decide whether cross-platform React Native is acceptable or whether you need native Swift.
Once you have a proper Expo project, export it and run it locally. Preview it on your iPhone with Expo Go to confirm it's genuinely mobile.
When you want a standalone iOS app, use EAS Build to compile a native binary in the cloud.
Finish in Xcode and App Store Connect for submission and TestFlight. This is the standard, supported route.
This sequence is the actual 'iOS app' outcome. Bolt.new handled scaffolding; Expo/EAS/Xcode handle the native reality.
Start every mobile project by naming Expo and React Native in your very first prompt. Don't let the AI default to web.
Keep a short reusable prompt template that specifies mobile framework, navigation, and native components.
Verify the project type immediately after generation, before building features on top of the wrong foundation.
And set expectations with your team: Bolt.new produces a React Native scaffold, not a finished native iOS app.
If you need deep native iOS features — advanced background processing, intricate platform APIs, or maximum performance — start native in Xcode.
If cross-platform with one codebase is the goal and React Native fits, Bolt.new's Expo path is a reasonable accelerator.
For a quick prototype or stakeholder demo, even a web app from Bolt.new can be useful as a throwaway proof of concept.
Match the tool to the requirement. Most 'web app instead of iOS' frustration disappears once you pick the right target deliberately.
Save yourself repeated frustration by keeping a tested prompt scaffold on hand. A good one names the framework, the navigation, and the component primitives in a single instruction.
For example: 'Create an Expo React Native app targeting iOS. Use React Navigation for screens and React Native components like View, Text, ScrollView, and FlatList. Do not use HTML elements or web routing.'
That single sentence removes most of the ambiguity that causes Bolt.new to drift back toward a web build. The AI follows explicit constraints far more reliably than vague intent.
When you need a new screen later, keep reinforcing the same vocabulary. Ask for 'a new React Native screen,' not just 'a new page,' so the model stays in mobile mode.
Treat the prompt like a small spec you reuse across projects. The more consistent your language, the more consistent the scaffolds you get back.
Sometimes you've already built real work on top of a web scaffold before realizing it isn't mobile. You don't always have to throw it away.
If the project is mostly UI and logic with a thin web shell, much of your business logic may be portable. The data handling and state often survive a move to React Native even when the components don't.
The components themselves are the hard part. Web elements like div, span, and HTML forms have no direct equivalent and must be rewritten as React Native primitives.
A reasonable approach is to start a fresh Expo scaffold, then port your logic over piece by piece while rebuilding the UI in native components. This is usually cleaner than trying to convert a web project in place.
Weigh the effort honestly. If the web work is small, regenerate; if it's substantial, port the logic and rebuild the surface. Either way, don't try to bolt mobile onto a fundamentally web structure.
A lot of the friction around this issue isn't technical — it's expectations. Non-technical stakeholders often hear 'AI built the app' and assume an App Store-ready iOS product exists.
Be clear and early about what Bolt.new produces. It generates source code, and for mobile that means a React Native scaffold, not a finished native binary.
Frame the native pipeline as a normal, expected stage rather than a surprise. Every React Native app, however it was started, finishes in Expo or EAS and Apple's toolchain.
Giving stakeholders this mental model up front prevents the awkward conversation where a polished preview is mistaken for a shippable app.
Clear expectations turn the boundary from a disappointment into a plan. The prototype impresses, and everyone understands what still stands between it and the App Store.
Because it's fundamentally a web app builder running in browser-based WebContainers. Vague prompts default to web React. You must explicitly request Expo/React Native.
No. Bolt.new does not produce native Swift under any prompt. The closest mobile target is a cross-platform React Native app via Expo.
Check package.json for Expo and react-native, and confirm components use View/Text rather than HTML tags like div and span.
Not yet. It's source code that still needs EAS Build and Apple's pipeline to become an installable iOS binary.
When you need deep native features, maximum performance, or genuine native Swift. In those cases start directly in Xcode.