Lovable app to the App Store and Google Play

As of 2 October 2026, Lovable builds web apps, not native mobile apps, so you cannot publish to the App Store or Google Play from Lovable itself. Lovable's own FAQ names two routes: turn the published app into a Progressive Web App that people add to their home screen, or wrap it with a tool like Capacitor and submit the wrapped app to the stores. A wrapper is what lets you submit. Getting through Apple's review, and keeping two store apps in step with a web app you still change every day, is the real work.

This guide compares the four routes, sets out the Apple and Google rules that trip up wrapped web apps, and walks through what a Capacitor release involves at founder level. Every platform fact comes from Apple, Google, Capacitor, Lovable or WebKit documentation, listed under Sources at the end.

Can you publish a Lovable app to the App Store?

Yes, but not directly. Lovable's FAQ says it does not generate React Native projects. Our guide to Lovable's limitations covers this and the other things Lovable cannot do. What it produces is a web app, and a web app reaches the stores only inside a native shell: a small iOS or Android project that opens your app in a web view and adds access to the phone, such as push notifications.

So the question is not whether, but which route, who owns the native projects, and whether Apple will accept the result. There are four realistic routes.

Which route should you choose: PWA, Capacitor, a wrapper service or a native rebuild?

A PWA is the cheapest first step. On iPhone it has improved: WebKit added web push notifications in iOS 16.4 for web apps that people have added to the Home Screen. People still have to find your site and choose Add to Home Screen first, and there is no store listing to search.

Capacitor is the tool Lovable's FAQ names as an example, and the one we would choose for most Lovable products that need to be in the stores. It keeps one codebase for web and mobile, and the native projects live in your repository, so you own them. The cost is that someone must maintain them.

A native rebuild only makes sense when the phone is the product. It adds a second codebase to maintain, and every feature you prompt in Lovable then has to be rebuilt by hand.

Whichever route you pick, submit the app under your own developer account. Apple's guideline 4.2.6 says apps created from a commercialized template or app generation service will be rejected unless the provider of the app's content submits them.

Will Apple reject a wrapped web app?

It can, and this is the rule a wrapped web app has to answer first. Apple's App Review Guidelines say an app should include features, content and UI that elevate it beyond a repackaged website (guideline 4.2, minimum functionality). Guideline 4.2.2 adds that apps should not primarily be web clippings or a collection of links. A wrapper that only shows your website in a frame is exactly what these rules are about.

Give the app reasons to exist beyond the browser. Push notifications, sign-in that remembers the user, camera or file access, offline screens and deep links from email all count as app-like. Make sure the layout fits the phone, with no browser-style menus or links that open your marketing site.

Four more rules are worth checking before you submit:

• Sign-in options (guideline 4.8). If users can sign in with Google or another third-party login, Apple requires an equivalent option that limits data to name and email, lets users keep their email private and does not collect their activity for advertising without consent. Sign in with Apple asks only for name and email, offers Hide My Email and, Apple says, does not track or profile users. Apps that use only their own sign-in system are exempt. Our guide to authentication and user roles in Lovable covers how sign-in is set up.
• Payments (guideline 3.1). If the app unlocks features or content, such as a subscription or premium access, guideline 3.1.1 requires in-app purchase. On the United States storefront, the guidelines also allow buttons and links that send users to buy on your website; in other storefronts that needs a special entitlement or is not allowed. Under 3.1.3(b), access bought on your website can be used in the app, provided the same items are also sold as in-app purchases. Physical goods and services used outside the app must use other methods, such as Apple Pay or card entry (3.1.3(e)). Our Lovable Stripe integration guide explains how a web checkout works.
• Account deletion (guideline 5.1.1(v)). If users can create an account in the app, they must be able to delete it in the app too.
• Completeness (guideline 2.1). Apple wants a final version, tested on a device, with working URLs, no placeholder content, and demo account details if the app has a login, with your backend switched on.

There is one more rule that affects how you ship updates. Guideline 2.5.2 says apps may not download or execute code that introduces or changes features or functionality. Pointing the app at your live website and changing features there sits close to that line. That is one reason Capacitor bundles your web code into each release.

What does Google Play require?

Google Play adds a testing step for new developers before they can publish. As of 2 October 2026, Google says personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers who have been opted in continuously for 14 days before applying for production access. Plan those two weeks into your launch date.

Registration costs a one-time US$25. Apple's Developer Program costs US$99 a year. To publish under your company's name on Apple, the company must be a legal entity with a D-U-N-S number, a work email on its own domain and a public website, and the person enrolling must be able to sign for it. Enroll as the company from the start: Apple shows the organization's legal name as the seller, or your personal legal name if you enroll as an individual.

How does a Capacitor release work?

You do not need to run these steps yourself, but you should know what they involve, because each one is a place where a release can stall. Capacitor's documentation, for version 8, sets them out:

1. 01Get the code out of LovableSync the project to GitHub so engineers can add the native projects next to your web code. The sync runs both ways: changes pushed to the connected branch flow back into Lovable, so you can keep prompting.
2. 02Add CapacitorInstall Capacitor's core and command-line packages, run its init step with your app name and package ID, and point it at the folder your build writes to. The app's index.html needs a head tag for Capacitor's plugins to work.
3. 03Create the native projectsAdd the iOS and Android platforms. This creates an Xcode project and an Android Studio project inside your repository.
4. 04Build and syncBuild the web app, then sync it into both native projects. Every web change needs a fresh build and sync before it reaches a phone.
5. 05Add native featuresPush notifications use Apple's push service on iOS and Firebase Cloud Messaging on Android, each with its own setup. On Android 13 and later, the app must ask the user's permission before it can receive them.
6. 06Sign and submitiOS builds need a Mac: Capacitor 8 requires Xcode 26.0 or later, and Android Studio 2025.2.1 or later. Each store build is signed, uploaded, reviewed and released separately.

Capacitor also has a setting that loads your live website inside the app. Its documentation says this is meant for live-reload during development and is not intended for production. Ship the bundled build.

How do push notifications, deep links and offline work?

Push notifications need a server that knows each user's device and sends through Apple and Google. That means storing device tokens against users, removing them when a user signs out, and keeping the sending keys on the server, never in the app.

Deep links open a link from an email straight to the right screen in the app. On iOS these are Universal Links, which need a file called apple-app-site-association on your website. On Android they are App Links, which need assetlinks.json. Both sit in the .well-known folder of your domain and must be served over HTTPS. The files prove that your app may open your links. If the app is not installed, the link opens your website instead.

Offline is easy to forget. A wrapped app that shows a blank screen with no signal looks broken to a reviewer and to users. At minimum, show a clear offline screen and retry when the connection returns.

How do you keep the web app and the store apps in sync?

This is the cost that lasts. Your web app can change many times a day. A store app changes only when a new build passes review. Three practices keep them in step:

• One repository and one pipeline. The same commit builds the web app and both store apps, and automated tests run before any of them ship. Our glossary entry on CI/CD explains the idea.
• A backend that works with older app versions. Not every user updates straight away, so database and API changes must not break the version they have.
• A minimum-version check. When an old version must stop working, the app should ask the user to update rather than fail.

Bell, an AI email assistant for Gmail that its founder designed in Lovable, shares its code this way: its web app and its Capacitor mobile shells sit over 6 shared packages. Bell is pre-launch and running on staging; the details are on the Bell case study. The production steps that apply before any store release, from access rules to monitoring, are in our guide to taking a Lovable app to production.

Starter costs $2,999 a month paid annually or $3,999 month to month, and Growth is custom; both are on our pricing page. To see where your app stands first, take the free production-readiness check: 19 questions, a score out of 100 and your three biggest risks.

Sources

Each platform fact above comes from one of these pages, checked on 2 October 2026.

• Lovable documentation: FAQ, mobile apps (docs.lovable.dev/introduction/faq); Sync your Lovable project with GitHub, two-way sync (docs.lovable.dev/integrations/github).
• Apple: App Review Guidelines, sections 2.1, 2.5.2, 3.1.1, 3.1.1(a), 3.1.3, 3.1.3(b), 3.1.3(e), 4.2, 4.2.2, 4.2.6, 4.8 and 5.1.1(v) (developer.apple.com/app-store/review/guidelines).
• Apple: Apple Developer Program enrollment (developer.apple.com/support/enrollment).
• Apple Support: What is Sign in with Apple?, published 4 May 2026 (support.apple.com/en-us/102609).
• Google Play Console Help: App testing requirements for new personal developer accounts (support.google.com/googleplay/android-developer/answer/14151465).
• Google Play Console Help: Get started with Play Console, registration fee (support.google.com/googleplay/android-developer/answer/6112435).
• Capacitor documentation: Installing Capacitor (capacitorjs.com/docs/getting-started); Environment setup (capacitorjs.com/docs/getting-started/environment-setup); Configuration, server.url (capacitorjs.com/docs/config); Push Notifications (capacitorjs.com/docs/apis/push-notifications); Deep links (capacitorjs.com/docs/guides/deep-links).
• WebKit blog: Web Push for Web Apps on iOS and iPadOS, 16 February 2023 (webkit.org/blog/13878).
• Case-study facts: our Bell case study, as published on this site.