# Can Bolt.new Build Native Mobile Apps? Yes, Here's How

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-01. 10 min read.
> Source: https://vp0.com/blogs/can-bolt-new-build-native-mobile-apps

The two paths from a Bolt prompt to a real app on the App Store.

**TL;DR.** Bolt.new can build native mobile apps two ways: the Expo path, where it generates real React Native for iOS and Android that you preview with Expo Go and build with EAS, and the Capacitor path, where you wrap an existing Bolt web app in a native shell. Both ship to the stores, though Bolt stops at the code and leaves the signed build to you, plus the $99 Apple and $25 Google fees. Start from a clean VP0 design so it feels truly native.

Yes, Bolt.new can build native mobile apps, and there are two ways to do it. The main path uses Bolt's [Expo integration](https://support.bolt.new/integrations/expo) to generate real React Native code for iPhone and Android from a prompt, which you preview on your phone and build with Expo's cloud service. The second path is to take a web app Bolt built and wrap it in a native shell with Capacitor. Either way you get an app that installs from the store, though Bolt itself stops at the code and leaves the final signed build to you. The piece Bolt cannot supply is a mobile-first design, which is where a clean [VP0 design](/blogs/bolt-new-mobile-app/) makes the difference between a real-feeling app and a web page in a frame.

## Can Bolt.new build native mobile apps?

Yes. Since its V2 update, Bolt generates React Native through Expo, so a plain-English prompt produces a cross-platform mobile app that runs on both iOS and Android. When you ask Bolt for a mobile app, it automatically scaffolds an Expo project with screens and navigation, and you can preview it on a real device in minutes.

The honest framing is that Bolt generates a native app, but it does not compile and ship it. That final step, turning the code into a signed app on the store, happens through Expo's build service and your own developer accounts. So Bolt builds the app, and a short, well-trodden pipeline turns it into something on the App Store.

## What "native" means for a Bolt app

It helps to be precise, because native means different things. Bolt's Expo output is a real native app in the sense that it installs and runs like any other and can access device features. But it is built with React Native, which uses JavaScript rendering native components, rather than being written in Swift or Kotlin.

For most apps, this distinction is invisible to users and works beautifully. It matters only for graphics-heavy or deeply hardware-specific products. So when people ask whether Bolt makes truly native apps, the accurate answer is that it makes real, installable apps through React Native, which is native enough for the vast majority of ideas, a point covered in more depth in the [Bolt mobile app overview](/blogs/bolt-new-mobile-app/).

## Two ways to get a native app from Bolt

There are two distinct routes, and the right one depends on what you have already built:

| Approach | How it works | Output | Best when |
| --- | --- | --- | --- |
| Expo and React Native | Bolt generates React Native, you preview and build with EAS | A real React Native app | You are starting a mobile app fresh |
| Capacitor wrap | Export a Bolt web app, wrap it with Capacitor | A web app in a native shell with device APIs | You already built a web app in Bolt |

The Expo path is the more native of the two and the default when you ask Bolt for a mobile app. The Capacitor path is a practical way to get an existing Bolt web app onto the stores with access to device features, without rebuilding it.

## The Expo path, step by step

The primary workflow is straightforward. Bolt spins up an Expo project, and you take it from prompt to store like this:

1. **Describe the app** and let Bolt generate the screens and navigation.
2. **Preview on your phone** by opening the Expo Go app and scanning the QR code, so you see it running on a real device.
3. **Refine by chatting** until the core flow works.
4. **Export the code** to your own repository.
5. **Run an EAS build** to compile the signed iOS and Android binaries in the cloud.
6. **Publish** to the App Store and Google Play with EAS Submit.

The [community docs on Expo mobile apps](https://bolters.io/docs/expo-mobile-apps.html) walk through the build and publish details, and the [export to App Store fixes](/blogs/bolt-new-export-ios-app-store-fix/) cover the common snags along the way.

## The Capacitor path for existing web apps

If you already built a web app in Bolt, you do not have to start over to get onto the phone. You can wrap it with Capacitor, which puts your web app inside a native container and gives it access to device features like the camera, storage, and push notifications. As the walkthrough on [transforming a Bolt app with Capacitor](https://capgo.app/blog/transform-bolt-new-app-to-mobile-with-capacitor/) shows, this turns your web code into real .ipa and .apk files for the stores.

The tradeoff is that a wrapped web app is not as fully native as a React Native build, since it runs your web UI inside a shell. For a content or tool app that already works well on the web, though, it is a fast and legitimate way to reach the app stores, and it reuses everything you have already built.

## Expo path or Capacitor path: which to choose

With two routes available, the choice comes down to where you are starting. If you are building a mobile app from scratch and want it to feel as native as possible, take the Expo path. Bolt generates React Native directly, the app uses native components, and you get the smoothest device integration, which makes it the right default for a phone-first product.

If you already have a working web app in Bolt and simply need it on the stores, the Capacitor wrap is faster and cheaper than rebuilding. You keep all your web code and gain access to device features through native plugins, at the cost of a slightly less native feel. In short, starting fresh for mobile means Expo, and porting an existing web app means Capacitor. Neither is wrong, they just suit different starting points, so match the route to what you already have.

## What Bolt handles and what you handle

The key limitation to plan around is that Bolt runs in the browser. Its WebContainers cannot run Xcode, Android Studio, or the EAS build pipeline, so Bolt produces the code but never the signed binary. That means the final build and submission are on you.

In practice, Bolt handles generating and previewing the app, and Expo's cloud service handles the actual build, signing, and store upload once you set it up. It is not difficult, but it is manual, and knowing it upfront avoids the surprise of reaching a finished-looking app with no obvious button to publish it. The [publishing guide for Bolt](/blogs/can-bolt-new-publish-to-app-store-and-google-play/) lays out exactly what falls to you.

## Getting device features to work

A real mobile app usually needs device capabilities, and both paths support them. On the Expo path, React Native and Expo expose the camera, location, notifications, storage, and more through well-supported libraries, which Bolt can wire in when you ask. On the Capacitor path, the native container provides plugins for the same features to your wrapped web app.

The practical advice is to name the device features you need in your prompt, since a generic request will not include them. Ask for camera access, push notifications, or offline storage explicitly, and test them on a real device early, because behavior in the browser preview does not always match the built app. Handling permissions cleanly, like a [native header and permission flow](/blogs/capacitor-custom-native-header-ui-ios/), is part of what makes the app feel finished.

## What you can build, and what needs more

Bolt's native output suits the broad category of standard apps: social apps, content and media, trackers, booking tools, dashboards, simple commerce, and utilities. For these, the React Native result is quick to produce and feels native to users, and the device features they need are well supported.

Where it strains is the same edge as React Native itself: graphics-heavy games, augmented reality, and features that need deep, platform-specific hardware access. Bolt also focuses on the app rather than complex backend architecture, so a data-heavy product may need a separate backend or a [tool built for complex backends](/blogs/bolt-new-alternative-for-complex-backends/). Match your idea to this scope and the native build will feel capable rather than limiting, since you will know in advance where to bring in extra help.

## Common problems and how to fix them

A few issues come up often enough to expect on the native path. The Expo Go preview can behave differently from the final EAS build, so test the built app on a real device before you trust it. Navigation is a frequent snag, since React Native routing differs from the web, and a mismatch often shows up as a blank screen rather than a clear error.

The EAS build step trips most people, because signing certificates and configuration are unforgiving of small mistakes. Work through them methodically, and keep the [React Router and Expo mobile fixes](/blogs/bolt-new-react-router-expo-mobile-fix/) handy for routing issues. None of these are dealbreakers, they are simply the reason to plan a build-and-test phase rather than assuming the app is done when the code looks right in the browser.

## What it costs to publish

The costs are the standard mobile ones. Bolt's own subscription starts free with paid plans for more usage. On top of that, publishing needs an Apple Developer account at $99 per year and a Google Play account at a one-time $25 fee, which are the platform fees every app pays regardless of how it was built. Expo's EAS has a free tier that covers occasional builds, so a single app usually does not need a paid Expo plan.

Budget the subscription and the store fees together, and remember that the real investment is time on the build-and-test phase, not money, since the generation itself is fast.

## The missing piece: a mobile-first design

Bolt will happily generate a mobile app, but a generated app tends to look like a generic template, which reads as unfinished on a phone where polish is expected. Because a model designs by averaging its training data, the default look is generic, and on mobile that shows immediately.

VP0 fills that gap. It is a free iOS design library for people building apps with AI, with mobile-first designs built to iOS conventions, and every design has a machine readable source page. You paste the link into Bolt and it generates the app around a real, native-feeling design instead of a default. That single step is often what separates a Bolt app that looks like a real product from one that looks like a wrapped web page.

## Tips for a better native build with Bolt

**Name the platform and features.** Tell Bolt you want a React Native mobile app and list the device features you need, or it will default to generic web patterns.

**Preview on a real phone early.** Use Expo Go from the start, since the browser preview hides platform differences.

**Export your code.** Own the project so you can run EAS builds independently of the browser session.

**Start from a real design.** A generic look is the fastest tell of a wrapped or templated app. Begin from a mobile-first design.

**Plan for the manual build.** Budget time for EAS, signing, and review, which are on you rather than Bolt.

**Choose the right path.** Start fresh for mobile on the Expo path, and wrap an existing web app with Capacitor. Matching the route to what you already have saves needless rework.

## Key takeaways: can Bolt.new build native mobile apps?

Bolt.new can build native mobile apps two ways: the Expo path, where it generates real React Native for iOS and Android that you preview with Expo Go and build with EAS, and the Capacitor path, where you wrap an existing Bolt web app in a native shell. Both produce apps you can publish, though Bolt stops at the code and leaves the signed build and submission to you, plus the $99 per year Apple fee and the $25 Google fee. Name your platform and device features in the prompt, test on a real phone early, and start from a clean VP0 design so the result feels like a true native app rather than a wrapped web page.

## Frequently asked questions

## Frequently asked questions

### Can Bolt.new build native mobile apps?

Yes. Since its V2 update, Bolt generates real React Native code through Expo, so a prompt produces a cross-platform app for iOS and Android that you can preview on your phone with Expo Go and build with Expo's cloud service. You can also wrap an existing Bolt web app in a native shell using Capacitor. Bolt stops at the code, so you run the final signed build and store submission yourself.

### Are Bolt.new apps truly native?

They are real, installable apps, but built with React Native rather than Swift or Kotlin, so they use a JavaScript layer rendering native components. For the vast majority of apps this is invisible to users and works well. The distinction only matters for graphics-heavy or deeply hardware-specific products. The Capacitor path is slightly less native, since it runs your web UI inside a native container, but it still ships to the stores.

### How do I build a native app with Bolt.new step by step?

Describe the app so Bolt generates the Expo project, preview it on your phone by scanning the Expo Go QR code, and refine the core flow by chatting. Then export the code to your own repository, run an EAS build to compile the signed binaries in the cloud, and publish with EAS Submit to the App Store and Google Play. You will need an Apple Developer account and a Google Play account to publish.

### Can I turn a Bolt web app into a mobile app?

Yes, using Capacitor. You export your Bolt web application and wrap it with Capacitor, which places the web app inside a native container and gives it access to device features like the camera, storage, and push notifications, producing real iOS and Android app files for the stores. It is a fast way to get an existing web app onto the phone without rebuilding it in React Native, though it is less fully native than the Expo path.

### Why do Bolt mobile apps look generic, and how do I fix it?

Bolt generates whatever the prompt describes, and because a model designs by averaging its training data, the default look is generic, which shows immediately on mobile. The fix is to give Bolt a real, mobile-first design to match. VP0 is a free iOS design library whose designs have machine readable source pages, so you paste a link into Bolt and it generates the app around a native-feeling design instead of a template.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*