If your iOS app sends any user data to a third-party AI service — OpenAI, Anthropic, Google Gemini, Mistral, your own hosted model — Apple now requires you to disclose that, name the provider, explain what the AI will do with the data, and obtain explicit consent before the first transmission. The rule has been live since November 13, 2025, and roughly six months in, the rejection patterns are clear, the enforcement is consistent, and there's a right way and a wrong way to ship this.
This guide walks through what App Review Guideline 5.1.2(i) actually requires, the consent UX patterns that pass review, the patterns that get rejected, and how to bake the disclosure into your release process so it doesn't bite you on every update.
What 5.1.2(i) actually says#
The amended language under section 5.1.2 of the App Review Guidelines requires developers to disclose where personal data will be shared with third parties — including third-party AI — and to obtain the user's explicit permission before sharing any of that data. Apple's clarification, published with the November 2025 update, explicitly names "third-party AI" as a category that triggers the disclosure requirement.
The rule is broader than it looks at first read. It applies to any scenario where identifiable user data leaves the device and is processed by a third-party AI system. That includes:
Sending user messages, prompts, or queries to a hosted LLM API. Uploading user documents, images, screenshots, or files to a cloud-based AI service for processing. Transmitting voice recordings or audio to a third-party transcription or speech-to-text service. Sharing user behavior, preferences, or interaction data with an AI recommendation or personalization engine. Routing user-generated content through any third-party AI moderation or classification service.
What it does not apply to: on-device AI processing using Core ML, Foundation Models, Create ML, or similar Apple frameworks where data never leaves the device. If your model runs locally and the user's data stays on their phone, you don't owe a 5.1.2(i) disclosure for it.
What the consent screen has to include#
Apple's review team evaluates 5.1.2(i) consent screens against four criteria. Get all four right and you pass. Miss any one and the rejection comes back with a citation of the exact guideline.
Name the provider. "Powered by AI" is not enough. You have to name the company — OpenAI, Anthropic, Google, etc. If you route through multiple providers, name all of them, or be specific about which one this particular feature uses. The rejection rate on generic "AI" disclosures is high; the rejection rate on named-provider disclosures is much lower.
Explain the purpose. The screen has to tell the user what the AI will do with their data. "Your messages will be sent to OpenAI to generate replies" passes. "We use AI to enhance your experience" gets rejected. The threshold is roughly: a reasonable user reading the screen understands what is being sent and what comes back.
Specify the data type. Be concrete about what data is transmitted — text input, photos, voice recordings, account metadata. "Some of your data" is not specific enough. "The text you type into the assistant input field" is.
Make the consent explicit and revocable. The user has to take an affirmative action to grant consent — a tap on an "Allow" or "Continue" button, not an inferred consent from "if you don't tap deny within 5 seconds." The consent must also be revocable later from a settings screen, not a one-way trapdoor.
The consent prompt has to appear before the first transmission, not after. Apple's reviewers test by triggering the AI feature on a fresh install. If the API call to the third-party AI fires before the consent screen appears, the rejection is automatic.
The consent UX patterns that pass review#
Three patterns I've seen pass review consistently in 2026:
The dedicated onboarding screen. A full-screen step in your onboarding flow that introduces the AI feature, names the provider, explains what's transmitted, and ends with an explicit "Enable" / "Skip" choice. This is the cleanest pattern because it sets the disclosure before any other AI interaction is possible.
The contextual prompt on first use. A modal or sheet that appears the first time the user taps the AI feature, with the same content as the onboarding screen but localized to the moment. This works well for apps where AI is a secondary feature — most users won't trigger it, so an onboarding step would feel disproportionate.
The settings-toggle gate. AI features are off by default and live behind a toggle in settings. The toggle screen contains the full disclosure. Tapping the toggle on is the explicit consent. This is the cleanest pattern for apps where the AI feature is power-user-only.
All three patterns share a common structure: a clear "this feature uses third-party AI" framing, a named provider, a specific list of what data is transmitted, a stated purpose, and a clear opt-in.
The patterns that get rejected#
Patterns I've seen rejected, with the rejection reason in plain English:
Buried in the privacy policy. A line in your privacy policy that says "we may share data with third-party AI services" does not satisfy 5.1.2(i). The rule requires a contextual, in-app disclosure, not a 40-page legal document the user has to scroll to find.
Pre-checked consent boxes. A modal with "I consent to AI data sharing" pre-checked and a "Continue" button is a deceptive pattern under both 5.1.2(i) and Apple's broader user-consent rules. The default state has to be unchecked.
The "by using this app you agree" frame. Implied consent from continued app usage does not count. Apple's wording is "explicit permission," and the reviewers are reading it strictly.
Generic "AI" without naming the provider. "Some features use AI" gets rejected. The reviewer wants to see "OpenAI" or "Anthropic" or whoever in the disclosure text.
Consent screens that fire after the API call. This one is the most common technical rejection — the developer assumes the consent prompt will appear before the network call, but the actual code path triggers the API request first to populate a loading state. Reviewers catch this on a packet-level test.
Bake it into your release process#
The right way to handle 5.1.2(i) is to treat it as a CI check, not a one-time fix. Three things to wire up:
A pre-submission audit. Before each App Store submission, run through every AI-touching code path and verify that (a) the consent prompt fires before the network call, (b) the disclosure names the active provider, and (c) the consent state is checked at runtime, not just at app launch. Most rejections happen on updates, not initial submissions, because a developer adds a new AI feature and forgets the disclosure for that specific path.
A per-feature consent check. If your app uses multiple AI providers for different features — say, OpenAI for chat and Anthropic for summarization — Apple's review team has been increasingly strict about per-provider consent. A single "I consent to AI" toggle is not enough; the user has to consent to each provider, or the disclosure has to name all of them upfront.
A revocation surface. Settings has to have a way for the user to revoke consent. Test it: revoke consent, trigger the feature, and verify the API call doesn't fire. If revocation doesn't actually disable the feature, that's a rejection.
Common edge cases and how Apple is reading them#
Six months in, a few edge cases have settled out of the rejection data:
On-device models with cloud fallback. If your app uses an on-device model by default and only falls back to a cloud LLM on certain queries, you still need 5.1.2(i) disclosure for the cloud fallback path — and the disclosure has to make clear when the fallback is triggered. Some apps surface this as a per-query indicator ("This response was generated by a cloud model"); others bake it into onboarding ("Some queries may be processed in the cloud").
Pseudonymized API calls. Some developers assume that if they strip identifiers from the data before sending it to the LLM, 5.1.2(i) doesn't apply. Apple disagrees. The rule covers any user-originated data, identifiable or not, sent to a third-party AI. The pseudonymization is a privacy best practice but not a 5.1.2(i) escape hatch.
Transcription and voice services. Apple has been particularly strict on voice. If your app sends audio to Whisper, AssemblyAI, Deepgram, or any other third-party transcription service, you need explicit consent that names the provider, and the consent prompt has to appear before the first recording is uploaded.
B2B or enterprise apps. The consent rule applies even if the user is an employee using a company-deployed app. Apple's position is that the consent rights belong to the end user, not the company. Enterprise apps deployed through MDM still have to surface the consent screen.
Where this is heading#
The 5.1.2(i) enforcement pattern is the same playbook Apple ran with App Tracking Transparency in 2021. The first six months are about establishing baseline compliance; the second six months are about tightening the consent UX and going after dark patterns. Expect the bar to keep rising through WWDC and into the iOS 27 release cycle.
Two trends to plan for over the next year:
Apple will likely require structured disclosures — a manifest format that names AI providers and data types, similar to the privacy manifest framework introduced in 2024. If you've already structured your consent screens around named providers and specific data types, the migration will be trivial.
The bar for "explicit consent" will get higher. Apple has historically tightened consent requirements over time, and the AI category is the most politically sensitive surface they have. A consent pattern that passes review today may need a refresh in 12 months.
How Stora handles this#
Stora's compliance engine includes a 5.1.2(i) check that scans your onboarding flows, settings screens, and runtime consent prompts for the four required disclosure elements: named provider, data type, purpose, and explicit opt-in. The check runs on every build and flags missing disclosures before the build hits TestFlight, which is where most teams currently catch the issue — usually after a rejection. The compliance engine also flags consent screens that fire after the API call, which is the technical rejection most teams miss until reviewers catch it.
The broader point is that 5.1.2(i) is one of the easier rules to comply with if you build for it from day one, and one of the most expensive rules to retrofit if you've shipped six AI features without it. The work is in the discipline of treating "is the consent screen correctly placed" as part of every release, not a one-time onboarding decision.
For a fresh app, the rule adds an hour of design work and a settings toggle. For a mature app with eight AI-touching paths, the audit takes a week. Either way, every rejection costs you at least a 24-hour review cycle, and one rejection per quarter on this rule erases real release velocity. Build it in once, check it on every release, and 5.1.2(i) becomes invisible.