How do I get my AI-built app into the App Store?
A web app built with Lovable, Bolt or Replit does not go into the App Store as it is. It needs a native shell such as Capacitor or Expo, a paid Apple developer account, a Mac or a cloud build service, and changes to logins and payments to meet Apple's rules. Then it goes through App Review, which checks a specific list, and most AI-built apps fail on the same few items the first time.
The items are predictable. The app must do more than show your website. If it creates accounts, it must delete them. Subscriptions and unlocked features must go through Apple's in-app purchase. A Google or Facebook login needs Sign in with Apple beside it. The privacy answers must match what the app really sends, including to the AI provider. We have taken our own native apps through App Review; the list below is what reviewers look at first.
Google Play is a separate process with its own billing rule and, for a new personal account, a required closed test with twelve testers over fourteen days before you can publish.
In founders’ words
“Lovable's Apple and Google auth implementation is clunky - it directs to lovable owned screen where it asked for additional permission from user, and my app got rejected by Apple because of this.”
“I read a wrapped app could likely get rejected. Is this true? Is the rebuild worth my time? A non-negotiable is launching a mobile app.”
“You can't just use Stripe on iOS. Apple requires in-app purchases for digital goods.”
“I have a fully built app ready in Lovable, and I'm looking for someone experienced who can help me get it published on the Google Play Store.”
From a web app to something you can submit
Three routes. Capacitor wraps your existing web app in a native shell and lets you add native features through plugins, which is the usual path for a Lovable or Bolt app. Expo rebuilds the app in React Native, which is more work and feels more native. Wrapper services do the Capacitor step for you, for a fee.
Whichever you pick, connect the project to GitHub first so the code exists outside the builder, and use the web version on a phone for a full day. Anything awkward at phone size will be awkward in the app.
- An Apple Developer Program membership, paid yearly.
- A Mac with Xcode, or a cloud build service that produces the build for you.
- An icon, screenshots for each device size that show the app in use, a privacy policy page, and a support page.
- A demo account for the reviewer, with the backend switched on, and review notes that describe every feature.
Where AI-built apps fail review
- 4.2 Minimum functionality. The app must include "features, content, and UI that elevate it beyond a repackaged website". A shell that shows your site fails on sight. Add things that only make sense as an app: the phone's camera, push notifications, a working offline state, native navigation.
- 2.1 Completeness. No crashes, placeholder text or dead links. If there is a login, the reviewer needs a demo account that works.
- 5.1.1 Privacy. A privacy policy link in the listing and inside the app. The App Privacy answers must match what the app and its libraries really send, including to the AI provider. Guideline 5.1.2 adds that sharing personal data "with third-party AI" must be disclosed and permitted.
- 5.1.1(v) Account deletion. If the app creates accounts, it must delete them inside the app. A support email does not count. If the app does not need an account, let people use it without one.
- 3.1.1 In-app purchase. Subscriptions and unlocked features must use Apple's in-app purchase. A Stripe checkout inside the app for those will be rejected.
Logins, payments and user posts
Logins. Under guideline 4.8, if you offer Google, Facebook or another third-party login, you must also offer one that limits data to name and email and lets people hide their email. Sign in with Apple meets that.
Payments. Your web app takes payment through Stripe. Your iOS app takes payment through Apple, usually through StoreKit or RevenueCat. Both write to the same subscription record on your server, and the server is what the app checks before unlocking anything. Apple allows a web subscriber to use the app as long as the same item can also be bought in the app. For physical goods and services used outside the app, guideline 3.1.3(e) says the opposite: do not use in-app purchase. Decide which side of that line you are on before you build the paywall.
User posts. Under guideline 1.2, if people can post, you need a filter for objectionable content, a report button, a block option and published contact details.
Google Play
- Subscriptions and unlocked features inside the app go through Google Play Billing. A free trial is an offer configured on the subscription in Play Console, and the app should check subscription status on your server.
- A personal developer account created after November 13, 2023 must run a closed test with at least twelve testers opted in continuously for fourteen days before it can apply for production access. Start that clock as soon as you have a build.
- Back up the upload key. Losing it means a reset request to Google before you can ship another update.
- The Data safety form in Play Console works like Apple's privacy answers: it must match what the app sends.
Before you submit
Run through the list once as a stranger: install the build on a real phone, create an account, buy the subscription in the sandbox, use every feature, delete the account. Then write the review notes as if the reviewer has never seen your product, because they have not.
Expect at least one rejection. The reply names the guideline and usually the screen. Fix that item, reply in the Resolution Center, and resubmit. Each round adds a day or more, so the checklist above is worth doing before the first submission rather than after the first rejection.
If the app is for you or your own team and you do not plan to charge in it, you may not need help. If subscriptions, logins and the privacy answers all have to be right on the first try because customers are waiting, that is the point where a second pair of eyes saves a week.
| Guideline | In plain words | Have ready |
|---|---|---|
| 4.2 | More than your website in a shell | Camera, notifications, offline state, native navigation |
| 2.1 | Nothing broken, nothing placeholder | A demo login, backend on, every link working |
| 5.1.1 | Privacy policy, and answers that match reality | Policy link in app and listing; list every library and the AI provider |
| 5.1.1(v) | Delete account inside the app | A button that really deletes, with a confirmation |
| 3.1.1 | Digital goods through Apple | In-app purchase for subscriptions; Stripe only on the web |
| 4.8 | A private login beside social logins | Sign in with Apple wired and tested |
| 1.2 | Rules for user posts | Filter, report, block, contact details |
Questions
Can I publish a Lovable app to the App Store?
Yes, but not from inside Lovable. Lovable's docs say there is no built-in flow that packages and submits a project to the App Store; the options are a web app people add to their home screen, or a Capacitor shell built outside Lovable around your published app, submitted through App Store Connect. To pass review, that shell needs native features, not only your website.
Can a Bolt app go on the App Store?
Yes, if it was built as a mobile app. Bolt builds mobile apps with Expo and submits iOS builds to TestFlight and the App Store through Expo's build service. Bolt's docs warn that projects created for the web do not easily switch over to mobile, so a Bolt web app usually needs a mobile version built for it.
Can a Replit app go on the App Store?
Yes. Replit builds mobile apps with Expo, and its Launch feature creates the iOS build, signs it and uploads it to App Store Connect. You still need your own Apple developer account, and the App Review rules above apply in full.
Can a Base44 app go on the App Store?
Yes. Base44 generates store files (on the Builder plan or higher) for an app that runs your published Base44 app inside a web view, so content changes show up without a new submission. Because it is a web view, guideline 4.2 is the main risk, and Base44's own docs warn that an app using Stripe for digital content is rejected.
Will a Capacitor app be rejected for being a wrapper?
Not for being Capacitor. It is rejected under 4.2 when it is only a website in a shell. Native camera, notifications, an offline state and native navigation are what move it past that line.
Do I need a Mac?
Building and signing an iOS app needs Xcode, which runs only on macOS. A cloud build service can do that step if you do not have a Mac.
My app lets users generate or run code. Anything special?
Yes. Guideline 2.5.2 says apps may not download or run code that changes their own features. Apps whose purpose is generating and running code have been rejected on that basis. Talk it through before you build the iOS version.
How do I offer a free trial?
On the App Store, as an introductory offer on the subscription in App Store Connect. On Google Play, as a free trial offer on the subscription in Play Console. In both cases the app reads the status from your server, not from the phone alone.
First look, $750. After a free call, we read your whole product and tell you what is finished, what is not, and what to do first.
Setup, $3,000 fixed. We make it ready for real customers, in accounts you own.
Partner, $2,500 a month. We review what your coding agent writes and keep the checks and tests current. Month to month.
