How To: Displaying Alerts With UIAlertController In Swift

In this article, you’ll learn how to use the UIAlertController class to display alert dialogs to the user of your iOS app. We’ll dive into setting up the alerts, responding to user actions, and getting input from the user with text fields.

The UIAlertController is a basic but important part of the iOS SDK, and it’s the default way to ask users to confirm an action. On top of that, UIAlertController also supports the action sheet – a convenient dialog style that allows your app’s users to quickly take action.

This article is specially written for beginner iOS developers. Working with the UIAlertController is a fundamental topic for practical iOS developers.

Displaying Alerts With UIAlertViewController

Are you sure? You’ve probably seen dozens of alert dialogs in iOS, Android, on the web, and on your Mac. Alert dialogs are as old as computers themselves! (Before computers had GUIs, you’d type “Y” or “N” at the command-line.)

Here’s an iOS alert dialog:

Alerts are crucial when building your app, to ask the user for confirmation of a sensitive action. Deleting data, signing out, giving permission, confirming a change – they are all tasks that your app’s user better think twice about before continuing.

As you can see in the example alert above, alerts help with grouping similar actions together and presenting them as one. Do you want to make a backup before erasing? Do you want to pay with PayPal or checkout with your creditcard? Do you want to take this incoming call or send an “I’ll call you later” message?

Most alerts can’t be dismissed without taking an action, and that’s why they’re so effective. When an alert is presented, it fills the entire iPhone screen. You can’t move away without making a choice. Such an alert is known as a modal dialog. On iOS, they’re simply called alerts.

As a design rule, you should always have a Cancel option that dismisses the alert and reverts the app to its previous state.

So… enough user interaction talk. Let’s check out how you can create an alert with UIAlertController!

First, you’re creating a constant called alert and assigning it an instance of UIAlertController. The constructor of UIAlertController takes three arguments: a title, a description and an alert controller style.

Then, you’re adding two actions to the alert: Yes and No. More on actions later.

Finally, you’re presenting the alert by calling the function present(_:animated:) on self. This will display the alert to the user.

Here’s how that example code looks in your app:

Using the UIAlertViewController constructor is pretty straightforward. You provide a title and message as strings, and then choose an alert type from the UIAlertControllerStyleenumeration.

You always have to “present” an alert, to show it to the user. Presenting a UIAlertController can only be done on a currently visible view controller that’s part of the view controller stack. Unless you’re doing something crazy, it’s most likely that you’re presenting the dialog from an active view controller.

Learn how to build iOS apps

Get started with iOS 13 and Swift 5

Sign up for my iOS development course, and learn how to build great iOS 13 apps with Swift 5 and Xcode 11.

UIAlertController Styles: Alert Or Action Sheet?

When creating your alert controller, you can choose between two options:

A simple alert, with the .alert constant

An action sheet, with the .actionSheet constant

Here’s what that exact same alert looks like, with both options:

Action sheets are pretty cool. They have three benefits over alerts:

They slide up from the bottom of the iPhone screen, so you can reach the action sheet buttons with your thumb. Easy!

You can fit more text on the button, compared to the alert style.

Usually, you need less text than an alert, because the action sheet buttons are self-explanatory.

When should you use an alert, and when an action sheet?

I think it’s best to use an action sheet for choosing between multiple similar options, like “Choose from Photo Library” and “Take Picture with Camera”.

When you need explicit confirmation on a positive and negative action, like “Yes” and “No”, or “OK” and “Cancel”, I think it’s best to use an alert style dialog.

It’s fairly typical for action sheets to not display a title or message to the user. Instead, you let the options speak for themselves. When you present a user with an action sheet, always give them the option to get out of the action sheet with a Cancel button.

Fun Fact: Prior to iOS 8, you would use the UIAlertView class to display alerts, and the UIActionSheet to display action sheets. You’d use the typical iOS target-action mechanism to respond to user interaction. Since then, those classes have been merged, and actions now take closures to respond to a user’s tap.

Responding To UIAlertController With Actions

With UIAlertController provides you with a mechanism to respond to user interaction. When a user taps an action you’ve attached to your alert, it calls a closure you’ve associated with that alert.

You can add actions to an alert with the addAction(_:) function. It takes one argument, an instance of UIAlertAction.

You can construct an UIAlertAction with a title, a style and a handler. The handler is a closure, and the style is a constant from the enum UIAlertActionStyle.

Within the closure you can define what happens when the action is executed, i.e. what happens when the user taps the alert button. In the above code, this is the closure that’s executed:

{ action inprint("Yay! You brought your towel!")
}

As you can see, the closure has one parameter action of type UIAlertAction. It’s a reference to the action that’s invoked and it allows you to distinguish between actions, for instance when you use one closure for multiple actions.

Actions can have three styles:

Default, with the constant .default

Cancel, with the constant .cancel

Destructive, with the constant .destructive

By default, the .cancel action is highlighted in the alert. You can see that in the example images above. The cancel option is effectively biased, which means you’ll have to make a conscious effort to confirm an alert. This means you’re less likely to make a mistake!

The .destructive style is usually red, indicating to your app’s users that this is a dangerous action or one that cannot be undone.

Note: Even if you change the order of adding the actions to the alert, the Cancel button is always shown first.

The UIAlertController can also have a preferred action. When specified, the alert then highlights that action. By default, the cancel button is the preferred action. You can also assign an action yourself, but you’ll first have to add it with the addAction(_:) function before assigning it to the preferredAction property of UIAlertController.

Then, you’re adding a text field with the addTextField(configurationHandler:) function. You can use the closure to configure the text field, like setting the placeholder property. When you want to use the input from the text field, you have to use one of the actions.

Finally, you’re adding an action that says OK. When this action is invoked, the input from the text field is printed out to the debugger with print. You can access the text field by using the textFields array on the alert.

And here’s what it looks like in your app:

Pretty neat, right? This effectively turns the alert into a prompt you can use to quickly ask for user input.

Learn how to build iOS apps

Get started with iOS 13 and Swift 5

Sign up for my iOS development course, and learn how to build great iOS 13 apps with Swift 5 and Xcode 11.

Further Reading

And that’s all there is to using alerts! You now know how to create one, how to configure it, how to respond to user actions, and why it’s sometimes better to use an action sheet than an alert dialog. Awesome!

Browse Topics

Swift Sandbox

Reinder de Vries

Reinder de Vries is a professional iOS developer. He teaches app developers how to build their own apps at LearnAppMaking.com. Since 2009 he has developed a few dozen apps for iOS, worked for global brands and lead development at several startups. When he’s not coding, he enjoys strong espresso and traveling.