Make ITMS-91053 Stop Catching Your Rork Max App — A Release-Proof Privacy Manifest Workflow

Step 2: Assign the Right Reason Codes

Once you know the categories, assign each one a reason code that matches reality. Misaligning this is itself a policy violation and turns into a different kind of problem. Here are the four categories that come up most in Rork Max apps with their typical sources and reason codes.

The principle worth holding onto: don't pick a reason code that "looks about right" — pick the one that matches how your app actually uses it. If an ad SDK is the only thing pulling in DiskSpace and your own code never checks free space, confirm whether E174.1 (a pre-write check) genuinely fits. If it doesn't, look up the reason code that corresponds to the real use in Apple's documentation.

Step 3: Aggregate Declarations in the App-Level Manifest

Even when libraries ship their own PrivacyInfo.xcprivacy, the app-level manifest is the source of truth. Review looks at the set of declarations in the final binary, so it's safest to explicitly declare in the app manifest any category pulled in by your own code or by older libraries that lack a manifest. Aggregate them in ios/PrivacyInfo.xcprivacy like this.

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
  <key>NSPrivacyTracking</key>
  <false/>
  <key>NSPrivacyCollectedDataTypes</key>
  <array/>
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>CA92.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>C617.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>E174.1</string></array>
    </dict>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array><string>35F9.1</string></array>
    </dict>
  </array>
</dict>
</plist>

Because Rork Max emits an Expo-based project under the hood, it's better to declare this as an Expo config plugin than to drop the file into ios/ by hand each time — that way it regenerates in the right place on every prebuild. Add the following to app.config.js and your declarations survive even when the native directory is rebuilt.

// app.config.js
module.exports = {
  expo: {
    ios: {
      privacyManifests: {
        NSPrivacyAccessedAPITypes: [
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryUserDefaults",
            NSPrivacyAccessedAPITypeReasons: ["CA92.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryFileTimestamp",
            NSPrivacyAccessedAPITypeReasons: ["C617.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryDiskSpace",
            NSPrivacyAccessedAPITypeReasons: ["E174.1"],
          },
        ],
      },
    },
  },
};

The advantage of keeping it in config is that the declaration stays under source control even if you .gitignore the ios/ directory. A hand-written PrivacyInfo.xcprivacy tends to get overwritten or wiped on prebuild, so anchoring the declaration in the config file is the more durable choice.

Step 4: Catch It Yourself Before You Upload

This is where the workflow pays off most. ITMS-91053 hurts because it's detected half a day after upload. Pull detection forward to your machine and the round-trip vanishes. There are two ways, and wiring up both is reassuring.

The first is to inspect the aggregated manifest in the .ipa/.xcarchive you built. The script below compares the covered categories referenced in the archive against the categories already declared in your app manifest, and fails if any are undeclared.

#!/usr/bin/env bash
# preflight-privacy.sh ARCHIVE_OR_IPA APP_MANIFEST
set -euo pipefail
TARGET="$1"; MANIFEST="$2"
 
# Categories referenced on the binary side
used=$(grep -rhoE "NSPrivacyAccessedAPICategory[A-Za-z]+" "$TARGET" 2>/dev/null | sort -u)
# Categories already declared in the app manifest
declared=$(grep -oE "NSPrivacyAccessedAPICategory[A-Za-z]+" "$MANIFEST" | sort -u)
 
missing=$(comm -23 <(echo "$used") <(echo "$declared"))
if [ -n "$missing" ]; then
  echo "❌ Undeclared categories found:"; echo "$missing"
  exit 1
fi
echo "✅ No missing declarations"

The second is to run Apple's own validation before upload. Use "Validate App" in Xcode Organizer, or xcrun altool --validate-app from the CLI, to run the pre-distribution checks that include ITMS-91053. Inserting this step before eas submit stops the bulk of rejections on your machine.

# Validate locally before distribution (credentials are placeholders)
xcrun altool --validate-app \
  -f ./build/YourApp.ipa \
  -t ios \
  --apiKey "YOUR_ASC_KEY_ID" \
  --apiIssuer "YOUR_ASC_ISSUER_ID"

If rejections keep repeating after you changed the config, your build cache may still hold the old declaration. Rebuild with eas build --platform ios --clear-cache and validate against the fresh artifact.

Step 5: Turn "Prove It Every Release" Into a System

Finally, make these three jobs run automatically on every release instead of being a one-off. What I actually do on my own indie apps is bind the preflight check to the release build profile. Wire preflight-privacy.sh into an EAS post-build hook or your CI release job, and stop the release if even one category is undeclared.

{
  "build": {
    "production": {
      "ios": { "buildConfiguration": "Release" },
      "env": { "PRIVACY_PREFLIGHT": "1" }
    }
  }
}

On top of that, include the privacyManifests block in app.config.js in code review, and make "did you run the Step 1 inventory script?" a checklist item on any PR that adds a new library. That way the person adding the dependency notices the drift on the spot. Running npx expo-doctor before release also helps, since it surfaces missing library-side manifests early.

Once it's a system, ITMS-91053 changes character — from "an occasional nuisance" to "a check that always turns green before upload." Apple has signaled it will keep expanding the Required Reason API scope, so the more you lean on regenerating and re-validating declarations every release, the more automatically you'll keep up with future requirements.

There's one thing you can do today: run scan-required-reason.sh on your project and check that every category it surfaces is present in the privacyManifests block of app.config.js. Any difference you find is the seed of your next rejection — better to pull it now. Thanks for reading.