Bolt to App Store: Publish Your Bolt App

Yes, you can publish a Bolt app to the App Store. The right method depends on what Bolt created for you: an Expo mobile project or a web app. A mobile project can follow Bolt's manual Expo and EAS workflow. An existing Bolt web app needs an iOS release layer before Apple can review it. WebNativeApp provides that layer without asking you to rebuild the product in a new framework.

The short answer: yes, but Bolt projects can take two different routes.

Bolt can generate both web projects and mobile projects. They are not the same output, and they do not reach the App Store in the same way.

If you asked Bolt for a mobile app from the first prompt

Bolt uses Expo for mobile apps. You can download the code, configure the project, create an iOS build with Expo Application Services (EAS), test it with TestFlight, and submit it through App Store Connect.

If you already built a Bolt web app

Your deployed website is not an App Store binary. You can manually put it inside a native shell such as Capacitor, or use WebNativeApp to generate the mobile project around the live app. This route lets your web product remain the source of truth.

Bolt's own documentation recommends choosing mobile in the first prompt because projects created for the web do not easily switch to mobile later. If the web app already works, packaging it is often more practical than starting again.

Method 1: publish a Bolt mobile project manually with Expo.

This is the native route for a project that Bolt created with Expo. Bolt helps generate the product, but you still need the accounts, configuration, release build, store listing, testing, and review process.

Download the code from Bolt: Open the project locally so you can run Expo's checks and release commands.
Create the required accounts: You need an Expo account and an active Apple Developer Program membership. You also need access to App Store Connect for the app record, TestFlight, and submission.
Install and verify the project: Install the project dependencies and EAS CLI, sign in to Expo, then run npx expo-doctor to catch incompatible packages or configuration problems.
Configure the app identity: Set the display name, Expo slug, iOS bundle identifier, version, build number, app icon, splash screen, and any permission descriptions. Choose the slug carefully before the first build.
Initialize EAS: Run eas init, then eas build:configure to connect the local project and create the build configuration.
Create and upload the iOS build: Build for iOS with EAS. Bolt documents eas build --platform ios --auto-submit as the path to create the iPhone build and send it to TestFlight.
Test with TestFlight: Install the real build on iPhones and test signup, login, payments, notifications, camera access, external links, and error states.
Complete App Store Connect: Add the app description, screenshots, category, age rating, privacy answers, support URL, review notes, and demo credentials when login is required.
Submit for App Review: Select the tested build, add it to the review submission, and respond to Apple if the reviewer requests changes or clarification.

This route gives you a genuine Expo codebase and is a good fit when the project was designed as a mobile app from day one. The tradeoff is that you own the full mobile toolchain and its release configuration.

Method 2: package an existing Bolt web app manually with Capacitor.

If your Bolt product is already live as a responsive website, a rewrite is not your only option. Capacitor can provide the native iOS project that the website itself does not contain.

Deploy the production app: Use a stable HTTPS URL. Confirm that routes, APIs, environment variables, authentication, and database access work outside the Bolt preview.
Audit the experience on an iPhone: Fix desktop-only layouts, small tap targets, keyboard overlap, unsafe-area spacing, loading states, file uploads, OAuth redirects, and links that should open outside the app.
Create a Capacitor project: Add the iOS platform, connect the production web app or its compiled assets, and configure the app name and bundle identifier.
Add the native layer: Prepare icons and the launch screen, then add only the native features the product needs, such as push notifications, haptics, camera access, biometrics, deep links, or an in-app review prompt.
Open and configure the project in Xcode: Select your Apple team, configure signing and capabilities, add permission descriptions, choose supported orientations, and verify the release version.
Test the native shell: Check navigation, cookies, login persistence, OAuth callbacks, external links, downloads, offline behavior, and app resume on physical devices.
Archive and upload the app: Create a signed release archive in Xcode and upload it to App Store Connect.
Run TestFlight and submit: Test the uploaded build, complete the store listing and privacy information, provide reviewer access, then send the app to App Review.

The manual Capacitor route preserves your Bolt web app, but it introduces iOS project structure, native configuration, Xcode, certificates, provisioning, and release maintenance.

Will Apple accept a Bolt app?

Apple does not reject an app because it was made with Bolt, Expo, Capacitor, or AI. It reviews the final product. The implementation still needs to meet the App Review Guidelines.

It must be more than a repackaged website

Guideline 4.2 says an app should offer enough features, content, and interface value to feel useful and app-like. A branded icon around an unmodified landing page is a weak submission. A focused product with good mobile navigation, useful workflows, and relevant native touches has a much stronger case.

The complete flow must work during review

Keep the production backend online, remove placeholder content, and provide a working demo account or demo mode if the app requires login. Reviewers need access to the important parts of the product.

Privacy, accounts, and payments need special attention

Declare the data collected by the app and its third-party services. If users can create an account, include an in-app account-deletion flow where Apple's rules require it. If the app sells digital features or subscriptions consumed inside the app, check Apple's in-app purchase rules before submission.

The easier route for an existing Bolt web app: WebNativeApp.

WebNativeApp is designed for the second scenario: you already have a Bolt web app that works and you want an iOS or Android project without rebuilding that product in Expo, React Native, or Swift.

Manual Capacitor route

Install and configure Capacitor.
Create and maintain the iOS project.
Prepare the app identity and native assets.
Configure Xcode, signing, and permissions.
Debug mobile-shell behavior yourself.
Build, test, and maintain the release workflow.

WebNativeApp route

Paste the URL of the Bolt app you already ship.
Choose iOS, Android, or both.
Receive the full app project in your own repository.
Test the generated app and follow the store-release path.
Keep shipping product updates from Bolt and the web.

Start with the product that already works

You do not need to recreate every screen. WebNativeApp packages the production website in a native Capacitor-based project, with the mobile identity and structure required to build an installable app.

Keep control of the source

The generated app source lives in your repository. It is not locked inside a hosted converter, and WebNativeApp does not charge a recurring converter subscription. Your existing hosting continues to serve the product.

Continue updating the app from Bolt

When the installed app uses your live deployment, normal fixes and product changes continue through the web workflow. A new store build is still needed when you change native code, capabilities, permissions, or other store-controlled behavior.

Add native features where they improve the product

Use push notifications, camera access, haptics, biometrics, share actions, deep links, or in-app review prompts when they support a real user action. Native features should make the product better, not merely decorate a website wrapper.

WebNativeApp removes much of the packaging work, but it does not bypass Apple. You still need an Apple Developer account, accurate store metadata, a tested product, and approval from App Review.

What to prepare before you start.

Bolt app readiness

A stable public HTTPS URL, not a temporary preview.
Responsive screens tested at iPhone widths.
Working signup, login, logout, password reset, and account deletion.
Reliable payments, forms, uploads, redirects, and external links.
Clear loading, empty, offline, and error states.

App Store readiness

Apple Developer Program and App Store Connect access.
App name, icon, bundle identifier, category, and screenshots.
Public privacy policy and support URLs.
Accurate privacy answers and permission explanations.
Review notes and a demo account when login is required.

Bolt to App Store questions

Can Bolt publish directly to the App Store?

Bolt provides a documented App Store path for mobile projects through Expo and EAS. It is not a one-click publication: you still configure the project, create the build, test it, complete App Store Connect, and submit it to Apple.

Can I turn an existing Bolt website into an iPhone app?

Yes. You can package the deployed website in a native shell manually with Capacitor or use WebNativeApp to generate the mobile project around it.

Should I use Expo or WebNativeApp for my Bolt project?

Use the Expo route when Bolt created the project as a mobile app and you want to maintain an Expo codebase. Use WebNativeApp when the working product is already a web app and you want to keep it as the source of truth.

Do I need a Mac or Xcode?

The fully manual Capacitor route normally uses Xcode on a Mac for iOS configuration, testing, signing, and upload. Expo's EAS service can perform cloud builds, although you still need to configure and test the mobile project. WebNativeApp reduces the native setup required for a web app.

Can I publish a Bolt app to the App Store?