Keep Your Rork App's Review From Stalling on a Privacy Manifest Gap

You can work out the categories from your features, in advance

If you only start investigating once the warning arrives, you have already added a round trip to your submission. But you can predict what your app trips with surprising accuracy. Rork's generated code sits on top of the Expo module set, so "if you do this, you will be declaring that category" is largely determined up front.

Here is the mapping I put together for my own Rork projects.

The table assumes "if that is your use." The same category takes a different reason code for a different purpose, and picking a code that does not match reality is itself a false declaration. Rather than copying the table, check once which row your implementation actually lands on.

Write the manifest in app.config.ts

In Expo, rather than editing the native PrivacyInfo.xcprivacy directly, the right path is to write the declaration in the iOS config of app.config.ts (or app.json). Do this and the manifest ships automatically every time you rebuild the Rork project — no manual re-pasting.

// app.config.ts
export default {
  expo: {
    ios: {
      privacyManifests: {
        NSPrivacyAccessedAPITypes: [
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryUserDefaults",
            // CA92.1 = UserDefaults access for the app itself only
            NSPrivacyAccessedAPITypeReasons: ["CA92.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryFileTimestamp",
            // C617.1 = timestamps of files inside your own container
            NSPrivacyAccessedAPITypeReasons: ["C617.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryDiskSpace",
            // E174.1 = checking free space before writing
            NSPrivacyAccessedAPITypeReasons: ["E174.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategorySystemBootTime",
            // 35F9.1 = measuring time elapsed between in-app events
            NSPrivacyAccessedAPITypeReasons: ["35F9.1"],
          },
        ],
      },
    },
  },
};

Pick reason codes from Apple's defined list that match your use. NSPrivacyAccessedAPITypeReasons is an array because one category can serve several purposes. If you use free-space checks both before a write and to display usage on a settings screen, list E174.1 and 85F4.1 together. Declaring only one while doing both is its own kind of gap.

The collected-data filing is separate from Required Reason APIs

Everything above covers only the second of the two requirements from the opening. The other one — declaring what you collect via NSPrivacyCollectedDataTypes — is still outstanding. Clearing the Required Reason API warnings while leaving this empty is an incomplete filing.

For a Rork app monetized with AdMob, the advertising identifier and crash data are the minimum in scope.

// app.config.ts — inside ios.privacyManifests
privacyManifests: {
  NSPrivacyTracking: true,
  NSPrivacyTrackingDomains: ["googleads.g.doubleclick.net"],
  NSPrivacyCollectedDataTypes: [
    {
      NSPrivacyCollectedDataType: "NSPrivacyCollectedDataTypeDeviceID",
      NSPrivacyCollectedDataTypeLinked: false,
      NSPrivacyCollectedDataTypeTracking: true,
      NSPrivacyCollectedDataTypePurposes: [
        "NSPrivacyCollectedDataTypePurposeThirdPartyAdvertising",
      ],
    },
    {
      NSPrivacyCollectedDataType: "NSPrivacyCollectedDataTypeCrashData",
      NSPrivacyCollectedDataTypeLinked: false,
      NSPrivacyCollectedDataTypeTracking: false,
      NSPrivacyCollectedDataTypePurposes: [
        "NSPrivacyCollectedDataTypePurposeAppFunctionality",
      ],
    },
  ],
  NSPrivacyAccessedAPITypes: [
    // the Required Reason API declarations from above go here
  ],
}

Linked means tied to the user's identity; Tracking means combined with other companies' data for tracking. If you hand the advertising identifier to third-party advertising, Tracking is true.

There is one trap here that actually changes runtime behavior. Domains listed in NSPrivacyTrackingDomains are blocked by the OS whenever App Tracking Transparency permission has not been granted. The declaration is not a safety blanket — network behavior changes the moment you write it. Discovering this backwards, from what looks like a drop in ad fill rate, costs real time to isolate. Before listing a domain, confirm your ATT consent flow is implemented and actually appearing.

One more thing. This manifest does not replace your "App Privacy" answers in App Store Connect. Both are required, and a mismatch between them gets flagged in review. The manifest covers what your own code collects; an SDK's share is carried by the SDK's own manifest. Your App Store Connect answers, by contrast, must cover the whole picture including what SDKs collect. That asymmetry is easy to miss, so I have fixed my order of operations: edit app.config.ts, then go straight to App Store Connect and re-read the answers.

Do not skip the third-party SDK check

This is the most overlooked pitfall. However well you set up your own app.config.ts, if AdMob or an analytics SDK does not carry its own privacy manifest, the warning will not clear.

The procedure looks like this.

1. Bump the SDK versions. Most major SDKs ship the manifest in their compliant releases. AdMob (the Google Mobile Ads SDK) has shipped it since a certain version too.
2. If an SDK update alone does not cover it, add the API categories that SDK touches to your own manifest and declare the reason.
3. Confirm that each SDK's .xcprivacy is included inside the built .app.

In my case, the warning persisted because of a leftover old analytics library. Bumping one SDK cleared two warnings at once, so I find it efficient to start from updating dependencies.

Verify it yourself before submitting

Waiting for the warning after submitting wastes time. After exporting the archive, I confirm the bundled state locally before submitting. I look inside the build artifact to eyeball whether both the app itself and the major SDKs carry a privacy manifest.

# List the manifests inside the exported .app
find MyApp.app -name "*.xcprivacy" -print
# e.g. MyApp.app/PrivacyInfo.xcprivacy
#      MyApp.app/Frameworks/GoogleMobileAds.framework/PrivacyInfo.xcprivacy

If your own app's manifest does not show up here, the app.config.ts declaration did not make it into the build. If an SDK's is missing, that SDK is non-compliant or out of date. After adding this one step, I almost stopped receiving warning emails.

Stop eyeballing it and return an exit code instead

Eyeballing gets forgotten, though. There is a lot to check before a release, and eventually you skim the list, decide it "looked fine," and move on. Partway through I started inserting this script.

#!/usr/bin/env bash
# verify-privacy-manifests.sh — pre-submission bundling check
# usage: ./verify-privacy-manifests.sh path/to/MyApp.app
set -euo pipefail
 
APP_PATH="${1:?pass the path to the .app}"
REQUIRED_SDKS=("GoogleMobileAds" "ExpoModulesCore")
missing=0
 
APP_MANIFEST="${APP_PATH}/PrivacyInfo.xcprivacy"
if [ ! -f "${APP_MANIFEST}" ]; then
  echo "FAIL: no app-level manifest (app.config.ts did not reach the build)"
  missing=1
else
  echo "OK: app-level PrivacyInfo.xcprivacy"
  # reject the file-exists-but-zero-declarations case
  if ! /usr/libexec/PlistBuddy -c "Print :NSPrivacyAccessedAPITypes:0" \
      "${APP_MANIFEST}" >/dev/null 2>&1; then
    echo "FAIL: NSPrivacyAccessedAPITypes is empty (shipping it will not clear the warning)"
    missing=1
  fi
fi
 
for sdk in "${REQUIRED_SDKS[@]}"; do
  if find "${APP_PATH}/Frameworks" -path "*${sdk}*" -name "*.xcprivacy" 2>/dev/null | grep -q .; then
    echo "OK: ${sdk}"
  else
    echo "FAIL: no manifest found for ${sdk} (possibly an outdated version)"
    missing=1
  fi
done
 
exit "${missing}"

A note on why it is written this way.

set -euo pipefail is there so a forgotten argument or a mid-script failure is never treated as a pass. A check script that quietly reports success is the worst outcome; I would rather it fall over.

REQUIRED_SDKS is an array so that adding one SDK is a one-line change. Rork projects accumulate dependencies with every feature, and keeping this spot easy to edit is what makes the habit survive.

The PlistBuddy read of the first element exists to catch a manifest that ships but contains nothing. Get the app.config.ts shape wrong and the file can be generated with no declarations inside — and a find listing will look perfectly healthy. That is exactly the case I missed first time around.

Returning exit "${missing}" means that even while you still run it by hand, you can later hang it off an EAS Build post-build hook or CI without rewriting anything.

Build it once and operation is light

A privacy manifest takes a lot of looking-up the first time, but once it is written correctly in app.config.ts it keeps shipping automatically on every build. All you need to check before release is whether a new feature trips a new Required Reason API.

Not stalling in review is unglamorous but ties straight to revenue. Lose a few days to a resubmission and that much AdMob impression and paid opportunity slides back. On your next release, start by running the verification script once against the exported .app. If it passes, submit; if it fails, the script names the cause for you.

Few things are as costly as days lost to a stalled review. I hope this helps you claw those days back.