Skip to content
← All writing
August 27, 2026·6 min read

Getting Through App Store Review Without Losing a Week

App review feels like a black box the first few times: you submit, wait days, and get back a rejection quoting a guideline number you've never read, with a screenshot that may or may not clarify anything. But after enough releases — and I've been through this cycle with multiple apps on both stores — a pattern emerges: the overwhelming majority of rejections come from a short list of predictable causes, and almost all of them are preventable before you ever hit Submit. The authoritative source is Apple's App Review Guidelines (and Google's Developer Policy Center for Play — Play's review is faster and more automated, but the same preparation covers both). This post is the field guide to the parts that actually bite.

The rejections that actually happen

Crashes and incomplete apps. Apple's guideline 2.1 covers "app completeness," and it's the most common rejection there is: the app crashes on launch on a device you didn't test, a button leads nowhere, placeholder text survives from development, an empty state shows lorem ipsum. Reviewers test on real hardware, often on the newest OS version, and frequently on iPad even for iPhone-only apps (your app runs there in compatibility mode, and it counts). Your app must at least run everywhere it claims to — which is an argument for testing on real devices being part of your release process, not a heroic pre-submission scramble.

The reviewer couldn't get in. If your app requires sign-in, you must provide a working demo account in the App Review notes. A surprising share of rejections are simply "we couldn't log in": the account expired, a verification email gated it, it was created in the wrong environment. Keep a dedicated, never-expiring review account, seeded with realistic data so features demonstrate well — a reviewer looking at an empty account sees an app that appears broken, and rejects accordingly.

Vague permission prompts. Every sensitive permission on iOS requires a purpose string, and "This app needs your location" gets rejected where "Your location is used to find nearby restaurants" passes. Write purpose strings that state the user benefit in plain language. And re-check them whenever you add a Flutter plugin: plugins quietly add permission requirements to your build, and a purpose string you never wrote — or an auto-generated placeholder — is a rejection you never saw coming.

Privacy paperwork mismatches. Your privacy policy link must resolve, and your privacy "nutrition label" must match what the app — including its third-party SDKs — actually collects. Same on Play, where the Data safety form gets checked against observed network behavior. Fill these in from what your dependencies really do (their documentation says, and their traffic confirms), not from optimism. An analytics SDK you added in an afternoon can contradict a label you filled in months ago; see App Analytics That Respect Users for keeping this honest by construction.

Account deletion. If your app lets people create an account, Apple requires it to also let them delete it — in the app, as a real flow, not via a support email (guideline 5.1.1). This one blindsides apps that added sign-up early and never designed the exit. Build it before it's requested.

Payments in the wrong lane. Digital goods and features must use in-app purchase; physical goods and real-world services must not. Mixing these up is an instant rejection in either direction. (The rules around linking to external payment options have been shifting by region for years — court rulings, the EU's DMA — so check the current guidelines for your markets rather than relying on folklore or last year's blog posts.)

"Minimal functionality." Guideline 4.2 rejects apps that are thin wrappers around a website or simply do too little. If your app is mostly WebView, expect scrutiny; native functionality, offline behavior, and platform integration (notifications, widgets, share sheets) are the answer — both for review and, frankly, for having an app worth installing.

The pre-submission checklist

Fifteen minutes before every submission, every time:

  1. Fresh install on a real device — not an upgrade over a dev build, which hides first-run bugs. Launch, sign up, run the core flow, background and resume.
  2. Demo account credentials in the review notes, tested from a clean state that same day.
  3. All links live: privacy policy, terms, support URL. Reviewers click them; broken links are free rejections.
  4. Purpose strings and privacy labels re-checked against any plugins added since last release.
  5. Screenshots match the actual current UI — stale screenshots draw metadata rejections, and they're also just bad marketing.
  6. Anything non-obvious explained in the review notes. Hardware requirements, region-specific features, why the app asks for an unusual permission, where the hidden feature lives. Reviewers reject what they can't understand in a few minutes; a paragraph of context — or a 60-second screen recording — prevents a multi-day round-trip. This is the cheapest insurance in the whole process.

On the Play side, run the pre-launch report — it exercises your app on a range of real devices and catches the crashes-on-device-you-don't-own class of failure before reviewers or users do.

If your release includes anything time-sensitive — coordinated launch, critical fix — submit early and use the store's release controls (manual release after approval) rather than gambling that review will be fast that week. Review times are usually a day or two now, but "usually" is not a launch plan.

When you're rejected anyway

Rejections still happen to well-prepared apps, and they're recoverable when handled calmly, in the Resolution Center thread:

  • If they're right — which, honestly, is most of the time — fix it and resubmit with a note describing exactly what changed. Re-reviews of a described fix are typically fast.
  • If they misunderstood the app, reply with a clarification and a screen recording demonstrating the flow in question before changing any code. A remarkable number of rejections dissolve on explanation — the reviewer saw the app for minutes, and a video showing "here is the feature working, here is where the setting lives" fills the gap that caused the rejection.
  • If you believe the guideline is genuinely misapplied, a formal appeal process exists. Use it sparingly and pick your battles: a small product change is usually cheaper than a crusade, and you want your appeals to carry weight the day one really matters.

Never argue through App Store metadata, and never ship sneaky workarounds (feature flags that hide functionality from reviewers are the classic — and detected — move). Developer accounts get flagged for patterns, and the goodwill you'd burn is exactly what you'll want on the day a critical bug fix needs an expedited review. Play has an equivalent escalation path; the same calm-and-documented approach works there.

The takeaway

Review is adversarial only if you treat it that way; mostly it's a checklist you either ran or didn't. Read the guidelines properly once — it's an afternoon, and it pays forever. Keep the pre-submission checklist next to your release process, hand the reviewer a working account and enough context to understand what they're looking at, and respond to rejections with fixes and videos instead of frustration. Rejections drop from routine to rare. The goal isn't just passing — it's making review boring, so shipping stays fast enough to matter.

Further reading