Post

Replies

Boosts

Views

Activity

iOS 27: app is not made inactive while the ATT prompt (or other permission alerts) is shown (FB25446786)
Since iOS 27, showing a system permission alert no longer deactivates the app. On iOS 26, sceneWillResignActive / applicationWillResignActive arrive about 0.05–0.1 s after ATTrackingManager.requestTrackingAuthorization. On iOS 27.0, 27.0.1 and 27.2 they don't arrive at all while the prompt is up, and SwiftUI's scenePhase stays .active. Apps that pause on resign, like games (Unity's iOS player pauses only on applicationWillResignActive), keep running behind the prompt: tutorials start, and timers and audio keep going. Minimal repro (plain UIKit with UIScene, fresh install so the status is .notDetermined): private var askedForTracking = false func sceneDidBecomeActive(_ scene: UIScene) { print("sceneDidBecomeActive") guard !askedForTracking else { return } askedForTracking = true DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("requesting ATT") ATTrackingManager.requestTrackingAuthorization { status in print("ATT finished: \(status.rawValue)") } } } func sceneWillResignActive(_ scene: UIScene) { print("sceneWillResignActive") }iOS 26.6: 3.27s requesting ATT 3.35s willResignActive 16.81s ATT finished: authorized 17.24s didBecomeActiveiOS 27.2: 3.21s requesting ATT 16.88s ATT finished: authorized 17.32s willResignActive 17.33s didBecomeActiveSo on iOS 27 the only lifecycle events are a resign/active pair about 0.44 s after the answer. What we found: The camera and notification permission alerts behave the same. It doesn't depend on the SDK the app is linked against, or on the thread making the request. SpringBoard's log shows the systemModalAlert deactivation assertion being added, but on iOS 27 the updateAllScenesForBand - Assertion added update never reaches the app's scene. The pending reason is only applied on the next unrelated scene update, such as a notification banner arriving, the screen dimming, an unlock, or the alert being dismissed. Taps outside the alert, a Control Center swipe or a home-indicator drag don't trigger it. Filed as FB25446786, with a sample project, delay sweeps on iOS 26 vs 27 (simulator and device) and a sysdiagnose. Is anyone else seeing this? And is there a supported way to know a permission alert is on screen until it's fixed? If you're affected, please file a Feedback and mention FB25446786; duplicates help.
0
0
1
8m
iOS 27: app is not made inactive while the ATT prompt (or other permission alerts) is shown (FB25446786)
Since iOS 27, showing a system permission alert no longer deactivates the app. On iOS 26, sceneWillResignActive / applicationWillResignActive arrive about 0.05–0.1 s after ATTrackingManager.requestTrackingAuthorization. On iOS 27.0, 27.0.1 and 27.2 they don't arrive at all while the prompt is up, and SwiftUI's scenePhase stays .active. Apps that pause on resign, like games (Unity's iOS player pauses only on applicationWillResignActive), keep running behind the prompt: tutorials start, and timers and audio keep going. Minimal repro (plain UIKit with UIScene, fresh install so the status is .notDetermined): private var askedForTracking = false func sceneDidBecomeActive(_ scene: UIScene) { print("sceneDidBecomeActive") guard !askedForTracking else { return } askedForTracking = true DispatchQueue.main.asyncAfter(deadline: .now() + 3) { print("requesting ATT") ATTrackingManager.requestTrackingAuthorization { status in print("ATT finished: \(status.rawValue)") } } } func sceneWillResignActive(_ scene: UIScene) { print("sceneWillResignActive") }iOS 26.6: 3.27s requesting ATT 3.35s willResignActive 16.81s ATT finished: authorized 17.24s didBecomeActiveiOS 27.2: 3.21s requesting ATT 16.88s ATT finished: authorized 17.32s willResignActive 17.33s didBecomeActiveSo on iOS 27 the only lifecycle events are a resign/active pair about 0.44 s after the answer. What we found: The camera and notification permission alerts behave the same. It doesn't depend on the SDK the app is linked against, or on the thread making the request. SpringBoard's log shows the systemModalAlert deactivation assertion being added, but on iOS 27 the updateAllScenesForBand - Assertion added update never reaches the app's scene. The pending reason is only applied on the next unrelated scene update, such as a notification banner arriving, the screen dimming, an unlock, or the alert being dismissed. Taps outside the alert, a Control Center swipe or a home-indicator drag don't trigger it. Filed as FB25446786, with a sample project, delay sweeps on iOS 26 vs 27 (simulator and device) and a sysdiagnose. Is anyone else seeing this? And is there a supported way to know a permission alert is on screen until it's fixed? If you're affected, please file a Feedback and mention FB25446786; duplicates help.
Replies
0
Boosts
0
Views
1
Activity
8m