How do I fix an App Store rejection?

First, identify the specific guideline violation from your rejection notice in App Store Connect. Common fixes include: adding a privacy policy URL, implementing Sign in with Apple for apps with third-party login, using In-App Purchase for digital goods, and ensuring screenshots accurately represent your app. Once fixed, submit a new build—replying in the Resolution Center alone does not trigger a new review.

Why was my app rejected from Google Play?

Google Play rejections typically fall into these categories: Data Safety form issues (incomplete or inaccurate declarations), sensitive permissions without core functionality justification (SMS, Call Log, Location), policy violations (deceptive behavior, misrepresentation), and technical issues (target SDK too old, 16KB page alignment for new devices). Check the Policy Center in Play Console for the specific violation and required remediation steps.

How long does an app review appeal take?

Apple typically responds to appeals within 24-72 hours for standard cases, though complex escalations can take up to a week. Google Play appeals usually receive a response within 3-5 business days. You get one appeal per rejected build, so include all relevant evidence (screenshots, demo videos, compliance documentation) in your initial submission. For iOS, you can also request a live App Review Appointment via Webex if written appeals fail.

Can I resubmit while an appeal is pending?

Yes, you can submit a new build while an appeal is pending on both platforms. This is often the faster path—fix the reported issue and submit an updated binary rather than waiting for the appeal outcome. If your appeal succeeds but you've already submitted a fixed version, the newer build will be reviewed. For metadata-only rejections (screenshots, description, keywords), you can update these directly without uploading a new binary.

What are the most common App Store rejection reasons?

Based on analysis of verified rejections: iOS top issues are Missing Privacy Policy (9.9%), Placeholder Content (7.8%), Misleading Metadata (4.6%), and Sign in with Apple (3.2%). For Google Play, the leaders are Data Safety Issues (11%), Sensitive Permissions (7.2%), and Foreground Service Type (3.2%). Privacy-related violations dominate both platforms, accounting for roughly 20% of all rejections combined.

Back to Rejection Hub

Quick Fix for Guideline 2.5.1

Update NSLocationAlwaysUsageDescription in Info.plist with a clear user benefit explanation. If background location isn't essential, switch to "When In Use" permission instead.

Guideline 2.5.1

Background Location Access

Your app is requesting or accessing location data in the background without a legitimate, user-facing reason, or you haven't explained it in the permission string.

AI-Friendly Summary

To resolve a Guideline 2.5.1 rejection, developers must ensure Apps should only request location permission when it is directly relevant to the app's functionality. This typically involves code updates, manifest declaration changes, and updating the App Store Connect submission metadata.

Recommended Fix Steps

Verify that background location is strictly necessary for your core feature.

Add `NSLocationAlwaysUsageDescription` and `NSLocationWhenInUseUsageDescription` to Info.plist.

The description MUST explain the benefit to the user (e.g., "We need location to alert you when you arrive at your destination").

Consider if "When In Use" is sufficient for your needs.