Skip to content
Get a quote

App Store Connect upload errorApp Store Connect: “ITMS-90683: Missing purpose string in Info.plist”

You uploaded a build and App Store Connect emailed ITMS-90683: Missing purpose string in Info.plist, naming a key such as NSCameraUsageDescription or NSPhotoLibraryUsageDescription. Something in the app can reach a protected resource, like the camera, photos, location or contacts, and the app does not say why. Apple wants a short sentence for each one, or the code gone.

Short answer

Read the key names in the email. For each one (NSCameraUsageDescription, NSMicrophoneUsageDescription, NSPhotoLibraryUsageDescription, NSLocationWhenInUseUsageDescription, NSContactsUsageDescription and so on), add that key to the app target’s Info.plist, or in Xcode under the target’s Info tab, with one plain sentence saying what the app does with the access, then upload a new build. If the app never uses that resource, the code that touches it is usually inside a plugin or SDK: remove or replace that dependency, or add an honest purpose string anyway.

Why the upload is flagged, and the fix

  1. 01

    Code in the app can reach a protected resource

    “App Review checks for the use of protected resources, and rejects apps that contain code accessing those resources without a purpose string.” Apple, Requesting access to protected resources

    Apple scans the uploaded build for APIs that touch the camera, microphone, photos, location, contacts, Bluetooth and similar resources. Any key that is missing is listed in the email. Per Apple, App Review rejects apps with code that accesses these resources without a purpose string.

  2. 02

    Add the key the email names, with a real sentence

    “The purpose string provides a description that’s accurate, meaningful, and specific about why the app needs to access the protected resource.” Apple, Requesting access to protected resources

    Each resource has its own key, such as NSCameraUsageDescription for the camera. Add it to Info.plist with a sentence a person can judge: what the app does with the access, in plain words. Apple says the string must be accurate, meaningful and specific, so a vague one like “This app needs the camera” risks a rejection in review. No Info.plist file in the project? Newer Xcode projects keep these keys in the target’s Info tab and store them as build settings such as INFOPLIST_KEY_NSCameraUsageDescription.

    <key>NSCameraUsageDescription</key>
<string>Take a photo of your receipt to attach it to an expense.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>Choose a photo from your library to use as your profile picture.</string>

  3. 03

    The app never uses it: a plugin or SDK does

    “To resolve this issue, provide a purpose string that explains why the app needs access to this sensitive information, or remove the code that’s accessing the resource.” Apple, Requesting access to protected resources

    Flutter plugins, React Native packages and SDKs such as image pickers, QR scanners or ad libraries often include camera, photo or location code even if your screens never call it. Remove the package you do not need, or swap it for one without that code. If the code has to stay, add the purpose string so the build passes.

  4. 04

    Check every target and every language

    “Create a string catalog file called InfoPlist.xcstrings, and build your app to populate the string catalog with keys for the usage description strings in your app.” Apple, Requesting access to protected resources

    Extensions such as widgets, share extensions and watch apps have their own Info.plist, so a key may be missing there and not in the main app. If the app is localized, add the translated strings too, but keep the base key in Info.plist. Then archive and upload a new build with a higher build number.

Checked against the vendor’s docs on : Apple Developer: Requesting access to protected resources; Apple Developer: NSCameraUsageDescription.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Resubmit before Apple’s holiday slowdown

Pay for the Diagnosis and send the rejection and access to the app by (US Eastern). The Diagnosis is back by . Pay for the Fix that day and it arrives as a pull request by , in time to build and resubmit before .

In past years Apple said reviews may take longer around the holidays: December 20 to 26 in 2024 (opens in a new tab), December 22 to 27 in 2023 (opens in a new tab), December 23 to 27 in 2022 (opens in a new tab). Apple hasn’t posted its 2026 dates yet (checked ). Approval stays Apple’s decision.

Related: ITMS-91053 Missing API declaration · ITMS-90725 SDK version issue · App Store Guideline 5.1.1 data collection · App Store Guideline 2.3

Questions

More on this rejection

Can I leave the string empty or write something generic?

No. Apple says to provide a valid purpose string that is accurate, meaningful and specific about why the app needs the access. A vague one can pass the upload and still be questioned in review.

What happens if the app asks for access without the key?

Apple says the access attempt fails and might crash the app. That is why the upload check exists: a missing key would break the feature for every user.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.

Describe your problem All fixes