Lovable logo Lovable → App Store & Google Play

Your Lovable app, approved on the App Store.

Lovable builds you a real product in an afternoon — then you find out it cannot go on the App Store. Glideep wraps it in a native shell with the capabilities Apple looks for, adds StoreKit and Play Billing so you can actually charge for it, and ships to both stores.

1–2 min
to build both platforms
98%
of our submissions clear review
$0
to start — no card needed
The actual problem

Why Lovable apps get rejected

This is the single most common thing people contact us about, so here is the honest version rather than the marketing one.

Lovable gives you a React single-page app on a *.lovable.app subdomain. It is genuinely a product — routing, state, a database behind it, real users. But it is delivered over the web, and that is the whole difficulty.

When a reviewer opens a plain wrapper around that URL, they see a responsive web page rendered inside a WebView. Guideline 4.2 — Minimum Functionality exists precisely for that case, and Apple's wording is blunt:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like”, it doesn't belong on the App Store.

The rejection is not about how your app was built. Apple does not know or care that Lovable wrote the code, and there is no penalty for AI-generated apps — hand-written React apps fail 4.2 constantly. The question a reviewer is answering is narrower: could I do all of this in Safari?

If the answer is yes, it gets rejected. So the job is not to disguise a website. It is to give the app things a browser tab genuinely cannot do, and then actually use them.

App Store Connect — Resolution Center
Guideline 4.2 — Design
We noticed your app only provides a limited set of features

Specifically, your app is a web page bundled in an iOS app and does not include native iOS functionality or content.

We encourage you to review your app concept and incorporate different iOS features and technologies to provide a more robust user experience.

The wording varies, but this is the shape of the rejection. It arrives after review, not before — which is why it is worth getting right the first time.
Side by side

The same app, submitted two ways

Nothing changes in Lovable. What changes is the shell around it.

RejectedA bare wrapper
  • Opens straight into the web page, full screen
  • Browser-style back button, or none at all
  • No notifications — nothing brings the user back
  • Login is a web form, same as the site
  • Payments go to an external checkout — a second rejection
  • Blank screen while the SPA boots, nothing offline

Everything here is available in Safari. That is the finding.

ApprovedThe same app, through Glideep
  • A native home screen built in the editor, not a web page
  • Native bottom tab bar and side drawer
  • Push notifications through OneSignal
  • Face ID / fingerprint lock, native Google and Apple sign-in
  • Subscriptions through StoreKit and Google Play Billing
  • Branded splash, onboarding slides, camera, location, offline

None of these exist in a browser tab. You do not need all of them — you need enough that the honest answer to “could I do this in Safari?” is no.

Walkthrough

Lovable to TestFlight, start to finish

Using Aileron, a travel app built in Lovable, as the worked example.

1

Publish in Lovable and copy the URL

Hit Publish in Lovable. You get the live address of your app — for Aileron that was wanderwise-vault-60.lovable.app. A custom domain works exactly the same way.

That is the only thing you need from Lovable. Nothing is exported, migrated or rebuilt, and your project stays where it is.

lovable.dev — Publish
Lovable's publish dialog showing the live URL wanderwise-vault-60.lovable.app for the Aileron travel app
Lovable confirms the app is live and shows the URL to copy.
2

Paste it into Glideep

Choose Create new app, give it a name and paste the URL. That is the entire setup — no SDK, no build config, no code to add on the Lovable side.

Your app appears with an editor beside a live preview, and you can scan a QR code to open the real thing on your phone before building anything.

app.glideep.com — Create new app
Glideep's Create new app dialog with the app name Aileron and the Lovable URL pasted in
Name, URL, Create app. Nothing else is required to start.
3

Turn on what gets you past 4.2

This is the step that decides whether you are approved, and the one people rush. Work through the editor tabs and switch on what genuinely suits your app.

Home Screen
A native landing screen with your own cards and actions, so the app does not open straight into the web view.
Navigation
A bottom tab bar and side drawer, so moving around feels like an app rather than a site.
Push notifications
Connect OneSignal. The clearest single signal to a reviewer that this is not a website.
Biometric lock
Face ID or fingerprint on open. Especially convincing if your app holds anything personal.
Social login
Native Google and Apple sign-in instead of a web form. Apple requires Sign in with Apple if you offer any other third-party login.
In-app purchases
StoreKit and Play Billing through RevenueCat. Required if you charge for anything inside the app.
Do not skip this and submit anyway. A wrapper with every switch left off is exactly the app guideline 4.2 was written for, and it will be rejected no matter which tool built it.
4

Build and submit

Building takes one to two minutes. No Mac and no Xcode at any point — iOS builds run on cloud macOS machines and the signed IPA is uploaded to TestFlight for you through the App Store Connect API.

.apk
Signed Android build for direct install and testing.
.aab
The bundle Google Play requires for new submissions.
.ipa → TestFlight
Uploaded automatically. Promote to review when ready.

You still need the store accounts: Apple Developer at $99 a year and Google Play at $25 once. Those go to Apple and Google, not to us — and the Apple account is usually the slowest part, so start it first.

Getting paid

Sell subscriptions from inside the app

The second reason people come to us, after rejections — and the two are related.

If your Lovable app charges for anything a user consumes inside the app — a subscription, a premium tier, credits — Apple and Google both require their own billing. Sending people to a Stripe or Paddle checkout is not a grey area; it is its own rejection, separate from 4.2, and it is one of the most common ways a second submission fails after the first one passed.

  • Apple StoreKit and Google Play Billing are wired into the native shell — you are not calling a web payment form from a WebView.
  • RevenueCat sits across both, so one set of products and entitlements covers iOS and Android instead of two separate integrations.
  • No code needed on the Lovable side. If your app can run custom JS, call the bridge. If it cannot, link any button to a URL with a product id appended and the app buys it instead of navigating.
  • Money goes to your store accounts, not through us. Glideep never takes a cut of your revenue.
Create the product
Set up the subscription or one-time purchase in App Store Connect and Google Play Console.
Connect RevenueCat
Import those products and attach each to an entitlement. Free to start.
Paste the SDK key
Drop the public key into the Features tab and switch In-App Purchases on.
Trigger from your app
A JS bridge call, or a plain link with the product id — whichever your build supports.
Done for you

Or let our team submit it for you.

Plenty of people get the app built and then stall at submission — the certificates, the store listing, the screenshots, the privacy answers, the first rejection nobody warned them about.

For a one-off fee our team takes it from a working build to a live listing. We QA the app on real devices, test the flows, prepare the store assets and handle the back-and-forth with review. This is the same service FlutterFlow users come to us for, having built the app but hit a wall at deployment.

  • QA on real devices — not just a simulator run.
  • Flow testing — sign-in, purchases, notifications, deep links.
  • Store assets — listing copy, screenshots, content rating, privacy answers.
  • Submission and review — including replying to the Resolution Center if it comes to that.
After you ship

You keep working in Lovable

Shipping an app does not mean freezing your product.

Content changes need nothing
Keep prompting Lovable and hitting Publish. The app loads your live site, so a change reaches users as soon as it is live — no rebuild, no resubmission, no review wait.
Most app settings are live too
Colours, navigation, the home screen, onboarding and most feature switches are read by the installed app each launch. Change them in the editor and they reach phones without a store submission.
Only the shell needs a rebuild
The app icon, the display name, the bundle identifier and the permission list are compiled into the binary. Changing those means a new build and a new submission — which is rare.
FAQ

Lovable to app store, answered

Will Apple reject my app because it was built with AI?

No. Apple does not ask how the code was written and there is no rule against AI-generated or no-code apps. What gets rejected is an app that offers nothing beyond its website, whoever or whatever wrote it. Hand-written React apps fail guideline 4.2 constantly.

Do I need a custom domain instead of *.lovable.app?

Not for the app to work — Glideep loads whichever URL you paste. A custom domain is worth having for branding and deep links, and it does read as more established to a reviewer, but it is not what decides a 4.2 outcome. Native features are.

My Lovable app uses Supabase auth. Does that need special setup?

No. Your login keeps working exactly as it does in the browser — it is the same app running in the WebView with its session intact. Native Google and Apple sign-in are an addition on top if you want them, not a replacement, and worth adding since a native sign-in sheet reads very differently to a reviewer than a web form.

Can I keep using Stripe for payments?

For physical goods and services consumed outside the app, yes. For anything unlocked inside the app — subscriptions, premium features, credits — Apple and Google require their own billing, and an external checkout is its own rejection. That is what the StoreKit and Play Billing integration is for.

What if I get rejected anyway?

Read the rejection carefully first — Apple names the guideline. If it is 4.2, the fix is almost always more native surface: a real home screen instead of opening into the web view, push notifications, biometric lock. If it is a different guideline it is usually about your content or privacy policy, and native features will not address that. We publish a full guide to clearing 4.2.

How long does the whole thing take?

The build is one to two minutes. Setting up the native features honestly takes an afternoon if you do it properly. Apple's review is typically 24 to 48 hours and Google Play is often faster, though a first submission can take longer. The slowest part is usually getting the Apple Developer account approved, so start that first.

Get your Lovable app onto the stores.

Start free, build a real app, and see it on your own phone before you pay anything.