UIAlertController RUM tracking not working - no known workarounds work

[dineshiOSDev]

UIAlertController RUM tracking is fundamentally not working in the iOS SDK. Neither automatic view tracking via predicate nor manual view management can properly isolate alert actions from the parent view.

Steps to Reproduce:

1. Configure UIKitRUMViewsPredicate to return a RUMView for UIAlertController
2. Present an alert with accessibilityIdentifier set
3. User taps alert button
4. Check Datadog RUM dashboard

Actual Behavior:

• Alert view is created and tracked separately
• Button tap actions are mapped to the parent view instead of the alert view
• This creates a disconnect between the view hierarchy and action tracking

Environment:

• SDK Version: 2.29.0
• iOS Version: iOS 18.0+
• Device: iPhone
• Xcode Version: 16.3

Code Example:

class CustomRUMViewPredicate: UIKitRUMViewsPredicate {
    func rumView(for viewController: UIViewController) -> RUMView? {
        if let alert = viewController as? UIAlertController,
           let label = alert.view.accessibilityIdentifier,
           let viewName = ScreenNameManager.shared.getAlertName(alert: label) {
            return RUMView(name: viewName)  // Returns valid RUMView
        }
        
        // Fallback for regular screens
        guard let viewName = ScreenNameManager.shared.getScreenName(for: viewController) else { 
            return nil 
        }
        return RUMView(name: viewName)
    }
}

// Usage:
let alert = UIAlertController(title: "Test", message: "Message", preferredStyle: .alert)
alert.view.accessibilityIdentifier = "TestAlert"
alert.addAction(UIAlertAction(title: "OK", style: .default) { _ in
    // This action gets tracked under parent view, not "TestAlert"
})
present(alert, animated: true)

[mariedm]

Hi @dineshiOSDev 👋

Thanks for the report and sharing the code snippet. Could you also share your full RUM configuration, please? In particular, the action tracking setup isn’t visible from the snippet you posted.

By design, the SDK does not automatically instrument UIAlertController views or their actions. Our heuristics focus on subclassed UIViewControllers, which typically represent meaningful screens for most apps. For reference:

• View tracking code
• Action tracking code

A UIAlertController can be tracked as a RUMView if you provide a custom UIKitRUMViewsPredicate, like you did. Now, to properly track alert button actions, you can track them manually, like this:

let alert = UIAlertController(title: "Test", message: "Message", preferredStyle: .alert)
alert.view.accessibilityIdentifier = "TestAlert"
alert.addAction(UIAlertAction(title: "OK", style: .default) { _ in
    RUMMonitor.shared().addAction(type: .tap, name: "alert_button")
})
present(alert, animated: true)

With this setup, the alert is tracked as a RUMView, and the button tap is tracked as a RUMAction, correctly linked to the alert view.

Can you try the above approach in your app and confirm if the actions now appear under the alert view in RUM?

Thanks!

[dineshiOSDev]

Hi @mariedm thanks for responding swiftly.
Here is the RUM Configuration

    private func setupRUM(domain: String) {
        RUM.enable(
            with: RUM.Configuration(
                applicationID: appID,
                sessionSampleRate: self.sessionSampleRate,
                uiKitViewsPredicate: CustomRUMViewPredicate(),
                uiKitActionsPredicate: DefaultUIKitRUMActionsPredicate(),
                urlSessionTracking: RUM.Configuration.URLSessionTracking(firstPartyHostsTracing: .trace(hosts: [domain], sampleRate: self.sampleRate)),
                trackFrustrations: true,
                trackBackgroundEvents: true
            )
        )
    }

I used CustomRUMViewPredicate to track the alertview and all other views, and I'm also tracking the user actions (RUMMonitor.shared().addAction), which are also tracked and reflected in the rum session.

The problem here is that the actions are not linked to the alert view, but rather to the view where the alert is displayed.

[mariedm]

Hi @dineshiOSDev, thanks for your answer.

Your setup looks correct, but I can reproduce the expected behavior on my end: the manual action tracking is correctly associated with the alert view.

Since the issue persists in your app, there might be something specific about your view hierarchy or setup that's affecting the RUM tracking behavior. To help debug this further, could you please enable debug logging by setting Datadog.verbosityLevel = .debug and look for any RUM-related warnings or messages that might indicate why the action isn't being associated with the alert view

If this doesn't reveal the issue, I'd need you to share a minimal sample project that reproduces the problem so we can troubleshoot further. Thanks!

[dineshiOSDev]

Hello, @mariedm . Thank you for the response.

I investigated it from my end. I believe the problem is that we display the UIAlertController from a general location by accessing the top viewcontroller, which may cause a problem mapping alert actions to their corresponding alert views?

When I tried displaying the alert view from its parent in Swiftui, it worked as expected.

Is there a chance this can be handled?

[mariedm]

Hi @dineshiOSDev, so we can troubleshoot this further, could you share a sample app so we can reproduce this on our end, please? Thanks.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity and has the awaiting-response label.

It will be closed if no further activity occurs within 3 days.

[simaoseica-dd]

Hello @dineshiOSDev 👋

Thank you for sharing the details about tracking UIAlertControllers interactions.

At the moment there isn't a reliable way to instrument UIAlertController taps on their own RUM Views using the public RUM APIs (manually or automatically).
While you can map a UIAlertController to a RUMView with a UIKitRUMViewsPredicate, the tap action itself won't be linked to that alert view due to the way UIKit processes the callback:

1. The system dismisses the UIAlertController first.
2. Only after dismissal completes does UIKit invoke the UIAlertAction's handler.

Since the SDK relies on the viewDidDisappear to stop the view lifecycle, any manual monitor.addAction(...) call will be associated with the next active view instead of the alert view.

For now, the recommended approach is to add contextual attributes to your manual actions. I'd also suggest filing a feature request through our public support channels.

Thanks again for raising this!