AI & TechnologyITMS-90683: Fix Missing Purpose String in Info.plist

If App Store Connect emailed you ITMS-90683, your app's code references an API that accesses sensitive user data, and Info.plist has no purpose string for it. The email names the missing key, for example NSCameraUsageDescription or NSPhotoLibraryUsageDescription. In a Flutter app the trigger is often a plugin, not your own code. The fix is to add an accurate purpose string for features you really ship, or to remove the access so the key is no longer needed.

The facts below come from Apple's developer documentation, the App Review Guidelines, the plugin READMEs and the GitHub issues listed in the sources. I checked each one on October 18, 2026.

Disclosure: App369 is my studio. I build and fix Android and iOS apps, mostly in Flutter, and the last section mentions what I sell. Apple doesn't pay me for anything on this page.

What the email says

The email heading is "ITMS-90683: Missing Purpose String in Info.plist". A Flutter issue (113603) quotes one such email, posted by an image_picker user. It includes this sentence: "While your app might not use these APIs, a purpose string is still required." Your wording may differ. Another issue (permission_handler 1543) quotes a version that also mentions entitlements, so read your own email for the key name.

That key name is the part you need. These are the keys I have seen in the sources for this page:

Why a Flutter app gets it for features it doesn't use

Apple's documentation says it plainly. App Review checks for the use of protected resources and rejects apps that contain code accessing them without a purpose string. It also says that external libraries or SDKs may reference APIs that require a purpose string, that a purpose string is still necessary even if your app doesn't use those APIs, and that you are responsible for all access of protected resources, including external SDK and library access. Source: Apple, Requesting access to protected resources.

Two common Flutter cases:

• image_picker. Its README says to add NSPhotoLibraryUsageDescription, NSCameraUsageDescription and, if you intend to record videos, NSMicrophoneUsageDescription. It adds that the photo library permission won't be requested if you always pass false for requestFullMetadata, but that "App Store policy requires including the plist entry." That matches the email quoted in issue 113603.
• permission_handler. The README says the plugin uses macros to control whether a permission is enabled. If a permission's code is compiled in, the app references that API, and Apple's page says App Review rejects code that accesses a protected resource without a purpose string.

Flutter's older issue 21941 shows this isn't new. In 2018 a developer got the same kind of email for contacts, calendars, Apple Music, motion and speech recognition keys that their app didn't use.

Fix 1: add accurate purpose strings

Do this for features your app really ships. Apple's rules for a purpose string:

• It isn't blank and isn't only whitespace.
• It is shorter than 4,000 bytes. Typical strings are one complete sentence.
• It is accurate, meaningful and specific about why the app needs the resource.
• The same rules apply to localized strings.

Add the key to ios/Runner/Info.plist. Here is the shape. These strings are examples only. Rewrite each one to say what your own app does with the data:

<key>NSCameraUsageDescription</key>
<string>EXAMPLE: Rewrite this. The camera lets you take a photo to attach to a job report.</string>
<key>NSPhotoLibraryUsageDescription</key>
<string>EXAMPLE: Rewrite this. Your photo library lets you choose an existing photo to attach to a job report.</string>

Apple's page says purpose strings help people make an informed decision, and that explaining accurately and concisely, typically in one complete sentence, improves the chances they grant access.

My advice: don't paste a generic sentence into every key just to clear the email. App Review guideline 5.1.1(ii) says "Ensure your purpose strings clearly and completely describe your use of the data." A string that describes a feature your app doesn't have is a new problem.

Fix 2: remove the access you don't use

Guideline 5.1.1(iii) says apps should only request access to data relevant to the core functionality of the app. Apple's page, in its example of an App Review message, says to either provide a purpose string or remove the code that's accessing the resource.

With permission_handler on CocoaPods, the README gives this procedure. In your Podfile's post_install block, set the macro of each permission you don't need to 0, and delete that same permission's usage description from Info.plist. The README says to use PERMISSION_CAMERA=0 instead of PERMISSION_CAMERA=1, for example. Trimmed shape:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)

    target.build_configurations.each do |config|
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [
        '$(inherited)',
        # permissions you use: keep the macro, set to 1, for example:
        'PERMISSION_PHOTOS=1',
        # permissions you don't use: set to 0, or leave the macro out
        'PERMISSION_CAMERA=0',
        'PERMISSION_CONTACTS=0',
        'PERMISSION_MICROPHONE=0',
      ]
    end
  end
end

A macro set to 1 compiles that permission in. A macro set to 0, or left out, leaves it out. Keep 1 only for permissions your app really uses. The ||= line is copied from the README.

Use the full list from the README. Its table maps each Permission to its Info.plist key and macro. Location has two macros: PERMISSION_LOCATION covers when-in-use and always, and the README says an app that only needs when-in-use should specify only PERMISSION_LOCATION_WHENINUSE.

The README also says that permission_handler by default excludes all permissions since version 8.0.0, and developers only enable those the app needs. If your Podfile came from an old template with every macro set to 1, that is a place to look.

If you build with Swift Package Manager, the README describes a different mechanism. It finds your Info.plist through the INFOPLIST_FILE setting and compiles in the permissions whose keys it finds there, so a single-flavor app needs no extra configuration. It also says that for apps with flavors, a permission declared in one plist can be compiled into every build, which it calls grounds for App Store rejection (ITMS-90683). It documents a permission_handler.yaml file to give each flavor its own plist. Issue 1558 shows a related report about location. Check the current README for your plugin version.

Rebuild and re-upload

1. Edit ios/Runner/Info.plist and, for CocoaPods, the Podfile.
2. From the ios folder, run pod install. The README's last step for the Podfile route is "Clean & Rebuild".
3. Build a new archive. The upload needs a new build number.
4. Upload again and wait for the processing email.

My advice: if your upload also fails with a different code, read it separately. For SDK version errors see the ITMS-90725 guide. For privacy manifest errors see the ITMS-91053 and ITMS-91061 guide. If a Flutter upgrade broke the iOS build itself, see the iOS build-failed-after-upgrade guide.

What happens if the string is missing at runtime

Apple's page says to always provide a valid purpose string in the Signing and Capabilities editor if your app uses a protected resource. It continues: "If you don't, attempts to access the resource fail, and might cause your app to crash." So a missing string can hurt users as well as your upload. Add the string for any feature you ship.

Need a hand?

If App Store Connect keeps flagging missing purpose strings, or App Review rejects the wording, the App Fix Ticket covers it in two fixed-price steps. A $450 Diagnosis gives you the root cause with evidence and a fixed repair quote within 3 business days, credited toward the fix. If you go ahead, the $1,200 Fix takes 5 business days and comes as a pull request. Or send me a short description.