iOS requires apps to show a custom explanation string alongside every permission request — camera, microphone, contacts, and so on — and that string has to clearly and honestly explain what the permission is used for, matching the app's actual behavior.
Why apps actually get flagged
Frequently caused by a generic or missing purpose string, like "App needs your location," that doesn't explain what feature actually needs it.
A real example
"Your app requests access to a protected resource, but the accompanying purpose string does not adequately explain how the data will be used, per guideline 5.1.1."
The short version, in more detail
Before an app can ask for the camera, location, contacts, photos, microphone or other protected data, it must tell the user why in a purpose string. Apple checks that these strings exist, are specific, and match how the app really uses the permission. Missing or vague purpose strings cause both automated upload errors and human rejections.
What this guideline covers
Purpose strings: the short text shown in the system permission prompt, which explains the reason for access.
Whether each permission the app or its libraries can request has a matching string.
Whether the request is made in a context where the user can understand why it is needed.
Whether the app remains usable if the user declines an optional permission.
What usually triggers this rejection
A permission is used in code or by a library, but the matching purpose string is missing from the app configuration, which produces an upload error such as ITMS-90683.
The purpose string is generic ("This app needs your location") and does not explain the benefit to the user.
The app asks for a permission it does not obviously need, or asks at launch before the user has a reason to agree.
The app refuses to work if the user declines an optional permission.
A third-party SDK references a permission the developer did not realise was in the build.
How reviewers evaluate it
Automated checks on upload flag missing purpose strings before a human ever sees the build.
Human reviewers read the strings and judge whether they are specific and honest.
They look at the moment the prompt appears and whether the app works without optional access.
They compare the permissions requested with the features described in the listing.
Common misunderstandings
An error about a permission does not always mean your own code uses it. Libraries can reference it too.
One generic sentence reused for every permission is a common reason for rejection.
Declined permissions are expected. Apps are not supposed to break because the user said no to something optional.
Common questions
What does ITMS-90683 mean?
It is an automated message saying a purpose string needed for a protected resource is missing from the app's configuration.
Why would motion or fitness access appear in my app?
Some libraries reference motion data by default, which can trigger the requirement even if your own features do not use it.
Are purpose strings shown to users?
Yes. They appear in the system permission prompt, so they are part of the user experience as well as a review requirement.
Platform rules change often. This page is a plain-language explanation written by AppReviewFix, not official guidance. Check the current App Store Review Guidelines for the exact wording.
Got this exact rejection?Paste it in and get a diagnosis specific to your app, free.