Permission rejections are among the most common — and most fixable — causes of app rejection. Here is what each permission error means and exactly how to fix it.
The principle: Every permission your app requests must be justified by a feature the user can see. Permissions with no visible purpose are rejected. Permissions with no usage description string are rejected. Permissions declared in code but not declared in Data Safety (Android) cause policy violations.
Cause
Your Info.plist declares a permission (camera, location, contacts, etc.) but does not include the corresponding NSUsageDescription string explaining why it is needed.
Fix
Add the usage description for every permission declared. Open Info.plist and add the key for each permission (e.g. NSCameraUsageDescription, NSLocationWhenInUseUsageDescription). The string must clearly explain to the user why the app needs this permission.
Cause
Your app requests permissions that are not used by any visible feature, or requests a broader permission than the feature requires.
Fix
Audit AndroidManifest.xml or Info.plist and remove every permission not directly required by a user-facing feature. Replace broad permissions with narrower alternatives where available (e.g. ACCESS_FINE_LOCATION vs ACCESS_COARSE_LOCATION, or READ_MEDIA_IMAGES vs READ_EXTERNAL_STORAGE).
Cause
Your app tracks users across apps or websites (directly or via an SDK like Meta or Google AdMob) but does not request ATT permission through Apple's AppTrackingTransparency framework.
Fix
Implement ATT using the AppTrackingTransparency framework. Call requestTrackingAuthorization before any tracking begins. Declare NSUserTrackingUsageDescription in Info.plist. Declare tracking in your Privacy Manifest.
Cause
Your Data Safety form in Play Console is incomplete, or the declared data collection does not match the permissions your app actually requests.
Fix
In Play Console, go to App Content > Data Safety. Complete every section. For each permission your app requests, declare the corresponding data type collected and its purpose. Include data collected by third-party SDKs even if you did not write the code.
Cause
Your app requests Always On (background) location but the use case does not justify it, or no explanation is provided to the user before the system prompt.
Fix
Change to 'While Using' location unless your app has a clear background location use case (navigation, delivery tracking). If background location is genuinely needed, explain this to the user before the system prompt appears, and document the use case clearly in your store listing.
Cause
Your app requests access to the user's contacts but the app category or description does not justify this.
Fix
Remove the contacts permission if it is not required. If it is required, ensure the usage description explains exactly why (e.g. 'To help you invite contacts to join your team'). Be prepared to justify this to a reviewer.
List every permission in AndroidManifest.xml or Info.plist
For each permission: name the specific feature that requires it
Remove any permission with no corresponding feature
Replace broad permissions with narrow alternatives where possible
Verify every iOS permission has a usage description string
Verify Android Data Safety form matches every permission declared
If using ATT on iOS: confirm requestTrackingAuthorization is called before tracking starts
Run the AppTester Health Check — it flags common permission issues automatically
The AppTester Health Check scans your binary for permission over-requests, missing usage strings, and ATT compliance issues. Free, no account required.
