Controls, Input, and User Interaction

Introduction

A SwiftUI interface is more than a collection of visual elements. It is an interactive system in which users express intentions, provide information, navigate choices, and receive feedback. Controls such as buttons, menus, text fields, toggles, pickers, and sliders translate those intentions into changes in application state. Effective interface design therefore requires both technical implementation and thoughtful interaction design.

SwiftUI is especially well suited to interaction-heavy interfaces because controls are connected to state through property wrappers and bindings. A view describes what should appear for the current state; user actions modify that state; SwiftUI then recomputes the affected view hierarchy. This unidirectional pattern reduces manual synchronization and encourages predictable interfaces.

This chapter explains how to implement common controls and input patterns, how to manage focus and the keyboard, how to validate user data, and how to provide accessible and timely feedback.

Learning Objectives

By the end of this chapter, you should be able to:

• select appropriate SwiftUI controls for common interaction tasks;
• distinguish state, bindings, actions, and derived presentation;
• implement buttons, menus, forms, pickers, text input, toggles, sliders, and steppers;
• manage focus and keyboard behavior on iOS;
• validate input and communicate errors clearly;
• apply gestures without compromising discoverability or accessibility;
• design feedback, confirmation, and destructive-action patterns;
• evaluate interaction designs using usability, accessibility, and privacy principles.

1. The Interaction Model: State, Binding, and Action

Most SwiftUI interaction can be understood through three concepts:

• State is data owned by a view or its model.
• Binding is a two-way connection to state owned elsewhere.
• Action is code executed in response to an event.

A simple example is:

struct ProfileView: View {
    @State private var name = ""
    @State private var notificationsEnabled = true

    var body: some View {
        Form {
            TextField("Name", text: $name)
            Toggle("Notifications", isOn: $notificationsEnabled)

            Button("Save") {
                saveProfile()
            }
        }
    }

    private func saveProfile() {
        print("Saving \(name)")
    }
}

The dollar sign creates a binding. TextField does not need to know how the value is stored; it reads and writes through $name. The view body is recalculated when either state value changes. This is preferable to manually changing labels, enabling buttons, or updating error messages in several unrelated locations.

A useful design principle is to keep one authoritative source of truth. If the same value is copied into several variables, those copies can become inconsistent. Derived values, such as whether a Save button should be enabled, should normally be calculated from authoritative state.

For data shared across several screens, use an observable model rather than placing all state in one view. Modern SwiftUI projects may use the Observation framework with @Observable; projects using earlier APIs commonly use ObservableObject and @Published. The principle is the same: the model owns meaningful application data, while the view presents and edits it.

2. Choosing the Correct Control

Controls should communicate both the kind of input expected and the consequences of changing it. The following patterns are common on iOS.

The visual appearance should not be the only basis for selection. A segmented control is efficient for two to five mutually exclusive choices, but it becomes difficult to use when labels are long or choices are numerous. A toggle is appropriate for an independent Boolean setting; it should not be used to represent a choice between two unrelated modes when a picker would be clearer.

3. Buttons, Menus, and Confirmation

A button represents an intentional action. Its label should normally be a verb or a concise verb phrase, such as “Save,” “Add,” or “Share.” Avoid vague labels such as “Continue” when the result is not clear.

VStack(spacing: 16) {
    Button("Save") {
        saveProfile()
    }
    .buttonStyle(.borderedProminent)

    Button(role: .destructive) {
        showingDeleteConfirmation = true
    } label: {
        Label("Delete account", systemImage: "trash")
    }
}

The role: .destructive declaration communicates meaning to the system and assists with appropriate styling. Destructive actions should be separated from routine actions and should generally require confirmation when the result is irreversible or difficult to undo.

A menu groups related secondary actions without occupying permanent space:

Menu {
    Button("Sort by name") { sortOrder = .name }
    Button("Sort by date") { sortOrder = .date }
    Divider()
    Button("Filter") { showingFilters = true }
} label: {
    Label("Options", systemImage: "ellipsis.circle")
}

Menus should not hide an action that users need frequently. They are useful for related alternatives, not for concealing the primary path through an application.

Confirmation dialogs are appropriate when the user must make a deliberate choice:

.confirmationDialog(
    "Delete this item?",
    isPresented: $showingDeleteConfirmation,
    titleVisibility: .visible
) {
    Button("Delete", role: .destructive) {
        deleteItem()
    }
    Button("Cancel", role: .cancel) { }
}

The confirmation message should state what will happen and, where relevant, whether the action can be undone. Avoid asking for confirmation of every minor action; excessive prompts train users to dismiss warnings without reading them.

4. Forms and Input Controls

Form provides a platform-appropriate layout for settings and data-entry screens. It groups related controls and adapts them to the device. Section adds hierarchy and can include a header or footer explaining requirements.

Form {
    Section("Account") {
        TextField("Email", text: $email)
            .textInputAutocapitalization(.never)
            .keyboardType(.emailAddress)
            .textContentType(.emailAddress)
            .autocorrectionDisabled()
    }

    Section("Preferences") {
        Toggle("Receive updates", isOn: $receiveUpdates)
        Picker("Appearance", selection: $appearance) {
            Text("System").tag(Appearance.system)
            Text("Light").tag(Appearance.light)
            Text("Dark").tag(Appearance.dark)
        }
    }
}

A form should be organized according to the user's task, not according to the order in which fields were implemented. Put frequently used and low-risk fields first. Explain unusual requirements near the relevant field rather than placing all instructions in a distant help screen.

Pickers

A picker binds to a selection value. Each option must have a tag whose type matches the selection:

enum DeliverySpeed: String, CaseIterable, Identifiable {
    case standard, express, overnight
    var id: Self { self }

    var title: String {
        switch self {
        case .standard: "Standard"
        case .express: "Express"
        case .overnight: "Overnight"
        }
    }
}

Picker("Delivery", selection: $deliverySpeed) {
    ForEach(DeliverySpeed.allCases) { speed in
        Text(speed.title).tag(speed)
    }
}

A picker is appropriate when the user must select one value. If multiple values may be selected, use a set of Boolean choices, a multi-selection interface, or a dedicated list pattern. The distinction between “one,” “many,” and “none” is part of the data model, not merely a visual decision.

Sliders, Steppers, and Toggles

A slider is suitable for continuous or approximately continuous values, such as brightness. A stepper is better when values are discrete and the exact quantity matters, such as the number of tickets.

Slider(value: $volume, in: 0...1, step: 0.05) {
    Text("Volume")
} minimumValueLabel: {
    Image(systemName: "speaker.fill")
} maximumValueLabel: {
    Image(systemName: "speaker.wave.3.fill")
}

Stepper("Quantity: \(quantity)", value: $quantity, in: 1...20)

The range, step, and displayed value should agree. If the interface displays a percentage but stores a fractional value, format the displayed value clearly so that users are not confused.

5. Text Input and Data Entry

Text input requires more than placing a field on screen. The keyboard, autocorrection, capitalization, content type, privacy, and validation behavior all affect completion speed and accuracy.

Important modifiers include:

• .keyboardType(.emailAddress) for email addresses;
• .textContentType(.username) or another semantic content type to support AutoFill;
• .textInputAutocapitalization(.never) for identifiers and email addresses;
• .autocorrectionDisabled() where correction is harmful;
• .privacySensitive() for sensitive content in supported contexts;
• .submitLabel(.next) or .submitLabel(.done) to communicate the next action.

A field should have a visible label or an equivalent accessible label. Placeholder text is a hint, not a substitute for a persistent label, because it disappears as soon as the user begins typing.

For multiline input:

TextEditor(text: $notes)
    .frame(minHeight: 120)
    .overlay(alignment: .topLeading) {
        if notes.isEmpty {
            Text("Add notes")
                .foregroundStyle(.secondary)
                .padding(.top, 8)
                .padding(.leading, 5)
                .allowsHitTesting(false)
        }
    }

The overlay above is visual guidance only. The editor still needs an accessible label, such as .accessibilityLabel("Notes").

6. Focus Management and Keyboard Behavior

Focus management allows users to move efficiently through a form and dismiss the keyboard when appropriate. @FocusState identifies the currently focused field.

enum Field: Hashable {
    case email, password
}

struct LoginView: View {
    @State private var email = ""
    @State private var password = ""
    @FocusState private var focusedField: Field?

    var body: some View {
        Form {
            TextField("Email", text: $email)
                .focused($focusedField, equals: .email)
                .submitLabel(.next)
                .onSubmit { focusedField = .password }

            SecureField("Password", text: $password)
                .focused($focusedField, equals: .password)
                .submitLabel(.done)
                .onSubmit { focusedField = nil }
        }
        .toolbar {
            ToolbarItemGroup(placement: .keyboard) {
                Spacer()
                Button("Done") { focusedField = nil }
            }
        }
    }
}

Focus should follow a logical reading and completion order. When the user taps Next, move focus to the next valid field. When no further input is required, dismiss focus rather than leaving the keyboard obstructing content. A toolbar Done button is helpful, but it should supplement—not replace—the keyboard's Return or Done key.

Avoid forcing focus automatically unless it supports a clear task, such as focusing a search field when a search screen opens. Unexpected keyboards can obscure context and create an unpleasant first interaction.

7. Validation and Feedback

Validation determines whether input satisfies the rules required by the application. It can occur at several times:

• Immediate validation gives feedback while the user edits.
• On-commit validation checks when the user leaves a field.
• Submission validation checks the complete form before processing.
• Server validation checks rules that only the backend can know.

A good strategy combines these approaches. Immediate validation is useful for obvious local constraints, such as a character limit. Submission validation is necessary for cross-field rules. Server validation remains authoritative for conditions such as whether an email address is already registered.

Validation should be specific and constructive. “Invalid input” is less useful than “Enter an email address such as [email protected].” Errors should appear near the relevant field and should not rely only on color.

private var emailIsValid: Bool {
    let value = email.trimmingCharacters(in: .whitespacesAndNewlines)
    return value.contains("@") && value.contains(".")
}

private var canSubmit: Bool {
    emailIsValid && password.count >= 8
}

var body: some View {
    Form {
        TextField("Email", text: $email)

        if didAttemptSubmit && !emailIsValid {
            Text("Enter a valid email address.")
                .font(.caption)
                .foregroundStyle(.red)
                .accessibilityLabel("Email error: enter a valid email address")
        }

        SecureField("Password", text: $password)
        Button("Create account") {
            didAttemptSubmit = true
            guard canSubmit else { return }
            createAccount()
        }
        .disabled(!canSubmit)
    }
}

The example uses a deliberately simple local check. Production applications should use requirements appropriate to the service and should not claim that a syntactically plausible address is definitely deliverable. Validation rules should be documented and consistent across client and server where possible.

Feedback also includes progress indicators, success messages, disabled states, haptic feedback, and error alerts. Feedback should be timely, understandable, and proportional. A short operation may need only a state change; a long operation should communicate progress and prevent accidental duplicate submission.

8. Gestures and Direct Manipulation

SwiftUI provides gestures such as tap, long press, drag, magnification, and rotation. A gesture is appropriate when the action is spatial or direct—for example, dragging a card or swiping a row. It is less appropriate when the action is essential but hidden, because gestures may be undiscoverable and difficult for some users.

struct DraggableCard: View {
    @State private var offset: CGSize = .zero

    var body: some View {
        RoundedRectangle(cornerRadius: 16)
            .fill(.blue)
            .frame(width: 220, height: 140)
            .overlay { Text("Drag me").foregroundStyle(.white) }
            .offset(offset)
            .gesture(
                DragGesture()
                    .onChanged { value in
                        offset = value.translation
                    }
                    .onEnded { _ in
                        withAnimation {
                            offset = .zero
                        }
                    }
            )
            .accessibilityHint("Drag to move the card")
    }
}

The gesture's state is temporary interaction state. If the final position matters to the application, store the committed position separately and update it when the gesture ends. Use simultaneousGesture, highPriorityGesture, and gesture composition carefully because competing gestures can make controls difficult to operate.

Every essential gesture should have an alternative where feasible. For example, a swipe-to-delete action may also be exposed through an edit menu or an explicit button. This supports accessibility, discoverability, and users who cannot perform precise gestures.

9. Accessibility and Inclusive Interaction

An interactive control must be perceivable, understandable, and operable by a wide range of users. Important practices include:

• provide meaningful labels and hints;
• do not communicate errors through color alone;
• ensure text remains legible with Dynamic Type;
• maintain sufficient touch targets and spacing;
• preserve a logical VoiceOver order;
• use semantic controls instead of drawing a custom control that merely looks like one;
• support reduced motion and avoid unnecessary animation;
• test with VoiceOver, larger text, increased contrast, and one-handed use.

A custom button made from a plain shape and a tap gesture may look correct but fail to expose the correct accessibility behavior. Prefer Button when the interaction is a button. Semantics allow assistive technologies to identify the control, its role, and its state.

Localization also affects interaction. Labels may expand in other languages, and text entry conventions differ by locale. Do not assume a fixed width, a particular date format, or that every user enters a name in the same order.

10. Applied Case: A Mobile Appointment Form

Background

Consider an illustrative appointment-booking application for a community clinic. The form asks for a patient's name, appointment type, preferred date, reminder preference, and optional notes.

Problem

An initial prototype placed every field in one screen, used placeholder text as labels, opened the keyboard without a dismissal path, and displayed a generic alert when any field was invalid. Users frequently submitted incomplete forms and did not know which field required correction.

Analysis

The form contains several different input types: short text, a single selection, a date, a Boolean preference, and multiline text. Treating all fields as plain text would increase error and reduce accessibility. The form also contains a dependency: the appointment can be submitted only when required fields are complete.

Approach and Solution

A revised design uses:

1. labeled TextField controls for the patient's name;
2. a Picker for appointment type, with a small set of clearly named options;
3. a date picker constrained to valid appointment dates;
4. a Toggle for reminders;
5. a TextEditor for optional notes;
6. @FocusState to move from name to the next relevant field;
7. a submission button that records an attempted submission and presents field-level errors;
8. a progress indicator while the request is sent;
9. a confirmation screen stating the selected date and appointment type;
10. an explicit cancellation path and protection against accidental duplicate submission.

The view model owns the appointment data and submission state. The view derives canSubmit from required values rather than maintaining a separate, manually synchronized Boolean. Validation distinguishes local problems—such as a missing name—from service responses, such as an unavailable appointment slot.

Outcome

The revised form makes the expected input visible, reduces unnecessary typing, gives users a predictable keyboard path, and identifies errors at their source. It also gives VoiceOver users meaningful control labels and allows users who cannot perform swipe gestures to complete the same task.

Learning Points

The case demonstrates that interaction quality depends on the relationship among data modeling, control choice, validation, focus, feedback, and accessibility. A technically functional form can still be inefficient or exclusionary if those elements are designed independently.

11. Common Challenges and Limitations

Overloaded forms. Too many fields increase cognitive and completion cost. Ask only for information needed at that stage, and defer optional information.

Premature validation. Showing an error before the user has had a reasonable opportunity to enter a value can feel hostile. Track whether a field has been edited or whether submission has been attempted.

Disabled controls without explanation. A disabled button may prevent errors, but users need to understand what remains incomplete. Pair disabled states with visible requirements or permit submission and explain errors.

State duplication. Separate flags for every possible interface condition can conflict. Prefer a small, meaningful state model and derive presentation from it.

Network uncertainty. A valid local form does not guarantee a successful request. Handle loading, timeout, retry, cancellation, and server-side errors explicitly.

Gesture conflicts. Nested scroll views and custom gestures can compete for touches. Test on actual devices and provide non-gesture alternatives.

Security and privacy. Do not log passwords or sensitive text. Use secure fields, appropriate content types, privacy indicators where relevant, and the minimum data necessary for the task.

12. Contemporary Practice

Current SwiftUI development increasingly emphasizes semantic controls, observation-driven state, structured concurrency, and accessibility from the beginning of the design process. As applications incorporate on-device intelligence or server-based AI, the same interaction principles remain essential: explain what the system is doing, indicate uncertainty, allow correction, and obtain appropriate consent before using personal data.

AI-generated suggestions should never silently replace user input in high-consequence contexts. Users should be able to review, edit, reject, and understand generated content. For forms involving health, finance, identity, or employment, validation, privacy, and human control are especially important.

Best-Practice Checklist

Before releasing an interactive SwiftUI screen, verify that:

• every control has a clear purpose and label;
• the control type matches the data and decision being made;
• state has a clear owner and bindings are used where appropriate;
• focus moves in a logical order;
• the keyboard can be dismissed without frustration;
• validation messages identify the problem and the remedy;
• loading and failure states are represented;
• destructive actions are distinguished and appropriately confirmed;
• essential actions do not depend only on gestures;
• VoiceOver, Dynamic Type, localization, and reduced motion have been tested;
• sensitive information is not exposed through logs or inappropriate previews.

Chapter Summary

SwiftUI interaction is built around state, bindings, and actions. Buttons initiate operations, menus organize secondary choices, forms structure data entry, and specialized controls communicate whether the user is selecting, toggling, entering, or adjusting a value. Text input must be designed together with keyboard configuration, focus movement, content semantics, and privacy.

Effective validation is staged and specific. Feedback should explain system state without overwhelming the user. Gestures support direct manipulation but should not hide essential functionality. Accessibility requires semantic controls, meaningful labels, alternatives to gesture-only actions, and testing with assistive technologies. Professional interaction design combines these implementation techniques with task analysis, error prevention, inclusive design, and responsible handling of user data.

Key Terms

State: Data that determines what a SwiftUI view displays.

Binding: A two-way connection through which a view reads and writes externally owned state.

Action: Code executed in response to an event such as a tap or submission.

Control: An interactive UI element that accepts input or initiates an operation.

Form: A SwiftUI container that organizes data-entry and settings controls.

Picker: A control for selecting a value from a defined set.

Toggle: A control representing an independent Boolean choice.

TextField: A control for entering a single line of text.

TextEditor: A control for entering multiline text.

FocusState: SwiftUI state used to identify and control the focused input.

Gesture: A recognized physical interaction such as a tap, drag, or long press.

Validation: The process of determining whether input satisfies required rules.

Derived state: A value calculated from authoritative state rather than stored independently.

Feedback: Information communicating the result or current status of an interaction.

Dynamic Type: Apple’s system for adapting text to the user’s preferred text size.

Semantic control: A control whose role and state are exposed meaningfully to users and assistive technologies.

Destructive action: An operation that deletes, overwrites, or otherwise causes significant loss or change.

Source of truth: The authoritative location from which a value is owned and updated.

Review Questions

Short Answer Questions

1. What is the difference between state and a binding in SwiftUI?
2. When is a picker more appropriate than a toggle?
3. Why should placeholder text not be the only label for a text field?
4. What is the purpose of @FocusState?
5. Give two reasons why an essential action should not depend only on a gesture.

Long Answer Questions

1. Explain how state ownership and derived state contribute to predictable SwiftUI interfaces. Include a small example.
2. Compare immediate, on-commit, submission, and server-side validation. Discuss when each is useful.
3. Describe how you would design a registration form that supports efficient keyboard navigation and accessible error feedback.
4. Explain the role of buttons, menus, confirmation dialogs, and destructive-action roles in preventing user error.
5. Discuss how accessibility, localization, and privacy affect the design of input controls.

Analytical / Application Questions

1. A form has twelve fields, a disabled Submit button, and a generic “Invalid form” alert. Analyze the likely usability problems and propose a revised interaction design.
2. Design the state model and control choices for a shopping screen requiring quantity selection, a delivery choice, optional notes, and a destructive “Remove item” action.
3. A swipe gesture conflicts with vertical scrolling in a list. Evaluate at least two alternative designs and justify which one you would implement.

Multiple Choice Questions with Answers

Question 1

Which SwiftUI feature provides a two-way connection to state owned elsewhere?

A. Binding

B. Gesture

C. Modifier

D. Preview

Correct Answer: A. Binding

Question 2

Which control is most appropriate for enabling or disabling an independent preference?

A. Slider

B. Toggle

C. Menu

D. TextEditor

Correct Answer: B. Toggle

Question 3

What is the main purpose of @FocusState?

A. Persisting data between launches

B. Controlling and identifying focused inputs

C. Animating a view

D. Fetching server data

Correct Answer: B. Controlling and identifying focused inputs

Question 4

Which modifier is most suitable for an email-address input field?

A. .keyboardType(.emailAddress)

B. .buttonStyle(.bordered)

C. .listStyle(.sidebar)

D. .transition(.slide)

Correct Answer: A. .keyboardType(.emailAddress)

Question 5

Why should a destructive action commonly use role: .destructive?

A. It automatically saves the application

B. It communicates the action's potentially harmful meaning

C. It prevents all possible errors

D. It converts the action into a gesture

Correct Answer: B. It communicates the action's potentially harmful meaning

Question 6

Which control is generally best for selecting one value from a small set of alternatives?

A. Picker

B. TextEditor

C. ProgressView

D. SecureField

Correct Answer: A. Picker

Question 7

Which validation message is most useful?

A. Invalid input

B. Error

C. Enter an email address such as [email protected]

D. Try again sometime

Correct Answer: C. Enter an email address such as [email protected]

Question 8

What should an application do when a gesture performs an essential action?

A. Hide the action completely

B. Provide an alternative way to perform it where feasible

C. Disable VoiceOver

D. Require a custom animation

Correct Answer: B. Provide an alternative way to perform it where feasible

Question 9

Which control is intended primarily for multiline text entry?

A. TextField

B. TextEditor

C. Stepper

D. Picker

Correct Answer: B. TextEditor

Question 10

Why is one authoritative source of truth valuable in SwiftUI?

A. It prevents views from being recomputed

B. It reduces inconsistency between duplicated values

C. It removes the need for accessibility labels

D. It guarantees network requests succeed

Correct Answer: B. It reduces inconsistency between duplicated values