Write a camera, microphone, or location purpose string reviewers can understand

“We need camera access” tells the user which permission you’re requesting, but not what you’ll do with it. Apple wants an explanation they can use to make the choice. Name the feature and give a concrete use of the data.

Apple’s purpose-string guidance explains how these short messages appear in system permission alerts. They’re part of the app’s configuration, not its App Store description or privacy questionnaire.

Describe what the person is about to do

These are original examples for fictional features. Use one only if it accurately describes your app:

Generic wording	More useful wording for the stated feature
”Camera access is required."	"Use the camera to photograph a receipt and attach it to your expense report."
"Allow microphone for a better experience."	"Record a voice note and attach it to the task you’re editing."
"We need your location."	"Use your current location to show nearby pickup points on the map.”

If the same permission supports several features, cover those uses clearly. If a library triggers a permission your app doesn’t need, investigate the dependency instead of inventing a justification for it.

We recommend writing the sentence beside a screenshot of the feature. It makes vague wording easier to spot: can the person connect the request to something they just chose to do?

Change the value that reaches the built app

Have your developer update the relevant usage-description value, such as NSCameraUsageDescription, NSMicrophoneUsageDescription, or NSLocationWhenInUseUsageDescription. The exact configuration path depends on the framework and build system. Check the generated app configuration too; editing a source setting isn’t proof that the packaged value changed.

Include the appropriate localized descriptions for the languages you support. Background location and other protected resources can need different configuration and policy checks; a better sentence doesn’t authorize access the app shouldn’t request.

A purpose string packaged with the app needs a new build to change it. A web-only text edit or a new App Privacy answer won’t replace the system alert’s message.

Read the actual prompt on a device

Install the corrected build in a test state where the permission hasn’t already been decided. Trigger the feature and read the system prompt, including its localized version. Capture it for your review reply.

Try both permission approval and denial. The accepted route should do what the sentence promises, and the declined route should explain what the user can do next. If the prompt doesn’t appear, check the device’s existing permission state before concluding the configuration is missing.

Reply with the corrected build number, the steps that show the prompt, and the screenshot. Keep privacy disclosures accurate too; they answer a different question from why the app needs this permission.