Has Lovable.dev ever published a binary directly to the App Store?

No. As of May 2026, Lovable's documentation states the platform is web-only and does not generate native iOS or Android binaries. Every Lovable app on a store has been wrapped through a separate tool such as Capacitor or Median.co. The review verdict reflects the wrapper plus its configuration, not Lovable itself. If a vendor claims to publish your Lovable app directly, that vendor is doing the wrapping step on your behalf.

Will my Lovable app be rejected just because it uses Capacitor?

Capacitor is not on any rejection list. Apple and Google both ship thousands of apps built on Capacitor or its predecessor Cordova. What matters is what the wrapped app does at runtime. A Capacitor build that loads the Lovable web URL and adds nothing else will get caught by Guideline 4.2. A Capacitor build that wires real native features (push, camera, share, offline) and respects platform privacy rules passes the same way a Swift or Kotlin app would.

Do I need a privacy policy URL for a Lovable.dev app on iOS?

Yes, in every case. Guideline 5.1.1 requires a privacy policy URL in App Store Connect metadata and an in-app link, regardless of whether the app collects data or not. The policy has to name the data collected (including data collected through any SDK in the Capacitor wrapper), name the third parties it is shared with, and describe deletion. A Lovable build without a policy URL will fail metadata review.

Does Apple block apps just because the code was AI-generated?

Not on that basis alone. App Review does not check whether code came from Lovable, Cursor, Claude Code, or a human team. It checks the binary against the App Review Guidelines. The reason AI-coded apps see higher rejection rates is the pattern behind them: WebView wrappers, hardcoded keys in the bundle, missing Purpose Strings, unused permissions, and Data Safety forms that do not match shipped SDKs. Fix those and the AI origin stops mattering.

Is Median.co's 100 percent approval claim trustworthy for Lovable apps?

It refers to the wrapper service's own track record across thousands of apps, not to a guarantee that any wrapped Lovable build will pass. Median's wrapping pipeline meets Apple's basic native-shell expectations, which covers most of what Guideline 4.2 needs, but the build still has to ship genuine native features and accurate Privacy Manifests. Treat the claim as a signal about the wrapper's quality, not a guarantee about your specific submission.

Do Lovable.dev apps pass App Store review?

If you built something with Lovable.dev and you are trying to figure out whether it can survive App Store review, the short version is that Lovable itself does not put anything on the App Store. The question is really about the native wrapper you put around the web app, the device features you add through that wrapper, and how the final binary reads to a human reviewer at three in the morning.

Short answer

Lovable.dev produces web applications, not iOS or Android binaries, according to Lovable's official documentation. To reach the App Store, the web app has to be wrapped with a native shell such as Capacitor, then signed and submitted like any other build. Whether that submission passes is decided mostly by Apple's Guideline 4.2 on Minimum Functionality, which rejects apps that are essentially repackaged websites. A wrapped Lovable build that adds genuine native features (push, camera, share, offline cache) usually passes. A bare WebView wrapper usually does not.

What you should know

Lovable.dev is web-only by design. It does not generate IPA or AAB files. The binary always comes from a wrapper layer such as Capacitor or Median.co.
Guideline 4.2 is the dominant rejection lane. Apple flags builds that read as repackaged websites with no genuine native behavior.
Capacitor is the common wrapper in this space. It bridges the Lovable web bundle to iOS and Android and exposes plugins for camera, push, storage, geolocation, and share.
Privacy Manifests still apply. A hybrid iOS app that pulls in an SDK on Apple's Required Reason API list needs a PrivacyInfo.xcprivacy entry, same as a fully native app.
OWASP MASVS treats hybrid apps as native. WebView, JavaScript bridge, and storage controls apply just as they would to a Swift or Kotlin app.
Google Play Data Safety covers everything in the wrapper. Analytics or push SDKs added at the Capacitor layer can trigger mismatches even when the Lovable web app itself collects nothing.

Does Lovable.dev actually produce iOS or Android binaries?

No. Lovable.dev is a web-only platform that generates a React or Next.js codebase deployed to a Lovable subdomain or a custom domain, as the Lovable FAQ makes explicit. There is no Lovable export option that hands you an IPA for App Store Connect or an AAB for the Google Play Console.

The path to a mobile binary is always through a second tool. The most common option in the Lovable community is Capacitor, an open-source native runtime maintained by Ionic. Capacitor takes the Lovable web bundle, drops it inside a WKWebView on iOS and an Android WebView, and exposes a plugin API for native features. Median.co is a paid alternative that does similar work as a hosted service. PWABuilder produces a Trusted Web Activity on Android and a Capacitor-style shell on iOS.

In practice, this means every Lovable app on a store is two layers: the Lovable-generated web code, and the native shell around it. App Review judges the combination, not either piece in isolation.

Why do wrapped Lovable.dev apps get rejected under Guideline 4.2?

Apple's Guideline 4.2 on Minimum Functionality is direct: an app should include features, content, and interface design that go beyond a repackaged website. If the build is not particularly useful, unique, or app-like, App Review can refuse it. Guideline 4.2.2 adds that apps should not primarily be marketing materials, web clippings, content aggregators, or a collection of links.

For Lovable builds, the typical failure pattern looks like this. A founder ships a clean Lovable web app, wraps it with Capacitor on default settings, signs the build, and submits. The reviewer opens the app, sees a WebView that loads the same pages as the Lovable URL, with no native navigation, no push permission, no share sheet, no offline behavior. The reject message references 4.2 or 4.2.2.

Hiding the URL bar or adding a splash screen does not change the verdict. The fix has to be structural. What App Review accepts is a build where two or three native features are clearly wired in: a native share extension, push notifications backed by APNs, a camera or photo flow, an offline cache, or a hardware integration. The web layer can still do most of the work. The native layer has to do something.

What native features turn a Lovable web app into something App Review will accept?

The pragmatic threshold reported by developers is two to three genuine native integrations. The exact set depends on what the app does. A short list of features that have a strong track record of clearing 4.2:

Push notifications through APNs on iOS and Firebase Cloud Messaging on Android, with a real opt-in prompt and a backend that sends meaningful pushes.
Native share using the platform share sheet rather than a navigator.share fallback inside the WebView.
Camera or photo library access with a clear in-app purpose (scanning, attaching, editing) and a correctly worded NSCameraUsageDescription Purpose String in Info.plist.
Offline mode through Capacitor's storage or filesystem plugins, so the app degrades gracefully on a flaky connection.
Geolocation when the app actually needs it, with the right Apple location authorization level and a Purpose String that matches the use case.

Adding all five is overkill for most Lovable apps. Two well-implemented features usually do the job. The mistake to avoid is sprinkling permissions in the manifest without backing them up with behavior the reviewer can trigger. Apple's automated review layer compares declared permissions against observed runtime calls, and a declared permission with no matching code path is a flag.

How do Privacy Manifests and Data Safety apply to a Lovable.dev build?

On iOS, Privacy Manifests became mandatory in May 2024 for SDKs on Apple's published list and for apps that include them. A Lovable build wrapped with Capacitor will inherit Privacy Manifest obligations from any commonly used SDK: Firebase, Sentry, Amplitude, RevenueCat, and the standard push notification plugins all carry Required Reason API usage that has to be declared in PrivacyInfo.xcprivacy.

This is the most common silent rejection for Lovable founders. The web layer collects almost nothing. The wrapper adds analytics. The submission fails the automated Privacy Manifest check at upload time and surfaces as an ITMS-91065 error in App Store Connect. The fix is to add the manifest, declare the SDK reasons, and resubmit.

On Google Play, the equivalent surface is Data Safety. The Data Safety form has to match the data the wrapped app actually collects, including data passed through analytics SDKs in the Capacitor layer. A Lovable build that declares no data collection but ships Firebase Analytics in the Android shell will eventually be flagged when Google's automated audit catches the mismatch.

Where does OWASP MASVS fit for a Lovable.dev hybrid build?

OWASP MASVS treats hybrid apps the same way it treats native apps. The compiled IPA or AAB has to satisfy the same control categories: MASVS-STORAGE for sensitive data on device, MASVS-NETWORK for transport security, MASVS-PLATFORM for IPC and WebView interaction, MASVS-CRYPTO for key handling, and MASVS-CODE for input validation.

For Lovable builds, the MASVS-PLATFORM controls deserve the most attention. WebView surfaces three risks that pure-native apps avoid: the JavaScript bridge between the web and native layers (the Capacitor plugin API in this case), the WebView cache that may persist tokens or PII, and any deep-link or custom-URL-scheme handling exposed by the native shell. MASVS-STORAGE then asks where Lovable's auth tokens live; localStorage inside a WebView is not encrypted at rest the way the iOS Keychain is.

The practical implication is that a Lovable wrapper that ships with default Capacitor settings is not automatically MASVS-aligned. Sensitive tokens belong in the Keychain or Android Keystore, not in WebView storage. Cleartext traffic should be explicitly disabled. Deep-link handlers should validate inputs server-side.

What does the realistic path from Lovable to a passing submission look like?

The end-to-end shape of a Lovable submission that clears review on the first or second attempt has six clear steps. The order matters: jumping straight to upload skips most of the work.

Step	What happens	Failure mode if skipped
1. Lovable build review	Read through the generated web app for hardcoded keys, exposed Supabase service-role tokens, and unused permissions	Secrets shipped in the bundle, flagged in static scans
2. Wrapper choice	Pick Capacitor or Median.co; configure WebView with HTTPS only and tight allowlists	Bare WebView wrapper, Guideline 4.2 rejection
3. Native feature pass	Wire at least two real device integrations (push, share, camera, offline)	Reviewer sees a website inside an app, 4.2 reject
4. Privacy artefacts	PrivacyInfo.xcprivacy on iOS, Data Safety form on Android, ATT prompt if tracking	ITMS-91065 at upload, Data Safety enforcement later
5. Pre-submission scan	Run the compiled IPA and AAB against an OWASP MASVS scanner before upload	High-risk MASVS-STORAGE or MASVS-NETWORK findings shipped to production
6. Submit and monitor	Upload through App Store Connect or the Play Console, watch for Required Reason API audit emails	Surprise compliance email weeks after launch

Step 5 is where outside automated tooling fits naturally. For builders who want a Capacitor or Median-wrapped Lovable build scanned against MASVS controls before upload, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission analysis of compiled IPA and AAB artifacts for no-code and AI-coded apps. None of the six steps is unique to Lovable. The pattern matters for any wrapped web app, but Lovable's user base skews toward non-technical builders who often skip steps 1, 4, and 5 because they did not show up during the Lovable preview.

What to watch out for

Default Capacitor config trusts a lot by default. Tighten allowedNavigation, set HTTPS-only, and review the iOS App Transport Security exceptions before submitting.
Lovable previews do not show device prompts. A permission that works in the Lovable web preview can still crash on iOS if the Purpose String is missing in Info.plist.
Supabase service-role keys are a recurring problem. Lovable templates sometimes leave a service-role key in the client bundle. That key has god-mode database access and belongs only on the server.
Median.co's "100 percent approval" claim is about their wrapper service. It does not mean every Lovable app they wrap passes; founders still have to clear 4.2 with native features.
The myth that hiding the URL bar fixes 4.2. It does not. App Review opens the binary in the simulator, watches behavior, and does not care whether the chrome is hidden.
The myth that a PWA wrapped with PWABuilder bypasses review scrutiny. PWABuilder produces a Trusted Web Activity on Android and a Capacitor-style shell on iOS; both go through normal review.

Key takeaways

Lovable.dev does not publish to the App Store on its own. The native binary always comes from a wrapper such as Capacitor, and it is the wrapper plus the configuration that determines whether App Review accepts the build.
Guideline 4.2 is the dominant rejection lane. Two or three genuine native features (push, share, camera, offline) usually shift a Lovable build from rejection to acceptance.
Privacy Manifests on iOS and Data Safety on Google Play apply to every SDK in the wrapper, not just to the Lovable-generated code. Ignoring them produces ITMS-91065 errors and later policy enforcement.
OWASP MASVS controls apply to the compiled IPA and AAB regardless of the web origin. Sensitive tokens belong in the Keychain or Android Keystore, not in WebView storage.
For builders who want an external automated read of the wrapped IPA or AAB against MASVS before submitting, PTKD.com (https://ptkd.com) is one of the platforms focused specifically on pre-submission scanning for hybrid and no-code builds.