You described an app, Lovable built it, and it works in the browser. Then someone asks whether it is on the App Store.
Lovable publishes a web app
Lovable says so in its own documentation: it builds web apps, and publishing always deploys to a web URL. What you get from Publish is a web app hosted at your-app.lovable.app or on a custom domain, with HTTPS included. There is no iOS build, no App Store Connect record and no submission.
The documentation offers two ways to get closer to a phone: a progressive web app that people add to their home screen, or a native shell around the published URL for app store submission. The first never appears on the App Store. The second runs into the review rule further down.
What a Lovable project is
Underneath the editor, a Lovable project is a React codebase; Lovable does not generate React Native. New projects get Lovable Cloud, a built-in backend on Supabase’s open-source foundation, for their database, sign-in and storage; some connect a Supabase project of their own instead. With a repository connected, the code syncs two ways with GitHub, GitLab or Bitbucket. On paid plans you can also download it.
That decides what comes next. A React web app’s screens are HTML drawn by a browser engine, and that stays true inside a wrapper. A real iOS app has to be built again with native components. The question is who builds it, and in what.
Three routes to an iPhone app
-
Wrap itCapacitor or a WebView service
A native shellloading your-app.lovable.appStill your websiteGuideline 4.2: a repackaged website -
Rewrite in React Nativea conversion service
React Native componentsrewritten from your React codeA real app, cross-platformits own runtime, its own look -
Bring it to AirBuildan AI team
Reads what it doesscreens, flows, what it talks toA native SwiftUI appApp Review handled
“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.”
That is why the wrapper route is a gamble: a shell around your-app.lovable.app is, by definition, a repackaged website, and each rejection costs a review cycle. A native SwiftUI app does not start with that problem, because it is not a website. Every screen is built with Apple’s own frameworks, which is why it scrolls, animates and responds like the other apps on the phone.
How bringing it works
Leave the link
Join the waitlist with the published address of your Lovable app, or the GitHub repository it syncs to, and a sentence about what the iOS app should do and who it is for.
Your AI team builds it again in SwiftUI
AirBuild’s product, design and engineering agents read what your app does, its screens and its flows, and build a native iOS app from them. Your web app stays untouched; you keep editing it in Lovable.
Try it on your iPhone, then App Review
The app reaches your phone through TestFlight so you can try it and ask for changes in plain language. When it is ready, AirBuild prepares the App Store listing, submits, tracks the review, replies to the reviewers, fixes what they raise and resubmits.
What carries over
Every screen keeps its job; the way you reach it changes. Browser routes become a tab bar, a navigation stack and sheets.
Your Lovable app, in the browser
/Dashboard with this week’s runs/runsEvery run, newest first/runs/:idOne run: route, pace, notesThe same app, in SwiftUI
| Part of your app | What happens to it |
|---|---|
| Copy, colors and branding | Carried over. The app should feel like yours, not like a template. |
| Data and backend | Stays where it is. Tell us what your app talks to, Lovable Cloud, a Supabase project of your own or an API, and we plan the iOS app around it. |
| Sign-in | Tell us how sign-in works today. Like your data, it stays where it is. |
| Your web app | Unchanged, and still yours to edit in Lovable. |
| App Store listing | New. Name, description, screenshots, privacy answers and review notes are prepared for you. |
What to have ready
- The published link of your Lovable app, or its GitHub repository if it has pages behind sign-in.
- An Apple Developer Program membership, or a plan to enroll before the app is submitted.
- One paragraph on what the iOS app should do first. It does not have to be everything the web app does.
- A privacy policy URL. Apple asks for one, and App Store Connect will not accept a submission without it.
Questions
Can Lovable make an iOS app?
No. Lovable builds web apps and publishing always deploys to a web URL. Its documentation suggests a progressive web app or a native shell around the published URL; neither is a native iOS app.
Is a wrapped Lovable app allowed on the App Store?
Often not. Guideline 4.2 says an app should include features, content and UI that elevate it beyond a repackaged website. A WebView around your published URL is the textbook case of a repackaged website.
Does this replace my web app?
No. Your web app keeps running at its lovable.app address or your domain, and you keep editing it in Lovable. AirBuild builds the iOS app beside it.
What happens to my backend?
It stays where it is. Tell us what your app talks to, Lovable Cloud, a Supabase project of your own or an API, when you join the waitlist, and we plan the iOS app around it rather than moving your data.
Do I need a Mac or Xcode?
Neither. AirBuild runs your AI team on a Mac or in the cloud, and the app reaches your iPhone through TestFlight. You do need an Apple Developer Program membership to publish.
Who owns the iOS app’s code?
You do. Your Lovable code stays yours, and so does the SwiftUI project AirBuild builds from it.