CanLovableBuildaMobileApp?Capacitor,ReactNativeandtheAppStorePathforaLovableWebApp

The short version

Your Lovable app works. Someone asked whether it is in the App Store, you searched, and you got three answers. Lovable's FAQ says wrap it. A wrapper vendor says buy our container, done in a day. A rebuild vendor says wrappers get rejected under Apple's guideline 4.2 and offers to regenerate the whole thing as React Native. Each of them is selling the answer they gave you, which is why you cannot tell who is right.

Here is the short version. Lovable does not build native apps and says so plainly. There are two honest routes to a phone, a Progressive Web App or a native shell around your web build, and one wrong route that Lovable's own publish page happens to point at. The wrap that passes App Review copies your compiled build into the app. The wrap that loads your live URL is the thing Capacitor's own docs call not for production and the thing Apple's rules call a web clipping. Which of those you end up with depends on a config file, and whether you even have a build to copy depends on which of Lovable's two stacks your project is on.

After that, the part every tutorial skips. Sign-in works in the browser and breaks inside the shell, for a reason Supabase documents. Apple wants a Sign in with Apple button next to your Google one before it looks at anything else. You need a Mac. Google Play wants twelve testers for two weeks. And since iOS 16.4 a Home Screen web app can send push notifications, which for a fair number of founders means the store was never the point. None of it is a reason to rebuild anything, and none of it replaces the production checklist your web app still needs before a shell goes around it.

Can Lovable build a mobile app at all?

No. Not a native one. That is not our reading of the product, it is Lovable's own FAQ, and it is worth quoting exactly because half the pages that rank for this question soften it.

Lovable's FAQ says: Lovable builds web applications, and you can design them to be fully mobile friendly. Lovable does not generate React Native projects. Then it gives the two paths. If you want an installable app on phones, there are two common paths: make your published app a Progressive Web App that users add to their home screen, or wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store. The publish documentation says the same thing from the other side. Lovable builds web apps and publishing always deploys to a web URL, your project's lovable.app address or your custom domain.

One thing to clear up before going further, because it pollutes every search on this topic. There is a Lovable mobile app in the App Store and on Google Play. It is Lovable's editor, for prompting and reviewing your projects from a phone. Lovable's own documentation for it says, in effect, if you want to turn a project you built into an app that people install on their phones, go and read the publishing question instead. So when the top results for lovable ios app are Lovable's store listing and a launch story, they are about Lovable's app, not yours. Yours does not exist yet, and this page is about whether it should.

A native shell is a small iOS or Android application whose main screen is a full-screen web view, with a bridge that lets the web code call native features such as the camera, push notifications and biometrics through plugins. Capacitor is the shell Lovable names and the one most of the tutorials use. The web code inside it stays the React that Lovable generated. That is the whole trick, and it is also where the two very different kinds of wrap come from, which is the next section and the one that decides whether you get rejected.

Wrapping the URL or bundling the build: which wrap did Lovable mean?

Bundle the build. Not the URL. Lovable's FAQ says wrap your published app, and its publish page says wrap your published URL in a native shell with Capacitor, and those two sentences describe two different apps. One of them gets approved.

Read Capacitor's configuration reference and the split is right there in two settings. The first is webDir, which Capacitor defines as the directory of your compiled web assets, and adds that this directory should contain the final index.html of your app. Capacitor's workflow guide describes what happens to it: running npx cap sync will copy over your already built web bundle to both your Android and iOS projects. So the app that ships contains your app. It opens without a network round trip, it can show something when the phone is offline, and to a reviewer it is a piece of software that happens to be built with web technology, which is what most apps on the store are.

The second setting is server.url. Capacitor's own words: load an external URL in the Web View. This is intended for use with live-reload servers. And then, on the same line of the reference, this is not intended for use in production. That setting is the URL wrapper. It is a browser with your address baked in and the chrome removed. Offline it is a blank screen. To Apple it is the thing guideline 4.2.2 describes when it says apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links, and the rejection notice that goes with it says the app does not sufficiently differ from a mobile web browsing experience. The URL wrapper is what a founder builds when they follow Lovable's publish page literally, and it is also, as far as their public pages let us tell, what most of the paid wrapper containers that rank for convert lovable to mobile app are. Their whole pitch is that you never touch the code, and you cannot bundle a build without touching the code.

That distinction is the most useful thing on this page, so here it is as a table. The PWA column is included because it is the option Lovable lists first and the one this page will come back to.

One more line on that updates column, because the vendors selling Capacitor tooling lead with it. Over-the-air updates push a new web bundle into an installed app without a store release. Apple's guideline 2.5.2 says apps may not download, install, or execute code which introduces or changes features or functionality of the app. Read that sentence with the product page open and decide for yourself what a bug fix is and what a feature is. We are not going to tell you a vendor's tooling is against the rules, and we are not going to tell you it is fine. We will tell you that 2.5.2 is the sentence a reviewer has in front of them.

Which Lovable stack are you on, and why does it change the wrap?

Because a bundled shell needs a folder of static files to copy, and only one of Lovable's two stacks produces that folder when you run the build.

Lovable's FAQ is the source for the split: new apps created from 13 May 2026 use TanStack Start with server-side rendering, and older apps use React and Vite. Lovable did not migrate the old ones. Our guide to what Lovable actually generates walks the full test, including the View Page Source check on your live site. The one-line version is enough here. If the Vite config at the root of your repository imports the React plugin and lovable-tagger directly, you are on the old stack. If it wraps everything in a call to @lovable.dev/vite-tanstack-config, you are on the new one.

On the old stack this section is short. The build writes a dist folder containing index.html and a bundle of JavaScript, and that is exactly the folder Capacitor's webDir wants. Every Capacitor tutorial on the first page of results, Capgo's included, tells you to set webDir to dist, and for a Vite project that is correct. Set the base path in the Vite config to a relative one so the assets resolve from inside the bundle, build, sync, open Xcode. The mechanics are an afternoon.

On the new stack there is no dist folder to point at, and this is where founders following those same tutorials get stuck without knowing why. A TanStack Start build produces a server, because server-side rendering means a process builds each page into HTML on request, and a server is not a folder of files you can copy into a phone. It is the same shape problem as deploying the new stack to a static host, which we covered in the Lovable to Vercel guide, and TanStack's own documentation gives the two ways out. The first is SPA mode. TanStack describes it as being for applications that do not require SSR for either SEO, crawlers, or performance reasons, where it may be desirable to ship static HTML to your users containing the shell of your application. It writes that shell to a file called /_shell.html, and TanStack is explicit that no SSR doesn't mean giving up server-side features, so your server functions keep working. The second is static prerendering, which TanStack defines as the process of generating static HTML files for your application, switched on with prerender.enabled and written out as /page/index.html files by default. Either gives Capacitor something to copy. Inside a phone, where nobody is crawling you, SPA mode is the one that fits.

One honest gap, and then the point. Those options are set on the TanStack Start plugin, and in a Lovable project that plugin sits behind Lovable's own config package. The npm registry entry for that package carries no README, so we could not confirm from the registry whether it passes the spa and prerender options through or not. A developer opens the config and looks. If the wrapper exposes them, it is two lines. If it does not, the config is unwrapped for the mobile build, which is still not a rewrite of anything. The point is that the tutorials are not wrong. They are describing the other stack, and if your project was created after 13 May 2026, you have been following instructions for an app you do not have.

Does Lovable support React Native, Expo or Flutter?

No, none of them, and the reason it matters is not the missing feature. It is what the people offering to fill the gap are actually selling.

The FAQ closes the question in one sentence, Lovable does not generate React Native projects, and there is an open request on Lovable's feedback board asking for React Native and Expo support, which tells you it has not shipped. There is no Flutter output either, and there never was. Lovable generates React for the browser, either React and Vite or TanStack Start, and both of those render HTML into a DOM. React Native renders native views and has no DOM, no CSS cascade and no div, which is why the two share logic and not screens. Our guide to taking a React web app to mobile walks what ports and what does not, including where the famous 99 percent code-sharing figures actually come from, and this page will not repeat it.

So what would a React Native version of your Lovable app be? A second frontend. It would sign in against the same Supabase project, read the same tables under the same row policies, call the same edge functions, and reuse your validation and formatting logic if that logic was ever separated from your components, which in a generated codebase it usually was not. Every screen would be written again. That is a legitimate project when the phone product is genuinely different from the web product, and a later section says when that is true.

Then there are the services that rank for lovable react native by offering to regenerate your project as React Native and Expo from your GitHub repository or your URL. Understand what that is. It is a new app, generated from a description of your old one, that does not share code with it and does not stay in sync with it. The next change you make in Lovable does not appear in it. You would own two products with one team, or more likely with none, and the tools that do this are competing with Lovable, not extending it. That is fine as a product decision if you have decided to leave Lovable. It is not a mobile version of the app you have.

Will Apple reject a wrapped Lovable app?

It rejects wrapped websites, and it rejects Google-only sign-in, and the second one is the rule nobody selling you a wrapper mentions.

Start with the one they do mention. Guideline 4.2 is titled Minimum Functionality. It asks that your app include features, content and UI that take it past being a repackaged website, and it says that if your app is not particularly useful, unique, or app-like, it doesn't belong on the App Store. 4.2.2 adds the list quoted earlier, with web clippings in it. The rejection notices founders post in Apple's developer forums use the same phrase every time: the app does not sufficiently differ from a mobile web browsing experience. A URL wrapper is that app by construction. A bundled shell is not automatically that app, because Capacitor apps ship on the store in large numbers, but a bundled shell whose whole content is your responsive site with nothing added is still that app. The reviewer is opening it and asking what it does that a Safari tab would not. The generic guide linked above lists the native capabilities that answer the question, push, biometric sign-in, camera wired to a real workflow, offline access to something that matters, and any one of them done properly moves you out of the category.

Now the one they do not mention. Guideline 4.8, Login Services, says that apps that use a third-party or social login service, and it names Google Sign-In, to set up or authenticate the user's primary account must also offer as an equivalent option another login service with the following features: the login service limits data collection to the user's name and email address, it allows users to keep their email address private, and it does not collect interactions with your app for advertising purposes without consent. That is a description of Sign in with Apple. The rule does not apply if your app exclusively uses your company's own account setup and sign-in systems, so email and password alone is fine. But a Lovable app that offers Google login, which Lovable's managed OAuth makes a one-line addition, and nothing else, fails 4.8 before the reviewer has formed an opinion about 4.2. Adding Sign in with Apple to a Supabase project is a documented provider setup plus the button, and it needs the paid developer account this page gets to shortly, so it is not a five-minute fix on submission day.

One more from the same document, 5.1.1, because it catches generated apps constantly. If your app supports account creation, you must also offer account deletion within the app. Most Lovable apps have a sign-up form and no delete button anywhere. That is a screen, a confirmation, and a call that removes the user and their rows, and it is a screen that has to exist before you submit, not after the rejection. Our Lovable authentication guide covers the Supabase side of both of these on the web, and the shell inherits whatever you did there.

Why does sign-in work on the web and break inside the app?

Because the login finishes in a browser that is not your app, and Supabase requires it to finish in the one that started it. This is the failure that turns a working afternoon into a locked-out launch, and it has a documented cause.

PKCE, which is the flow Supabase uses for browser sign-in, works by creating a secret on the client at the start of the flow and proving it at the end. Supabase's PKCE documentation says the code verifier is created and stored locally when the Auth flow is first initiated, and draws the conclusion for you: that means the code exchange must be initiated on the same browser and device where the flow was started. In a normal browser tab that is invisible. You click Google, you go to Google, Google sends you back to the same tab, the tab has the verifier, the session completes. Inside a shell it comes apart. The Google step opens in a browser context outside your app's WebView, Google redirects to the web address on your Supabase allow list, and that address opens in the phone's browser, which has no verifier, no app, and no idea what to do with the code. Magic links and password resets are the same story from an email instead of a button. Supabase's native mobile guide says as much: many Auth methods involve a redirect to your app, and it lists signup confirmation emails, magic link signins and password reset emails as the ones that carry a link.

The shape of the fix is in that same guide. Your app gets a custom URL scheme, the guide writes it as your scheme, two slashes, your hostname, and that address goes into the Additional Redirect URLs list in your Supabase auth settings. Then the flow inside the app changes so the provider opens in an in-app browser rather than kicking the user out to Safari, and the app listens for its own scheme being opened and finishes the exchange itself. In the reader's words, four steps:

Two honest notes. First, the direct-to-scheme redirect from an in-app browser is not reliable on every setup, and developers who have shipped this pattern recommend landing on an https page first that then forwards to the scheme. A developer who documented the Universal Links version of this flow also noted that some browsers, Orion and Brave among them, will not launch a native app from a link at all, so the fallback web page is not optional. Second, Lovable's managed Google login was configured against your web origin when Lovable set it up. It has no idea the shell exists. Lovable's hosting guide says managed OAuth configuration is a feature of the built-in backend, so if you are on Lovable Cloud this is the point where you find out how much of that configuration you can see and change, and if you moved to your own Supabase project it was already yours. Either way the provider console needs the new redirect, and Apple's console needs the Sign in with Apple service set up from the previous section.

What do you need to test on an iPhone and to publish on both stores?

A Mac, two paid developer accounts, twelve people who will keep an app installed for two weeks, and a build that is not the one your tutorial stopped at. None of this is hard. All of it is a surprise to someone who was told the conversion takes an afternoon.

Capacitor's environment guide is where the Mac comes from. To build iOS apps, you will need macOS, and Capacitor 8 requires a minimum of Xcode 26.0. Android is friendlier: Capacitor 8 requires a minimum of Android Studio 2025.2.1 and an Android SDK platform for API 24 or greater, and Android Studio installs the Java toolchain for you. Cloud build services exist for teams with no Mac in the building, and Capgo's own tutorial routes you through one, but signing still happens against Apple's account and Apple's rules, so the Mac is a convenience you can outsource and the account is not.

The account is the Apple Developer Program. Apple's program page lists distributing on the App Store and inviting testers with TestFlight as things membership gives you, and it is a paid annual membership. TestFlight is how you answer the how do I test my Lovable app on my iPhone question. Apple's page says you can designate up to 100 members of your team as internal testers and invite up to 10,000 external testers, and, the part that catches people, that to invite external testers you must have your first build already approved by App Review for TestFlight. Your external test is your first review. Budget for it as one.

Google Play has its own version, and it is the one founders with a personal account hit hardest. For personal developer accounts created after 13 November 2023, Google's policy says you must run a closed test for your app with a minimum of 12 testers who have been opted in continuously for at least 14 days before you can apply for production access, and when you apply, Google reviews your submission and asks about your testing process and production readiness. Twelve real people, two weeks, no shortcuts. If you announce a launch date without knowing this, you miss it.

Then push notifications, which is the native capability most Lovable apps add first to answer the 4.2 question. Capacitor's push plugin says that on iOS you must enable the Push Notifications capability in Xcode and handle the registration callbacks in the app delegate, and the device token you get back is the APNs token. On Android the plugin uses Firebase Cloud Messaging, and all that is required is your Firebase project's google-services.json file added to the app module, plus a permission request on Android 13 and later. Then you need something on the server that actually sends the notifications, which is an edge function and a table you do not have yet. None of that is in the app you exported from Lovable, and all of it is ordinary work.

Last, the two things Capacitor's own deployment pages tell you they will not walk you through. Capacitor's iOS deployment page opens by sending you to Apple's official documentation on submitting apps, and its Android page sends you to Google's launch checklist. Screenshots for every device class, a privacy policy URL, the App Privacy questionnaire, an age rating, review notes with a test account, a signed release bundle and a keystore you must never lose. Process, not code. It is where the weeks go.

When is a PWA enough, and when is it not?

More often than the vendors will admit, and Lovable's FAQ lists it first for a reason. If the store listing itself was never the requirement, this is where you stop.

A Progressive Web App is your published site with a manifest and a service worker, so a phone can install it to the Home Screen with an icon, open it full screen without browser chrome, and load cached parts of it offline. Lovable's publish documentation describes exactly that outcome, installable so users can Add to Home Screen and launch it like a native app, with offline support and a full-screen shell. No Xcode, no Mac, no developer accounts, no review, no twelve testers, no 4.2. The next deploy is the next update.

The objection used to be notifications, and on iPhones that objection expired. WebKit's announcement for iOS and iPadOS 16.4 says a web app that has been added to the Home Screen can request permission to receive push notifications, with the permission request made in response to direct user interaction, such as tapping a subscribe button, and the same release added the Badging API so the icon can show a count. If the reason you wanted an app was so you could notify people and have an icon on their phone, a PWA on a current iPhone does both.

What a PWA cannot do is be found in the App Store. On Google Play it can be listed, through a Trusted Web Activity, which Chrome's documentation describes as a way to open your Progressive Web App from your Android app, where the content rendered comes from the web and is rendered by the user's browser, with the app and site verified as coming from the same developer through Digital Asset Links. Apple has no equivalent. A PWA reaches the App Store only by being put inside a shell, at which point it is a bundled shell and everything above applies. And because a Home Screen web app renders whatever your site serves, a project on the old React and Vite stack is serving an empty shell that fills in after the JavaScript runs, which is the same rendering fact that decides whether Google can read you. That story is in our Lovable SEO guide.

So the honest test is one question. Did someone ask for a listing, or did someone ask for an app? A customer whose procurement team wants a link in the App Store, an investor who wants to see it there, a product that people will only ever find by searching a store, those need the shell. A founder who wants users to have an icon and get notified needs a manifest and a service worker, and can have it by the end of the day, and should not read the rest of this page until something changes.

When is a React Native rebuild the honest answer, and when is it being sold?

Never because a wrapper was rejected. A rejection under 4.2 is fixed by adding a capability, a rejection under 4.8 is fixed by adding a button, and neither has anything to do with which framework rendered the screen.

The rebuild pitch that ranks for these queries goes like this: Apple's guideline 4.2 explicitly targets apps that are simply a website bundled in a native shell, reviewers will reject it, so let us regenerate your project as React Native. The first clause is true and this page quoted the rule. The conclusion does not follow from it. Apple is not detecting a framework. It is opening the app and judging whether it does anything a browser tab would not, and a bundled shell with push, biometric sign-in and a phone-shaped navigation passes that judgement every day. The rebuild vendors know this. Their business depends on you not knowing it.

There is a real case for a React Native product, and pretending otherwise would be its own kind of selling. Build one when the phone product is a different product: gesture-driven interaction, long high-performance lists, offline-first data with real conflict handling, background location, deep integration with the platform, or a business where the app is the primary surface and the website is the brochure. If you can name the capability the web version lacks and it is on that list, you are building a second frontend against your existing Supabase project, and the generic guide linked above tells you how to audit the codebase before you commit to a date. If nobody can name it, the rebuild is a rebuild of what you already own, and the only thing it produces is a second codebase that drifts from the first.

And who does not need any of this. If your product is used at a desk, during working hours, with a connection, and no customer has asked for a listing, you need a better mobile layout and possibly a PWA, and you need to close this tab. A Lovable app that is not in the App Store is not an unfinished product. Most web products are not in the App Store.

That is the work we do at Geminate Solutions. We take apps built in Lovable, Bolt, v0 and Replit and get them to the point where real customers can use them, pay through them and trust them, on a phone when a phone is what the business needs, and we do not sell rebuilds. Your Lovable app stays your Lovable app, inside a shell when a shell is right. We have shipped 50+ products, run an EdTech platform at 250,000+ daily users and an exam system absorbing 10 million requests a minute, we track 30,000+ vehicles for Pixytan, and we hold Top Rated Plus on Upwork at 4.9. You own the code from the first commit. Our AI builder to production service lays out how an engagement runs, and the production checklist for Lovable apps is the hub this page hangs off.

What does the path look like, in order?

Decide, identify, build, bundle, fix sign-in, add the one native thing, test, submit. In that order, because every step before the last one is cheaper than the one after it, and the first one might be the last.

The first step is a written mobile read. Send us the repository and the URL. A senior engineer names which stack you are on, says whether a static build exists or what it takes to make one, reads the sign-in flow and the provider setup against the shell, lists every store gate that applies to your account, and tells you honestly whether you need a shell, a PWA, or nothing at all. It comes back within 48 hours and it is yours whether or not we ever speak again.

Frequently Asked Questions

Can Lovable build a mobile app?

Not a native one, and Lovable's own FAQ says so: Lovable builds web applications and does not generate React Native projects. The FAQ gives two paths to a phone. Make the published app a Progressive Web App that users add to their Home Screen, or wrap the app in a native shell with a tool like Capacitor and submit that shell to the App Store or Play Store. The Lovable mobile app you see in the store is Lovable's editor for building projects from a phone, not a way to publish yours.

Does Lovable support React Native or Expo?

No. Lovable generates React for the browser, either React and Vite for projects created before 13 May 2026 or TanStack Start with server-side rendering after it, and there is no React Native or Expo output. A React Native version of your app would be a second frontend written against the same Supabase project, sharing your data and your logic but none of your screens. Services that promise to regenerate a Lovable project as React Native are building that second product from a prompt. It is not your codebase and it does not stay in sync with it.

Can you publish a Lovable app to the App Store or Google Play?

Yes, through a native shell, and the version that passes review bundles your compiled web build inside the app rather than loading your live URL. Capacitor's own configuration reference says its remote URL option is for live-reload servers and is not intended for production, and Apple's guideline 4.2.2 names web clippings as something the App Store does not accept. Expect the store gates as well: a paid Apple Developer Program membership and a Mac with Xcode for iOS, a Sign in with Apple option beside any Google login, and on Google Play a closed test with at least 12 testers for 14 days before a personal account can publish.

Why does login work on the web but break inside the Capacitor app?

Because Supabase's PKCE flow stores the code verifier in the browser that started the sign-in and requires the exchange to finish on the same browser and device. Inside a shell, the Google or magic-link redirect lands in a browser context that is not your app's WebView, so the verifier is missing and the session never completes. The fix is a custom URL scheme for the app, added to the Supabase redirect allow list, an in-app browser for the provider step, and code that catches the returning URL and finishes the exchange. Lovable's managed Google login was configured for a web origin and does not know the shell exists.

Do you need a Mac to put a Lovable app on the App Store?

Yes. Capacitor's environment guide says building iOS apps requires macOS, and Capacitor 8 needs Xcode 26 or later. You also need a paid Apple Developer Program membership to distribute on the App Store and to use TestFlight, and an external TestFlight build goes through App Review before testers can install it. Android needs Android Studio and a Google Play developer account, which can be done from any operating system. Cloud build services exist for teams without a Mac, but signing and review still run through Apple's account and Apple's rules.