Confirmation Dialog in SwiftUI

As an iOS Developer, you know that user interaction is the foundational pillar of any successful application. In the vast world of Swift programming, making decisions about how and when to request user confirmation can be the difference between a smooth experience and an accidental disaster (like deleting an entire database with a wrong tap).

As SwiftUI has matured, Apple has been refining its tools for building declarative interfaces. If you have been working with Xcode for a while, you probably remember the old .actionSheet() modifier. However, starting with iOS 15, macOS 12, and watchOS 8, Apple introduced a much more powerful, semantic, and cross-platform solution: confirmation Dialog in SwiftUI.

In this tutorial we are going to dive deep into confirmationDialog(). You will learn everything from its most basic syntax to how to handle dynamic data, along with UX best practices to implement it in your Swift projects across iOS, macOS, and watchOS.

1. Goodbye ActionSheet, Hello confirmationDialog()

In the early days of SwiftUI, developers used .actionSheet() to present a menu of options that slid up from the bottom of the screen on the iPhone. While functional, it had significant limitations:

1. It was heavily tied to the iOS design paradigm, making it difficult to adapt to macOS or watchOS.
2. The way its buttons were constructed (using the ActionSheet.Button struct) did not take full advantage of the power of the ViewBuilder that we were already using in the rest of SwiftUI.

To unify Swift programming across all its platforms, Apple deprecated ActionSheet and introduced confirmationDialog(). This new modifier is semantically more correct: its name indicates exactly what it is for (confirming an action), and it allows the use of standard Button views inside it, automatically adapting its visual design according to the operating system where it is running.

2. Basic Syntax and First Steps in Xcode

To start using confirmationDialog() in SwiftUI, you need two fundamental elements:

1. A state (a @State variable) that controls whether the dialog is visible or not.
2. The modifier attached to a view in your hierarchy.

Open Xcode, create a new Swift project, and let’s write our first example:

import SwiftUI

struct BasicConfirmationView: View {
    // 1. State to control the presentation
    @State private var showingDialog = false
    
    var body: some View {
        VStack {
            Button("Empty Trash") {
                // 2. Change the state when tapping the button
                showingDialog = true
            }
            .buttonStyle(.borderedProminent)
            .tint(.red)
        }
        // 3. The confirmationDialog modifier
        .confirmationDialog(
            "Are you sure you want to empty the trash?",
            isPresented: $showingDialog
        ) {
            // 4. The action buttons (ViewBuilder)
            Button("Empty", role: .destructive) {
                emptyTrash()
            }
            Button("Cancel", role: .cancel) {
                // The cancel action is handled automatically
            }
        } message: {
            Text("This action cannot be undone and you will lose all files permanently.")
        }
    }
    
    func emptyTrash() {
        print("Trash emptied using Swift programming.")
    }
}

Analyzing the code:

• Title: The first parameter is the dialog’s title ("Are you sure...?").
• isPresented: A Binding to your state variable. SwiftUI will automatically set it to false when the user selects an option or taps outside the dialog.
• Actions: Inside the closure, we use standard Button components.
• Message (Optional): An additional block where you can provide more context to the user using a Text view.

3. Understanding Button Roles

As an iOS Developer, one of the best features you will find in confirmationDialog() in SwiftUI is the use of Button Roles.

By assigning a role to a button inside the dialog, you are giving SwiftUI semantic clues about what that button does. The operating system will use this information to style it correctly.

• role: .destructive: Indicates an action that permanently deletes or alters data. In iOS, this button will appear red by default.
• role: .cancel: Indicates the action to abort the operation. SwiftUI will always place this button in the most accessible location (at the very bottom in iOS) and with a bold, prominent style. If you don’t include a cancel button, the system usually infers one, but it’s a good Swift programming practice to include it explicitly for clarity in your code.
• No role: If you omit the role parameter, the button is treated as a standard action and will be displayed using the system’s default tint color.

4. Controlling Title Visibility

Unlike a traditional alert (.alert()), where the title is always prominent, confirmationDialog() in SwiftUI allows you to hide the title if you consider it redundant. This is achieved using the titleVisibility parameter.

.confirmationDialog(
    "Select a Filter",
    isPresented: $showingFilters,
    titleVisibility: .visible // Can be .automatic, .visible, or .hidden
) {
    Button("Black and White") { applyFilter(.mono) }
    Button("Sepia") { applyFilter(.sepia) }
    Button("Vivid") { applyFilter(.vivid) }
    Button("Cancel", role: .cancel) { }
}

• .hidden: Hides the title and the message, showing only the buttons. Ideal for quick option menus where the context is already obvious from the button the user just tapped.
• .visible: Forces the title (and message if it exists) to always be shown.
• .automatic: This is the default behavior. The system decides whether to show it or not depending on the platform.

5. The Power of Cross-Platform: iOS, macOS, and watchOS

The true magic of using Swift and SwiftUI in Xcode is that you write the code once and the framework adapts it to the device. The confirmationDialog is the perfect example of this adaptive behavior.

On iOS (iPhone)

It is presented as an Action Sheet that slides up from the bottom of the screen. The buttons are stacked vertically, making them easy to reach with your thumb.

On iPadOS

If the user is on an iPad, the dialog does not slide up from the bottom; instead, it is presented as a small Popover pointing directly at the button or view that triggered the action. This maintains visual context on larger screens.

On macOS

On the Mac, the concept of an “Action Sheet” doesn’t exist in the same way. Therefore, SwiftUI automatically transforms the confirmationDialog into a traditional macOS modal alert that drops down from the window’s title bar, with buttons arranged horizontally or vertically depending on the available space.

On watchOS

On the Apple Watch’s small screen, the dialog takes over the entire screen, displaying the title and stacking the buttons as a scrollable list, ensuring the touch targets are large enough for the user’s finger.

As an iOS Developer, you don’t have to write complicated if os(iOS) statements. SwiftUI handles all the heavy lifting for the user interface.

6. Advanced Handling: Passing Data to the Dialog (The ‘presenting’ parameter)

So far, we have used a boolean to show the dialog. But in real-world Swift programming, you often need to show a dialog about a specific item. For example, swiping to delete an item from a list and asking for confirmation about that particular item.

Using a boolean and a separate state variable for the selected item can lead to race conditions or crashes due to forced Optional Unwrapping. To solve this, SwiftUI provides an overload of the modifier that accepts a presenting parameter.

This modifier takes an Optional value. When the value becomes non-nil, the dialog is shown, and SwiftUI safely passes the unwrapped value into the closure of your buttons.

struct UserInfo: Identifiable {
    let id = UUID()
    let name: String
}

struct UserListView: View {
    @State private var users = [
        UserInfo(name: "Steve"), 
        UserInfo(name: "Craig"), 
        UserInfo(name: "Tim")
    ]
    
    // The state is now the optional item to delete, not a boolean
    @State private var userToDelete: UserInfo?
    
    var body: some View {
        List {
            ForEach(users) { user in
                Text(user.name)
                    .swipeActions {
                        Button(role: .destructive) {
                            // Assign the specific user to the state
                            userToDelete = user 
                        } label: {
                            Label("Delete", systemImage: "trash")
                        }
                    }
            }
        }
        // We use the 'presenting' variant of confirmationDialog
        .confirmationDialog(
            "Delete User",
            isPresented: Binding(
                get: { userToDelete != nil },
                set: { if !$0 { userToDelete = nil } }
            ),
            presenting: userToDelete
        ) { user in // Here 'user' is of type UserInfo (non-optional)
            Button("Delete \(user.name)", role: .destructive) {
                delete(user)
            }
            Button("Cancel", role: .cancel) { }
        } message: { user in
            Text("Are you sure you want to delete \(user.name) from your database?")
        }
    }
    
    func delete(_ user: UserInfo) {
        users.removeAll { $0.id == user.id }
        userToDelete = nil
    }
}

This is a crucial technique that every iOS Developer must master in Xcode to avoid inconsistent state bugs in their applications.

7. Dynamic Button Generation with ForEach

Sometimes, the options you want to present in your confirmationDialog() aren’t static but come from an array. Since the content of the dialog is a ViewBuilder, you can use a ForEach to dynamically generate buttons, exactly as you would in a list or a VStack.

struct ExportView: View {
    @State private var isShowingExportOptions = false
    let exportFormats = ["PDF", "CSV", "JSON", "XML"]
    
    var body: some View {
        Button("Export Data") {
            isShowingExportOptions = true
        }
        .confirmationDialog("Select an export format", isPresented: $isShowingExportOptions) {
            
            // Dynamic generation of buttons
            ForEach(exportFormats, id: \.self) { format in
                Button("Export as \(format)") {
                    exportData(in: format)
                }
            }
            
            Button("Cancel", role: .cancel) { }
        }
    }
    
    func exportData(in format: String) {
        print("Exporting in format: \(format)")
    }
}

8. UX/UI Best Practices for the iOS Developer

Mastering Swift syntax is only half the job. The other half is knowing when to use the right tool. Here are some design guidelines (Apple’s Human Interface Guidelines) applied to confirmationDialog() in SwiftUI:

1. Difference between Alert and Confirmation Dialog:
   • Use .alert() for critical situations that require the user’s immediate attention (network errors, system failures) or yes/no questions where both options hold equal weight.
   • Use .confirmationDialog() when the action was initiated by the user (like tapping a delete button) and you need to offer alternative options or confirmation for a destructive action. It is also ideal for presenting a list of secondary actions related to an item.
2. Clear and Direct Titles: The dialog’s title should concisely explain the situation or the action. Avoid generic titles like “Warning” or “Options”.
3. Use Roles Correctly: Never use the .destructive role for an action that does not delete data. If a button formats text, simply use a normal button. The red color instills caution in the user; don’t abuse it.
4. Cancel Button: Although tapping outside the dialog sometimes cancels it, always include an explicit .cancel button. It increases user confidence by offering a clear “emergency exit”.

9. Common Mistakes and How to Avoid Them in Xcode

As you integrate this into your Xcode projects, watch out for these common stumbling blocks in Swift programming:

• Putting non-Button views inside: Although the closure is a ViewBuilder, on most platforms, a confirmationDialog only expects to receive Button views or logical constructs like ForEach and If that return buttons. If you try to put an Image or a Slider in there, it likely won’t render correctly or will cause weird behaviors, as it is not a general-purpose view but an action menu.
• Forgetting to reset the presentation state (pre-iOS 15): While isPresented is handled automatically, if you are managing complex global state logic, ensure your bound variable (Binding) returns to its original state to prevent the dialog from getting stuck.
• Too many options: If your ForEach generates 15 buttons, a confirmation dialog is the wrong tool. For long lists of options, you should consider navigating to a new screen or showing a full sheet with a List.

Conclusion

The confirmationDialog() in SwiftUI is further proof of Apple’s commitment to providing robust, declarative, and semantic tools for Swift programming. Leaving the old ActionSheet behind has given developers a cleaner, safer (thanks to the presenting parameter), and truly cross-platform way to interact with our users.

As an iOS Developer, adopting these modern APIs not only makes your code in Xcode easier to read and maintain but also ensures your apps feel native and respond fluidly, whether on a 6-inch iPhone or a Mac with a Retina display.

If you have any questions about this article, please contact me and I will be happy to help you . You can contact me on my X profile or on my Instagram profile.