App Store review

Most first-time rejections aren't about quality — they're about a handful of predictable policy boxes you didn't tick. Knowing them up front turns a multi-week back-and-forth into a single clean submission.

The rejections that catch founders most

1. Login walls and demo access

If your app has a login, review needs to get in. Reviewers reject apps where they hit a wall they can't pass.

• Provide a working demo account (username + password) in App Store Connect / Play Console review notes.
• If you gate features behind a paywall, make sure the reviewer can see what the app does — a demo account that's fully provisioned beats one that's empty.
• Don't require an invite code or a real-world action to even open the app.

2. Sign in with Apple

On iOS, if you offer any third-party or social login (Google, Facebook), you generally must also offer Sign in with Apple. Skipping it is a common, avoidable rejection. Email/password-only apps are exempt.

3. Payments through the wrong rail

This is the big one. For digital goods and subscriptions consumed in the app, Apple and Google require their in-app purchase systems — you can't just drop in a Stripe checkout to dodge the cut. Use StoreKit / Google Play Billing, or a layer like RevenueCat that wraps both.

• Physical goods and real-world services (e.g. ordering food, booking a ride) use normal payment rails — IAP would actually be wrong there.
• Don't link out to an external web purchase to bypass IAP for digital content. Rules on external links have shifted by region — check the current App Store Review Guidelines rather than trusting old blog posts.

4. Privacy: labels, policy, and permissions

• A privacy policy URL is mandatory. The page must be live and reachable.
• Fill out the privacy "nutrition label" accurately — what you collect and why. Mismatches with your actual SDKs (analytics, ads) get flagged.
• Request permissions (location, camera, contacts, tracking) only when you use them, with a clear purpose string. Asking for tracking with App Tracking Transparency? You need the prompt and a real reason.

5. Thin, broken, or placeholder builds

• No lorem ipsum, no obvious crashes, no broken links, no "coming soon" buttons.
• A pure web-view wrapper with no native value tends to get rejected as minimal-functionality. Add real native behavior or reconsider the wrapper.
• Test on a real device, not just the simulator.

Before you hit submit

• Bump the build/version number; an old number silently fails upload.
• Screenshots must match the actual app — no fabricated UI.
• Age rating and category set honestly.
• Account deletion in-app is required if you support account creation — not just a "email us" line.
• Read your rejection messages literally. They cite a specific guideline number; open that guideline, fix exactly that, and reply in Resolution Center with what you changed.

Plan for the timeline

Review usually lands within a day or two, but plan a buffer. Don't schedule your launch tweet for the same hour you submit. Submit early, keep a TestFlight/internal-track build flowing so you're not blocked, and treat the first rejection as routine rather than a crisis.

Ship-ready when

• Working demo account + clear review notes provided.
• Sign in with Apple present if you offer social login (iOS).
• Digital goods/subscriptions use IAP / Play Billing (or RevenueCat); physical goods use normal rails.
• Live privacy policy URL + accurate privacy labels + just-in-time permission prompts.
• No placeholder content, no crashes, real device tested.
• In-app account deletion available; version bumped; screenshots honest.