Choosing the Right iOS Control: UIKit and SwiftUI Side by Side
A surprising number of iOS usability problems come from using the wrong control: a switch that triggers an action, a segmented control with eight segments, an alert where a menu belongs. Apple's Human Interface Guidelines describe each control in depth, but when you are building a screen you usually want a quicker answer: which one, and what is it called in UIKit and SwiftUI?
This guide is that answer.
Quick reference
| You need the user to⦠| Use | UIKit | SwiftUI |
|---|---|---|---|
| Trigger an action | Button | UIButton |
Button |
| Pick one of a few actions | Menu (pull-down button) | UIButton with menu |
Menu |
| Switch between 2β5 views or modes | Segmented control | UISegmentedControl |
Picker with .segmented style |
| Turn a setting on or off | Switch | UISwitch |
Toggle |
| Choose a value from a continuous range | Slider | UISlider |
Slider |
| Nudge a number up or down | Stepper | UIStepper |
Stepper |
| Pick a date or time | Date picker | UIDatePicker |
DatePicker |
| Pick one of many options | Picker / list | UIPickerView, or a menu |
Picker |
| Pick a colour | Colour picker | UIColorPickerViewController |
ColorPicker |
| Enter short text | Text field | UITextField |
TextField |
| Enter long text | Text view | UITextView |
TextEditor |
| Search | Search bar | UISearchController / UISearchBar |
.searchable |
| Show progress | Progress / activity indicator | UIProgressView, UIActivityIndicatorView |
ProgressView |
| Confirm something important | Alert | UIAlertController (.alert) |
.alert |
| Choose among destructive or several actions | Action sheet / confirmation dialog | UIAlertController (.actionSheet) |
.confirmationDialog |
| Show page position | Page control | UIPageControl |
TabView with .page style |
Buttons vs menus
Use a button for one clear action. When several related actions share a space (sort options, "Add photo / Add file"), a menu keeps the screen clean and avoids a stack of buttons. In UIKit, assign a UIMenu to a button's menu property and set showsMenuAsPrimaryAction = true if tapping should open it immediately.
Switches are for state, not actions
A switch should change a setting that takes effect immediately, like "Show badges". If flipping it would start a download, send a message or open a screen, use a button instead. Users expect to be able to flip a switch back without consequence.
Segmented controls: keep them short
Segmented controls work for two to about five short labels that switch a view or a mode (Day / Week / Month). With more options, or long labels, use a menu or a picker. In SwiftUI, a segmented control is a Picker with .pickerStyle(.segmented).
Slider or stepper?
- Slider: the exact value matters less than the feel (volume, brightness, playback position).
- Stepper: small, precise integer changes (quantity, number of copies). Show the current value next to it, because a stepper doesn't display one.
Pickers: wheel, inline or menu
Wheel pickers suit a handful of values but get tedious with long lists. For long lists, push a searchable list instead. For dates, UIDatePicker and SwiftUI's DatePicker offer compact, inline and wheel styles; the compact style takes the least room in forms.
Alerts vs action sheets
- Alert: something important the user must acknowledge, or a confirmation with one or two choices. Keep the title short and the buttons specific ("Delete", not "OK").
- Action sheet / confirmation dialog: a choice among several actions, often including a destructive one, related to something the user just did.
Avoid alerts for information that could sit inline on the screen; frequent alerts train users to dismiss them without reading.
Progress: determinate or not?
If you know how far along a task is, show a progress bar. If you don't, use an activity indicator, and keep it short; anything that spins for more than a few seconds should explain what's happening.
Default first, custom second
The system controls come with accessibility, Dynamic Type, Dark Mode and localisation support built in. Start with the default configuration, check it on a real device in light and dark appearance with a large text size, and customise only where you have a reason.
See them before you build
Reading a list of control names only goes so far; it's much faster to tap a live example and compare configurations.
Try every control on your phone: Catalog - UI (free, by the author of this guide) lets you browse and try iOS UI components (controls, pickers and views, with parallel SwiftUI demos), view and copy code snippets, filter by UIKit, Controls, Views, Pickers or SwiftUI, and save favourites.
A five-question checklist for any control
- Does it trigger an action or change a state? (Button vs switch.)
- How many options are there? (Segmented control vs menu vs list.)
- Does precision matter? (Slider vs stepper vs text field.)
- Will the user need to undo it? (Destructive actions need confirmation.)
- Does it still work with VoiceOver and a large text size?
Answer those five and you'll pick the right control nearly every time.