You uploaded the build, the App Privacy questionnaire in App Store Connect is filled in, and the Resolution Center reply still cites Guideline 5.1.2, Legal, Privacy, Data Use and Sharing. The rejection points at something inside the binary, the privacy answers, or the relationship between the two. Apple has tightened this section twice in the past two years, most recently to name third-party AI services in 5.1.2(i).
Short answer
The short answer is that Guideline 5.1.2 covers seven sub-points about how an app collects, transmits, shares, repurposes, and stores user data, and the rejection always names which sub-point failed. The most common trigger is 5.1.2(i): tracking without an App Tracking Transparency prompt, sharing data with a third-party SDK or AI service without explicit consent, or gating functionality on the tracking opt-in. The fix lives inside the binary, the App Privacy answers in App Store Connect, and any usage description strings, all aligned together. According to the App Review Guidelines, the section was clarified in November 2025 to mention third-party AI explicitly, which has produced a wave of new rejections through 2026.
What you should know
- Guideline 5.1.2 has seven sub-points. The rejection email always cites one. Read the citation; do not guess the fix from the headline alone.
- 5.1.2(i) is the most common trigger. It covers tracking, third-party sharing, ATT prompts, and the new third-party AI clause added in late 2025.
- The App Privacy questionnaire must match the binary. A reviewer compares what was declared against what the app actually does, including hidden SDK behavior.
- Reviewers test the ATT prompt on a fresh install. If the prompt is missing, gated, or skipped on first launch when tracking is implied, the build fails.
- Hidden SDK telemetry is a frequent surprise. Analytics, attribution, and ads SDKs send data on initialization even when the developer thinks they configured them off.
- Third-party AI is now named in the guideline. Apps that route user prompts, voice, photos, or messages to external models must declare the provider and obtain consent.
What exactly does Guideline 5.1.2 cover?
The short answer is data use and sharing, broken into seven sub-points: 5.1.2(i) through (vii). The first sub-point governs the consent flow and ATT; (ii) bans repurposing data without further consent; (iii) bans surreptitious profiling of anonymous users; (iv) bans building a contact database from Contacts or Photos APIs; (v) restricts using user data to message third parties; (vi) bans marketing use of HealthKit, HomeKit, ARKit, and similar sensitive APIs; (vii) restricts data acquired through Apple Pay.
The Resolution Center reply usually quotes the sub-point in the body of the email. A line such as "your app appears to track users without the App Tracking Transparency prompt" maps to 5.1.2(i). A line about contact harvesting maps to (iv). Reading the cited sub-point before drafting the resubmission is the difference between a one-build fix and three review cycles, per Apple's User Privacy and Data Use guidance.
In practice, the vast majority of 5.1.2 rejections hit 5.1.2(i), specifically the App Tracking Transparency clause. The second-most-common pattern in 2026 is the new third-party AI clause inside 5.1.2(i), added in November 2025.
Why does the App Tracking Transparency prompt trip the most rejections?
The short answer is that since iOS 14.5 in 2021, any app that links user or device data with data from another company's app or website for targeted advertising must request permission through the App Tracking Transparency framework. Most builders forget that the rule covers SDK behavior they did not write, not only their own code.
The mechanism is the AppTrackingTransparency framework. Calling ATTrackingManager.requestTrackingAuthorization triggers the system prompt, and the response (authorized, denied, restricted, notDetermined) decides whether the build can read the device's IDFA and whether tracking SDKs can correlate users across apps. Without the prompt, any tracking SDK that runs by default is operating in a state Apple treats as non-consented, and the binary fails 5.1.2(i).
The evidence is in the wording of the rejection. Apple's standard 5.1.2(i) email reads as a variation on "the app collects data in order to track the user but does not use App Tracking Transparency to request the user's permission before tracking." The line is generated when the reviewer's test pass detects tracking SDKs in the binary (analytics, attribution, ad networks) without the ATT prompt firing on first launch.
The consequence is that the fix has two parts. Add the NSUserTrackingUsageDescription key to Info.plist with a clear purpose string. Then call the request method before any tracking SDK reads the IDFA. Skipping either part keeps the build in rejection.
The limit is that the ATT prompt cannot be gated. Per Apple's App Tracking Transparency framework documentation, an app cannot require the user to accept tracking in order to access content or use functionality. Apple rejects builds where the prompt blocks core features, where the app shows a paywall behind tracking consent, or where the denial removes meaningful capability.
How does the new third-party AI clause in 5.1.2(i) work?
The short answer is that since November 2025, Apple's 5.1.2(i) text explicitly names third-party AI alongside other third parties. Any app that sends user content (text, images, voice, files, screen contents) to an external AI model has to disclose the sharing and obtain explicit user permission before it happens. Per TechCrunch's coverage of the November 2025 App Review Guidelines update, the language was added to address the rapid integration of OpenAI, Anthropic, Google, and other model providers inside consumer apps.
The mechanism is the same disclosure-plus-consent model used elsewhere in 5.1.2(i). The privacy policy has to name the AI providers, the data types sent (prompts, embeddings, files, transcripts), and the retention behavior. The first run of the app should surface the disclosure before the first AI call, not bury it deep in settings. The App Privacy questionnaire in App Store Connect should declare the data types shared with third parties.
In practice, the apps tripping this clause in early 2026 are AI writing tools, voice transcription apps, photo enhancement apps, code helpers, and any app that pipes user text to a model API. Three patterns generate the rejection: an undisclosed model provider in the privacy policy, a missing or pre-checked consent on first run, and an App Privacy declaration that says no third-party sharing while the binary calls api.openai.com or similar endpoints.
The limit is that on-device models do not trigger the clause. Local Core ML inference, on-device speech recognition, and similar features stay inside the device and do not count as third-party sharing.
How do I align App Privacy answers with the binary?
The short answer is that the App Privacy details form in App Store Connect has to match what the binary actually does, including every SDK linked into the app. A mismatch where the form declares less than the binary collects is one of the most reliable ways to trip 5.1.2.
The reviewer can run the app while watching network traffic with proxy tools, and the comparison is mechanical. If the binary contacts analytics.firebase.com, the App Privacy form should declare Firebase Analytics. If the binary contacts app-measurement.com, Firebase Analytics is again the declared SDK. If the app uses AdMob, the form must declare advertising data. The friction is that builders often add an SDK once, forget about it, and answer the App Privacy form months later with stale assumptions.
In practice, the alignment check has three steps. First, list every SDK in the build, including transitive dependencies brought in by other SDKs. Second, read each SDK's Apple-required privacy manifest (the PrivacyInfo.xcprivacy file) and the SDK vendor's documented data collection. Third, fill the App Privacy questionnaire to match the union of those declarations, then verify any tracking SDK fires the ATT prompt before activation.
The limit is that the App Privacy form cannot be edited after submission without a metadata change, and the change ships with the next build version, per the App Store Connect manage app privacy help. A submission that ships before the questionnaire is corrected stays in a state where the listing contradicts the binary.
What needs to change before I resubmit?
The honest answer is that the resubmission has three layers, and skipping any one keeps the rejection alive.
Layer one is the binary. Add NSUserTrackingUsageDescription to Info.plist. Call ATTrackingManager.requestTrackingAuthorization before any tracking SDK reads the IDFA. Confirm the prompt fires on first launch on a clean device. If the app sends user content to a third-party AI service, add the consent surface before the first call.
Layer two is the listing. Update the App Privacy questionnaire to declare every data type the binary collects, including SDK-side data. Declare third-party sharing for tracking SDKs and any AI provider. Localize the privacy policy URL if the app ships in multiple languages.
Layer three is the document. The privacy policy text on the public URL must match the App Privacy declarations and disclose every third-party recipient, including AI providers. The text covers data types, purpose, retention, and the user's right to revoke or delete. A privacy policy that says the app does not share data with third parties, while the binary calls a model API, fails review even when the ATT prompt fires correctly.
| Sub-point | What it bans | Common trigger | Typical fix |
|---|---|---|---|
| 5.1.2(i) | Tracking or third-party sharing without consent | Missing ATT prompt, undisclosed AI provider | Add ATT prompt, declare provider, update App Privacy |
| 5.1.2(ii) | Repurposing data without further consent | Analytics events feeding a new advertising flow | Add a separate consent for the new purpose |
| 5.1.2(iii) | Surreptitious profiling of anonymous users | Building a fingerprint from device signals | Remove fingerprinting, fall back to IDFV |
| 5.1.2(iv) | Building a contact database from Contacts or Photos | Uploading the address book to a developer server | Process contacts on-device only |
| 5.1.2(vi) | Marketing use of HealthKit, HomeKit, ARKit | Sending health metrics to an ad SDK | Block the SDK from the sensitive data path |
What to watch out for
The first trap is treating the rejection as a single problem. Guideline 5.1.2 has seven sub-points, and a build can fail more than one in the same review. Read the Resolution Center text carefully, and if the reviewer cites two sub-points, fix both before resubmitting.
The second trap is the SDK assumption. Builders often assume that adding an analytics SDK and not calling its track methods means no data is sent. Most modern SDKs send install events, session events, and device data on initialization unless the developer explicitly disables those defaults. The cleanest test is a packet capture during first launch on a clean device, watching every outbound request.
The third trap is the privacy policy template. Generic privacy policies generated by online tools rarely match the actual data flow of the specific build. Reviewers compare the document against the App Privacy answers, and a generic template that names no SDKs while the form declares Firebase, Mixpanel, and OpenAI fails the consistency check.
The fourth trap is the third-party AI assumption. Sending user prompts to OpenAI, Anthropic, or Google is third-party sharing even when the developer's own backend proxies the request. The model provider is still a third party from Apple's point of view, and the disclosure has to name the provider, not just the relay server.
For builders who want an external automated read of their build before resubmission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning aligned with OWASP MASVS. The scan inspects which SDKs ship in the binary, which network endpoints they contact, and where data might be flowing without a matching App Privacy declaration.
Key takeaways
- Read which 5.1.2 sub-point the rejection cites; the fix is sub-point-specific, not generic, and a single email can list more than one failed sub-point.
- Verify the ATT prompt fires on a clean first launch, with a clear
NSUserTrackingUsageDescriptionand no gating of functionality on consent. - Match the App Privacy questionnaire to the actual SDK and network behavior of the binary, including transitive dependencies and third-party AI calls.
- Update the privacy policy to name third-party AI providers, the data types sent, and the retention behavior, then localize per supported language.
- Some teams running pre-submission audits use platforms like PTKD.com (https://ptkd.com) to catch SDK leaks and 5.1.2-shaped issues before App Store Connect runs its own checks.
