How to get a Lovable or AI-built app into the App Store and Google Play

Lovable builds web apps, so a Lovable app cannot go into the App Store or Google Play as it is. There are two ways in: package the web app as a native app with Capacitor and give it features a website cannot offer, or rebuild the mobile app in React Native with Expo, which is what Bolt and Replit already use for mobile apps. Either way, Apple and Google turn away apps that are only a website in a shell (App Review Guideline 4.2 and Google Play's functionality policy). A wrapper that simply loads your live site is the version most likely to be rejected.

This guide covers what your AI tool actually built, the three routes (one of which is staying on the web), what Apple and Google check besides functionality, and the accounts, fees and timing to plan for. Apple and Google make every approval decision, so no route comes with a guarantee.

What your AI tool built

Where you start depends on the tool:

• Lovable builds web applications, not native apps, and does not generate React Native projects. Its FAQ suggests turning the published app into a Progressive Web App, or wrapping it with a tool such as Capacitor outside Lovable and submitting that to the stores (Lovable FAQ).
• Bolt can build iOS and Android apps with Expo (Expo's announcement, February 2025).
• Replit builds mobile apps with React Native and Expo, and guides you through TestFlight and App Store submission (Replit docs).
• Cursor, Claude Code and similar coding agents build whatever stack you and the agent chose, so check your repository before you plan anything.

A Lovable app needs the most work, because there is no mobile app yet. A Bolt or Replit mobile app is already an Expo app, so the work is getting it ready for review rather than choosing a route.

Why a website in an app gets rejected

Apple's guideline 4.2, Minimum Functionality, asks for features, content and interface that lift an app "beyond a repackaged website". It says apps that are not particularly useful, unique or app-like do not belong on the App Store, and guideline 4.2.2 adds that apps should not be mainly marketing material, web clippings or a collection of links.

Guideline 4.3, Spam, rejects apps that are indistinguishable from apps already widely available, and multiple copies of the same app under different bundle IDs. If you have used an AI builder to make several near-identical apps, submit one.

Guideline 4.2.6 rejects apps created from a commercialised template or app generation service unless the provider of the app's content submits them. Apple does not say whether AI app builders count. The cautious reading is to submit from your own developer account, in your business's name, and not from a builder's or a freelancer's account.

Google Play's functionality policy does not allow apps with only limited functionality and content, or apps that crash, freeze or fail to load. Its spam policy also bans apps whose main purpose is a webview of a website without the owner's permission. For your own site, the limited functionality rule is the one to plan for.

There is a technical trap too. Lovable's FAQ talks about wrapping the published app, and the quickest way to do that is to point Capacitor at your live URL. Capacitor's own configuration docs say loading an external URL is meant for live reload during development and is not intended for production. Build the web app into the native project instead.

Route 1: Capacitor, when the web app is right and needs native features

Choose Capacitor when the web app already works well on a phone and you want one codebase for the web and the stores. The work:

1. Get the code out of the builder. Lovable can keep a Git repository in sync with your project (Lovable FAQ).
2. Add Capacitor and bundle the built app into iOS and Android projects, so the app opens without loading your website.
3. Add what a website cannot do: push notifications, the camera and photo library, biometric sign-in, offline use of the data people need most, sharing to other apps. No guideline lists which features are enough, so pick the ones that make the app worth installing for your users.
4. Make it feel like an app: safe areas around the notch, the Android back button, no browser-style links that open the website, and sign-in that survives closing the app.

Building for iOS needs Xcode on a Mac; Capacitor's docs mention cloud build services as an alternative but recommend having the tools locally to test properly (Capacitor environment setup). Our Ionic and Capacitor page covers this kind of app.

Route 2: rebuild the mobile app in React Native with Expo

Choose a rebuild when the app needs to feel fully native, works offline for long stretches, leans on device features, or when Bolt or Replit already gave you an Expo app. The backend usually stays: the new mobile app talks to the same Supabase project or API as your web app.

Expo's hosted build service builds iOS apps on macOS machines in Expo's cloud (Expo build docs), and its submit service uploads builds to the stores from any operating system (Expo submit docs). One thing to check in any AI-built Expo app: Expo's public environment variables are visible in plain text in the compiled app (Expo environment variables), so secret keys must stay on your server.

Flutter is the other good option for a native rebuild. Our guide to Flutter vs React Native sets out how to choose, and our React Native page covers Expo builds.

Route 3: stay on the web

Not every app needs a store listing. Lovable's FAQ suggests a Progressive Web App that people add to their home screen. If customers use your app now and then, or mostly on a computer, a web app avoids store review, store fees and waiting for approval, and every update reaches users at once. Our progressive web app page covers this route.

What Apple and Google check besides functionality

Apple and Google check much more than functionality. Before you submit, check these:

1. A finished app. Apple's guideline 2.1, App Completeness, rejects placeholder content, crashes and broken links, and asks for a demo account (with your backend switched on) if the app has a sign-in. Apple says over 40% of unresolved issues relate to guideline 2.1 (App Review).
2. Account deletion. If people can create an account, Apple requires a way to delete it inside the app (5.1.1(v)). Google Play requires an in-app path and a web link where people can ask for their account and data to be deleted (Google Play account deletion).
3. A privacy policy and honest data answers. Apple wants a privacy policy link in App Store Connect and inside the app (5.1.1), and Google asks all developers to answer the data deletion questions in the Data safety form (Google Play account deletion).
4. AI features. If the app sends personal data to an AI provider, Apple requires you to say so clearly and get explicit permission first (5.1.2(i)).
5. Sign-in options. If the app uses a third-party or social sign-in such as Google for the main account, Apple also requires an equivalent option that limits data to name and email and lets people keep their email private, with some exceptions, such as apps that only use your own account system (4.8).
6. Payments. On iOS, unlocking features or content inside the app, such as a subscription or premium access, generally has to use in-app purchase (3.1.1), with exceptions Apple lists in section 3.1. Physical goods and services used outside the app must use other payment methods, such as Apple Pay or a card (3.1.3(e)). A web checkout that unlocks digital features is the one to look at first.
7. A current Android target. Since 31 August 2026, new apps and updates on Google Play must target Android 16 (API level 36) or higher, apart from some device types such as Wear OS and TV (Google Play target API level).
8. Google Play's closed test. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, opted in for the 14 days before they apply for production access (Google Play testing requirements).

Accounts, fees and timing

• Apple Developer Program: US$99 per membership year, or the local currency equivalent where available (Apple).
• Google Play Console: a US$25 one-time registration fee, with a choice of a personal or an organisation account (Google Play). The closed test above applies to personal accounts.
• Whose name: set both accounts up in your business's name, so the listings, reviews and ratings stay yours whoever builds the app.
• Review time: Apple says it reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours (App Review). Each rejection adds a round, and a new personal Google Play account adds at least the 14-day test.

How Rocket Lab can help

If your app works on the web, we can take it the rest of the way: recommend the route, add the native features or rebuild the mobile app, then set up the builds, store listings and submission. Our page on taking AI-built apps to production covers the fixes that usually come first, such as data access rules, keys and payments. We have taken apps first built with AI tools such as Lovable, Bolt and Cursor to production.

If nobody has reviewed the app yet, start with an App Rescue Report: a fixed-price audit of an app built with AI tools that tells you what to fix before launch, with estimates. Once the app is in the stores, Apple and Google raise their requirements every year, and mobile app maintenance keeps it current.

Frequently asked questions

Can I put my Lovable app in the App Store?

Not as it is, because Lovable builds web apps. You can package it with Capacitor and add features a website cannot offer, or rebuild the mobile app in React Native with Expo. Apple and Google decide on approval.

Will Apple reject an app built with Capacitor?

Not for using Capacitor. The guidelines judge what the app does, not the framework behind it. Guideline 4.2 asks for more than a repackaged website, so an app that bundles its code and offers real app features is in a far better position than one that loads your live site.

What does App Store guideline 4.3 spam mean for an AI-built app?

Apple rejects apps that are indistinguishable from apps already widely available, including opportunistic variants of popular apps, and names crowded categories, such as flashlight and wallpaper apps, that need a meaningfully different experience. Submitting the same app several times under different bundle IDs also falls under 4.3. An app built with AI is judged the same way as any other.

Do I need a Mac to publish an iOS app?

For a Capacitor app, building for iOS needs Xcode on a Mac, although cloud build services exist. For an Expo app, Expo's build service builds iOS apps in the cloud, and its submit service runs from any operating system.

Do I need to change my Supabase backend for a mobile app?

Usually not: the mobile app talks to the same backend. Check two things. The app should contain only Supabase's publishable key, never a secret key, because anyone can download the app and read what is in it (Supabase API keys). And your Row Level Security policies have to hold, because they, not the app, decide what each user can read.

How long does it take to get an app approved?

Apple says it reviews 90% of submissions in less than 48 hours, but each rejection adds another round. On Google Play, a new personal developer account needs a 14-day closed test with at least 12 testers before it can publish. Build that time into your launch date, and more if the app needs native features or a rebuild first.

Talk to us about your app

• Talk to the team. Book a free 30-minute consultation and we will talk through your app, how it was built and the best route into the stores.
• Prefer a call back? Request a callback: leave your number and a time that suits you, and we will call you.