Introduction

The safest way to avoid stacking duplicate alerts in iOS is to inspect the current presentation chain before presenting a new UIAlertController. In practice, that means finding the top-most presented view controller and checking whether it is already an alert.

Why This Check Matters

UIAlertController is a modal presentation. If your code fires the same error handler twice, or a network callback arrives while another alert is still on screen, calling present again can create warning logs, awkward animation behavior, or duplicate prompts for the user.

A clean alert strategy should answer two questions before every presentation:

• what controller is actually visible right now
• is that controller already a UIAlertController

A Practical Helper

This helper walks the presented view controller chain and presents an alert only when the top-most controller is not already an alert:

1import UIKit
2
3extension UIViewController {
4    func topMostPresentedController() -> UIViewController {
5        var top = self
6        while let presented = top.presentedViewController {
7            top = presented
8        }
9        return top
10    }
11
12    func presentAlertIfNeeded(title: String, message: String) {
13        let top = topMostPresentedController()
14
15        if top is UIAlertController {
16            return
17        }
18
19        let alert = UIAlertController(
20            title: title,
21            message: message,
22            preferredStyle: .alert
23        )
24        alert.addAction(UIAlertAction(title: "OK", style: .default))
25        top.present(alert, animated: true)
26    }
27}

Usage is straightforward from a screen that owns the flow:

1final class LoginViewController: UIViewController {
2    func showNetworkError() {
3        presentAlertIfNeeded(
4            title: "Network Error",
5            message: "Please try again in a moment."
6        )
7    }
8}

This pattern keeps the check close to the presentation call and avoids repeated boilerplate.

Prefer Intentional Alert Ownership

Even with a helper, you should still think about which controller is responsible for showing alerts. A common mistake is letting networking layers, managers, and view controllers all present alerts directly. That makes duplicate prompts more likely.

A better design is to let the visible screen decide when to show UI. Service layers can return errors, but the controller that owns the user interaction should decide whether to show an alert, a banner, or an inline validation message.

When the Top Controller Is Not the Right Controller

Sometimes the top-most controller is a sheet, tab controller, or navigation controller, not the content controller you expected. That is normal. The goal is not to find a specific subclass. The goal is to present from whatever controller is actually on top of the hierarchy.

If your app presents alerts from many places, you can centralize the lookup at the window scene level instead of assuming the current controller is the root of the active presentation chain.

Queueing Versus Skipping

Checking top is UIAlertController prevents duplicates, but it does not answer what should happen to the second alert request. In some apps, skipping is correct. In others, you may want to queue alerts and present the next one only after the current alert is dismissed.

That design decision depends on the product. For example, repeated validation alerts can usually be skipped, while distinct security warnings may need queueing.

Common Pitfalls

The most common mistake is checking presentedViewController only on the current controller, even when another controller has already been presented on top of it. Walk the chain to the actual top-most controller first.

Another issue is presenting from a controller that is no longer visible. Even if the alert itself is valid, UIKit can log warnings when the presenting controller is not in the active hierarchy.

Developers also treat duplicate alerts as purely a UI issue. Often they are really a state-management issue caused by duplicated callbacks or repeated error handling paths.

Summary

• Find the top-most presented controller before showing a new alert.
• Skip presentation when that controller is already a UIAlertController.
• Keep alert presentation owned by visible UI controllers rather than deep service layers.
• Present from the active controller in the hierarchy, not from an arbitrary stored reference.
• If multiple alerts matter, build a queue instead of blindly presenting duplicates.