Expo Missing Purpose String Rejection: The Real Fix

What is this rejection actually telling you?

Two presentations, one disease. At upload, App Store Connect bounces the build with ITMS-90683 naming a missing purpose string; at runtime, the app dies the instant a permission prompt should have appeared. Either way the meaning is identical: the binary references a protected API, and Info.plist lacks the matching usage-description key, the NS…UsageDescription entries Apple documents for camera, microphone, photo library, location, contacts, and the rest.

The diagnostic fork is the whole triage: does your app actually use the named capability? If yes, you owe a real purpose string. If no, something in your dependency tree references the API anyway, and the right fix is removal, not boilerplate, because shipping a camera explanation for a camera you never open is the wrong kind of compliance.

Where does the fix live in an Expo project?

In app.json, two ways, both landing in Info.plist at prebuild:

{
  "expo": {
    "plugins": [
      ["expo-camera", { "cameraPermission": "Scan documents to attach them to your reports." }],
      ["expo-location", { "locationWhenInUsePermission": "Show walks on the map while you record them." }]
    ],
    "ios": {
      "infoPlist": {
        "NSMicrophoneUsageDescription": "Record voice notes you choose to attach."
      }
    }
  }
}

The config plugins for capability-bearing packages (Expo’s permissions guide catalogs them) accept the strings as options, which is the preferred route because the plugin keeps key and capability in sync. Anything without a plugin goes under ios.infoPlist directly. Rebuild, npx expo prebuild then a new binary, because purpose strings live in the build, not in JavaScript; no hot reload ever fixes this class.

When the named capability is a stranger, hunt the reference: search node_modules for the key name or API, check recently added packages first, and remember the usual suspects, kitchen-sink media libraries, analytics SDKs with optional capture features, and the agent-added image picker from three Tuesdays ago. Configure the library to exclude the capability, replace it with a narrower one, or supply the string only if the transitive use is real.

What makes a purpose string good instead of merely present?

String	Review outcome	Prompt outcome	Verdict
”Scan documents to attach them to your reports.”	Passes	Users grant; the benefit is theirs	The bar: specific action, user’s benefit, one sentence
”This app needs camera access.”	5.1.1 magnet	Users hesitate; whose need?	Present but worthless; the classic AI-generated filler
”Camera.”	Rejection bait	Distrust	Never
A string for an unused capability	Scrutiny of the whole app	n/a	Remove the capability instead

The string appears verbatim in the system permission prompt, which makes it conversion copy as much as compliance: a user deciding whether to grant camera access is reading your one sentence, and the version that names their benefit wins grants as well as review. Write it in the user’s language (it localizes with the app), keep it to one sentence, and let it match what the feature visibly does, the same say-what-happens honesty that runs through the transcription app’s mic strings and the background location disclosures.

How does this fit the AI-builder workflow?

As the canonical skipped side-requirement. Agents add capability-bearing packages fluently, an image picker for the avatar feature, a location hook for the store finder, and the plist edit is precisely the kind of adjacent obligation they omit unprompted; the build then fails days later at upload, wearing an error code nobody recognizes. The standing prompt clause costs one line: “any dependency touching camera, microphone, photos, location, or contacts ships with the matching app.json permission string and a one-line justification.”

Triage discipline transfers from the rest of the toolchain series: read the actual error (ITMS codes name the exact key), fix the build configuration, and keep the agent away from refactoring innocent JavaScript, the same machine-not-code instinct as the ffi architecture fix. The rejection most often lands at the TestFlight gate, the same pipeline stage covered in the Replit-to-iPhone guide, and clearing it there, before the 10,000-tester external track, is the cheap place to clear it. The capability audit is also a privacy audit for free: every purpose string your app ships is a promise the deeper 5.1.1 data-collection rules hold you to.

The screens behind the permissions, the scanner, the recorder, the map, start as ever from a free VP0 design generated by Claude Code or Cursor; the permission strings are the one part of the feature the design cannot carry, which is exactly why they belong in the prompt.

The sibling build-time registration, custom fonts that vanish between preview and device, follows the same plist-and-naming logic in the Rork Xcode fonts fix.

Key takeaways: missing purpose string in Expo

• One disease, two faces: ITMS-90683 at upload or a crash at the prompt; the binary references a protected API without its NSUsageDescription key.
• The fork is the triage: real feature → real string; stranger capability → find and remove the dependency reference, never boilerplate it.
• Fix in app.json, rebuild: plugin options for capability packages, ios.infoPlist for the rest; purpose strings live in the build, not in JS.
• Specific, user-benefit, one sentence: the string is conversion copy in the system prompt and a shield against the guidelines’ privacy rules (5.1.1) in review.
• Put the obligation in the agent’s standing prompt, audit capabilities at the TestFlight gate, and start the screens from a free VP0 design.

Frequently asked questions

How do I fix the missing purpose string rejection in Expo? Name the API from the error, then either supply the string (plugin options or ios.infoPlist in app.json) and rebuild, or remove the dependency that references a capability you never use.

What is Apple actually requiring? A user-facing usage-description key for every protected resource the binary references, per the NS…UsageDescription documentation; missing keys reject at upload or crash at the prompt.

Why does the rejection name a feature my app doesn’t use? A dependency references it: kitchen-sink media libraries, SDK optional features, agent-added packages. Search, then exclude, replace, or honestly justify.

What makes a purpose string pass review instead of drawing 5.1.1? One specific sentence stating the user’s benefit (“Scan documents to attach to your reports”), never generic need-statements; it doubles as grant-rate copy.

How do I stop AI agents from reintroducing this? A standing clause: capability-touching dependencies ship with their app.json permission string and a one-line justification, enforced at review like any other diff rule.