App review rejections,
beyond the screenshots.
Screenshot rejections are the visible ones. Most refusals come from somewhere else entirely: a demo account that stopped working, a privacy label that does not match the binary, a payment link that should have been an in app purchase. Here are the categories that actually catch indie apps.
Guideline 2.1, the catch all
Apple's most cited rejection is "app completeness", and it is usually mundane. A demo account that stopped working, a feature behind a login the reviewer cannot pass, a placeholder screen, a crash on the reviewer's device. Reviewers test on current hardware with a fresh install and no cached state, which is precisely the path developers test least.
The fix is boring and effective: install the exact build on a wiped device, sign in with the demo credentials you submitted, and use the app the way a stranger would.
Guideline 4.2, minimum functionality
An app that is a wrapper around a website, a single feed, or a thin utility that the OS already provides gets refused. This catches a lot of first apps. The test Apple applies is whether the app does something a mobile web page could not, and repackaged web content is the most common failure.
If your app is genuinely a web view, it needs native capability around it worth installing for: offline access, notifications, hardware integration, something.
Guideline 3.1.1, purchases
Anything that unlocks digital content or features inside the app must use in app purchase. Linking out to your website to take a payment is the classic rejection, and the rules around what you may say about external payment options have shifted repeatedly. Physical goods and services consumed outside the app are the exception and should use a normal payment flow.
Subscriptions carry extra requirements: the price, the period, and a link to your terms and privacy policy must all be visible on the paywall itself, not only in the store listing.
Privacy, the fastest growing category
- Nutrition labels that do not match behaviour. Apple compares your declared data collection against what the binary does. Third party SDKs collect things you may not have declared.
- Tracking without the prompt. Using the advertising identifier requires App Tracking Transparency. Shipping without it is an immediate rejection.
- Account creation with no deletion path. Both stores now require an in app way to delete an account, not an email address to write to.
- Permission requests with no explanation. Every permission needs a usage string that says why, and vague strings get refused.
What differs on Google Play
Play review is mostly automated, and its enforcement arrives differently: policy strikes can land months after approval, during a sweep, rather than at submission. The categories that catch indies most often:
- Data safety mismatch. Same idea as Apple's labels, checked against observed traffic.
- Permissions declared but unjustified, especially location in the background and any access to installed packages.
- Target API level. Play enforces a minimum that rises every year, and an app below it stops being distributable to new users.
- Metadata claims. "Best" and "number one" are explicitly disallowed in Play listings, where Apple mostly tolerates them.
Replying to a rejection
Read the guideline number before the message. The number tells you the category; the message is often a template. If you believe the reviewer misread something, reply in the Resolution Center with a short explanation and a screen recording that reproduces the flow. That resolves more cases than resubmitting an unchanged build, which usually gets the same answer.
If you disagree on principle rather than fact, there is a separate appeal path, but use it sparingly and only when you can point to the specific guideline text.
Metadata only problems, including anything in the listing images, generally do not need a new build. Fix the listing and resubmit for review, which is a much shorter cycle. The listing checklist covers what to verify before you do.