App Store Compliance

The 'We noticed your app collects data' App Review email, decoded

App Review emailed you about data collection or your privacy questionnaire. What that email actually means, what they want back, and how to respond so it doesn't recur.

By · · 7 min read

You got an email or Resolution Center message from App Review that reads roughly like:

We noticed that your app collects data that may be used to track the
user, but you have not indicated this in your App Store Connect
privacy information. Before we can continue, please review your app's
privacy practices and update your App Privacy responses in App Store
Connect to accurately reflect the data your app — and the third-party
SDKs it includes — collects.

This isn’t an ITMS processing error and it isn’t a Guideline rejection with a number. It’s App Review telling you the App Privacy questionnaire answers in App Store Connect don’t match what your binary actually does. The phrasing varies but the cause is almost always the same.

This decodes what they’re seeing, what they want, and how to respond so the next submission doesn’t get the same message.

For the full context, see our walkthrough of iOS privacy nutrition labels and every URL and file Apple requires for submission.

What App Review is actually seeing

When you submit, Apple’s tooling inspects your binary and the SDKs in it, then compares that against three things you control:

  1. Your App Privacy responses in App Store Connect (the nutrition-label questionnaire).
  2. Your privacy policy URL content.
  3. Your bundled PrivacyInfo.xcprivacy manifest.

If the binary contains an SDK that collects, say, a device identifier for advertising, but your App Privacy answers say “Data Not Collected,” Apple flags the discrepancy. The “we noticed your app collects data” email is the human-readable version of “your declarations are under-reporting.”

This sits under Apple’s User Privacy and Data Use requirements, enforced via Guidelines 5.1.1 and 5.1.2.

The three things that trigger it

1. A third-party SDK collects data you didn’t declare

By far the most common. You answered the App Privacy questionnaire based on what your code does, but an analytics, attribution, ad, or crash SDK collects identifiers, usage data, or diagnostics that you never declared. Apple sees the SDK’s behavior; your questionnaire doesn’t mention it.

2. You declared “Data Not Collected” with any analytics SDK present

“Data Not Collected” is the strictest possible declaration and Apple scrutinizes it hard. Almost any analytics or crash-reporting SDK collects something (at minimum Diagnostics or Identifiers). If you picked “Data Not Collected” and ship Firebase, Sentry, Amplitude, or similar, expect this email.

3. Tracking is happening but “Used to Track You” is unchecked

Your SDK links device data with third-party data for ads/measurement (Apple’s tracking definition) but in the questionnaire you didn’t mark the relevant data types as “Used to Track You,” and you have no ATT prompt. This one often arrives alongside a Guideline 5.1.2 citation — see our 5.1.2 rejection guide.

How to respond (the steps that resolve it)

Step 1: Inventory what every SDK collects

List every third-party SDK and, for each, what data it collects and the purpose. The SDK’s own privacy manifest (PrivacyInfo.xcprivacy inside the framework) is the authoritative source — Apple requires the commonly-used SDKs to ship one declaring exactly this.

# Pull the data-collection declarations out of each bundled SDK manifest
find . -name "PrivacyInfo.xcprivacy" -path "*Frameworks*" -print -exec \
  plutil -p {} \; 2>/dev/null

Step 2: Update the App Privacy questionnaire to the union

In App Store Connect → your app → App Privacy → Edit. Declare the union of what your code AND every SDK collects. For each data type:

  • Which of the 14 categories it falls in (see our category-by-category guide).
  • Whether it’s linked to identity.
  • Whether it’s used to track (per Apple’s definition).
  • The purpose (App Functionality, Analytics, etc.).

The questionnaire answers are public on your App Store listing — accuracy is the point, not minimization.

Step 3: Make the privacy policy and manifest agree

All three surfaces have to tell the same story:

  • App Privacy questionnaire — updated in Step 2.
  • Privacy policy URL — must disclose the same categories, purposes, and third parties. If you use a generator, it should map to Apple’s taxonomy (our iOS privacy policy generator post covers what to look for).
  • PrivacyInfo.xcprivacy — NSPrivacyCollectedDataTypes should list the same categories. Our privacy manifest generator derives this from the same answers.

Step 4: Reply in Resolution Center

App Privacy questionnaire changes don’t always require a new build — but you must tell App Review you’ve updated it. In Resolution Center:

We have reviewed our app and all bundled third-party SDKs. The App
Privacy responses have been updated to declare: <Identifiers –
Analytics – linked>, <Diagnostics – App Functionality – not linked>,
[etc.]. Our privacy policy at <URL> and our PrivacyInfo.xcprivacy
have been updated to match. No tracking occurs; <or: tracking is now
gated behind an ATT prompt>.

Be specific. “We updated our privacy info” with no detail often gets the same message back.

Why under-declaring is the wrong instinct

The reflex is to declare as little as possible to look privacy-friendly. That backfires: Apple can see the binary, the mismatch is mechanical to detect, and “Data Not Collected” with analytics present is a guaranteed flag. Over-declaring is safe; under-declaring is a rejection. Declaring “we collect Identifiers for Analytics” honestly costs you nothing on the App Store and clears the email immediately.