Apple’s App Store now calls out third-party AI by name, and that changes how iOS teams should build

Apple tightened its App Review Guidelines in a way that will hit a lot of AI features already in production.

The change sits in rule 5.1.2(i). Apple now says apps must clearly disclose when personal data is shared with third parties, including third-party AI, and get explicit user permission before doing it.

That wording matters. AI inference APIs can no longer hide inside broad language about partners or service providers. Apple is calling out the pattern directly. If your app sends user text, images, audio, or behavioral context to OpenAI, Anthropic, Google, Cohere, or a gateway in front of them, Apple wants that data flow disclosed and consented to inside the app.

Apple is drawing a line around external inference

The update arrives as Apple pushes toward a more capable Siri in 2026, reportedly with outside model support including Google Gemini. The timing is hard to miss. Apple wants room to expand assistant behavior across apps while setting tighter rules for everyone else moving user data off device.

It also fits the rest of the latest guideline changes. Apple tightened language around regulated categories, including crypto exchanges, and added policy for its Mini Apps Program. AI now sits in the high-scrutiny bucket.

That's fair enough. Third-party inference became a blind spot in a lot of apps. Teams carefully disclose analytics SDKs, then ship a prompt pipeline that sends chat history, voice transcripts, screenshots, or contact-derived context to an LLM endpoint with barely any user-facing explanation. Apple is closing that gap.

Hybrid and cloud AI are the obvious targets

For iOS teams, there are roughly three common patterns:

1. On-device inference with Core ML, Apple's Neural Engine, or local models
2. Hybrid inference, where the app preprocesses locally and sends a prompt payload or retrieval context to a cloud model
3. Cloud-first inference, where raw user inputs go straight to a third-party API for processing

The new rule mostly lands on the second and third categories.

If everything stays on device, the compliance burden is lower. You still need normal privacy hygiene, but there isn't a third-party transfer to explain. If your smart reply feature sends message content to a hosted LLM, or your voice assistant uploads transcripts to a model provider, that now needs explicit consent with real detail.

Not vague Terms of Service language. Not a checkbox buried in onboarding. Apple's wording points to an in-context permission step tied to the feature itself.

That matters because hybrid architectures are everywhere. They're faster to ship than fully local models, and they're usually better than current on-device options for long-context text generation, retrieval, and multimodal work. They also create the exact data path Apple wants dragged into the open.

"Personal data" is broader than many prompt pipelines assume

A lot of developers still think in classic PII terms: email addresses, phone numbers, maybe account IDs. App Review won't.

Personal data can include precise location, health information, financial details, biometrics, photos with identifiable faces, contact lists, voice recordings, and text that reveals identity through context. Prompt payloads are especially messy because they often contain indirect identifiers. A support summary, a document excerpt, a message thread, or a calendar-based task description can all count as personal data even after the obvious fields are stripped out.

That complicates redaction. Rule-based masking for emails and phone numbers helps, but it won't catch "pick up my daughter Emma from Roosevelt Middle School at 3:15" or "summarize the lab results from my cardiologist visit."

LLMs are good at pulling structure out of context. Reviewers know that now. Apple almost certainly does too.

The problem is the whole pipe

If you're shipping AI features on iOS, the model vendor is only part of the privacy story. The full request path matters.

A typical production stack might look like this:

• app collects user input
• local preprocessor formats a prompt
• request hits your backend or LLM gateway
• gateway routes by cost, latency, or capability
• provider returns output
• observability stack logs metadata, maybe bodies
• output is stored for continuity or feedback tuning

Any one of those steps can create disclosure trouble.

Routing is a good example. Plenty of teams use a gateway that chooses between vendors dynamically. Fine operationally. Messy for consent. If one request can go to Anthropic today and Google tomorrow based on queue depth or feature flags, your disclosure has to cover that. Apple is unlikely to accept "we may share data with trusted AI partners."

Telemetry is another weak point. Even teams that anonymize prompts before inference often leak raw content into traces, error logs, or debug tooling. If request bodies end up in Datadog, Sentry breadcrumbs, or internal replay systems, your "we don't store personal data" story falls apart fast.

What a safer implementation looks like

The cleanest answer is still on-device inference where it's good enough. For classification, ranking, lightweight summarization, or narrow prediction tasks, local models buy you speed, offline support, and less App Review friction.

Most teams won't stay fully local, though. In those cases, the safer pattern looks like this.

Put a consent gate in front of each AI feature

Make consent feature-specific. "Allow third-party AI for smart replies" is better than one giant AI toggle. Users can tell what they're enabling, and you can block outbound requests cleanly until approval exists.

Redact before the network hop

Run PII filtering before data leaves the device, or before your backend forwards the payload. Use NER plus rules. For images, blur or crop faces if identity isn't needed. For chat history, send summaries instead of raw threads when you can.

Centralize policy in an LLM gateway

This is one place where a gateway actually earns its keep. Put vendor selection, consent enforcement, redaction checks, retention policy, and request shaping in one service. Otherwise every team recreates the same mistakes in slightly different ways.

Minimize context aggressively

Most prompts are bloated. Trim attachment metadata. Send recent turns, not the entire thread. Replace full records with task-specific summaries. Smaller payloads are cheaper, faster, and easier to defend in review.

Treat logs as part of the data-sharing surface

Disable body logging by default. Mask IDs and tokens. Keep retention short. Separate production telemetry from verbose developer diagnostics. If you need deep debugging, use scrubbed repro flows instead of live user content.

None of this is exotic. It does require discipline, which is exactly what Apple is trying to force.

Provider policy details now shape product decisions

One awkward part of this change is that model vendor behavior varies a lot.

Some providers say API data isn't used for model training by default. Some offer zero-retention or limited-retention options. Others keep logs for abuse detection. Some let you opt into data sharing for quality improvement. If your consent copy says the wrong thing, you're creating risk for no good reason.

That will push teams to audit vendor settings much more closely. It may also affect procurement. A provider with strong retention controls, clear enterprise settings, and clean documentation becomes easier to ship on iOS, even if model quality is a bit worse or the price is higher.

That trade-off is real now. Review risk costs time.

Another point in favor of on-device AI

By naming third-party AI explicitly, Apple is making external inference feel exceptional and local inference feel normal.

That doesn't mean every app should try to cram a 3B parameter model onto a phone. Thermal limits, memory pressure, battery life, and model quality still matter. Plenty of workloads belong in the cloud. But for teams that were already on the fence, this changes the math.

If a feature runs well enough with Core ML or a compact local model, the product case just got stronger. Fewer disclosures. Fewer consent prompts. Less review friction. Less vendor overhead.

Apple knows that.

What should go into the next sprint

If your iOS app sends user data to external AI services, the checklist is pretty direct:

• add a dedicated in-app consent flow before the first third-party AI request
• name the vendors or vendor categories involved
• describe exactly what data leaves the app
• state the purpose in plain language
• verify provider retention and training settings
• update App Store privacy disclosures so they match reality
• scrub logs, traces, and replay systems
• add prompt redaction or summarization before network calls
• make vendor routing explainable if you use a gateway
• keep consent scoped per feature instead of burying it in a master setting

Test it like a real product surface. If a reviewer can trigger a cloud AI feature before seeing a clear permission step, you're asking for trouble.

Apple's wording is narrow. The effect isn't. A lot of AI-powered iOS features were built as if data handling sat somewhere off to the side. Now it's part of the user experience. That's overdue.