Blog

Preventing App Store and Google Play Rejections: A Pre-Submission Guide

App Store and Google Play rejections are preventable. The patterns that cause most rejections are documented in Apple's App Store Review Guidelines and Google Play's Developer Policy — they are not hidden or ambiguous. The gap between preventable rejections and actual rejections is almost always a missing pre-submission review process. This guide documents the rejection patterns that appear most frequently in the current review cycle and the test coverage that catches them.

App Store: the top rejection categories in 2026

Apple's App Store review guidelines are updated frequently. The following categories accounted for the highest rejection volume in the 2025–2026 review cycle based on published App Store developer communications and community-reported data.

  • Privacy manifest incomplete or missing (Guideline 5.1.1): apps using required reason APIs without a valid PrivacyInfo.xcprivacy file are rejected at automated review. Third-party SDK manifests must be merged into the app's manifest.
  • In-app purchase bypass (Guideline 3.1.1): any mechanism that allows users to purchase digital goods or content without using Apple's in-app purchase system triggers rejection. This includes links to external purchase flows for digital content.
  • Login with Apple not offered (Guideline 4.8): apps that offer social sign-in (Google, Facebook, LinkedIn) must also offer Sign In with Apple as an option.
  • Inaccurate app description (Guideline 2.3.7): screenshots, preview videos, or descriptions that do not accurately represent the app's current functionality — including out-of-date screenshots after a redesign.
  • Data usage declaration mismatch (Guideline 5.1.2): App Privacy nutrition labels that do not accurately reflect data collection, sharing, or tracking behaviour as implemented in the submitted build.

Google Play: the top policy violation categories

Google Play uses a combination of automated policy scanning and human review. The following categories generate the most policy violation notices and app removal actions.

  • Data Safety section inaccurate: the Data Safety form in Play Console must accurately reflect which data types the app collects, how they are used, and whether they are shared with third parties. Automated analysis of submitted APK/AAB is compared against declarations; discrepancies trigger violations.
  • Sensitive permissions without valid use case: CALL_LOG, SMS, CONTACTS, and LOCATION permissions require a Primary Permission declared use case that satisfies Google Play's use case requirements. Permissions requested without a compliant use case declaration trigger removal.
  • Target API level out of date: apps must target Android SDK 33 (Android 13) minimum for new submissions; SDK 34 (Android 14) is required for new submissions since August 2024.
  • Malicious behaviour patterns: Play Protect scanning triggers on apps that use accessibility services, device admin APIs, or overlay permissions without a compliant use case.

The pre-submission review process

A structured pre-submission review catches most rejection-category violations before submission. The review should be conducted against the actual build being submitted, not an earlier build, and should be repeated after any changes to the submission.

  • Step 1: Run Apple's Privacy Manifest Audit (xcodebuild -create-xcframework) to verify all required reason API declarations are present
  • Step 2: Review App Privacy nutrition labels against the actual data collection implementation in the build
  • Step 3: Verify all screenshots, preview videos, and app description copy are accurate for the current build
  • Step 4: Test in-app purchase flows on a real device to confirm Apple IAP is used for any digital goods
  • Step 5: For Android, compare the Data Safety form against a static analysis of the APK's data collection behaviour
  • Step 6: Review permissions declared in AndroidManifest.xml against the use case declarations in Play Console

Frequently asked questions

Standard App Store review takes 24–48 hours for most submissions. Expedited review (for critical bug fixes) typically completes within 24 hours. A rejection adds 5–10 business days in practice: 24–48 hours to receive the rejection notice, time to diagnose and fix, resubmission, and another review cycle. For revenue-generating apps on a release schedule, this delay cost is the primary argument for pre-submission compliance review.

Need more detail?

Our team can provide vertical-specific data, custom analysis, or a live walkthrough of any resource on this page.