ITMS-90683 — missing purpose string

Find which dependency brought it in

# what the built app actually declares
/usr/libexec/PlistBuddy -c "Print" ios/*/Info.plist | grep -i 'UsageDescription' -A1

# which pods link the capability
grep -rl "AVCaptureDevice\|CLLocationManager\|PHPhotoLibrary\|CNContactStore" \
  ios/Pods --include="*.h" --include="*.m" --include="*.swift" 2>/dev/null \
  | cut -d/ -f3 | sort -u

# what your config plugins add
grep -A40 '"plugins"' app.json app.config.js 2>/dev/null

The usual culprits in an RN tree: image pickers and camera wrappers, anything doing QR scanning, media library access, geolocation, contacts import, audio recording, and several analytics or support SDKs that bundle a screenshot or screen-recording feature.

The two fixes

If the feature is real: add the key with a purpose string that names the actual feature, set through app config or the plugin rather than in the generated Info.plist.

["expo-camera", {
  "cameraPermission": "Used to photograph a job so it can be attached to the invoice."
}]

Write your own string. Plugin defaults are generic, and a generic purpose string is both a worse user prompt and a weaker answer when App Review asks what the permission is for.

If the feature is not real: remove the dependency. That removes the key, removes the review question, and usually removes a privacy-manifest obligation at the same time. A capability you do not use is pure liability. Auditing what your config plugins added.

Why "add a generic string to get it uploaded" backfires

It works, and it moves the problem downstream to somewhere more expensive.

The upload succeeds. Then a reviewer reads an Info.plist declaring camera access, looks for a camera feature, does not find one, and you are in Guideline 5.1.1 data-minimisation territory — where the fix is the thing you avoided doing, and you have now spent a full review cycle finding that out.

The same applies with more force to location: Guideline 2.5.4 specifically addresses declaring the location background mode without a legitimate persistent-location feature. Detail.

The Expo trap

ios/ is a build artefact regenerated on every prebuild. Adding the key directly to ios/YourApp/Info.plist works locally, disappears when EAS rebuilds, and produces an identical second upload failure — with the change having been correct both times.

Set it in app.json, app.config.js, or a config plugin. Why RN and Expo fail differently.

Where it sits among the other upload blockers

All four are checked at upload, before review, and an app can hit several in one submission. They also share a cause: capability arriving through a dependency rather than through a decision.

That is why the useful habit is auditing on a dependency change rather than before a release. shipcheck reads app config, config plugins, the generated Info.plist, Podfile.lock and node_modules together and reports purpose strings with no corresponding code path, before you build. What it checks. · The first-submission checklist.

Questions and answers