Your app works in Cursor, Lovable, or Bolt. The next step is to turn the project into a signed mobile build, test it on devices, and prepare its store listing.
The right route depends on the code your project uses. This guide compares SwiftUI, Expo, and a Capacitor wrapper, then explains the testing and submission work each route needs.
For the review rules that affect AI-built apps, read our guide to Apple's app review requirements. Keep the launch checklist open as you prepare the final submission.
The Key Difference: What Each Tool Actually Outputs
Before you pick a publishing path, you need to understand what your tool actually generates:
| Tool | Output | Path to App Store | Mobile-Ready? |
|---|---|---|---|
| Cursor | Source code (any language/framework) | Depends on framework chosen | If using SwiftUI, React Native, or Flutter, yes |
| Lovable | React + Tailwind web app | Wrap with Capacitor or Median.co | No, requires wrapping step |
| Bolt.new | Web app OR React Native (Expo) mobile app | Expo (mobile) or Capacitor (web) | Yes, if you start with mobile template |
Check your framework before following a build tutorial. A React web app needs a different setup from an Expo project, even if both were created with the same AI tool.
Path 1: Cursor → App Store
Cursor is a code editor. You choose the framework, which determines how you build and submit the app.
Option A: Cursor + SwiftUI (Native iOS)
For a SwiftUI project, write the code in Cursor and use Xcode to build, test, and submit the iOS app.
- Write your app in Cursor using SwiftUI. The Sweetpad extension lets you build and run Swift projects directly from Cursor without switching to Xcode for every change.[1]
- Open the project in Xcode for final testing, previews, and the submission pipeline.
- Test on real devices via Xcode's device manager or TestFlight.
- Archive and upload (Product → Archive in Xcode), then manage your submission in App Store Connect.
Real-world timing: One developer with zero Swift experience built and published a card game using Cursor. The core build took 10-15 hours, but total time including debugging was 60-80 hours. His biggest tip: create a rules file telling the AI not to make destructive edits to working code.[2]
Requirement: You need a Mac. Xcode only runs on macOS.
Option B: Cursor + React Native (Expo)
If you want to ship to both iOS and Android from one codebase, use Cursor with React Native and Expo.
- Write your app in Cursor using React Native with Expo.
- Preview supported features with Expo Go, then test a development or production build for the native features your project uses.
- Build for production using
eas build --platform ios(cloud-based, no Mac required). - Upload the signed build using
eas submit --platform ios, then complete the submission in App Store Connect.
Check Expo's pricing against the number of builds you expect to run. Allow time for store review after the build and upload are complete.
Cursor Pitfalls to Watch
- Review AI changes carefully. Use version control and inspect changes before accepting them, especially when they touch working features.
- Certificate management for native iOS can be confusing. Expo's EAS handles this automatically; SwiftUI + Xcode requires manual setup through the Apple Developer portal.
- Test generated code. Run the app on the devices you support and check failures yourself; a plausible explanation from the coding tool is not a test result.
Path 2: Lovable → App Store
For a Lovable web project, a native container is one route to a mobile build. Check Lovable's mobile guidance against your project before choosing the setup.
Method A: Capacitor Wrapper (Recommended)
Capacitor puts your web app inside a native container. Device features such as the camera or push notifications also need the appropriate plugins, permissions, and platform configuration.
- Export your Lovable code via GitHub.
- Set up Capacitor using the official setup guide. Install the platforms you need and configure the web build directory.
- Build your web app:
npm run build - Sync to native projects:
npx cap sync - Open in Xcode:
npx cap open ios - Test, archive, and submit through Xcode → App Store Connect.
Source: Analyse Digital guide[5]
Method B: Third-Party Wrapper (Median.co, Natively.dev)
A wrapper service can handle parts of the native build setup. Compare the features, source access, and maintenance work included in its service. Median describes its approach in this Lovable conversion guide.
Method C: PWA (No App Store)
A Progressive Web App is another option if browser access suits your product. Test installation, storage, notifications, and background behavior on the devices you support before choosing that route.
Lovable Pitfalls to Watch
- Touch interactions need rework. Lovable designs for desktop (hover states, cursor effects). These don't translate to mobile. You'll need to replace hover-based patterns with tap-friendly alternatives.
- CORS configuration. Your Supabase API calls may fail in the Capacitor wrapper due to CORS. Configure your backend to allow requests from the native app origin.
- Guideline 4.2 risk. Apple rejects web view wrappers that don't provide sufficient native functionality. Add at least push notifications, offline support, or other native features to differentiate from a website.
- Performance. Test loading, scrolling, and the main workflow on older devices you plan to support.
Path 3: Bolt.new → App Store
Bolt has an Expo integration for mobile projects. Use the mobile setup when you intend to build for iOS and Android.
Critical First Step: Start with Mobile
Tell Bolt you want a mobile app when you start the project. Check its mobile project guide before building out the screens; converting an existing web project can require extra work.
Bolt Mobile → App Store Workflow
- Build your app in Bolt using the mobile/Expo template.
- Test on your phone by scanning the QR code with Expo Go.
- Download the source code from Bolt.
- Install dependencies:
npm install - Check project identifiers. Confirm the app name, bundle identifier, package name, version, icon, and splash screen before building.
- Build for iOS:
eas build --platform ios. After the build completes, upload it with EAS Submit.[9] - Test on TestFlight, then submit via App Store Connect.
- For Google Play:
eas build --platform androidfollowed byeas submit --platform android.
Bolt Pitfalls to Watch
- Plan time for debugging. A comparison of coding tools can suggest questions to ask, but test your own app before release.
- Test purchases separately. Complete the store configuration and verify purchase, restore, and cancellation behavior for the billing system you use.
- Check project identifiers. Confirm the app name, bundle identifier, package name, version, icon, and splash screen before building.
- Check the current build-service plan and queue limits for your workload.
Comparison: Which Path Is Right for You?
| Factor | Cursor + SwiftUI | Cursor + Expo | Lovable + Capacitor | Bolt + Expo |
|---|---|---|---|---|
| Coding required? | Moderate | Some | Some (wrapping step) | Minimal |
| Mac required? | Yes | No (EAS cloud) | Yes (Xcode step) | No (EAS cloud) |
| iOS + Android? | iOS only | Both | Both | Both |
| Rendering approach | Yes | Yes (React Native) | No (WebView) | Yes (React Native) |
| Best for | iOS-only, polished apps | Cross-platform, indie devs | Existing web apps | Quick prototypes |
After Publishing: Don't Skip the ASO
Once the app is ready for review, give the listing the same attention as the build.
The title, description, and screenshots should help someone understand the main task and decide whether the app suits them. Use real product captures and describe the features available in the submitted version.
Start with these three tasks:
- Metadata generation prepares a draft from the app facts you provide. Review each claim, relevant term, and final field limit before use. Generation speed and scores do not establish search demand or conversion performance.
- Prepare screenshots. Show the main workflow clearly and check the exported sizes against store requirements.
- Choose a market to support. Translate selected listing drafts, then have someone fluent in the language review them.
For the complete optimization playbook, follow our ASO checklist.
Frequently Asked Questions
Can I publish a Lovable app to the App Store?
Yes, a web project can use a supported native packaging route. Test the full mobile experience and check Apple's minimum-functionality requirements. Adding a push notification or an offline screen alone does not establish that the app meets them.
How do I publish a Bolt.new app to the App Store?
Bolt documents an Expo path for mobile projects. Export the project, follow Expo's build setup, create a signed build, and upload it using EAS Submit. Then complete testing and store review. Bolt Expo guide.
Do I need a Mac to publish an iOS app?
It depends on your path. If using Expo's EAS Build service (Cursor + Expo or Bolt + Expo), builds happen in the cloud. No Mac required. For SwiftUI apps built with Cursor, you need Xcode which only runs on macOS. For Capacitor-wrapped Lovable apps, you need Xcode for the final iOS build step.
Will Apple reject my vibe-coded app?
Apple reviews what the submitted app does and how it behaves. Check functionality, privacy, and listing accuracy against its guidelines. Using AI to write the code does not by itself determine the review outcome.
How much does it cost to publish?
Budget for the applicable developer registration, build services, testing, store assets, and paid tools. Apple Developer Program membership normally renews annually; Google Play has a registration fee. Check current prices and eligibility before purchase.
Continue Reading
- Why Apple Is Rejecting Vibe-Coded Apps (And How to Get Approved): Key guidelines every vibe coder must know before submitting.
- Vibe Coder's App Store Launch Checklist: The complete checklist covering security, metadata, screenshots, and review tips.
- App Store Screenshots That Sell: Design screenshots that convert visitors into downloads.
