Your Resolution Center note cited Guideline 5.1.2(i) and the reviewer attached a screenshot of your AI feature beside the App Privacy section in App Store Connect. The fix is usually not a redraft of the privacy policy: it is making the nutrition label, the consent UI, and the actual data sent to OpenAI or Anthropic say the same thing.
Short answer
Apple checks three things when it flags a 5.1.2(i) rejection on third-party AI: the disclosed App Privacy categories in App Store Connect, the in-app consent screen, and the data the binary actually transmits to the provider. When all three line up, the rejection clears. When the label says no data is linked to the user but the binary sends authenticated chat messages to OpenAI, the reviewer treats that as a 5.1.2(i) breach.
What you should know
- The five fields Apple checks on each third party. Every third party on your App Privacy declaration carries five attributes: data types collected, purposes, the linked-to-user flag, the tracking flag, and the third party's identity.
- AI providers do not get a built-in nutrition label category. OpenAI, Anthropic, and Google Gemini are declared the same way as any analytics or backend SDK: by listing the data types you actually send and the purpose.
- User Content is the most common forgotten category. Apps that send chat text or transcripts to an LLM almost always need User Content (Other User Content) declared alongside any identifier the request carries.
- Linked vs Not Linked is decided by what your backend sends, not the provider's marketing. If your call to the OpenAI API carries a user ID, the data is linked, even if OpenAI does not reuse it.
- Tracking is its own decision. Tracking means linking user or device data with third-party data for advertising or sharing with data brokers. Sending a transcript to OpenAI for the AI reply does not count as tracking under Apple's definition.
What does Guideline 5.1.2(i) actually ask you to disclose?
The short answer is a clear, in-app statement naming each third party (including AI providers) and an explicit consent grant before personal data leaves the device.
The exact language in Apple's App Review Guidelines 5.1.2(i) reads: "You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so." The phrase "including with third-party AI" was added on November 13, 2025, per Apple's news post on the updated guidelines.
In practice, the clause works on two surfaces. The first is the App Privacy declaration inside App Store Connect, which becomes the visible nutrition label on the App Store page. The second is the consent UI inside the binary that appears before the first transmission. Reviewers expect both to exist and to describe the same data flow. When the label is silent on User Content but the app sends chat text to OpenAI, the rejection cites 5.1.2(i) regardless of how clean the consent screen is.
Which App Privacy categories cover the data sent to OpenAI or Anthropic?
The short answer is whichever categories your binary actually sends, plus the identifier you attach to the request.
Apple's App Privacy Details page lists fourteen top-level data categories. For an AI feature that sends prompts to a third-party model, the categories that typically apply are User Content (the text or audio the user provided), Identifiers (the user ID or session ID attached to the API call), Usage Data (only if you also log the interaction with the AI feature), and occasionally Contact Info (when the user pastes an email or phone number into the prompt).
Two patterns appear in most rejection cases. The first is the missing User Content row: the developer declared identifiers because the SDK is obvious, but forgot the chat text itself, which is the primary thing being sent. The second is the under-counted purpose: the data flows to OpenAI for App Functionality (generating the AI reply), but the declaration omits the purpose entirely, which reads to a reviewer as a half-finished label.
| Data type | When to declare for AI | Linked? | Tracking? |
|---|---|---|---|
| User Content > Other User Content | Chat text, prompts, transcripts sent to the LLM | Yes if a user ID accompanies the request | No, unless joined with third-party ad data |
| Identifiers > User ID | When your backend forwards an account ID to the provider | Yes | No |
| Identifiers > Device ID | If the IDFA is passed through to the AI call | Yes | Yes if used for advertising |
| Usage Data > Product Interaction | When you log feature usage with the prompt content | Yes | No |
| Contact Info > Email | When users paste emails into prompts and you forward them | Yes | No |
The table is a starting point. The actual declaration follows the binary, not the table.
How do I decide whether AI data sharing counts as Tracking?
The short answer is only when the AI data is linked with third-party data for advertising, or sold to data brokers.
Apple's definition of tracking is narrower than most teams assume. Tracking is linking user or device data collected from your app with user or device data collected from other companies' apps, websites, or offline properties for targeted advertising or advertising measurement, or sharing user or device data with data brokers. Sending a prompt to OpenAI to compute the AI reply, with no advertising use case downstream, sits outside that definition. The flow still requires the 5.1.2(i) consent screen, but it does not require App Tracking Transparency permission.
There is a real exception. When the app pipes the user content through a vendor whose business model is ad targeting, or when the AI provider is contractually allowed to combine the data with its own advertising graph, the tracking flag is correct. Most direct OpenAI or Anthropic API integrations do not fall in that bucket, because those providers do not run ad networks. Some smaller AI SDKs do, and the data sheet for each SDK is what decides the flag.
What goes on the in-app consent screen, and what goes on the label?
The short answer is that the label describes the data flow at rest, and the consent screen asks for permission at the moment of the first call.
The two surfaces serve different purposes for App Review. The label is a settled statement: this app sends these data types to these third parties for these purposes. The consent screen is a transactional act: the user grants explicit permission for a specific data sharing event. Both are required for AI features under 5.1.2(i).
Concretely, the consent screen names the provider (OpenAI or Anthropic), names the data category in plain English (the message you type), states the purpose (to generate the assistant reply), and offers an Allow or Don't Allow choice that the app remembers. The screen lives in the native shell, not inside model output. The label, by contrast, sits in App Store Connect under App Privacy and translates the same flow into the structured fields Apple uses across the store.
For pre-submission verification, walking the app with a network proxy (mitmproxy, Charles Proxy, Proxyman) and watching every outbound call is the cleanest check. Each non-first-party host in the trace should map to a row in the App Privacy declaration and to a consent screen the user saw. For teams that want this verification automated against the OWASP MASVS data storage and network controls, PTKD.com (https://ptkd.com) is one of the platforms that scans compiled IPAs and AABs, lists the third-party hosts the binary calls, and lines those hosts up against the categories declared in the nutrition label.
How do I keep the label, the manifest, and the binary in sync over time?
The short answer is to change the label and the consent UI in the same release that changes what the binary sends.
Three updates tend to drift apart. The first is adding a new model provider mid-cycle (swapping the chat backend from OpenAI to Anthropic) without touching the App Privacy declaration; the reviewer sees a call to a domain that does not appear on the label. The second is adding a feature that pipes more data (a summarize-my-photos capability that now sends image content) without updating the User Content row. The third is changing the consent copy in the in-app screen but forgetting to mirror the language in the privacy policy URL referenced by App Store Connect.
A simple guardrail: treat the App Privacy declaration as part of the release checklist, not as a one-time setup. When the diff in the release changes outbound calls, the declaration changes in the same submission. The Privacy Manifest file, PrivacyInfo.xcprivacy, declares SDK-level data flows; the App Privacy declaration in App Store Connect declares app-level flows; the consent UI declares the user-facing moment. The three surfaces are independent but must agree.
What to watch out for
The first trap is treating "I do not store the data" as a defense. The 5.1.2(i) clause is about sharing, not about retention. Sending a prompt to OpenAI and discarding the response on the server is still a third-party data share at the moment of the API call, and the label has to reflect that.
The second trap is grouping all AI providers under one row. If the app calls both OpenAI and Anthropic, both providers appear on the App Privacy declaration. Bundling them into a single AI partner row is the kind of generic label that triggers a reviewer second look, and the Resolution Center note often quotes the missing third party by name.
The third trap is assuming on-device inference removes the entire clause. When the on-device model runs and the result never leaves the device, the clause does not apply to that specific flow. When the on-device model produces a transcript that the app then forwards to a cloud LLM, the cloud call is back inside 5.1.2(i). The boundary is the network call, not the inference style. This is one of the myths reviewers most often correct in Resolution Center replies cited on the Apple Developer Forums.
The fourth trap is treating the privacy policy URL as the disclosure. The policy can describe sharing in detail and still fail 5.1.2(i), because the clause asks for an in-app consent moment, not a buried paragraph the user clicks through during account creation.
Key takeaways
- Match the App Privacy nutrition label to the data your binary actually sends to OpenAI, Anthropic, or any other AI provider, including the User Content row when prompts or transcripts leave the device.
- Treat the in-app consent screen and the nutrition label as separate, both-required surfaces under 5.1.2(i): the label is the static disclosure, the consent is the explicit permission for the specific share.
- List third-party AI providers individually on the App Privacy declaration; bundling them into a generic AI row reads as a missing disclosure to App Review.
- Update the App Privacy declaration in the same submission that changes the AI backend, the data sent, or the consent copy; drift between these surfaces is one of the most common 5.1.2(i) findings.
- Some teams outsource the verification step to platforms like PTKD.com (https://ptkd.com) that scan a compiled IPA, list the third-party hosts the binary reaches, and check those hosts against the OWASP MASVS data storage and network controls before submission.
