How to Publish an App Built in Lovable to the App Store and Google Play

Here is the honest starting point: Lovable builds web apps, and the App Store and Google Play sell native apps. Type your idea into Lovable and you get a React application that runs beautifully in a browser, but you cannot upload a website to either store. The good news is that the bridge between those two worlds is short and well-paved. I have taken multiple Lovable and vibe-coded projects through both store reviews, and the full path, export, wrap, sign, submit, is a weekend of work when you know the steps and a month of frustration when you guess. This guide is the version where you know the steps: how to publish a Lovable app to the App Store and Google Play, including the one Apple rule that rejects lazy wrappers and exactly how to pass it.

Quick Answer: The Path in One Paragraph

Export your Lovable project to GitHub, clean up hardcoded URLs and exposed keys, add Capacitor (npx cap add ios, npx cap add android) to wrap your built web app in real native projects, open those projects in Xcode and Android Studio, add icons, splash screens, and at least a couple of native features (push notifications matter for Apple), create an Apple Developer account ($99/year) and a Google Play developer account ($25 once), fill in the privacy forms, test through TestFlight and Play internal testing, then submit. Google usually reviews in hours to days; Apple in one to two days, with Guideline 4.2 (minimum functionality) as the risk you design against.

Key Takeaways

• Lovable outputs web code; stores want native binaries. Capacitor is the standard bridge and reuses 100 percent of your code.
• There are three paths: Capacitor wrapper (both stores, recommended), Trusted Web Activity (Google Play only), or a full native rebuild (when the wrapper limits you).
• Apple Guideline 4.2 is the boss fight. A bare website-in-a-shell gets rejected; add push, offline handling, and native feel to pass.
• Real costs are small: $99/year Apple, $25 once for Google, plus a Mac (or cloud Mac) for the iOS build.
• Google now gates new personal accounts behind a closed test with real testers before production release; budget time for it.
• Clean up before you wrap: hardcoded URLs and exposed keys that hide in a browser become visible problems in an app bundle.
• Updates flow two ways: store releases for structural changes, OTA live updates for content and UI tweaks without re-review.

Quick Facts

Why This Matters

Store presence changes what your app is. A web app is a tab someone forgets; an installed app is an icon on the home screen with push notifications and a retention curve. For founders who validated an idea in Lovable, the stores are where the product graduates: distribution, discoverability, subscription billing through in-app purchases, and the credibility of existing where users already look. The technical gap between "works in a browser" and "approved in both stores" is the cheapest moat-crossing in mobile, if you do it in the right order.

The Three Paths From Lovable to the Stores

The Trusted Web Activity route packages your PWA for Google Play with no wrapper code at all, and it is genuinely fine for content apps on Android, but Apple does not accept it, so any two-store plan lands on Capacitor. The full rebuild is the eventual destination for a minority of apps; wrap first, validate, rebuild only if the data forces it. Plenty of successful products started exactly this way, as our roundup of the top vibe-coded apps shows.

Step 1: Export Your Lovable Project to GitHub

Lovable has first-class GitHub sync: connect your GitHub account from the project settings, and Lovable creates and pushes a repository with your full source. From that point the repo is yours, and you can keep editing in Lovable (changes sync) or work locally. Clone it, run npm install and npm run dev, and confirm the app runs on your machine before touching anything mobile. The full walkthrough, including the gotchas, is in our guide to exporting your Lovable project to GitHub.

Step 2: The Pre-Wrap Cleanup

A browser forgives what an app bundle exposes. Before wrapping, fix:

• Hardcoded URLs. Any localhost, preview, or lovable.app URL in the code breaks inside the native shell. Move the API base URL into an environment variable and build with production values.
• Exposed keys. Your Supabase anon key is designed to be public (security lives in Row Level Security policies), but service-role keys, OpenAI keys, or payment secrets in frontend code are extractable from the app bundle. Move them behind an edge function or backend.
• Routing. Client-side routers need a catch-all so deep links inside the app resolve; test a hard refresh on every route in the production build.
• Error and offline states. A blank white screen in a browser is a shrug; in an installed app it is a one-star review. Add loading states and a friendly offline message.

If the project has accumulated deeper AI-generated debt (dead code, duplicated components, fragile state), do a structured pass first; our Lovable cleanup guide is the checklist we use internally.

Step 3: Add Capacitor and Generate the Native Projects

Capacitor turns your built web app into genuine iOS and Android projects. From your project root:

# 1. Install Capacitor
npm install @capacitor/core
npm install -D @capacitor/cli

# 2. Initialize (pick your app name and a reverse-DNS id, e.g. com.yourbrand.appname)
npx cap init

# 3. Build your web app (Lovable projects are Vite: output goes to dist/)
npm run build

# 4. Add the native platforms
npm install @capacitor/ios @capacitor/android
npx cap add ios
npx cap add android

# 5. Copy the web build into the native shells
npx cap sync

In capacitor.config, set webDir to dist (Vite's output). You now have an ios/ folder (an Xcode project) and an android/ folder (an Android Studio project). These are real native projects you own; nothing about them is locked to Capacitor.

Step 4: Make It Feel Native (This Is How You Pass Apple)

Apple's Guideline 4.2, minimum functionality, is the rule that rejects thin web wrappers: if your app is indistinguishable from visiting the website, it does not belong in the store. Design against it deliberately:

• Push notifications. The single strongest signal. Add @capacitor/push-notifications and give users a reason to receive them.
• Native capabilities. Camera, haptics, share sheet, biometric login; even one or two used meaningfully changes how the app reads in review.
• Offline grace. Detect connectivity and show a designed offline state, not a browser error.
• No browser chrome. No visible URLs, no "open in browser" prompts, no links that dump users onto your website for core actions (Apple also dislikes apps that route around in-app purchase this way).
• Splash screen and app icon generated for every required size (the @capacitor/assets tool does this from one 1024px master image).
• Account deletion in-app if you have accounts; it has been a hard Apple requirement since 2022.

Thousands of Capacitor apps pass review every month. The ones that get 4.2'd skipped this section.

Step 5: Developer Accounts and Signing

• Apple: enroll in the Apple Developer Program at $99/year (identity verification can take a day or two). Xcode manages certificates and provisioning profiles nearly automatically now; let it. You upload builds through Xcode or Transporter into App Store Connect.
• Google: create a Play Console developer account for a one-time $25. You generate a signing keystore (or better, enroll in Play App Signing and let Google hold the release key), then upload an AAB (Android App Bundle), not an APK.
• Heads-up for new Google accounts: personal accounts created recently must run a closed test with a set of real testers over a sustained period before Google unlocks production publishing. It is not hard, but it adds calendar time; recruit your testers early.
• No Mac? iOS builds require Xcode on macOS. Cloud options (Codemagic, Bitrise, GitHub Actions macOS runners, or a rented cloud Mac) solve it without buying hardware.

Step 6: Store Listings, Privacy Forms, and Assets

Both stores need, prepare these once and reuse:

• App name, subtitle/short description, and full description written for humans and search.
• Screenshots for required device sizes (iPhone 6.7-inch and 6.5-inch classes for Apple; phone plus optional tablet for Google). Take them from the simulator or a device in your final UI.
• A hosted privacy policy URL (a page on your site is fine).
• Apple App Privacy labels: declare every category of data you collect and whether it is linked to identity. If you use Supabase auth and analytics, you are collecting data; declare it honestly, because mismatches get flagged.
• Google Data safety form: the same declaration in Google's format.
• A support URL and contact email.

Listing quality is also your acquisition engine; the keyword and screenshot tactics that still move installs are in our App Store Optimization guide.

Step 7: Test Through TestFlight and Internal Testing

Do not submit a build no one has installed. Push to TestFlight (Apple) and a Play internal testing track (Google), install on real devices, and walk every flow: cold start, sign-up, payments in sandbox mode, push permission prompt, offline behavior, deep links, and the back button on Android (web apps habitually get it wrong). Fix what you find; a rejection costs you a review round-trip, but a bad first week of reviews costs you the launch.

Step 8: Submit and Survive Review

• Apple: typical review is 24 to 48 hours. If the reviewer questions functionality (the 4.2 conversation), respond in Resolution Center with specifics about native features; a clear reply often flips a rejection without code changes.
• Google: hours to a few days, longer for first-time accounts. Automated checks flag policy issues (permissions you declared but do not use are a common one).
• Plan the buffer: first submissions should assume one rejection round-trip. It is normal, not failure.

What It Costs

Common Rejections and Their Fixes

After Launch: How Updates Work

Change the app in Lovable or locally, rebuild, run npx cap sync, bump the version, and resubmit; both stores review updates faster than first submissions. For content and UI changes there is a faster lane: OTA live-update services (Capacitor's ecosystem has several) push new web assets directly to installed apps without store review, which is legitimate as long as native code is unchanged and you are not altering the app's core purpose. The sustainable rhythm: OTA for tweaks, store releases for features.

Why Founders Publish With Make An App Like

Make An App Like has shipped 500+ apps for founders in 40+ countries since 2016, including a steady pipeline of Lovable, Bolt, and Replit projects taken from prototype to both stores. We handle the whole path as a fixed-scope service: cleanup, Capacitor wrapping, native features, signing, listings, privacy forms, submission, and reviewer back-and-forth. And when a project outgrows the wrapper, we rebuild it into a fully owned production codebase through our Convert Lovable App service.

Estimate Your Publishing or Build Cost

Want a line-item budget for wrapping, publishing, or extending your Lovable app? Use our free calculator: https://makeanapplike.com/tools/app-cost-calculator

Launch Faster With a Ready-Made Foundation

Skip months of build time with a white-label app foundation, already store-ready: https://makeanapplike.com/buy-white-label-apps

Conclusion

Publishing a Lovable app to the App Store and Google Play is a solved problem with a known sequence: export to GitHub, clean up the web-app shortcuts, wrap with Capacitor, make it feel native enough to clear Apple's minimum-functionality bar, set up the two developer accounts, fill the privacy forms honestly, test through TestFlight and internal tracks, and submit with a buffer for one review round-trip. The out-of-pocket cost is $124 in the first year; the payoff is an installed icon, push notifications, and a retention curve no browser tab will ever give you. Ship the wrapper this month, learn from real users, and let the data tell you if a native rebuild is ever worth it.

Frequently Asked Questions

1. Can I publish a Lovable app directly to the App Store and Google Play?

Not directly, because Lovable produces a React web app and the stores accept native binaries. But the bridge is short: wrap the exported code with Capacitor to produce real iOS and Android projects, then build, sign, and submit them like any native app. The wrapping itself takes hours; the store setup, assets, and review process are where the real days go.

2. What is the best way to turn a Lovable app into a mobile app?

Capacitor is the standard path. It embeds your built web app in a native shell, gives you access to native features (push notifications, camera, haptics) through plugins, and produces genuine Xcode and Android Studio projects you own. A Trusted Web Activity can get a PWA onto Google Play without wrapping, but Apple does not accept that route, so Capacitor is the one answer that covers both stores.

3. How much does it cost to publish a Lovable app to the app stores?

The unavoidable costs are an Apple Developer account at $99 per year and a Google Play developer account at $25 one time. Beyond that: a Mac (or a cloud Mac service) for the iOS build, store assets like screenshots and icons, and your time. If you hire the wrapping, signing, and submission out as a done-for-you service, typical market cost runs from a few hundred to a couple of thousand dollars depending on how many native features you add.

4. Will Apple reject my Lovable app for being a web wrapper?

It can, under Guideline 4.2 (minimum functionality), which is the single biggest risk for wrapped web apps. Apps that are just a website in a shell get rejected. You pass by making the app feel native: add push notifications, handle offline states gracefully, remove any browser-like chrome, use native transitions where possible, and make sure nothing in the app tells the user to visit the website. Thousands of Capacitor apps are approved every month; the rejected ones skipped this step.

5. Do I need a Mac to publish a Lovable app to the App Store?

Yes, the iOS build and upload require Xcode, which only runs on macOS. If you do not own a Mac, the workarounds are a cloud Mac service (MacStadium, MacinCloud), a CI service that builds iOS in the cloud (Codemagic, Bitrise, GitHub Actions with macOS runners), or borrowing one for build day. Android has no such restriction; Android Studio runs on Windows, Mac, and Linux.

6. How long does app store review take for a wrapped app?

Google Play typically reviews within a few hours to a few days, though new developer accounts and first submissions can take longer and Google now requires a closed test with real testers for brand-new personal accounts. Apple usually reviews within 24 to 48 hours, but plan a buffer for a first submission because a Guideline 4.2 conversation or a metadata fix can add a round trip of a few days.

7. How do updates work after publishing?

When you change your Lovable app, you rebuild the web assets, run npx cap sync to copy them into the native projects, bump the version number, and resubmit both stores. For content and UI changes there is a faster lane: OTA (over-the-air) live-update services can push updated web assets to installed apps without a store review, as long as you are not changing native code. Most teams combine both: OTA for small changes, store releases for anything structural.

8. What do I need before submitting: privacy policy, data forms, screenshots?

Both stores require a hosted privacy policy URL. Apple additionally requires App Privacy labels declaring what data you collect and whether it is linked to the user, and Google requires the equivalent Data safety form. You also need an app icon (1024px master), screenshots for the required device sizes, a short and full description, and a support URL. If your app has accounts, Apple also requires an in-app account deletion option.

9. Should I use Capacitor or rebuild in React Native?

Wrap first, rebuild only when the wrapper genuinely limits you. Capacitor reuses 100 percent of your Lovable code and ships this week. React Native or Flutter gives you fully native UI and better performance for animation-heavy or offline-heavy apps, but it is a rebuild, not a wrap. The pragmatic sequence: ship the Capacitor version, validate demand, and rebuild natively only if user feedback or performance data forces it.

10. Does my Lovable app need a cleanup before wrapping?

Almost always, yes. Wrapped apps expose the loose ends web apps hide: hardcoded localhost or preview URLs break inside the shell, exposed API keys become extractable from the app bundle, and missing error states look worse full-screen. Fix hardcoded URLs, move secrets server-side (your Supabase anon key is fine, service keys are not), add loading and offline states, and test the production build locally before you ever open Xcode.