Mobile app update rejected by App Store or Play review: fix guide

TL;DR — If your mobile app update was rejected, the fastest path is to open the rejection notice in your store dashboard, copy the exact guideline or policy number, and fix that specific issue before resubmitting. The most common causes are mismatched privacy disclosures, missing demo/test credentials, metadata that does not match the app, or requesting sensitive permissions without a clear in-app reason. Reading time: ~6 min

The scenario

It is Tuesday afternoon, your agency has shipped a routine mobile app update, and a few hours later the client forwards a message that says the release was rejected in review. Marketing already scheduled the announcement, the old version is still live, and the rejection note mentions a policy number you do not recognize. You open the store dashboard and see a short reviewer comment, maybe a screenshot, and a status like "Rejected" or "Metadata Rejected." The pressure is not really technical yet — the hard part is translating that note into one concrete fix.

Symptoms

• The release status in the store dashboard shows one of these:

  Rejected
  Metadata Rejected
  Developer Rejected
  Changes Needed
  Removed from Sale
  

• The reviewer message includes a guideline or policy reference such as:

  Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage
  Guideline 2.1 - Performance - App Completeness
  Guideline 2.3.1 - Performance - Accurate Metadata
  Guideline 4.8 - Design - Sign in with Apple
  Permissions policy: Sensitive permissions are not sufficiently disclosed
  User Data policy issue
  

• The reviewer says they could not sign in, reproduce a feature, or complete review:

  We were unable to access your app's content.
  Please provide demo account credentials.
  App requires login to access features, but no review account was provided.
  

• The rejection mentions privacy, tracking, or data handling:

  Your privacy details do not accurately reflect the app's data collection.
  Missing purpose string for camera access.
  Data safety form is inaccurate or incomplete.
  

• The rejection mentions metadata or screenshots:

  The app or its metadata includes misleading information.
  Screenshots do not sufficiently reflect the app in use.
  

• The rejection mentions payments or external purchase links:

  The app unlocks digital content without using in-app purchase.
  External links or calls to action direct users to alternate purchasing mechanisms.
  

Likely causes

Step-by-step diagnosis

1. Open the exact rejection notice in the store dashboard.

   • Path: in your provider's dashboard, open your app → the rejected version/release → review message or policy notice.
   • This is your problem if you see a specific guideline/policy number and a short reviewer explanation.
   • Jump to the matching fix section below.

2. Check whether the rejection is about the app binary (the uploaded app) or only metadata.

   • Path: app dashboard → rejected version → status details.
   • "Metadata Rejected" means the app build may be fine and only the listing needs changes.
   • If the note mentions screenshots, description, keywords, age rating, or promotional text, jump to Fixes → Metadata does not match the build.

3. Verify review access.

   • Path: app dashboard → rejected submission → review notes / app review information.
   • This is your problem if review notes are blank, test credentials are missing, 2FA (two-factor authentication) blocks access, or the app opens to a login wall with no demo path.
   • Jump to Fixes → Reviewer could not log in or access the feature.

4. Compare privacy answers to the real app behavior.

   • Path: app dashboard → privacy/data safety section, then compare it with the app's actual SDKs (third-party code libraries), analytics, ads, crash reporting, login, and permissions.
   • This is your problem if the app collects email, device identifiers, location, diagnostics, or tracking-related data but the form says it does not.
   • Jump to Fixes → Privacy disclosures do not match the app.

5. Check sensitive permissions and purpose text.

   • Path first: open the rejection note for permission names. Then check your app settings/project files.
   • iOS quick check:

   grep -R "NSCameraUsageDescription\|NSMicrophoneUsageDescription\|NSPhotoLibraryUsageDescription\|NSLocationWhenInUseUsageDescription\|NSUserTrackingUsageDescription" .
   

   • Android quick check:

   grep -R "uses-permission" app/src/main/AndroidManifest.xml
   

   • This is your problem if the app requests a permission but the reason is vague, missing, or not visible before the permission prompt.
   • Jump to Fixes → Sensitive permission usage is not properly explained.

6. Review payment flows for digital purchases.

   • Path: install the submitted build and tap every upgrade, subscription, credit, or premium flow.
   • This is your problem if the app sells digital access/content and sends users to a browser checkout or asks them to pay outside the store's billing system.
   • Jump to Fixes → External payment flow violates store billing rules.

7. Reproduce the reviewer path on a clean device.

   • Path: use your internal testing build distribution or the exact archived release candidate; sign out, clear app data, and test on a device with no developer shortcuts enabled.
   • This is your problem if the app crashes, shows blank screens, depends on production-only data, or requires hidden steps not documented for review.
   • Jump to Fixes → App is incomplete, crashes, or review path is broken.

Fixes

Privacy disclosures do not match the app

Update the store privacy questionnaire/data safety form so it matches the app exactly.

Concrete actions:

• In your store dashboard, open the app → privacy or data safety section.
• For each SDK or feature, answer based on real behavior in the submitted build:
  • analytics/crash reporting = diagnostics/usage data
  • login/profile = name, email, user ID
  • ads/tracking = identifiers and tracking-related disclosures
  • location features = coarse/fine location if collected
• If the form is correct but the app changed recently, remove the undeclared SDK from the build and resubmit.

Common code-side check for iOS/Android projects:

grep -R "Firebase\|AppsFlyer\|Adjust\|Branch\|Amplitude\|Mixpanel\|Sentry\|RevenueCat\|AdMob" .

Verify it worked: the updated privacy form matches the reviewer note, and your resubmission notes explicitly say what was corrected.

Reviewer could not log in or access the feature

Provide a stable demo account and exact review steps.

Concrete actions:

• In the store dashboard, open the rejected submission → review notes / app review information.
• Add:
  • test username
  • test password
  • any one-time setup steps
  • which screen to open to see the reviewed feature
  • whether a VPN, region, or hardware device is required
• If your app uses 2FA, create a review account that does not require it, or provide a backup code flow that works during review.
• If content is account-specific, preload the review account with sample data.

Suggested review note template:

Review account
Email: review@example.com
Password: ExamplePass123!

Steps
1. Open the app.
2. Tap Sign in.
3. Use the credentials above.
4. Tap Dashboard -> Reports.
5. Tap the first sample report to test the updated feature.

Notes
- No 2FA is required for this review account.
- Sample data is preloaded.

Verify it worked: a non-team member can install the build, follow only the review note, and reach the feature without asking questions.

Metadata does not match the build

Align the listing with the actual app screens and behavior.

Concrete actions:

• In the store dashboard, open the app listing.
• Replace screenshots that show old UI, unavailable features, placeholder text, or device frames that imply unsupported hardware.
• Edit the description to remove claims the app does not currently support.
• Update age rating/content declarations if the app now includes user-generated content, chat, or web access.

Checklist to compare against the build:

- App name matches brand shown in app
- Screenshots show current UI
- Description does not promise unreleased features
- Subscription text matches actual plans and billing period
- Support URL and privacy policy URL load correctly

Verify it worked: every screenshot and sentence in the listing can be pointed to inside the submitted build.

Sensitive permission usage is not properly explained

Add clear purpose text and an in-app explanation before the system prompt.

For iOS, add or improve purpose strings in Info.plist:

<key>NSCameraUsageDescription</key>
<string>We use the camera so you can scan receipts and attach them to expenses.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>We use your photo library so you can upload existing receipt images.</string>
<key>NSLocationWhenInUseUsageDescription</key>
<string>We use your location only while using the app to show nearby service locations.</string>
<key>NSUserTrackingUsageDescription</key>
<string>We request permission to measure campaign performance across apps and websites.</string>

For Android, review permissions in AndroidManifest.xml and remove any unused ones:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

Then add a short pre-permission screen in the app, for example:

Allow camera access
Use your camera to scan receipts. You can also upload a photo instead.

Verify it worked: the app asks only for permissions tied to a visible feature, and the reason shown to the user matches the reviewer concern.

External payment flow violates store billing rules

Remove or change purchase flows for digital goods.

Concrete actions:

• If the app sells digital subscriptions, credits, premium features, or content consumed in the app, replace web checkout links with the platform's in-app purchase/billing flow.
• Remove text like:

Buy on our website
Subscribe at example.com for a lower price

• If the app only sells physical goods or offline services, rewrite the screen so it clearly reflects that and does not unlock digital content.

Search your codebase for obvious external payment links:

grep -R "stripe.com\|checkout\|subscribe\|billing\|example.com/pay\|Buy on our website" .

Verify it worked: from the app, users can no longer purchase digital access through an external browser flow.

App is incomplete, crashes, or review path is broken

Fix the broken path in the submitted build and resubmit a new binary.

⚠️ If you change app code, you will need a new build and a fresh review cycle. Do not resubmit the same broken binary with only a note.

Concrete actions:

• Install the exact release candidate on a clean device.
• Test with production-like settings, not developer shortcuts.
• Fix blank states, missing API endpoints, feature flags (remote on/off switches), and startup crashes.
• If a feature is region-locked or account-gated, either disable it for review or document the exact access requirements in review notes.

Basic crash/log checks for local testing:

# iOS project
grep -R "fatalError\|assert\|precondition" .

# Android project
grep -R "throw RuntimeException\|TODO()\|NotImplementedError" .

Verify it worked: a fresh install on a non-developer device completes the reviewer path without crashing, hanging, or needing hidden setup.

Prevention

1. Add a release checklist to CI/CD (build and delivery automation) that blocks submission when review notes are empty.

release_check:
  script:
    - test -n "$REVIEW_USERNAME"
    - test -n "$REVIEW_PASSWORD"
    - test -n "$REVIEW_STEPS"

1. Keep a privacy inventory in the repo and review it on every release.

{
  "analytics": ["Firebase Analytics"],
  "crash_reporting": ["Sentry"],
  "auth_data": ["email", "user_id"],
  "permissions": ["camera", "photo_library"]
}

Use it when updating the store privacy/data safety form.

1. Fail the build if sensitive iOS purpose strings are missing.

plutil -p ios/App/Info.plist | grep NSCameraUsageDescription
plutil -p ios/App/Info.plist | grep NSPhotoLibraryUsageDescription

1. Audit Android permissions in CI and flag unexpected additions.

grep "uses-permission" app/src/main/AndroidManifest.xml > current-permissions.txt
diff -u allowed-permissions.txt current-permissions.txt

1. Capture fresh store screenshots from the release candidate, not from design files.

Process: install release candidate -> navigate to key screens -> take screenshots on device -> upload those exact images to the listing

1. Maintain a permanent review account with sample data and no 2FA, and test it monthly.

Owner: support@youragency.example
Account type: reviewer
Requirements: sample data loaded, password stored in team vault, no expiring OTP required

This article was written by an AI system and published pending human review. Verify anything you intend to act on.