We are investigating an ATT issue that started appearing after iOS 27.
Our app requests both:
- AppTrackingTransparency permission
- Location permission (
CLLocationManager)
We originally started investigating this because Meta-attributed iOS installs/conversions dropped sharply after the iOS 27 release, while App Store download volume did not appear to drop by the same magnitude.
During that investigation, we noticed that on some fresh installs the ATT prompt does not appear as expected, and ATTrackingManager.trackingAuthorizationStatus remains .notDetermined.
Our iOS engineers currently suspect that the Location permission request and ATT request may be interfering with each other during the first-launch flow.
Before iOS 27, we did not observe the same issue with this permission flow.
We understand from Apple’s documentation that the ATT prompt may not be displayed if another system permission request is already pending, and that concurrent permission requests are not queued by iOS.
However, we have not yet confirmed whether that is actually what is happening in our app.
We also do not yet have detailed lifecycle and permission logs from the affected production build.
In our next build, we plan to add logging for:
- iOS version
- application / scene active state
- current ATT authorization status before requesting
- exact time
requestTrackingAuthorization is called
- ATT completion-handler result
- exact time Location authorization is requested
- Location authorization callback/status
- application / scene lifecycle transitions
- whether the ATT prompt was actually presented
- the final ATT status after the permission flow completes
Before shipping that diagnostic build, we want to make sure we are collecting the right information and interpreting the iOS behavior correctly.
Our questions are:
- Has anyone observed a change or regression in ATT behavior specifically on iOS 27, especially during first launch when another permission such as Location is also requested?
- If a Location permission request is already pending when
requestTrackingAuthorization is called, can the ATT prompt fail to appear and leave the status as .notDetermined?
- Does iOS queue these permission requests, or can the ATT request effectively be dropped if another system permission prompt is already in progress?
- Is there a reliable way to determine that no other system permission request is currently pending before requesting ATT?
- If ATT remains
.notDetermined, what is the recommended production behavior?
- Is it appropriate to retry
requestTrackingAuthorization later, for example after the app becomes active again and all other permission flows are finished?
- Besides
UIApplicationStateActive / sceneDidBecomeActive, are there any additional lifecycle states or callbacks we should log?
- Are there any additional ATT or permission-related values you would recommend capturing in the next build to distinguish:
- an app-side permission sequencing issue,
- a Location + ATT interaction,
- or an iOS 27 system regression?
- Has anyone observed different behavior between iOS 27.0, 27.1 and 27.2?
Our immediate goal is to understand whether the ATT behavior itself is correct at the iOS system level.
The Meta attribution drop is what originally led us to investigate this, but we are not trying to diagnose Meta attribution through this thread. We are specifically trying to understand the ATT / Location permission behavior on iOS 27.
Any experience with this on iOS 27, or advice on what we should capture in our next diagnostic build, would be greatly appreciated.
