Web apps ship when you click Publish. Mobile apps ship when Apple and Google say so — and an app built by describing it to an AI hits the review process with a specific, predictable set of problems, because the tools optimise for “runs on my phone,” not “passes a reviewer’s checklist.” Here are the rejection reasons we see most on vibe-coded iOS and Android apps, and how to clear each before you submit.
Before you read the list
Rejection is normal, not fatal. Most apps get at least one on the first submission, reviewers tell you the guideline number, and you resubmit. What costs weeks is fixing one thing at a time and resubmitting each. Clear the whole list below first, then submit once.
The usual rejections, roughly in order of frequency
1
It crashes or shows a blank screen on the reviewer’s device
Usually: a missing environment variable in the release build, an API that only works from your network, or a crash on a device size you never tested. Clear it: install the release build on a device that isn’t yours, with no cached login, on cellular. Turn on crash reporting before submitting so you can see what the reviewer hit.
2
Reviewer can’t get past login
You forgot to provide a demo account, or the demo account has no data, or sign-up requires a real phone number. Clear it: a working demo login in the review notes, seeded with realistic data, and a way to try the core feature without real-world dependencies.
3
Third-party sign-in without the platform’s own option
On iOS, offering Google or Facebook login generally means you also need to offer Sign in with Apple. AI tools add “Sign in with Google” in one prompt and never mention this.
Clear it: add the platform sign-in, and make sure account linking works so one person doesn’t become two users (hole 7 in
authentication in vibe-coded apps).
4
Subscriptions or digital goods sold outside the store’s billing
A Stripe checkout for a Pro plan inside the app is the classic. Digital features unlocked in-app generally have to go through App Store / Play billing.
Clear it: use StoreKit / Play Billing — most teams reach for
RevenueCat to handle both — and keep any web checkout for web-only. The rules here have regional nuances; check the current guidelines for your markets.
5
Permission prompts without a reason, or for things you don’t use
The template asked for camera, location, contacts and microphone “just in case.” Clear it: request only what a feature actually needs, at the moment it needs it, with a one-sentence usage description that names the feature.
6
Privacy policy, data-safety form or tracking disclosure is missing or wrong
Both stores require a privacy policy URL and a declaration of what data you collect. If you use analytics or an AI provider, that’s “data collected.”
Clear it: write the policy for what the app actually does (the
AI-features guide has the disclosure points), fill the store forms to match, and on iOS handle App Tracking Transparency correctly if you track.
7
Placeholder content, broken links, “lorem ipsum,” dead buttons
The AI scaffolded a Settings screen with six options that do nothing. Reviewers tap everything. Clear it: remove what doesn’t work. A smaller finished app passes; a bigger unfinished one doesn’t.
8
It’s “just a website in a wrapper”
A WebView of your web app with no native features can be rejected as not offering enough app-like value. Clear it: native navigation, offline states, push notifications where they make sense — or ship it as a proper installable web app instead.
9
No way to delete the account from inside the app
If users can create an account in-app, they must be able to delete it in-app — and the deletion has to actually delete (hole 8 in the auth guide).
10
Metadata mismatch
Screenshots from a different version, a description that promises features that aren’t there, an age rating that doesn’t match the content, a support URL that 404s. Boring, common, and entirely avoidable.
Android-specific things people miss
Google’s process is more automated and the failures are more administrative: the data-safety section not matching what the app’s libraries actually do, target SDK requirements that the AI’s template didn’t meet, a debug-signed build uploaded by mistake, and — for new personal developer accounts — a required closed-testing period with real testers before production access. Plan for that testing window; it’s calendar time you can’t prompt away.
Before you submit: the one-hour pass
Release build on a borrowed phone. Demo account seeded. Every button tapped. Permissions listed and justified. Privacy policy live and matching the forms. Billing through the store. Sign-in options complete. Account deletion works. Screenshots current. Then submit once. If a rejection still comes back, it will name the guideline — read it, fix everything it could apply to, and reply with a short note describing what changed; reviewers respond well to that.
And if the rejection is for a crash or a security concern rather than a policy item, that’s the moment to run the 12-point audit on the mobile app the way you would on a web app — the store review is a shallow test of the same problems.
FAQ
How long does review take?
Often a day or two on either store for straightforward apps, longer for first submissions, apps with payments, or resubmissions after a rejection. Don’t announce a launch date that assumes zero rejections.
My app was built with FlutterFlow / Expo / an AI builder — does that matter to reviewers?
No. Reviewers judge the app, not the tool. The tool matters only in that it may have scaffolded the problems above. Our
Flutter and React Native guides cover the subscription wiring specifically.
Can I appeal?
Yes, on both stores, and it’s worth it when you believe the reviewer misread the app. It’s not worth it as a substitute for fixing a clear guideline miss — that just adds a week.
Should I launch on web first?
Often, yes. Web has no review, and the feedback you get shapes what the mobile app should be.
Getting the web app found is a separate problem, but a faster one.
Want the pre-submission pass done for you?
We run the release build, the demo account, permissions, billing, sign-in and store metadata against the current guidelines — and fix what would bounce — before you submit.
Book a Store-Readiness Review →
