Publish a Lovable App to the App Store

What do I need before I can submit to the App Store?

Four things must be in place before you open Xcode or App Store Connect: an Apple Developer account enrolled in the Developer Program ($99/year), a unique App ID (bundle ID) registered in the Apple Developer portal, a signed binary built from Xcode or EAS Build, and your Lovable app packaged in a Capacitor or Expo container. A web URL cannot be submitted to the App Store — the submission requires a .ipa binary file.

Apple Developer Program enrollment takes 24–48 hours to be approved after payment. Plan for this lead time — you cannot create provisioning profiles or submit to the store until enrollment is approved. Use the time to set up your Capacitor project, configure your Bundle ID, and prepare your App Store metadata.

Your Bundle ID must be globally unique in reverse-domain format (e.g. `com.yourcompany.appname`). It is registered in the Apple Developer portal under Identifiers. Once your app is live on the store, the Bundle ID cannot be changed — pick it carefully and make it specific enough to be unique.

How do I create a signed iOS binary from a Lovable project?

Signing an iOS binary for App Store distribution requires a Distribution Certificate and a Distribution Provisioning Profile, both issued by the Apple Developer portal. Xcode can manage these automatically if you enable 'Automatically manage signing' — the recommended approach for most teams. If you use EAS Build, the signing configuration is handled through the EAS CLI after connecting your Apple Developer account.

1. In the Apple Developer portal, create an App ID under Identifiers matching your bundle ID.
2. In Xcode → project settings → Signing & Capabilities, enable 'Automatically manage signing' and select your development team.
3. Ensure your app version and build number are set in Xcode: version (e.g. 1.0.0) and build number (e.g. 1) must both be set before archiving.
4. Select 'Any iOS Device (arm64)' as the destination — not a simulator.
5. Go to Product → Archive. Xcode builds and archives the release binary.
6. In the Organizer window that opens, select your archive and click 'Distribute App'.
7. Choose 'App Store Connect' as the distribution method and follow the upload wizard.
8. Wait for the binary to appear in App Store Connect under TestFlight — typically 15–30 minutes after upload.

What App Store Connect metadata do I need to prepare?

App Store Connect requires a substantial set of metadata before you can submit for review. Missing any required field blocks submission. Prepare all metadata before your binary is ready so you can submit immediately once the binary is processed — the review queue starts only after submission, not binary upload.

Required metadata: App Name (30 characters max — distinct from your title), Subtitle (30 characters max, optional), Description (4000 characters max), Keywords (100 characters total, comma-separated), Support URL, Marketing URL (optional), Privacy Policy URL (required), copyright string, and age rating questionnaire.

Screenshots are required at specific resolutions and cannot be skipped. Apple requires screenshots for the 6.7-inch display (iPhone 15 Pro Max size), and strongly recommends 5.5-inch (iPhone 8 Plus) screenshots as a fallback for older devices. Screenshots can be taken from the iOS Simulator (Product → Screenshot in Xcode) or Capacitor on a real device. All screenshots must reflect the actual app — no mockups with content the app does not contain.

What app-review guidelines must a Lovable app comply with?

Apple's App Store Review Guidelines are the rulebook for every submission. For a Lovable app wrapped in Capacitor or rebuilt in Expo, three guidelines carry the highest rejection risk: Guideline 4.2 (Minimum Functionality), Guideline 5.1.2 (Data Collection), and Guideline 2.5.6 (Apps using WebViews). Understand all three before submitting — a rejection resets your review queue position.

Guideline 4.2 (Minimum Functionality): Your app must offer meaningful functionality beyond a mobile website. A bare Capacitor wrapper with no native features is the most-rejected pattern. Integrate at least one native capability — push notifications, camera access, or offline mode — before submitting. Native APIs signal to reviewers that the app offers genuine value as an installed app.

Guideline 5.1.2 (Data Collection): If your app collects any personal data — including Supabase Auth user records, analytics, or usage telemetry — your Privacy Policy must accurately describe what is collected and how it is used. Apple will ask during submission which data types your app collects. The answers must match your Privacy Policy.

Guideline 2.5.6: Apps that download and execute JavaScript at runtime are prohibited. All JavaScript must be bundled locally in the binary. Verify that your Lovable app does not dynamically load scripts from external CDNs — if it does, inline those scripts or remove them before submitting.

Which guideline actually rejects a wrapped Lovable app?

Four clauses in Apple's guidelines do the rejecting, and they sit next to each other in section 4.2. Google Play's equivalent is far narrower — it has no template or generator clause at all. Reading both texts before you submit is cheaper than a rejection cycle, because each clause tells you exactly which change clears it.

The clause worth reading twice is 4.2.6, because its own wording contains the escape. It rejects apps built from a commercialized template or app generation service "unless they are submitted directly by the provider of the app's content" — so the exposure is not that a tool generated your code, it is that somebody else ships your app under their account. A founder submitting their own product from their own Apple Developer account is the case the clause carves out.

Google Play's version is materially weaker, and that asymmetry is the practical planning fact: Play's policy talks about limited functionality and broken functionality, and says nothing about how the app was generated. The bar it does enforce is that the app installs, loads and responds — which is why a wrapper that white-screens on a reviewer's device fails Play even when it would have passed on content grounds.

How do I submit to Google Play alongside the App Store?

Google Play submission is generally faster and less strict than the App Store. You need a Google Play developer account ($25 one-time fee), an Android App Bundle (.aab) built from Android Studio or EAS Build, and Play Store metadata including screenshots, description, and a content rating questionnaire. Google Play's review takes 1–7 days for first submissions and is typically 1–3 days for updates.

1. Create a Google Play developer account at play.google.com/console.
2. Build a signed Android App Bundle (.aab) from Android Studio: Build → Generate Signed Bundle/APK → Android App Bundle.
3. Create your keystore file when prompted — store it securely. The keystore is required for every future update to the same app and cannot be recovered if lost.
4. In Google Play Console, create a new app and complete the app setup checklist.
5. Upload the .aab to the Production release track.
6. Complete the content rating questionnaire, privacy policy, data safety form, and store listing (title, description, screenshots).
7. Google requires at least two screenshots for the phone form factor. Screenshots for 7-inch and 10-inch tablets are optional but recommended.
8. Submit for review.

Why can't a new Google Play account publish to production yet?

A new Google Play developer account cannot publish to production at all until it has run a closed test. Google requires personal accounts created after 13 November 2023 to hold at least 12 testers opted in for 14 continuous days, then apply for production access and answer questions about that test. Plan two weeks before your Play launch date.

The 14 days have to be consecutive for each tester. Google's own FAQ is explicit that it does not count "testers who opted in, tested for less than 14 days, and then opted out" — even if they opt back in and reach 14 days in total, the days must be consecutive to count toward the 12-tester criterion. Recruiting 12 people on day 10 restarts the clock rather than shortening it.

Production and Pre-registration stay disabled in Play Console until the application is approved, and Google states the review of that application "usually takes 7 days or less, but may occasionally take longer." This is the single most common reason a Lovable founder's Android launch slips: the Apple side is a review queue measured in days, and the Play side, for a brand-new personal account, is a testing requirement measured in weeks.

How do I test the app before submitting?

Apple's TestFlight allows beta distribution to up to 10,000 external testers before your public App Store release. Submitting to TestFlight uses the same binary upload path as App Store submission but has a lighter review process (typically 1 day for TestFlight review vs 1–3 for App Store). Testing on TestFlight before public submission gives you real-device feedback and catches issues the Simulator misses.

1. After uploading your binary to App Store Connect, go to TestFlight and enable your build for external testing.
2. Add tester email addresses or create a public TestFlight link for broader beta access.
3. Request external testing review — Apple requires a brief review of TestFlight builds before external testers can access them.
4. Test every major flow on real devices: auth sign-in, core feature usage, push notification receipt, deep link handling, and app re-launch from background.
5. Fix any crashes found in TestFlight. Download crash logs from Xcode → Organizer → Crashes or from App Store Connect.
6. Once the TestFlight build is stable across real devices, submit the same build (or a new incremented build number) for App Store review.