Lovable · App Store · Google Play · TestFlight
Publish your Lovable app to the App Store and Google Play
Apple and Google only accept signed native binaries — not URLs. AppNative turns your Lovable repo into a signed .ipa and .aab, registers the bundle ID, generates certificates and provisioning, uploads to TestFlight and Google Play, and writes your store listing, screenshots and privacy answers along the way.
How do you publish a Lovable app to the App Store?
Connect the GitHub repo Lovable syncs to, set a bundle ID, icon and splash, enable the native features your app needs, and press Build. AppNative registers the App Store Connect app record, generates signing certificates and provisioning profiles, compiles a signed .ipa on hosted macOS CI, uploads it to TestFlight, and produces the Google Play .aab from the same project — no Xcode or Android Studio.
- What Apple accepts
- A signed .ipa uploaded to App Store Connect — never a website URL
- What Google accepts
- A signed Android App Bundle (.aab)
- Accounts you need
- Apple Developer ($99/yr) and Google Play ($25 one-time), in your name
- Signing
- Certificates, provisioning profiles and keystore generated and stored for you
- First TestFlight build
- Usually under an hour from connecting the repo
- Biggest rejection risk
- Guideline 4.2 minimum functionality — solved with native capabilities
How to turn a Lovable app into a native mobile app, step by step
Six steps, one codebase, no native development. Each step happens inside AppNative except the first.
- 1
Connect your Lovable GitHub repo
Lovable syncs your React + Vite source to GitHub. Authorize AppNative and pick that repo and branch — it becomes the source of truth for every build.
- 2
Register the bundle ID and app record
Add your Apple API keys once. AppNative creates the Bundle ID in the Developer Portal, enables the capabilities your app uses, and creates the App Store Connect app record with your name, category and locale.
- 3
Generate signing assets
AppNative creates the distribution certificate, provisioning profiles (including widget and notification extensions) and the Android keystore, and keeps them so future builds stay consistent.
- 4
Add native features so you pass review
Turn on push notifications, Face ID, widgets, Live Activities, in-app purchases or Wallet passes. This is what separates an approved app from a 4.2 rejection.
- 5
Build, TestFlight, then submit
Builds run on hosted macOS and Linux CI. The .ipa uploads to TestFlight automatically; the .aab goes to your chosen Google Play track. Generate metadata, keywords and device screenshots in AppNative, then submit for review.
Native capabilities your Lovable app gains
These are real native implementations compiled into the binary — not browser fallbacks — and they're what moves an app past Apple's "minimum functionality" bar.
- Signed .ipa and .aab from your Lovable repo with zero local tooling
- Automatic Bundle ID, App Store Connect record and capability registration
- Certificate, provisioning profile and keystore generation and storage
- TestFlight upload, internal testers and beta review submission
- Google Play upload to internal, closed or production tracks
- AI-written store metadata, keywords, descriptions and release notes
- Correctly sized icons and device screenshots (alpha stripped for Apple)
- Native capabilities that satisfy guideline 4.2 minimum functionality
Lovable to mobile: the alternatives, compared
Why Apple rejects wrapped web apps — and how to avoid it
Guideline 4.2 rejects apps that are just a repackaged website. The reliable fix is real device functionality: push notifications, biometric unlock, home-screen widgets, Live Activities, camera or offline support. AppNative compiles those as native code into your binary, so reviewers see an app, not a bookmark.
AppNative vs Median.co and Despia for store submission
Most wrappers hand you a binary and leave signing, store records and metadata to you. AppNative automates the Apple side end-to-end — bundle IDs, certificates, profiles, TestFlight, screenshots, metadata — and adds native extensions those wrappers can't ship.
Publishing vs rebuilding in React Native
Porting a Lovable app to React Native means a second codebase and months of work before you can even submit. Wrapping ships the same app you already have, this week, and web updates keep deploying instantly afterwards.
Lovable to mobile app: every question, answered
The exact questions people ask before shipping a Lovable project to the App Store and Google Play.
Can you submit a Lovable app to the App Store directly?
No. Apple only accepts a signed native .ipa, and Lovable produces a web app. AppNative builds and signs that .ipa from your Lovable repo and uploads it to TestFlight and App Store Connect.
Do I need a Mac or Xcode?
No. Builds run on hosted macOS CI. You never install Xcode, Android Studio or a certificate manually.
How long does review take?
Apple review is typically 24–48 hours once you submit; Google Play is often faster for the first release. Getting to TestFlight with AppNative usually takes under an hour.
What if my app is rejected under 4.2?
Enable more native capabilities — push, widgets, Live Activities, Face ID, offline — rebuild and reply to review noting the native functionality. AppNative also ships a rejection-rescue playbook.
Do web updates require a new App Store submission?
No. Content and UI changes deploy on the web instantly. You only rebuild when you change native features, icons, versions or capabilities.
Web app to mobile app: key terms defined
- Native app wrapper
- A native app wrapper is a compiled iOS or Android application that renders your existing web app inside a native web view (WKWebView on iOS, WebView on Android) while exposing real device capabilities — push notifications, biometrics, camera, in-app purchases — to that web code through a JavaScript bridge.
- Hybrid app
- A hybrid app ships web technologies (HTML, CSS, JavaScript) inside a native binary that can be distributed through the App Store and Google Play. It differs from a progressive web app, which is installed from the browser and cannot be listed in either store.
- App Store guideline 4.2 (minimum functionality)
- Apple's rule that an app must do more than repackage a website. Apps that add native capability — push notifications, biometric login, camera use, offline support, widgets, in-app purchases — satisfy it; a bare website in a shell does not.
- Bundle ID / package name
- The permanent reverse-domain identifier for your app (for example com.yourcompany.yourapp). It's registered once with Apple and Google and can never be changed for a published app, so it must be decided before your first submission.
- Code signing and provisioning profile
- Apple requires every binary to be signed with a distribution certificate and matched to a provisioning profile tied to your bundle ID and team. Android requires an upload keystore. Without them a build cannot be installed or submitted.
- TestFlight
- Apple's beta distribution service. Uploading a signed build to TestFlight lets up to 100 internal testers install the app immediately, before public App Store review — the fastest way to see your wrapped app on a real device.
- Over-the-air update
- Because a wrapper renders your live web app, deploying your web app updates the mobile experience instantly with no store review. A new native build is only required when something inside the binary changes: icon, splash screen, bundle ID or a native capability.
- StoreKit and Google Play Billing
- The in-app purchase systems Apple and Google require for selling digital goods inside an app. Stripe stays valid on the web, so most apps run both and grant the same entitlement from either payment source.
Lovable to mobile app: frequently asked questions
Can I publish a Lovable app to Google Play?
Yes. AppNative produces a signed Android App Bundle from the same project and uploads it to your Play Console track, with the keystore stored so future updates keep the same signing key.
Who owns the app on Apple and Google?
You do. The app lives in your Apple Developer and Google Play accounts; AppNative only automates builds and uploads with the keys you provide.
Can AppNative write my store listing?
Yes. It generates the title, subtitle, keyword field, description, promotional text and release notes, and resizes screenshots to Apple's and Google's exact device dimensions.
What about privacy questionnaires and permissions?
AppNative generates the usage-description strings for camera, microphone, location, Face ID and notifications, and tells you which App Privacy answers correspond to the features you enabled.
Can I migrate an app already on the stores?
Yes. Upload your existing Android keystore and reuse your Apple bundle ID so updates ship to the same listing and existing users update in place.
Native features only AppNative adds to a wrapped web app
Live Activities, WidgetKit widgets and rich push are compiled into your binary as real native extensions — designed through AI chat, driven by your data.
Ship from your AI app builder
Submission goes smoothest when your Lovable app ships real native features. See what AppNative can add, or read the full Lovable → native app guide.
Deep dives by builder and feature
Step-by-step guides for the specific thing you're trying to ship — push, in-app purchases, widgets, store submission — for Lovable and Base44 apps, plus how AppNative compares to Median.co and Despia.
Ship your Lovable app to the App Store and Google Play
Connect your repo, toggle the native features you need, press Build. Your first TestFlight build can be in testers' hands today — and your Lovable workflow doesn't change at all.