System Buttons & Actions

System buttons form essential building blocks of Apple interfaces. Every button combines a specific style, content, and role to communicate its purpose clearly to users.

Button styles include size, color, and shape, while content can be text, symbols, or both. The system's role defines what each button means and can change how it looks.

Apple provides various button types beyond standard buttons. These include common controls like info and close buttons, plus specialized components like toggles, pop-up buttons, and segmented controls.

Common button attributes include:

• Style elements. Size, shape, color, and visual weight
• Content types. Text labels, SF Symbols, or combined elements
• System roles. Pre-defined meanings that affect appearance^[1]

Primary action buttons guide users toward key tasks. In Apple's interfaces, these buttons use a filled style and prominent placement to show they represent the main action on screen.

HIG requires specific styling for primary buttons. They need solid background color, high contrast with surrounding elements, and clear labels that describe the action. The filled style helps them stand out from other interface elements.

Primary buttons must follow consistent patterns across an app. Main actions like Save, Continue, or Done use the same styling everywhere they appear. Different screens can have different primary actions, but each screen should have only one primary button.

Common primary button patterns include:

• Clear verbs. Action words that show what the button does
• High contrast. Filled style that stands out visually
• Consistent style. Same styling for primary actions across screens

Destructive buttons handle risky actions in Apple interfaces. They warn users about operations that delete content, remove data, or make significant changes that are hard to undo.

These buttons use red text with a plain style for clear warning. The color red signals caution, while keeping the button's appearance simple and consistent with other interface elements. In confirmation dialogs, destructive actions switch to filled red style for final confirmation.

Position and spacing matter for destructive buttons. They should be placed away from frequently used actions and include enough padding to prevent accidental triggers.

Common destructive button patterns include:

• Plain red style. Red text without background for initial actions
• Red filled. Used in confirmation dialogs for final actions
• Clear labels. Direct words like "Delete" or "Remove"

Segmented controls help users switch between related options. A common example is the grouping in the Photos app (All, Months, Years).

HIG specifies clear styling for segments:

• Equal sizing. Each segment needs enough width for its content, equal height across all segments, and clear active states
• Clear states. The selected segment stands out visually. The selected segment uses a filled style while others remain plain
• Brief labels. Segments work best with similar-length options. Text labels should be short and descriptive and fit without truncation. Having too many segments or uneven content makes controls harder to use

Pop-up buttons present a list of mutually exclusive options. After selecting an item from the menu, the button updates to show the current choice, helping users track their selection. Common examples include choosing text size in Settings, selecting video quality in media players, or picking time zones.

HIG specifies key patterns for pop-up buttons:

• Menu content. Options should be mutually exclusive and presented in a flat list. For example, meeting admission options: People who were invited, Everyone, Only me
• Default selection. The button shows a useful default option before users make their first choice. For instance, Sidebar icon size defaults to Medium
• Clear labeling. Button labels or nearby text should help users predict available options without opening the menu^[2]

Pull-down buttons reveal actions related to a specific task. When users select an item from the menu, the app performs that action immediately, unlike pop-up buttons that change states.

HIG recommends specific patterns for pull-down buttons:

• Action focus. Menu items perform commands like Sort, Add, or Filter. For example, a Sort button shows options for sorting by date, name, or size
• Menu length. Include at least three items to make opening the menu worthwhile. Too many items make finding specific options harder
• Clear purpose. Button content and menu items should explain available actions without needing extra titles
• More actions. Use the More button (ellipsis.circle) to group secondary actions where space is limited, but consider that hidden items become harder to discover^[3]

Button states help users understand when and how they can interact with controls. iOS buttons have 5 distinct states: default, highlighted, focused, selected, and disabled.

HIG stresses the importance of clear visual feedback for each state change. The transition between states must be instant and noticeable, helping users understand their actions were detected. This immediate response builds trust in the interface.

Each button type shows these states differently. Primary buttons display prominent state changes through background colors, while secondary buttons use more subtle indicators like opacity changes.

Common state patterns include:

• Visual clarity. Each state needs a distinct appearance
• Instant feedback. Immediate response to state changes
• State hierarchy. Clear progression between different states

Icon buttons use symbols to represent actions. In iOS, these buttons typically use SF Symbols — Apple's system icons that automatically adapt to different contexts and accessibility settings.

HIG defines specific requirements for icon buttons:

• Clear meaning. Icons should instantly communicate their purpose. Common actions like Add (+) or Share should use standard system symbols.
• Consistent styling. Icons need to match the iOS style, including weight, size, and color. SF Symbols help maintain this consistency.
• Touch targets. Despite small icons, buttons need a minimum tap area of 44x44 points on touchscreen devices. This ensures reliable touch interaction while maintaining visual compactness.

Back buttons help users return to previous screens. In iOS, these buttons automatically show the title of the previous screen and adapt their width based on available space.

HIG specifies key patterns for navigation buttons:

• Back buttons. Show a chevron pointing left (<) followed by the previous screen's title in iOS. On watchOS, back buttons appear automatically for hierarchical navigation
• Forward navigation. Uses a chevron pointing right (>) to indicate more content. Common in list views and detail screens
• Placement rules. iOS places back buttons in the navigation bar's leading edge. On watchOS, account for the persistent clock in the navigation bar when positioning content^[4]