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

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
            NSPrivacyAccessedAPITypeReasons: ["CA92.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategoryFileTimestamp",
            // C617.1 = reading timestamps of files inside your own app
            NSPrivacyAccessedAPITypeReasons: ["C617.1"],
          },
          {
            NSPrivacyAccessedAPIType: "NSPrivacyAccessedAPICategorySystemBootTime",
            NSPrivacyAccessedAPITypeReasons: ["35F9.1"],
          },
        ],
      },
    },
  },
};

Pick reason codes from Apple's defined list that match your use. If you use UserDefaults to store the app's own settings, that is CA92.1; if you only read timestamps of files inside your own app, C617.1. Choosing a code that does not match reality is itself a false declaration, so I strongly recommend confirming the use before choosing.

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.

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. Next time you ship, make a habit of inserting that one verification command before submission. Your release rhythm steadies in proportion to the warning emails that stop arriving.