App Store RejectionGuideline 2.5.2 — Software Requirements — Device Permissions

Your Permission Strings Are Too Vague — or You Don't Need Those Permissions

Apple reads every NSUsageDescription string in your Info.plist. Generic descriptions like 'to improve your experience' get rejected. So does requesting camera access when your app never touches the camera.

What Apple said

“Your app requests access to the device microphone, but the purpose string provided does not adequately explain why this access is required. Additionally, we could not identify a feature in your app that uses microphone access. Please provide a clear, specific purpose string or remove the permission from your app.”

What this actually means

Every permission your app requests needs a clear, specific explanation that a user can understand — and your app must actually use that permission for the described purpose. Reviewers test both sides: they read the string and they look for the feature. Vague strings or unused permissions will trigger a rejection and a privacy flag.

What Apple needs to see

  • Purpose strings (NSUsageDescription) that explain specifically what feature uses each permission, in user-facing language
  • Every requested permission actively used by a feature accessible to the reviewer
  • No permissions in Info.plist from removed features or copied boilerplate
  • A privacy policy that lists which data types you collect and why, linked from your App Store listing
  1. 1Open Info.plist and read every usage description string — if it could apply to any app, rewrite it to be specific to yours
  2. 2For each permission key, verify in your code that the permission is actually requested and used by a real feature
  3. 3Delete any permission keys for features you removed or third-party SDKs you no longer use
  4. 4Rewrite purpose strings in first person user language: 'So you can scan product barcodes' not 'Used for scanning purposes'
  5. 5Update your privacy policy at yourapp.baseterms.com/privacy to reflect exactly which permissions you request and what data they access

While you're at it — Apple also requires these pages for every app.

Fix this rejection, then make sure you're covered on the compliance side too. Apple requires every app to link to a hosted Privacy Policy, Terms of Service, Support page, and Data Deletion page. No link means another rejection — just for a different reason.

Privacy Policy
Terms of Service
Support Page
Data Deletion Page
Generate my compliance pages — FREE

Common questions

An SDK I use requires camera permission but I don't use the camera in my app. What do I do?
Contact the SDK vendor or check if there's a version without camera requirements. If the SDK silently requests camera access in a way you can't control, that's a problem — you're responsible for all permissions in your binary. Consider replacing the SDK or using a more surgical integration that doesn't include the camera-dependent components.
How specific does my usage description need to be?
Specific enough that a user understands exactly what they're allowing and why. 'To allow you to record voice memos' is good. 'For audio functionality' is not. The test is: could a user read this and make an informed decision? If yes, it's probably specific enough.
I was rejected for Bluetooth permission but I'm using it — what's wrong?
Bluetooth has two separate permission strings depending on whether you're using Core Bluetooth (NSBluetoothAlwaysUsageDescription) or Bluetooth for phone calls (NSBluetoothPeripheralUsageDescription). Make sure you're using the right key for your use case and that the description is specific to your feature.