Introduction

Constraint warnings around UIAlertController are frustrating because the alert often still appears while Xcode fills the console with Auto Layout noise. In most cases the problem is not a bug in your main app layout. It is a mismatch between what UIAlertController supports and what you are trying to force into it.

Why UIAlertController Triggers Constraint Warnings

UIAlertController is a system-owned controller with a private view hierarchy. Apple expects you to customize only the documented parts: title, message, actions, preferred style, and optional text fields for .alert.

Warnings often appear when you push beyond that supported surface area, for example:

• very long localized text that does not fit
• too many actions or text fields
• custom subviews added into alert.view
• presenting from the wrong controller state
• using .actionSheet on iPad without a popover anchor

The key point is that the warnings usually come from unsupported customization, not from a missing constraint in your own normal screens.

Use The Supported API First

A standard alert should look like this:

1import UIKit
2
3final class LoginViewController: UIViewController {
4    @IBAction func showResetAlert(_ sender: UIButton) {
5        let alert = UIAlertController(
6            title: "Reset Password",
7            message: "Enter the email address for your account.",
8            preferredStyle: .alert
9        )
10
11        alert.addTextField { textField in
12            textField.placeholder = "[email protected]"
13            textField.keyboardType = .emailAddress
14            textField.autocapitalizationType = .none
15        }
16
17        alert.addAction(UIAlertAction(title: "Cancel", style: .cancel))
18        alert.addAction(UIAlertAction(title: "Send", style: .default) { _ in
19            let email = alert.textFields?.first?.text ?? ""
20            print("Reset requested for \(email)")
21        })
22
23        present(alert, animated: true)
24    }
25}

This stays inside the supported alert API and rarely causes constraint noise by itself.

Avoid Modifying The Alert View Hierarchy

Developers sometimes try to add labels, images, or stack views directly to alert.view. That is brittle because the internal hierarchy is undocumented and can change between iOS releases.

Code like this is a red flag:

let alert = UIAlertController(title: "Warning", message: nil, preferredStyle: .alert)
let customView = UIStackView()
alert.view.addSubview(customView)

Even if you add valid constraints, the system alert's own private constraints may fight back. If you need real custom layout, UIAlertController is usually the wrong tool.

Build A Custom Modal For Rich Content

If the design needs custom controls or complex layout, create your own UIViewController instead:

1import UIKit
2
3final class ConfirmDeleteViewController: UIViewController {
4    private let titleLabel = UILabel()
5    private let messageLabel = UILabel()
6    private let deleteButton = UIButton(type: .system)
7
8    override func viewDidLoad() {
9        super.viewDidLoad()
10
11        view.backgroundColor = .systemBackground
12        view.layer.cornerRadius = 14
13
14        titleLabel.text = "Delete Project"
15        titleLabel.font = .preferredFont(forTextStyle: .headline)
16
17        messageLabel.text = "This action cannot be undone."
18        messageLabel.numberOfLines = 0
19
20        deleteButton.setTitle("Delete", for: .normal)
21
22        let stack = UIStackView(arrangedSubviews: [titleLabel, messageLabel, deleteButton])
23        stack.axis = .vertical
24        stack.spacing = 16
25        stack.translatesAutoresizingMaskIntoConstraints = false
26
27        view.addSubview(stack)
28
29        NSLayoutConstraint.activate([
30            stack.topAnchor.constraint(equalTo: view.topAnchor, constant: 24),
31            stack.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 24),
32            stack.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -24),
33            stack.bottomAnchor.constraint(equalTo: view.bottomAnchor, constant: -24)
34        ])
35    }
36}

This gives you full control over layout and removes the alert's private constraints from the equation.

Check Presentation Context Too

Some warnings come from presenting the alert at the wrong time rather than from the alert content itself. For example, presenting while another transition is in progress can trigger layout and hierarchy complaints together.

A safe pattern is:

DispatchQueue.main.async {
    self.present(alert, animated: true)
}

That is not a universal fix, but it avoids many timing-related presentation issues.

Common Pitfalls

The biggest mistake is treating UIAlertController like a generic modal layout container. It is not designed for arbitrary custom subviews.

Another common issue is showing too much content in a system alert. Long messages, many actions, or multiple text fields can push the internal layout into awkward compression.

Developers also often forget iPad-specific rules for .actionSheet. Without a valid popoverPresentationController anchor, the presentation can fail or warn.

Finally, do not ignore Dynamic Type. Text that fits in one simulator can overflow badly for users with larger accessibility sizes.

Summary

• Treat UIAlertController as a fixed system component, not a general-purpose container.
• Stay within the documented customization points when possible.
• Use a custom modal UIViewController when the content needs real custom layout.
• Check presentation timing and iPad popover requirements before blaming Auto Layout broadly.
• Most alert constraint warnings come from unsupported customization rather than from your app's main screen constraints.