Will your app get rejected? Find out before Apple and Google do. For apps built with Lovable, Bolt, Replit, Cursor, v0, and friends — what the stores check, how to self-test, and how bad each miss is.
What they check: Does the app do something an app should do, or is it a website in an app costume? The #1 rejection for vibe-coded apps.
Self-test: Open your app next to your site in Safari — indistinguishable in 30 seconds is a fail. Count native capabilities (push, offline, camera/location/haptics, native navigation). Zero or one is the kill zone.
What they check: Full-screen browser pointed at your URL. Apple rejects "web content not sufficiently optimized"; Google rejects webviews with no added value.
Self-test: Airplane mode, then open the app — white screen or browser error means no offline handling. Pinch-to-zoom on your UI or links opening browser chrome scream "website."
What they check: Whether your app looks like hundreds of others from the same generator — reviewers recognize every default template.
Self-test: Any default theme, stock icon, or example copy left? Three lookalikes in your App Store niche? Differentiate (real branding, distinct features) before submitting.
What they check: Reviewers tap every screen on real devices. One crash = rejection. Vibe-coded apps crash on permission dialogs, empty states, slow networks.
Self-test: Run the release build on a physical phone as a brand-new user. Deny every permission. Airplane mode mid-flow. Browser-only testing = assume it crashes.
What they check: Working contact info, complete metadata, answered submission questions (export compliance, rights, ads). "Information Needed" stops your clock for days.
Self-test: Every App Store Connect field filled? Support URL loads? Review notes explain anything non-obvious? Encryption question answered (standard HTTPS is usually exempt)?
What they check: If your app has a login, review must get past it. No credentials in the notes = automatic rejection — the most avoidable one there is.
Self-test: Create a stable review account, log in on a fresh install, seed it with data, paste credentials into the review notes for both stores. Phone-OTP-only login needs a hardcoded review number/code.
What they check: Lorem ipsum, "coming soon" screens, dead buttons, 404ing links, empty catalogs — treated as an incomplete app and 4.2 fuel.
Self-test: Tap every button and link in app and listing. Grep the codebase for "lorem", "TODO", "placeholder", "example.com" — generators leave these everywhere.
What they check: Digital content, subscriptions, premium features, or credits bought in-app must use Apple IAP / Play Billing. A Stripe checkout inside the app for digital goods is an instant rejection. Physical goods and real-world services should use outside payment.
Self-test: Any in-app screen taking payment for something digital via web checkout? Fix: StoreKit/Play Billing (RevenueCat makes this sane) or genuinely remove all purchase UI from the binary.
What they check: Offer Google/Facebook/GitHub login and Apple requires an equivalent privacy-focused option — in practice, Sign in with Apple.
Self-test: "Continue with Google" but no Apple button = rejection on sight. Supabase, Firebase, and Clerk all support it — config work, not a rebuild.
What they check: Both stores require a live privacy policy URL even if you collect nothing.
Self-test: Does your /privacy page load on a phone, name your actual app, and describe what you actually collect? Boilerplate naming the wrong product is worse than none.
What they check: Your "nutrition label" answers versus what the binary does. "No data collected" while shipping Firebase Analytics or Sentry is a rejection.
Self-test: Inventory every SDK and backend (auth, analytics, crash reporting, ads). Each collects identifiers, usage, or diagnostics. Answer from that list, not from optimism.
What they check: iOS builds need PrivacyInfo.xcprivacy manifests declaring data use and "required reason" APIs; popular SDKs must ship their own.
Self-test: Upload a build and read Apple's email — ITMS-91053 warnings name the APIs needing reasons. Current Capacitor/Expo/Firebase versions ship manifests; stale lockfiles don't.
What they check: Sign-up in the app requires in-app account deletion — not logout, not "email us." Google requires a declared deletion path too.
Self-test: Sign up, then fully delete your account from inside the app in under a minute. Can't? One backend function + a confirm dialog.
What they check: Every iOS permission needs a usage string explaining why. Missing = crash on request. Vague or unused-but-declared = rejection.
Self-test: For each NS*UsageDescription in your config: does the app really trigger it, and does the string name the feature ("Scan receipts to log expenses")? Delete what you never use — templates over-declare.
What they check: Screenshots must show the actual app on the actual device class — not framed browser shots, marketing slides, or stretched iPhone shots in iPad slots.
Self-test: Capture from the real build at required sizes. Phone-only web app? Don't check the iPad box. Screen 1 shows the core feature, not a splash screen.
What they check: Questionnaire answers versus actual content — UGC, chat, unrestricted web access, gambling-ish mechanics, medical info all push ratings up.
Self-test: Redo it honestly (UGC or open web access likely means 17+ on Apple) and keep Google's IARC answers consistent with Apple's.
What they check: Google's Data safety form versus observed SDK behavior — mismatches get updates rejected.
Self-test: Same SDK inventory as #11, entered in Play Console → App content → Data safety. Using Firebase/Supabase/analytics? "No data collected" is wrong. Declare your deletion URL (#13).
What they check: Personal Play accounts created after Nov 2023 must run a closed test with 20 testers opted in for 14 consecutive days before production access. A hard gate, not a review judgment.
Self-test: Play Console dashboard shows the requirement? Start the closed track now — the 14-day clock is the long pole. (Organization accounts with a D-U-N-S number skip it.)
What they check: New apps and updates must target a recent Android API level — stale templates fail at upload; you can't even submit.
Self-test: Check targetSdkVersion in android/app/build.gradle (or your Expo SDK version). Template older than ~a year? Update the toolchain before building the release AAB.
What they check: Any posting or interaction requires: report content, block users, filtering, published contact info. Vibe-coded social features almost never ship these.
Self-test: Can a user report a post and block another user in-app? If you have any social surface and answered no, add both — two screens turn a likely rejection into a pass.
LaunchPilot (a GGdata service) runs your app, build config, and metadata through the full 60-point internal version of this list — written report in 48 hours, $199, credited toward a launch package. You keep your account and your code.
Book a preflight audit →