Guideline 5.1.1(ii) permissions and purpose strings, in plain English

What Guideline 5.1.1(ii) means

iOS keeps the camera, microphone, location, photos, contacts and other protected data closed until the person allows access, and the request shows your purpose string, also called a usage description. Apple's App Review page adds that an app whose code references an API that reads sensitive data must include a purpose string for it.

Apple's help page on purpose strings gives the rules: explain specifically how the app uses the data, name the feature or result it makes possible, write a separate string for each resource, and give a concrete example. Write one short, complete sentence in the active voice, ending with a period, with no marketing copy and no vague benefit like "a better experience".

Apple's own example of a good string: the app uses location data to work out the route to your destination and give turn-by-turn directions. If the app is localized, each language needs its own purpose strings, and you're responsible for the strings of any SDK in the app that asks for access.

The rest of part (ii) is about consent itself: get it even for data that seems anonymous, never make paid features depend on someone granting access, and give people an easy way to withdraw consent later.

Why apps are turned down under Guideline 5.1.1(ii)

• The purpose string doesn't explain how the data is used

  It restates the resource ("This app uses your camera") or promises a general benefit without saying what the app does with it.

• A permission is requested with no purpose string

  The code, or a library in it, reaches a protected resource and the matching usage description is missing, so iOS stops the request.

• The app asks for data it doesn't need

  A permission for a feature that doesn't exist, or full access where a picker would do, which part (iii) on data minimization rules out.

How to fix it and resubmit

1. List every permission the app asks for and the feature that uses each one.
2. Remove permissions no feature needs, and the code or library that asks for them.
3. Rewrite each purpose string as one sentence naming the feature: "The app uses the camera to scan receipts you add to a trip."
4. Add a localized string for each language the app supports, and test that each request shows the right text.
5. Build, upload the new build and resubmit; purpose strings live in the app, so a new build is needed.

How Borel helps

Borel reads the Apple APIs a Borel app's own code calls and makes sure each permission it needs has a purpose string. When the AI's own sentence is missing, Borel writes a plain one that names what the feature does, such as "This app uses the camera to take the photos and scans you ask for."

Before you publish, Stamp checks that every capability the app uses has a purpose string, and flags strings too vague to say anything. Asking for a better sentence is a plain-words request in the chat.

Questions people ask

Related guidelines

• Guideline 5.1.1Data Collection and Storage
• Guideline 5.1.2Data Use and Sharing
• Guideline 2.5.1Public APIs