Tech
Lovable to the App Store: What the Wrapper Guides Don't Tell You
October 6, 2026
Taking a Lovable app to the App Store?
Tell us about your Lovable app and how you plan to get it into the stores, and we'll reply within one working day with what we'd check first.
Get a free checkYes, you can get a Lovable app into the App Store and Google Play. Lovable won't do it for you, though. Its own documentation says publishing "always deploys to a web URL" and that there "isn't a built-in flow that packages and submits your project to the App Store or Google Play". It points you to two options instead: make your app a Progressive Web App, or "wrap your published URL in a native shell with Capacitor".
So founders go looking, and much of what they find on page one comes from companies that sell the wrapper. Their guides are accurate as far as they go. They tend to stop at "wrap it and submit", because that's the product.
One Lovable builder on Reddit in July was "curious how strict Apple's review has been for AI-generated builds lately", and added: "Trying to avoid rebuilding the whole thing in native code if I don't have to." Most founders who contact us about Lovable are asking the same thing. The answers below come from our own App Store submissions and from what Lovable builders report.
Yes. Lovable's FAQ answers "Who owns the projects and the code that Lovable creates?" with "You as the creator do!" You can sync the code to your own GitHub, GitLab or Bitbucket repository on any plan, sell the app, charge for it and put it in the stores.
Charging is where it gets harder. If your app sells access to digital features or content inside the iPhone app, Apple's guideline 3.1.1 says you "must use in-app purchase". Lovable's built-in payments run through Stripe or Paddle on the web. We've covered those rules in why Base44 apps can't charge on iPhone, and most of it applies to Lovable too.
Lovable does have one advantage over Base44 here. Base44 builds its own wrapper and doesn't expose the native layer, so you can't add Apple's in-app purchase to it. A Capacitor project that you or your developer control is a real native project. RevenueCat publishes a Capacitor SDK for in-app subscriptions, so a Lovable app wrapped this way can sell through Apple and Google properly.
There are three routes, and they suit different apps.
A Progressive Web App. Users "add to home screen" from the browser. It's the quickest option and needs no store, but it isn't in the App Store, so nobody finds it there.
A wrapper. Capacitor, or a service built around it, puts your web app inside a native shell that you submit to Apple and Google. Most Lovable builders take this route, and it works. One wrote in August: "I started in lovable. Moved to cursor. Wrapped in capacitor. Approved in both app stores." We're pricing this route for a client's AI-built app right now, because it keeps everything they've already built.
Lovable's advice to wrap your published URL has a catch. Pointing the wrapper at your live website is Capacitor's server.url setting, and Capacitor's own documentation says that setting "is not intended for use in production". A shell that just loads your website is also the shape Apple's minimum functionality rule is most likely to question. The approved wraps we've seen package the app's files inside the shell, and that takes developer work outside Lovable.
A native rebuild. Lovable is candid here too: it "does not generate projects in React Native", and its docs suggest prototyping the screens in Lovable and rebuilding outside it. It's more work up front, and it makes sense when the app depends on the phone itself: health data, Bluetooth, background location, offline use.
In our experience the wrapper isn't automatically the cheap option. Once a founder's list includes a couple of features that need native code, a proper wrap and a rebuild can land closer together than people expect. Get both priced before you decide.
Guideline 4.2.6 is the rule almost nobody selling a wrapper mentions. Here's how it reads today:
"Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences."
Apps built with Lovable and wrapped apps can both meet it, as long as the business whose content it is submits the app. So your app should go in under your own Apple developer account, enrolled as your business, with a seller name that matches the app's brand. That's what the rule asks for, though it isn't a guarantee. Developers on Apple's own forums report 4.2.6 rejections of template-built apps submitted from the client's own account, where Apple couldn't see that the account owned the brand, and one reply describes Apple asking for paperwork to prove it.
The riskier version is a service that publishes your app from its own developer account, next to other clients' apps. That's the pattern 4.2.6 names. Before you pay any wrapper service, ask whose Apple developer account the app will be listed under. The answer should be yours, with you as the Account Holder, because only the Account Holder can accept Apple's legal agreements.
Usually not, going by what builders report. It does happen, though, and we've been on the receiving end.
Guideline 4.2 asks that an app "include features, content, and UI that elevate it beyond a repackaged website". Most Lovable builders who post about their submissions got through with a wrapper, and the rejections they paste are mostly about payments, sign-in, design and layout, and privacy settings. The 4.2 rejections that do turn up include a wrapped Lovable app turned down twice even though it had Face ID, push notifications and camera access.
Here's our own lesson. We built three apps for a trade supplier, each on iPhone and Android, as web wrappers around their existing websites. Apple's first rejection, under 4.2, came in April 2025, and rejections followed across all three iPhone apps later that year. Getting them through meant changing how the apps opened web content, reworking the store screenshots, adding account deletion and App Tracking Transparency, moving the apps to unlisted distribution for trade customers, and replying to Apple in writing in January 2026 on 4.2 and on 4.3(a), Apple's rule against near-duplicate apps. The apps are live for trade customers through unlisted links, and that position has held. But three near-identical wrappers from one company is a profile we think Apple looks at closely, and it's still the standing risk on that estate.
What we took from it: a wrapper of a website you already run invites the question "what does the app add?" If people could just use your Lovable app in Safari, have an answer ready before a reviewer asks, whether that's push notifications, a native feature or offline use.
Sign-in catches a lot of apps. If yours offers Google sign-in, guideline 4.8 means you must also offer an equivalent option that limits data collection and tracking and lets users hide their email address. In practice that's Sign in with Apple, and it's one of the rejections Base44 builders paste most. Lovable's built-in authentication supports Apple sign-in, so switch it on before you submit. There's a second trap in a wrapped app: Google's OAuth policy doesn't allow its sign-in page to load inside the app's web view, so it has to open in the system browser or use a native sign-in plugin. Test both buttons on a real phone.
Payments come next, and selling digital features inside the iPhone app needs in-app purchase (see above).
Then there are builds that pass and don't run. A founder in May, after adding a push notification plugin, wrote: "Build succeeds. App launches to a white screen and never renders the React app." Test on real devices through TestFlight before you submit, not only in the simulator.
On Android, Google's webview rule only bans wrapping someone else's site without permission, so a wrapper of your own is allowed in principle. It still has to meet Play's minimum functionality policy. And if your Google Play developer account is a personal one created after 13 November 2023, you must run a closed test "with a minimum of 12 testers who have been opted in continuously for at least 14 days" before you can publish. Plan the fortnight in.
Your code is portable. Your backend takes more work to move.
Lovable Cloud is on by default, and Lovable switches it on (or asks first) when you ask for a feature that needs a backend. It's built on Supabase, but Lovable's docs say "There is no one-click migration from the built-in backend (Cloud) to your own Supabase project." You can export the database, including users' password hashes. Storage files, secrets, sign-in settings and API keys have to be moved and set up again by hand.
Builders who tried to leave in late 2025, before Lovable added a database export in July 2026, had a rough time. One was told by support "to ask Lovable AI one at a time for every single entity in my database". It's easier now, but it still isn't a button.
This matters more once you're in the App Store. Lovable's own docs say users who are signed in when you switch backends need to sign in again, so moving later means asking every live user to log back in. Decide where your backend will live before launch.
Security is usually the other question. A care provider's director built the app that onboards their care staff in Lovable and Supabase. It holds passports, DBS certificates and bank details, and they told us on our first call: "because with vibe coding, I know it's not that secure." Lovable runs a quick scan of database access rules when you publish, and offers a deeper code scan too. Its own docs say the scans "do not replace a thorough security review". That's where we'd start.
Approval starts an annual cycle. Apple and Google release new OS versions every year, and store policies move with them. Apple's App Store Improvements policy is blunt about neglected apps: if an app hasn't been updated in three years and gets almost no downloads, the developer gets an email and 90 days to update it, and "apps that crash on launch will be removed immediately".
Some bugs only show up away from your desk. One Lovable founder had tested push notifications and a subscription grace period for a month at home. On a trip abroad both fired at the wrong times, because the app stored times in UTC and adjusted them by their home time zone.
The app is listed under your own Apple developer account, enrolled as your business, with you as Account Holder.
Anything you charge for inside the iPhone app goes through in-app purchase.
Google sign-in sits alongside Sign in with Apple, and both work on a real phone.
You've tested on a real iPhone and a real Android phone, through TestFlight and a Play testing track.
You know where your backend lives, and how you'd move it.
You can answer "what does this app do that the website doesn't?"
If you'd like a second pair of eyes, our £95 App Rescue review looks at an AI-built app's code, security, stability and account ownership and tells you what to fix first. If you've outgrown Lovable, our Lovable to production service takes you from wrapper or rebuild through to the stores, with ongoing care after launch.
No, not directly. Lovable publishes to a web URL. To get into the App Store you wrap the app (Lovable suggests Capacitor) or rebuild it natively, then submit it from your own Apple developer account.
Yes. Lovable says you own the projects and code it creates. If you sell digital features inside the iPhone app, Apple requires in-app purchase, which a Capacitor wrapper can support through a plugin such as RevenueCat's.
To build the iPhone app with Capacitor you need Xcode, which runs on a Mac. Capacitor's docs mention cloud build services for people without one, but they still recommend having the tools locally to test properly.
It can. Google's webview rule targets apps that wrap a site without the owner's permission, though the app still has to work as an app, not just show a website. New personal developer accounts must complete a 14-day closed test with at least 12 testers first.
Not in itself. Guideline 4.2.6 wants the app submitted by the business whose content it is, so it should go in under your own developer account, enrolled as your business, with a seller name that matches the brand. That still isn't a guarantee: developers report 4.2.6 rejections from clients' own accounts when Apple couldn't see that the account owned the brand. Check the service isn't publishing from an account of its own.
