How to Publish an App Built with Cursor, Lovable, or Bolt

You used Cursor, Lovable, or Bolt to build your app. It works. Now what? The publishing process is different for each tool — and getting it wrong means rejection, wasted time, or an app that crashes on real devices.

This guide covers the exact workflow for each tool: how to go from finished code to live on the App Store and Google Play. No generic advice — specific steps for each platform, including the pitfalls that trip up first-time publishers.

Before diving in: if you haven't read our guide to Apple's vibe coding crackdown, start there. Understanding which apps Apple is targeting (and which are safe) will save you from building on the wrong foundation. And for the full submission checklist covering both stores, see our launch checklist.

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

This distinction matters. Lovable and web-mode Bolt generate React web apps that need a native wrapper. Cursor and mobile-mode Bolt can generate genuinely native code. The publishing path is completely different.

Path 1: Cursor → App Store

Cursor is a code editor, not an app generator. That means you have the most flexibility — but also the most decisions to make.

Option A: Cursor + SwiftUI (Native iOS)

This is the most direct path to the App Store. You write Swift code in Cursor and build/submit through Xcode.

1. 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]
2. Open the project in Xcode for final testing, previews, and the submission pipeline.
3. Test on real devices via Xcode's device manager or TestFlight.
4. 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.

1. Write your app in Cursor using React Native with Expo.
2. Test instantly by scanning a QR code with Expo Go on your phone — no build step needed.
3. Build for production using eas build --platform ios (cloud-based, no Mac required).
4. Submit using eas submit --platform ios which handles certificates and App Store Connect upload automatically.

Advantage: Expo's EAS Build service runs in the cloud, so you don't need a Mac for iOS builds. The free plan gives you low-priority builds; $19/month gets priority.^[3]

Cursor Pitfalls to Watch

• AI loses context on large projects. After ~15–20 components, Cursor starts making destructive changes to working code. Use Git religiously and commit before every major AI interaction.
• Certificate management for native iOS can be confusing. Expo's EAS handles this automatically; SwiftUI + Xcode requires manual setup through the Apple Developer portal.
• Model choice matters. Developers report Gemini 2.5 Pro has better reasoning for some iOS tasks, while Claude excels at architectural decisions. Experiment with both.

Path 2: Lovable → App Store

Lovable generates React + Tailwind CSS web apps with Supabase backends. It does not create native mobile apps. To get a Lovable app into the App Store, you need to wrap it in a native container.^[4]

Method A: Capacitor Wrapper (Recommended)

Capacitor wraps your existing web app in a native container, giving you access to native device APIs (camera, push notifications, biometrics) without rewriting code.

1. Export your Lovable code via GitHub.
2. Install Capacitor:

   npm install @capacitor/core @capacitor/cli
   npx cap init
   npx cap add ios
   npx cap add android

3. Build your web app: npm run build
4. Sync to native projects: npx cap sync
5. Open in Xcode: npx cap open ios
6. Test, archive, and submit through Xcode → App Store Connect.

Source: Analyse Digital guide^[5]

Method B: Third-Party Wrapper (Median.co, Natively.dev)

Services like Median.co handle the wrapping process for you. Upload your web app URL, configure native features (push notifications, offline support), and they generate the iOS/Android builds. Less control but faster for non-technical builders.^[6]

Method C: PWA (No App Store)

If you don't need to be in the App Store, a Progressive Web App lets users “install” your app from the browser. Lovable supports PWA output. However, iOS PWAs have limitations: no push notifications (until recently), limited background sync, and storage quotas. This is a fallback, not a primary strategy.

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. Wrapped web apps are inherently slower than native apps. Test thoroughly on older devices.

Path 3: Bolt.new → App Store

Bolt.new has a major advantage: an official Expo integration that generates native mobile apps, not just web apps.^[7]

Critical First Step: Start with Mobile

When you create a project in Bolt, you must specify it's a mobile app in your first prompt. Web projects cannot be easily switched to mobile later. Tell Bolt: “Create a mobile app for [your idea]” to trigger the Expo template.^[8]

Bolt Mobile → App Store Workflow

1. Build your app in Bolt using the mobile/Expo template.
2. Test on your phone by scanning the QR code with Expo Go.
3. Download the source code from Bolt.
4. Install dependencies: npm install
5. Configure app.json — set your app name, slug, version, icon, and splash screen. Warning: the slug is permanent after your first build.
6. Build for iOS: npx testflight — this handles certificates, builds, and uploads to Apple automatically.^[9]
7. Test on TestFlight, then submit via App Store Connect.
8. For Google Play: eas build --platform android followed by eas submit --platform android.

Bolt Pitfalls to Watch

• “Generates the most bugs” of the major vibe coding tools, according to comparative testing. Expect significant debugging time.^[10]
• No built-in monetization. In-app purchases require integrating RevenueCat or a similar service separately.
• Slug is permanent. Choose your app slug carefully in app.json — you can't change it after the first build.
• EAS builds are slow on free tier. Low-priority queue can take 30+ minutes. $19/month Expo plan gets priority builds.

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
Truly native?	Yes	Yes (React Native)	No (WebView)	Yes (React Native)
Apple rejection risk	Low	Low	Medium (4.2)	Low
Time to App Store	Days–weeks	Hours–days	Hours–days	Hours–days
Best for	iOS-only, polished apps	Cross-platform, indie devs	Existing web apps	Quick prototypes

After Publishing: Don't Skip the ASO

Getting your app approved is step one. Getting it discovered is the game that actually matters.

With over 2 million apps in the App Store, your listing's metadata, keywords, and screenshots determine whether anyone finds your app. Most vibe coders skip this entirely — and their apps die with single-digit downloads.

Three actions that make the biggest difference:

1. Optimize your metadata. Generate optimized titles, descriptions, and keywords for both stores. AI-powered tools can do this in under 60 seconds, hitting the right character limits and keyword density automatically.
2. Create professional screenshots. AppDrift's free screenshot generator supports all device sizes for iOS and Android. Headlines + device frames + clean backgrounds convert 3x better than raw screenshots.
3. Localize to reach global users. Your listing is probably only in English. That means 75% of smartphone users can't find you. Translate your metadata to 40+ languages with AI that adapts to local search trends — not just word-for-word translation.

For the complete optimization playbook, follow our ASO checklist.

Frequently Asked Questions

Can I publish a Lovable app to the App Store?

Yes, but not directly. Lovable generates React web apps, not native mobile apps. You need to wrap your Lovable app using Capacitor (free, open-source) or a service like Median.co to create a native container. Then submit through Xcode for iOS and Android Studio for Google Play. Be aware that web view wrappers risk rejection under Apple's Guideline 4.2 (Minimum Functionality) unless you add native features like push notifications or offline support.

How do I publish a Bolt.new app to the App Store?

Bolt.new has an official Expo integration. The key is to specify “mobile app” in your first prompt so Bolt uses the Expo template. Then download the code, run npx testflight to handle certificates and building automatically, test on TestFlight, and submit via App Store Connect. The entire process from code download to submission can take under an hour.

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 is not rejecting apps built with AI coding tools. It is rejecting apps that generate and execute new code at runtime (like the Replit and Vibecode apps, which are themselves vibe-coding platforms). An app built with Cursor, Lovable, or Bolt that has a fixed codebase at submission time is completely safe. Apple confirmed it is “not targeting vibe coding as a category.”

How much does it cost to publish?

Apple Developer Program costs $99/year. Google Play Console costs $25 one-time. Expo's free plan includes low-priority cloud builds. Expo's paid plan ($19/month) gives priority builds. Total minimum cost: $124 to publish on both stores.

Continue Reading

• Why Apple Is Rejecting Vibe-Coded Apps (And How to Get Approved) — Critical 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.