iOS 27.2 ATT expanded prompt: an EU migration guide

Prepare for the iOS 27.2 ATT expanded prompt in Germany, France, Italy, Poland, and Romania with regional QA, consent-state tests, copy review, and reprompt controls.

iOS 27.2 ATT expanded prompt: mobile privacy engineer arranging regional test phones face down
Regional fixtures make the five-country branch visible before release.

A consent prompt passes in a United States test account, then the release reaches France and records an unexpected branch as a generic denial. The product loses the distinction between a user choice, a system-level restriction, and a prompt that can become eligible again after a year.

The photographs use face-down phones, regional color tokens, a time wheel, a phone back, event lights, and an unmarked time wheel as consent-test props. They do not reproduce Apple’s prompt interface.

Apple’s privacy guidance describes an expanded prompt option for apps on iOS and iPadOS 27.2 in Germany, France, Italy, Poland, and Romania. Teams need regional fixtures and a time-aware state model before changing production copy or analytics.

Apple’s developer announcement and iOS 27.2 release notes separate two scopes: the alternative prompt is mandatory in five countries, while the one-year reprompt rule applies across the European Union.

Map the iOS 27.2 ATT expanded prompt by region

Apple names Germany, France, Italy, Poland, and Romania for the alternative expanded interface. Keep a fixture for each country plus one unaffected EU country and one non-EU region, because a single locale setting does not prove storefront, account, device, and runtime conditions agree.

Store the observed prompt family with the app build, OS build, region inputs, authorization status before request, and status after response. That record separates a product bug from a fixture that never entered the intended regional path.

Keep Apple’s status as the source of truth

The AppTrackingTransparency framework exposes the authorization status used by the app. Route analytics and advertising behavior from that status rather than from a local “prompt shown” flag that can drift after reinstall, restore, account change, or system settings.

Persist only the product context needed to explain your own flow, such as the screen that requested consent and the policy version. Do not create a parallel consent answer that can contradict the operating system.

Consent-state matrix

  • Authorized: run only the disclosed tracking paths and verify the matching event route.
  • Denied or restricted: suppress tracking-dependent requests and keep core use intact.
  • Not determined: request at a moment with enough context, then read the resulting status.
  • Global requests disabled: do not schedule a future reprompt.

Treat Additional Information as a product surface

Apple allows an optional Additional Information button in the expanded experience. Use the space to explain the concrete data use and user consequence in plain language, then make sure dismissal returns to a coherent consent decision.

Legal review should compare the explanation with the privacy nutrition label, privacy policy, SDK inventory, server events, and deletion behavior. A polished explanation cannot repair a data path that the disclosure omits.

Test the response against real downstream behavior

Record the authorization status, event route, ad request behavior, and next eligible prompt date as one fixture. Send a recognizable test event through the authorized branch and prove that the denied branch does not send the tracking-dependent counterpart.

Inspect SDK initialization, attribution links, server-to-server events, audience building, and data export. A disabled client call offers weak protection when a backend joins the same identifier later.

iOS 27.2 ATT expanded prompt test with a face-down phone, event lights, and a time wheel
Original Neyrotex editorial photograph. Consent, analytics, and ad behavior must agree after each response.

Exercise the one-year reprompt rule with a clock fixture

Apple’s guidance allows another request after one year across the EU, regardless of whether the earlier response was acceptance or denial. Users who disable tracking requests at the system level should not receive that reprompt, so represent eligibility as a policy decision that consumes trusted status and time rather than a notification scheduled on the first response date.

Test just before and after the boundary, device restore, app update, region change, and system-level disablement. The test should assert both prompt eligibility and the downstream behavior when no prompt appears.

Make analytics survive the migration

Create explicit event versions for the old and expanded flows, then annotate the release date and eligible regions. Do not compare raw opt-in rates across prompt families without separating region, app build, acquisition source, and whether users opened the information step.

Watch for sudden changes in “not determined,” missing callbacks, duplicate request attempts, and SDK traffic in denied states. Alert on contract violations rather than celebrating a favorable percentage before the sample stabilizes.

Keep the non-tracking experience complete

Core navigation, account access, purchases, and support should remain usable after denial. Explain any contextual ads or reduced personalization without punishing the user or repeating the consent request through custom screens.

Review accessibility with larger text, VoiceOver, reduced motion, and the longest supported localized copy. The system prompt may be accessible while the product’s lead-in or information page blocks the same user.

Release through a regional canary

Start with internal or controlled distribution that can produce the real five-country branch, then compare device evidence with the expected state matrix. Expand only after privacy, analytics, advertising, support, and product owners sign the same result.

This guide does not use or modify the monthly Mobile review plan. It covers a developer migration contract and contains no product rating, Best list, device review, or queued review item.

Keep a release evidence record

Save the source versions, selected capability, test fixture, expected result, observed result, failure path, owner, and review date together. Recheck the decision when the platform contract, dependency, device class, model snapshot, or business consequence changes; a green launch artifact is evidence for one bounded state, not a permanent guarantee.

Continue with the Mobile hub, then use our first related guide and second related guide to connect this decision to the surrounding platform work. The next-action guide carries the resulting evidence into the following release decision.

Keep the tradeoff visible

An extra information step may improve understanding while adding friction, and a one-year reprompt can recover consent while creating a new timing risk. Ship only the branches that your product, legal review, and telemetry can explain together.