The App Store usually flags two patterns: “you claim it exists, but reviewers cannot verify it” and “your listing says one thing, but the app behaves differently.” The most reliable submission is the one where completeness, metadata, privacy, subscriptions, and reviewer validation paths are aligned before upload.
1) Guideline 2.1 completeness & stability
Walk through first launch, login, primary actions, weak network, and foreground/background transitions. Blank states, dead buttons, broken login, or unstable test environments are classic 2.1 triggers.
2) Guideline 2.3 metadata accuracy
Title, subtitle, description, screenshots, and preview videos must reflect the current build. Avoid “coming soon” placeholders and screenshots that show flows reviewers cannot actually access.
3) Guideline 5.1.1 privacy & data use
Privacy policy URL must work, and the in-app privacy entry must be visible. Data collection, purpose, sharing, permission prompts, and policy text should not contradict each other.
4) Account deletion flow
If users can create an account, reviewers expect a verifiable deletion path. The entry point, confirmation step, and result state should be visible inside the app, not explained only through support.
5) Subscription / IAP path
Make pricing, billing period, trial, auto-renew wording, restore purchases, and cancellation guidance visible. Restore Purchases should be obvious and functional to avoid misleading-payment signals.
6) Login & test accounts
If core value depends on login, region, whitelist, or role-based access, provide working test credentials and the shortest route to the core feature. Reviewers should never need to guess the path.
7) External links & payment ownership
Do not route users to external webpages for digital content purchase on iOS. If external links are necessary, make their purpose explicit and do not disguise them as primary in-app actions.
8) Permission timing & justification
Camera, location, microphone, photos, and similar permissions should be justified before the system prompt appears. The text, timing, and actual use case must align.
9) Guideline 4.3 repetitive-app risk
If the app is templated, white-label, or one of several similar packages, review whether positioning, homepage, main flow, screenshots, and metadata communicate distinct value before submission.
10) App Review Information
Write test credentials, OTP method, shortest reviewer path, region limits, hardware dependencies, and special notes clearly. Many “working” apps still fail because reviewers never reach the intended screen.
The most effective operator mindset is not “explain more”. It is “reduce reviewer validation cost”. If a reviewer can see where to tap, what to verify, and what result to expect within 3-5 minutes, approval odds usually improve.
This is the operator view. When a rejection email arrives, first map it back to the exact App Store Connect section, then decide whether the fix belongs in the app, the listing, or the review package.
App Review Information
App Store Connect → version page → App Review Information. Use it for test credentials, reviewer steps, contact information, and edge-case notes.
Subscriptions / In-App Purchases
App Store Connect → In-App Purchases / Subscriptions. Verify pricing, billing period, trial configuration, screenshots, and review notes.
Privacy policy & account deletion
App Store Connect → App Information / privacy-related settings, plus a visible in-app entry under Settings or Profile.
Metadata & screenshots
App Store Connect → App Store → App Information / Promotional Text / Screenshots. Ensure screenshots represent the current build, not an old branch.
Age rating & content
App Store Connect → App Information / Age Rating. Social, UGC, finance, and health apps should double-check that rating and description align.
Version release control
App Store Connect → version page. Confirm the correct build is attached so you do not submit an old binary with new metadata.
2.1 App CompletenessStart with stability and verifiability, not copy rewrites. If reviewers cannot enter, tap, or complete the flow, 2.1 will usually be the first stop.
2.3 Accurate MetadataListing promises that do not match in-app behavior get flagged quickly. Keep screenshots, subtitle, pricing context, and feature claims synchronized with the live build.
5.1.1 PrivacyDo not only check for a privacy policy URL. Check whether permissions, data use, account deletion, and user disclosure form a consistent loop.
4.3 Spam / repetitive structureIf the app is part of a white-label or multi-package pattern, review 4.3 risk before the next submission cycle even if the current email cites a different clause.