How to convert your Lovable app to a mobile app and publish to the App Store and Google Play

Lovable makes it genuinely easy to build a working web app from scratch. Getting that web app into the App Store or Google Play as a native mobile app is where many builders hit their first real wall.

The Apple App Store and Google Play are the two main distribution platforms for mobile apps, the places iPhone and Android users go to find, download, and install apps on their phones.

To get listed on either one, you need a native mobile app, not a web app, and the path from a Lovable project to a published mobile app listing involves steps that most AI builders don't cover.

In short: Lovable handles the build and Median.co handles everything after.

The same gap exists for Replit, Base44, Vercel, and Netlify. The AI platform gets you to a live URL. Converting that into a mobile app, generating the native files, submitting for review, and getting through Apple and Google's requirements is on you to figure out.

This post walks you through what's actually required, what trips most people up before review, and the fastest path to a published mobile app listing on iOS and Android.

Why can't I just publish my Lovable app directly to the App Store?

This question shows up constantly in Lovable communities. You build something you're proud of, get it working in the browser, and then hit a wall trying to figure out how to actually get it into the App Store or Google Play.

Lovable is an AI-powered app builder that lets you create web applications using natural language prompts. It's designed for no-code/low-code users, indie founders, and small teams who want to quickly build and iterate on UI-focused apps. You can build your app's interface and functionality just by prompting with an AI agent.

Lovable handles your frontend, UI, database connections, and deployment. What it doesn't produce is an iOS or Android app. As Lovable's own documentation puts it, the platform is focused on web applications, not mobile apps.

Why Lovable apps don't automatically become mobile apps

Lovable builds web applications, and the app stores don’t accept web applications.

Apple and Google require native app files, an IPA for iOS and an AAB for Android, that are built, signed, and submitted through their developer portals. Lovable doesn't produce those files, and there's no export button that gets you there.

If you want your AI project in the App Store or Google Play, you need an additional step that “wraps” your live URL into a native app shell and adds the mobile-specific functionality that both stores require.

This isn't a limitation unique to Lovable. It also applies to any web app built on Replit, Base44, Vercel, or Netlify.

How Median.co helps

Lovable gets your app built. Median.co gets it published.

Median.co converts your Lovable web app into a mobile app via a WebView approach.

Your web app, built with Lovable, runs inside a native "shell" that we provide. This shell/wrapper "bridges" the gap between your web code and the device's native features, such as push notifications, haptics, and biometric authentication.

Try it for free!

Enter any URL to build your webview app

Why an App Store listing matters

A mobile-optimized website isn't the same thing as an app, and most users know the difference. Here's what you actually get from being in the store:

Users can find you without already knowing you exist

App store search works differently from web SEO, and for certain categories and audiences, it's where buying decisions start.

Someone looking for a tool in your category may search the App Store before they search Google, and if you're not there, you're not in the consideration set.

App store optimization is its own discipline, and the earlier you're in the store, the earlier you're building that visibility.

You can reach users between sessions

Push notifications are one of the most direct lines to your users that exist in mobile, and they're only available in a native app. A mobile website can't send a push. A browser tab doesn't appear on a lock screen.

For products where re-engagement matters, whether that's a reminder, an update, or a time-sensitive offer, push notifications are the feature that makes the difference between a product people check daily and one they forget about.

Read more: How to boost user engagement through targeted push notifications.

Your app feels like a real product

For many products, especially those that ask users to create an account, store data, or pay for something, an Apple App Store or Google Play listing signals legitimacy in a way a mobile website doesn't.

Users trust apps they can find in the store. They can read reviews, check ratings, and make decisions based on what they see in the listing.

Your users are already set up to buy

If your app sells digital goods, subscriptions, or premium features, being in the App Store or Google Play means your users can purchase without ever entering a credit card.

iPhone users already have their payment details stored in their iCloud account, and Apple's in-app purchase flow is a single tap. Android users have the same experience through Google Play's billing system, which pulls from whatever payment method is saved in their Google account.

Mobile web checkouts often lose people at the payment step. In a native app, that step is already done, and for the right product, minimizing the conversion friction is significant. It's one of the less obvious arguments for publishing that's worth thinking about early.

Both Apple and Google require you to use their own billing systems for digital content, so Stripe isn't an option for subscriptions or in-app features on either platform. For physical goods and services, external payment providers are allowed on both stores.

For any product monetizing through digital content, the App Store and Google Play are checkout experiences your users already trust.

What Apple and Google actually require

Both stores have a minimum functionality requirement that catches many first-time publishers off guard.

Apple's Guideline 4.2 specifically rejects apps that simply repackage a website without adding native, mobile-specific functionality.

Google Play has an equivalent rule under its Spam and Minimum Functionality policy. A bare webview wrapper, your URL loaded into a native shell with nothing added, will almost certainly get rejected on both platforms.

What reviewers need to see is that your app offers something a user couldn't get from opening the same URL in a browser. You don't need to add every native feature, but you do need enough to make the case.

How to demonstrate your app is truly native:

• Push notifications

• Biometric authentication

• Deep linking to specific screens

• Offline behavior; and

• Meaningful camera or location access.

Median's native plugin library covers most of these out of the box, so you're not building them from scratch.

The two paths from Lovable to the App Store

Option 1: Use a web-to-app platform (recommended)

The fastest path for most Lovable builders is a platform that wraps your published URL and adds native capabilities without touching your web code.

Median.co has handled over 1.7 million app builds since 2014 and has a 98% app store approval rate.

The basic steps using Median’s App Studio are:

1. Publish your Lovable project and confirm the URL is stable in production

2. Create a Median account and paste your URL

3. Configure your app details (name, icon, splash screen) and add native functionality such as push notifications or biometric login

4. Build your native files (IPA for iOS, AAB for Android)

5. Submit through App Store Connect for iOS and Google Play Console for Android

6. Publish your app

For more on how to turn your Lovable app into a native app, visit our complete guide: How to convert your Lovable app into a native app.

Option 2: Capacitor (for developers)

Capacitor is an open-source option for developers who want to manage the entire build process themselves. It requires exporting your Lovable project to GitHub, initializing Capacitor locally, and building your iOS and Android targets in Xcode and Android Studio, respectively.

You'll need a Mac for iOS builds, and you'll be responsible for signing certificates, managing bundle IDs and provisioning profiles, and addressing every round of Apple review feedback.

For developers with mobile build experience who have specific requirements a wrapper platform can't meet, it's a viable path. For most people who built something in Lovable, it's a significant amount of infrastructure to take on for a problem that's already solved.

Where most vibe-coded apps get stuck

With AI, the app-building process is easier. The compliance, publishing, and app review process is what trips people up because not every app builder follows the best practices that help apps get through the review process.

You can ship a working web app in an afternoon and still spend two weeks figuring out why Apple or Google keeps rejecting it.

A few of the app rejection causes vibe coders don't always see coming:

External link handling – Apple requires external links to open in an in-app browser, not the system Safari. That means specific code to intercept the link and open it inside your app. Google Play is less strict, but apps that consistently kick users out to the system browser still feel like webview wrappers, which can trigger Google's version of the minimum functionality flag.

Payment gateways – For digital goods, Apple requires you to use their in-app purchase system, and Google Play requires you to use Google Play Billing. Linking out to Stripe or another payment provider for digital content is a rejection cause on both stores. Physical goods and physical services differ, each with its own rules.

Minimum functionality – A wrapper alone isn't a mobile app on either platform. Apple's Guideline 4.2 requires apps to offer functionality beyond a website. Google Play has an equivalent rule under its Spam and Functionality policy, with a slightly lower bar in practice but the same underlying principle.

Permission and capability declarations – iOS apps require specific entries in the Info.plist file declaring which device capabilities the app uses and why. Android apps require equivalent declarations in the AndroidManifest.xml. Missing or incorrect declarations are common reasons for rejection on both platforms.

None of these is unfixable. In fact, most are configuration problems, not architecture problems. But each one is a round of review feedback if you don't catch it before submitting, and review cycles are measured in days, not hours.

Tip: Plan for some back-and-forth with reviewers on your first submission. Read every rejection note carefully. Both stores almost always cite the policy or guideline they're referring to, which makes the fix much easier to scope.

If you want to skip the publishing hassle, Median’s Publishing Service can handle your submission end-to-end.

Convert your Lovable app to a mobile app with Median.co

The Median platform is built for exactly this situation. Your Lovable web product stays as-is.

Median.co wraps it in a native app shell, adds the features app store reviewers need to see and can even handle the publishing step that most first-time submitters get stuck on.

For Lovable builders, this means going from a live URL to a published app store listing in days, not months, without learning Xcode, managing signing certificates, or hiring a mobile developer. For a recent example of how fast this can move, SkinCure Oncology used Median's publishing service to convert its AI-built web app into a native iOS and Android app and get it into both app stores in time for an industry conference launch.

Plans start at $179/year for self-serve, with fully managed business and enterprise support available when you need expert help.

You used Lovable to build something real. Median.co gets it into the hands of the people it's built for.

Frequently asked questions about publishing your Lovable app

Can you turn a Lovable app into a mobile app?

Yes, but it requires an extra step. Lovable builds web applications, not native iOS or Android apps. To get your Lovable project into the App Store or Google Play, you wrap the live URL in a native app shell, add mobile-specific features like push notifications and biometric login, and submit through each store's developer portal. Platforms like Median.co handle this process without requiring you to touch your web code.

How do you publish a Lovable app to the Apple App Store?

You need an Apple Developer account ($99/year), a native app build that meets Apple's guidelines, and a submission through App Store Connect. The most common path for Lovable builders is using a web-to-app platform that wraps your published URL, adds the native functionality Apple requires, and generates the IPA file you upload for review. Apple's review process typically takes 24 to 48 hours, though first submissions can take longer.

How do you publish a Lovable app to Google Play?

You need a Google Play Console account ($25 one-time fee), an Android App Bundle (AAB file), and a completed store listing that includes a privacy policy, screenshots, and a content rating. A web-to-app platform wraps your Lovable URL and generates the AAB file. Google Play reviews are generally faster than Apple's, though new developer accounts may receive extra scrutiny on early submissions.

How long does it take to publish a vibe-coded app?

Building the web app with an AI tool can take mere hours. The publishing timeline is a different question entirely. If your Apple Developer account is already set up and active, you can go from a finished Lovable project to a submitted App Store listing in a few days. If you're starting from scratch, Apple Developer organization account verification takes 2 to 4 weeks, which can be the bottleneck for your entire launch. That’s why we recommend you start the account setup before your app is finished.

Will Apple reject a Lovable app?

Apple reviews the app itself, not the tool you used to build it. What often triggers rejection is submitting a bare URL in a webview without any native functionality. Apple's Guideline 4.2 requires apps to offer features that a user couldn't access by opening the same URL in a browser. Adding push notifications, biometric login, or deep linking is usually enough to clear that bar. Building with Lovable, Replit, or any other AI tool is not, by itself, a cause for rejection.

How do I turn HTML code into a mobile app?

You don't need to rebuild anything. If your app is running at a live URL, that's all you need to get started. A web-to-app platform like Median.co wraps your existing HTML and serves it within a native app shell, then layers on mobile-specific features such as push notifications, biometric login, and deep linking that app store reviewers require. The HTML stays exactly as it is. You're adding a native container around it, not touching the code underneath.

What's the difference between a PWA and a native app?

A progressive web app, or PWA, runs in a browser engine and can be added to a user's home screen, but it's still a webpage at its core. A native app runs in a dedicated shell, has its own app store listing, and can access device features such as push notifications, biometric authentication, and offline storage in ways a PWA can't fully replicate, especially on iOS. For products where the mobile experience matters, the difference is noticeable to users.

Do I need to resubmit my app every time I update my Lovable project?

Not for most updates. Because a web-to-app wrapper loads your live URL, changes you publish in Lovable appear in the app automatically without a new store submission. You only need to resubmit when something in the native shell changes, such as the app name, icon, bundle identifier, or a new device permission. Routine content and design updates don't require going back through the review process.

Can I submit to just one store?

Yes. There's no requirement to publish on both platforms. Some teams launch on Android first because the Google Play process is faster and less expensive to set up, then add iOS once the app is stable. Others go iOS-first because that's where their audience is. You can generate files for each store independently and submit them on whatever timeline works for your launch.

What do I do if my app gets rejected?

Read the rejection notice carefully before doing anything else. Apple identifies the specific guideline you've violated, making the fix straightforward to scope in most cases. The most common causes are limited functionality (Guideline 4.2), a missing or inaccessible privacy policy, payment flow violations for digital goods, and missing permission declarations. Most rejections are configuration problems you can fix without rebuilding. Address the cited guideline, update your build, and resubmit.

How much does it cost to publish an app?

Apple Developer Program membership costs $99 per year. A Google Play Console account is a one-time $25 registration fee. If you use a web-to-app platform to handle the build and submission, that's an additional cost on top of your developer accounts. Median's self-serve plans start at $179 per year.

What is vibe coding?

Vibe coding is the practice of building functional software using AI tools and natural language prompts, without writing code manually. Instead of hiring developers or learning a programming language, you describe what you want, and the AI builds it. Tools such as Lovable, Replit, Base44, Vercel, and Netlify have made this genuinely accessible, and the results are real, production-ready web apps that work in a browser. The gap that vibe coding doesn't close is the mobile app gap. Getting from a working web app to a published listing on the App Store or Google Play requires a separate set of steps that none of these tools handle natively.