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.
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.
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 same app, submitted two ways
Nothing changes in Lovable. What changes is the shell around it.
- 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.
- 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.
Lovable to TestFlight, start to finish
Using Aileron, a travel app built in Lovable, as the worked example.
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.
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.
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.
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.
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.
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.
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.
You keep working in Lovable
Shipping an app does not mean freezing your product.
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.