yourapp.lovable.appHow do you read an App Store rejection?
Start with the guideline number, because it tells you exactly which rule the reviewer applied. You fixed the website-in-a-wrapper problem, resubmitted, and a day later App Store Connect says Rejected again, for a rule you hadn't heard of. The note looks vague, but it isn't: every rejection has the same three parts.
- A guideline number, such as 4.2. That's the rule the reviewer says the app broke, and it maps to a section of Apple's App Review Guidelines.
- A short explanation of what the reviewer saw when they used the app.
- Sometimes, screenshots of the screen where they got stuck.
Check the status too. Metadata Rejected means App Review didn't accept your listing: Apple's instructions are to edit the metadata in App Store Connect and reply to the message, with no new build. Rejected means the reviewer found a problem with the app itself, so if the fix is in the app, you upload a new build.
Have you fixed the common rejections first?
Fix those first, because they're the ones we see most often, and a rejection note can list more than one guideline at once. The six are 4.2 (a website in an app), 2.1 (crashes or no demo account), 5.1.1(v) account deletion, 4.3 spam, 5.1.1 privacy and permissions, and 2.3 metadata. Each is covered with its fix in why Apple rejects AI-built apps, and the rejections at a glance table there is a quick check before you resubmit.
This guide covers the four that often come after. AI builders don't add them for you, so they tend to surface on a later submission, once the common six are fixed: sending data to an AI service, Google login on its own, selling digital features through Stripe, and letting people post without any way to report or block.
Why was my app rejected for sharing data with AI?
Because the app sends people's personal data to a third-party AI service without telling them and asking first. Many AI-built apps call an AI API somewhere, and since November 13, 2025 Apple's guideline names third-party AI explicitly.
“You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so.”
The fix: before the first AI request, show a screen that says which data goes to which provider (for example "Your messages are sent to OpenAI to write replies") and ask for permission. Name the provider in your privacy policy too, which Guideline 5.1.1(i) already requires you to link inside the app. The third-party AI consent guide has the screen, the wording and the privacy policy lines.
Do I need Sign in with Apple?
Yes, if your app's main account uses Google, Facebook or another third-party login. Guideline 4.8 says such apps must also offer an equivalent login option that limits data collection to name and email, lets people keep their email private and doesn't collect their interactions for advertising without consent.
Sign in with Apple meets all three, which makes it the usual choice. Apple also lists when no extra option is needed, starting with an app that "exclusively uses your company's own account setup and sign-in systems", such as plain email and password. So if your app has Google sign-in, either add Sign in with Apple next to it, or remove Google sign-in and keep only your own email sign-in.
Can I use Stripe instead of In-App Purchase?
Only for physical goods and real-world services. Guideline 3.1.1 says: "If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase."
- Digital features, content and subscriptions use In-App Purchase. A service such as RevenueCat can handle much of the setup.
- Physical goods and services used outside the app, such as a delivery or a booked appointment, can keep Stripe.
- On the United States storefront, apps may also include buttons and links to your own checkout. In other storefronts, linking out needs one of Apple's entitlements, which only apply in specific storefronts and app types.
The Stripe or In-App Purchase guide goes through each case, and adding subscriptions covers the setup.
What does Apple require for user-generated content?
Four safeguards, if people can post anything others will see. Guideline 1.2 says apps with user-generated content must include:
- A method for filtering objectionable material from being posted to the app.
- A mechanism to report offensive content, and timely responses to those reports.
- The ability to block abusive users.
- Published contact information so people can easily reach you.
Community, chat and marketplace apps built with AI builders often ship with posting but without these safeguards. Add a Report option on every post and profile, a Block option on every profile, a word filter on posts and a contact email in settings, and mention them in the review notes.
What should you write to App Review after a rejection?
A short reply that names the guideline, says what changed and where the reviewer can see it. The steps (fix, reply, resubmit, and when to appeal) are in what to do after a rejection; here are the two pieces of text to copy. Resubmitting the same build unchanged and hoping for a different reviewer doesn't work. A good reply is short and specific:
“Hi, thanks for the review. We've addressed Guideline [X]: [what you changed, in one sentence]. You can see it at [screen or steps]. The demo login is in the review notes. Happy to clarify anything.”
Then give the reviewer everything they need in the App Review notes, so the next review doesn't stall on a sign-in screen:
“Demo account: demo@yourapp.com / [password]. It's pre-filled with sample data. To test [main feature]: [step 1], [step 2], [step 3]. [Feature] needs [a location, the camera or a second account], so here's a short video: [link]. Questions: [email]”
How is a Google Play rejection different?
Google Play has its own common blockers, and several are about forms and declarations rather than the app's design:
- The Data safety form doesn't match what the app and its SDKs actually collect. Google says it will require you to fix it, and apps that don't can have updates blocked or be removed.
- Sensitive permissions, such as location in the background, are used without a declaration in Play Console.
- The app doesn't target a recent enough Android API level.
And one that isn't a rejection but delays every new personal account: before publishing to production, personal developer accounts created after November 13, 2023 need a closed test with at least 12 testers opted in for 14 days in a row. That adds at least two weeks to a launch, so start recruiting testers before your build is final. The 12-tester requirement explains what counts, and publishing to Google Play covers the rest.
How can you check your app before you submit?
Run a free check against these rules before you hit Submit, and decode the note if a rejection still arrives:
- Before you submit: the rejection-risk check for Lovable apps, which takes a lovable.app link, and the pre-submission checklist for any app.
- After a rejection: paste the message into the App Store rejection decoder to see what it means and how to fix it.
None of these fixes is hard on its own. Together they can add up to weeks of work that has nothing to do with the app you built. If you'd rather hand it off, rejection help explains how we take an app through every reply until it's approved.
We take your AI-built app the last mile.
Send us your app, whether you built it with Lovable, Bolt, Rork or by hand, and preview the native version on your own phone for free. We convert web apps to React Native and Expo, add account deletion, write the privacy policy, privacy labels, Data safety form and listing, then submit and handle every reply from the reviewer until it's approved, fixing whatever they flag along the way. Phone-only features such as in-app purchases are quoted up front. If your app follows the store policies and we can't get it approved, you get a full refund.
