Lovable App to APK: Ship Your Lovable App on Android (2026)

You built something real in Lovable. It runs at yourapp.lovable.app, it talks to Supabase, people can use it in a browser. Then someone asks “can I install it?” and you go looking for the Download APK button that doesn't exist. If you followed a Capacitor tutorial from there, you probably got about this far:

That error is the Android toolchain telling you it isn't installed. Fixing it means Android Studio, an SDK, a JDK, Gradle, and eventually a signing keystore — a full native development environment for a project you built by describing it in English. There are two honest ways from a Lovable app to an installable APK. Here's which one fits your situation.

Why Lovable doesn't give you an APK

Lovable generates a web application: React, Vite, Tailwind, usually Supabase for auth and data. A good stack — but not an Android project. An APK is a compiled, signed native package, and nothing in Lovable's output contains an android/ folder, a Gradle build, or a keystore. To get on a phone's home screen, your web app needs a native shell around it, and a toolchain to compile and sign that shell. There are exactly two ways to get one.

Route 1: wrap your deployed URL (most people want this)

Your Lovable app is already deployed and live. The shortest path to Android is to wrap that URL in a native WebView shell — a real Android application that renders your live app full-screen, with the native pieces a browser tab can't give you. You paste the URL, and the build produces:

• A signed Preview APK for compatible Android devices; a paid offer is required for Release APK/AAB delivery. Preserve the accepted signing identity when updating an existing app.
• Your icon and a native splash screen — upload one 512×512 PNG and every density variant is generated. No logo yet? A clean monogram icon is generated from your app name.
• An optional Android OneSignal integration; configure the provider and permissions, then test delivery on a real device.
• Native handling for the details: hardware back button following your app's history, pull-to-refresh, an offline screen, mailto: and tel: links opening native apps.

Build time depends on queue and dependencies. The wrapper loads your live site, so published web changes follow your deployment and cache behavior. Native-shell changes need a rebuild, and all updates remain subject to store policies.

Route 2: you exported the code

Lovable can push your project to GitHub, and some people add a native layer to that export themselves (or have their AI assistant do it). Precision matters here: a raw Lovable export is not a buildable Android project. It's the same React web app as source code. Uploading it to any build service, ours included, won't produce an APK — there's nothing Android in it to compile.

A Capacitor project — one where you ran Capacitor's cap add android locally or asked your AI tool to add it — is not a live source lane here yet: Capacitor source builds are on our waitlist, so today you would build it locally. Our pipeline compiles Flutter and native Gradle projects on machines with the SDK, JDK, and Gradle available. The source lane requires Builder or Pro and spends bundled credits; Builder allows 20 Android source builds per calendar month. Managed toolchain handling is not a promise to repair invalid source or dependencies. Restore the accepted signing key for an existing published app rather than replacing a missing key merely to make compilation pass.

Read the actual build log and any recognized failure classification. Platform/ network faults refund credits actually charged; customer compile errors do not. An unknown failure may still need investigation, and a successful compile does not prove that the installed app works.

Which route fits you

The do-it-yourself path, honestly

You can absolutely do this locally for free, and if you want to learn the Android toolchain it's a fine weekend project. The real steps:

1. Export and build the web app. Push from Lovable to GitHub, clone it, then npm install && npm run build to produce the dist/ folder.
2. Add Capacitor. npm i @capacitor/core @capacitor/cli @capacitor/android, then npx cap init (set webDir to dist) and npx cap add android.
3. Install the toolchain. Android Studio plus the SDK and a JDK — plan for roughly 10 GB of disk and the first-run SDK download. This is where the SDK location not found error from the top of this post goes away.
4. Create a signing key. keytool -genkey -v -keystore upload.jks -keyalg RSA -validity 10000, then wire it into android/app/build.gradle as a signing config. Back it up; Play App Signing has a separate upload-key reset process if applicable, but a new unrelated key is not an automatic replacement.
5. Build. npx cap sync android, then cd android && ./gradlew bundleRelease for a Play Store AAB, or assembleRelease for an APK.
6. Repeat for every code change. A Capacitor app bundles your web assets, so each Lovable edit means export, rebuild, and re-sign again.

Budget an afternoon the first time if everything goes well; longer if Gradle versions disagree with each other, which in AI-generated projects they often do.

If Google Play is the goal

Two things matter beyond “having an APK.” First, Play requires the AAB format — both routes above produce one. Second, signing continuity: every update you publish must use the listing's accepted upload key, unless you complete Google's applicable upload-key reset process. APK update installation also depends on package ID, app-signing identity and increasing version code; a stable build key alone is not a guarantee. Choose your package ID (like com.yourapp.mobile) carefully — it's permanent once published. Expect Google's $25 one-time developer fee, and note that new personal accounts must run a closed test with real testers before a production release.

Honest limits

• The app is your web app. If your Lovable project is slow or awkward on a phone browser, wrapping it won't fix that. Fix it in Lovable first.
• Test authentication. Exercise email/password, recovery, magic links and OAuth on the installed app. A session created in an external browser does not automatically exist in the WebView.
• iOS has separate requirements. Eligible App, Builder and Pro customers can request an unsigned IPA. Optional cloud signing requires active Pro and matching certificate/profile inputs. A Web Clip is a separate home-screen shortcut, not an IPA. See iOS setup; submission and approval are separate.

FAQ