ATT bug, don't wait for user

Hello, when I'm asking for the ATT permission don't wait for the user response. I doesn't matter which approach use never waits for user answer.

Using xcode 15.2 on iOS 17.4 simulators, versions before like iOS 17.2 works without any issue.

            Task {
                self.resultStatus = await ATTrackingManager.requestTrackingAuthorization()
                completion()
            }
        }
            ATTrackingManager.requestTrackingAuthorization(completionHandler: { status in
                self.resultStatus = status
                completion()
            })
        }

Replies

This is still an issue with the iOS 17.4 RC. In addition to that, one funny thing is that once one gets a default denied status after initially calling requestTrackingAuthorizationWithCompletionHandler: method, the actual value of the authorization status is still zero (not determined). Try running this code and check the values of the callbackStatus and status:

[ATTrackingManager requestTrackingAuthorizationWithCompletionHandler:^(ATTrackingManagerAuthorizationStatus callbackStatus) {
    ATTrackingManagerAuthorizationStatus status = [ATTrackingManager trackingAuthorizationStatus];
}];
Post not yet marked as solved Up vote reply of ugi Down vote reply of ugi
  • Same issue here. Callback status is denied and ATTrackingManager.trackingAuthorizationStatus is 0 - not determined. However, if you click allow, exit out of your app and enter again, it will work fine and will show the actual answer.

Add a Comment

Actually Apple test with a 17.4, we still have the problem and sometimes the ATT doesn't appear at all. So we see our app be refused when submitted. The weird fact is that we don't have the problem when building with Xcode, it's only when we deploy in TestFlight. In previous version of iOS, everything is fine.

  • Hello, has this problem been solved?

Add a Comment

I have the same problem. Has anyone found a solution?

Same issue here. Is there any solution? :(

This problem is impacting all apps on the store and has consequences on in-app advertising. Is there any news on the resolution?

Hi everyone, I'm writing from Italy and I have noticed the same issue. In my country the DMA is enforced, I don't know if this bug may be related to the specific implementations that have been made to comply to the DMA.

Anyway, I see the same behaviour described by @dgonzalezballester. I experimented with this bug a bit and discovered the following:

  • The same app, downloaded from the App Store, compiled with the same SDK exhibits the bug on a physical device with iOS 17.4. It behaves correctly when running my old iPhone 8 with iOS 16.7.4
  • We have code in the callback of ATT that is ran depending on the value of the status parameter being denied or accepted. I tried working around that by checking the value of ATTrackingManager.trackingAuthorizationStatus to no avail, because the callback doesn't get called again when the user actually makes the choice
  • To demonstrate the point, I tried running a while loop in a background thread inside the callback that stops when the value of ATTrackingManager.trackingAuthorizationStatus changes from .notDetermined. In the body of the while I ran the code depending on ATTrackingManager.trackingAuthorizationStatus and not the status parameter passed in the callback. This actually worked, but is a very dirty workaround that I'm not willing to put it in a build production.
  • Thank you for this. I'm hoping that iOS 17.4.1 will bring a fix for the issue.

Add a Comment

I am getting this problem on real devices too after updating them to iOS 17.4.

I can see the correct status in the device settings yet the call back always returns .denied without waiting for the user choice.

Unfortunately iOS 17.4.1 has come out, and the issue still persists.

  • Exactly, I am also facing this issue after updated to 17.4.1. Any response from Apple for this issue?

Add a Comment

Hi everyone,

As you know, due to a bug in iOS 17.4, ATTrackingManager.requestTrackingAuthorization() immediately triggers the callback with a value of status = denied, even though the true value of ATTrackingManager.trackingAuthorizationStatus is still notDetermined because the user has not yet made a choice by responding to the tracking consent popup. The issue persists on iOS 17.4.1.

Anyway, the app triggers a didBecomeActiveNotification when the user responds to the popup, so we can use this workaround to avoid the issue and proceed only after the user has made a choice:

func requestTrackingAuthorization() {
    self.removeObserver()
    
    ATTrackingManager.requestTrackingAuthorization {
        [weak self] status in
        
        if status == .denied,
           ATTrackingManager.trackingAuthorizationStatus == .notDetermined {
            debugPrint("iOS 17.4 authorization bug detected")
            self?.addObserver()
            return
        }
        
        debugPrint("status = \(status)")
    }
}

private weak var observer: NSObjectProtocol?

private func addObserver() {
    self.removeObserver()
    self.observer = NotificationCenter.default.addObserver(
        forName: UIApplication.didBecomeActiveNotification,
        object: nil,
        queue: .main
    ) { [weak self] _ in
        self?.requestTrackingAuthorization()
    }
}

private func removeObserver() {
    if let observer {
        NotificationCenter.default.removeObserver(observer)
    }
    self.observer = nil
}
  • Thank you for sharing the workaround. It totally makes sense and we are using it too.

  • Thanks for the life save brother. I am using the same thing with few minor changes... makes sense

Add a Comment

@davidebalistreri nice one, thanks for sharing.

In the past couple days I also opened a ticket on the Feeback Assistant tool and as of today the bug has been recognized with, I quote, a potential fix identified for a future OS update.

Same error. Tested on lots of devices (17.4 + 17.4.1).

Same issue here. This is a very horrible bug to have. Do we even know if 17.4.2 is fixing this? Seems like the only fix for now is to block all those in iOS 17.4 from seeing the ATT alert. :(

It looks like this is fixed in the first iOS 17.5 beta.

I am seeing the alert presented correctly without calling the completion closure immediately with denied. The closure is now only called once you interact with the buttons on the alert.

I have tested this out on a number of different iOS versions and I can confirm @donnywdavis's observation that this is resolved in the iOS 17.5 beta.

Here are the results of my testing:

 --------------------------------------
 | iOS     | Works? | Bug? | Test      |
 --------------------------------------
 | 16.4.0  | Yes    | No   | Simulator |
 | 17.0.0  | Yes    | No   | Simulator |
 | 17.2.0  | Yes    | No   | Simulator |
 | 17.3.1  | Yes    | No   | Device    |
 | 17.4.0  | Yes    | Yes  | Simulator |
 | 17.4.1  | Yes    | Yes  | Simulator |
 | 17.5.0b | Yes    | No   | Device    |
 --------------------------------------

Even though Apple is providing a fix, this bug will always be out there and will be relevant for quite a while. So, I have adapted the solution from @davidebalistreri into a drop in replacement for ATTrackingManager.requestTrackingAuthorization().

final class BugFixingATTrackingRequestManager {
    class func requestTrackingAuthorization() async -> ATTrackingManager.AuthorizationStatus {
        let status = await ATTrackingManager.requestTrackingAuthorization()
        if status == .denied, ATTrackingManager.trackingAuthorizationStatus == .notDetermined {
            debugPrint("iOS 17.4 ATT bug detected")
            for await _ in await NotificationCenter.default.notifications(named: UIApplication.didBecomeActiveNotification) {
                return await requestTrackingAuthorization()
            }
        }

        return status
    }
}

This solution improves on the above by being more compact, supporting async/await, and returning the AuthorizationStatus which allows it to be used directly as a replacement for let status = await ATTrackingManager.requestTrackingAuthorization()

Hope this is helpful.

  • I just wanted to clarify the columns in the table I posted above. For each version of iOS, the "Works" column indicates whether the solution BugFixingATTrackingRequestManager works as expected, and the "Bug" column indicates whether the bug is present in that version.

Add a Comment

Where do i put this? I'm new to app development