# Lovable to App Store

Lovable (and Bolt / Base44-style builders) ship **web** apps. The App Store and Play need a **native binary**. The standard path is: push to **GitHub**, wrap with **Capacitor**, sign, upload to **TestFlight** / Play testing. CapWrapp is the desk for that loop — connect the repo, add Capacitor via PR if it’s missing, preview a commit, then ship a store test build without living in Xcode. This page is the checklist. Not a promise that every wrapped SPA passes review — Guideline **4.2** still applies.

- HTML: [https://capwr.app/guides/lovable-to-app-store](https://capwr.app/guides/lovable-to-app-store)
- Landing: [https://capwr.app/lovable](https://capwr.app/lovable)
- Docs: [Built with Lovable?](https://capwr.app/docs/lovable)

## Why Lovable ≠ App Store

Lovable (and similar builders) give you a **website**: screens, auth, and a `dist` folder. Shoppers do not install a URL from the App Store. Apple and Google distribute a **signed app binary** with a bundle ID / package name, icons, and a native project.

Capacitor is the usual bridge: a small iOS and Android shell that loads your web build. Without that shell — and without signing and store upload — there is nothing for TestFlight or Play Internal testing to install.

CapWrapp does not replace Lovable. It ships **what you already pushed to GitHub**.

## The path

1. **Sync GitHub.** In Lovable, connect GitHub so the project is a real repo. CapWrapp cannot wrap a site that only lives on a Lovable URL. See [Built with Lovable?](https://capwr.app/docs/lovable).
2. **Ship a static web build.** Capacitor loads files from your web folder (usually `dist`). Vite / Lovable SPAs are fine. **SSR is a footgun**: if the app only exists when a Node server is running, the native shell will show a blank or error screen. You need a static export (SPA or prerender), not a server-only render.
3. **Add Capacitor** if it is missing — `capacitor.config`, native `ios/` / `android/` folders, app ID. CapWrapp can open that pull request; you merge it and paste the follow-up prompt into Lovable so packages and native folders finish.
4. **Signing.** Create the app record in App Store Connect and Play Console, then paste API keys in CapWrapp. CapWrapp keeps certificates and keystores off your laptop.
5. **Upload a test build.** Pick a commit, confirm, and GitHub Actions archive iOS / Android and upload to **TestFlight** and Play Internal testing. That is a test binary, not a skip of App Store review.

## The 4.2 gotcha

Apple’s Guideline **4.2 (Minimum Functionality)** is why “we wrapped the SPA” is not a store strategy by itself. If the app is just a website in a webview — no real native value, no reason to be an app — review can reject it. CapWrapp will still **build and upload**. It will not invent native features or argue 4.2 for you.

Be honest in the listing: what the app does on a phone, not only that it has a URL. For deeper reading on review patterns, see [AcceptMyApp’s guideline notes](https://acceptmy.app/guidelines).

## Where CapWrapp fits

| You / Lovable | CapWrapp |
| --- | --- |
| Product, UI, GitHub commits | Connect the repo |
| Merge PRs, paste the AI follow-up | Open a Capacitor PR if the repo is still a website |
| Apple / Google developer accounts | Store keys, signing, GitHub Actions upload |
| Native features that satisfy 4.2 | Preview a commit, listings, TestFlight / Play test builds |

Flow: **GitHub → Capacitor PR if missing → you confirm a commit → TestFlight / Play**. Docs: [How it works](https://capwr.app/docs/how-it-works) and the [Lovable product page](https://capwr.app/lovable).

## Checklist

- Lovable project synced to GitHub
- Static web build (SPA / `dist`) — not SSR-only
- Capacitor in the repo (`capacitor.config`, `ios/` and/or `android/`) on the default branch
- Apple Developer + App Store Connect app record (for iPhone)
- Play Console app record (for Android)
- CapWrapp connected to the repo, keys in Settings, shipping pipeline on
- One test commit uploaded to TestFlight and/or Play Internal
- Listing copy that describes a real app, not only a wrapped site (4.2)

## After the test build

A binary on TestFlight or Play internal testing is not a store submission. Privacy answers, screenshots, age rating, and the review button are still yours. Continue with the [App Store submission checklist](https://capwr.app/guides/app-store-submission-checklist) and the [Google Play submission checklist](https://capwr.app/guides/google-play-submission-checklist).

## FAQ

**Can Lovable publish directly to the App Store?** No. Lovable ships a web app. Apple and Google need a signed native binary — typically a Capacitor shell uploaded to TestFlight or Play testing.

**Do I need a Mac?** Not on your desk. CapWrapp starts GitHub Actions, including macOS runners, to archive and upload iOS. You still need a paid Apple Developer account.

**Will Apple reject a wrapped Lovable app?** They can. Guideline 4.2 (Minimum Functionality) still applies to wrapped SPAs. A webview of your site is not enough on its own.

**CapWrapp vs Capgo?** CapWrapp is the desk that wraps the repo if needed and ships TestFlight / Play test builds from GitHub; Capgo is live updates after a store binary already exists.