App rejected: missing or vague permission purpose string
If your app requests a permission and Info.plist has no matching usage description, iOS terminates the app the moment the prompt would appear. App Review hits that immediately, which is why this is a blocker rather than a note. A purpose string that exists but says nothing is a separate and softer problem: it does not crash, it gets rejected on review.
Why it matters
Each permission has its own key, and the app has to carry the key for every permission it actually requests: NSCameraUsageDescription for the camera, NSMicrophoneUsageDescription for the microphone, NSPhotoLibraryUsageDescription for the photo library, and so on through location, contacts, calendars, reminders, Bluetooth, motion, Face ID, tracking, local network, speech recognition and HealthKit.
The crash is not a bug you can work around: iOS treats a missing purpose string as a developer error and ends the process rather than showing a prompt with nothing in it. It happens the first time that permission is requested, so a permission behind a feature a reviewer reaches on their second session still fails, just later.
The other half is the copy itself. A string left as a template value, or one short enough to say only that access is needed, tells the user nothing about what the app does with it. Reviewers reject purpose strings that are empty, templated or meaningless, and short strings that do not describe a concrete user-facing feature are rejected often enough to be worth rewriting before you submit.
The reverse case is worth knowing too: a purpose string declared for a permission the app never requests. That is its own rejection reason, because the app is asking for access to something it does not use.
How to fix it
- For every permission the app requests, add the matching key to Info.plist. The key name is specific to the permission and using the wrong one has the same effect as having none.
- Write each string as a sentence naming the feature and the benefit, not the access. "We use your camera so you can attach a photo to a report" rather than "This app needs camera access".
- Remove purpose strings for permissions the app no longer requests, which is common after a feature is cut and the Info.plist key stays behind.
- Test each one on a device with the permission not yet granted, which is the only path that actually exercises the prompt.
The guidelines behind it
Read from Apple’s App Review Guidelines as last updated October 16, 2026.
Worth knowing
Source-symbol matching is a signal rather than proof, so a finding that rests on it carries the evidence and a reduced confidence, and the score charges less for it. A scan of a built app cannot read source at all, so there it reports the purpose string it found and says plainly that whether the app requests the permission was not checked.
What ReviewAhead checks
Permission usage descriptions. Every permission the app requests needs a purpose string that explains the user-facing benefit.
- Fifteen permissions, matching API use found in your source against the purpose strings declared in Info.plist.
- Purpose strings that are still placeholder or template copy.
- Purpose strings too short or too generic to describe a feature, reported as a risk rather than a blocker because judging copy by length is approximate.
- Permissions declared in Info.plist with no matching API use found.