Introduction

Despite the title, modern iOS apps should not create UIAlertView. Apple deprecated that class long ago, and UIAlertController is the supported API for both alerts and action sheets. If you want a simple message with one or two buttons, the right answer today is to present a UIAlertController from the current view controller.

Presenting a Basic Alert

The simplest alert has a title, a message, and one or more actions. Each action can be .default, .cancel, or .destructive, and each one can run a handler when the user taps it.

1import UIKit
2
3final class ProfileViewController: UIViewController {
4    @IBAction private func deleteButtonTapped(_ sender: UIButton) {
5        let alert = UIAlertController(
6            title: "Delete draft?",
7            message: "This removes the draft from this device.",
8            preferredStyle: .alert
9        )
10
11        let cancelAction = UIAlertAction(title: "Cancel", style: .cancel)
12        let deleteAction = UIAlertAction(title: "Delete", style: .destructive) { [weak self] _ in
13            self?.deleteDraft()
14        }
15
16        alert.addAction(cancelAction)
17        alert.addAction(deleteAction)
18
19        present(alert, animated: true)
20    }
21
22    private func deleteDraft() {
23        print("Draft deleted")
24    }
25}

This code is enough for most confirmation dialogs. The view controller builds the alert, adds actions, and presents it. The destructive action uses a weak capture of self so the alert handler does not accidentally keep the view controller alive longer than necessary.

Adding Text Input

Alerts can also collect a small amount of input. A common example is asking for a folder name, an email address, or a one-time code. UIAlertController lets you add text fields only when the preferred style is .alert.

1import UIKit
2
3final class FoldersViewController: UIViewController {
4    func promptForFolderName() {
5        let alert = UIAlertController(
6            title: "New Folder",
7            message: "Enter a name for the folder.",
8            preferredStyle: .alert
9        )
10
11        alert.addTextField { textField in
12            textField.placeholder = "Folder name"
13            textField.clearButtonMode = .whileEditing
14        }
15
16        let saveAction = UIAlertAction(title: "Save", style: .default) { [weak alert] _ in
17            let folderName = alert?.textFields?.first?.text?.trimmingCharacters(in: .whitespacesAndNewlines) ?? ""
18            guard !folderName.isEmpty else { return }
19            print("Create folder named: \\(folderName)")
20        }
21
22        alert.addAction(UIAlertAction(title: "Cancel", style: .cancel))
23        alert.addAction(saveAction)
24
25        present(alert, animated: true)
26    }
27}

This pattern keeps the UI lightweight. The alert owns the text field, and the save action reads the value when the user confirms. For anything more complex than one or two fields, a dedicated view controller is usually easier to validate and test.

When the Old UIAlertView Name Still Matters

You will still see UIAlertView in old blog posts, legacy Objective-C code, and migration questions. The concepts map cleanly to modern UIKit:

• 'UIAlertView title becomes the UIAlertController title.'
• 'UIAlertView message becomes the UIAlertController message.'
• Button callbacks become UIAlertAction handlers.

If you are maintaining an older app, replacing UIAlertView with UIAlertController is usually straightforward. The main difference is that alerts are now presented by a view controller rather than shown directly by the alert object itself.

Common Pitfalls

The most common mistake is trying to use UIAlertView in new code. It is deprecated, and relying on deprecated UIKit APIs makes future maintenance harder. Use UIAlertController unless you are reading very old sample code.

Another frequent issue is presenting the alert from the wrong place. If the current view controller is not in the visible hierarchy, present(_:animated:) may log a warning and nothing appears. Present from the controller that is currently on screen.

Action sheets need extra care on iPad. If you use .actionSheet, you must provide an anchor with popoverPresentationController?.sourceView, sourceRect, or barButtonItem. Without that anchor, the app can crash at runtime on iPad.

Finally, keep action handlers short. Launching long-running work directly in the tap handler can make the interface feel frozen. Trigger the next operation quickly, then move any expensive work to the appropriate async path.

Summary

• Use UIAlertController for simple alerts in modern iOS code.
• Add actions with UIAlertAction and present the alert from a visible view controller.
• Use text fields only with the .alert style and keep the interaction small.
• Replace legacy UIAlertView references with UIAlertController when updating older code.
• Remember the iPad anchor requirement for action sheets.