Generate Apple HIG Controls Code

Compiles Apple's Human Interface Guidelines for fourteen selection and input controls - toggles, segmented controls, sliders, steppers, pickers, combo boxes, text fields, text views, labels, token fields, virtual keyboards, rating indicators, gauges, and controls in general - into eleven synthesized Key Principles plus the full Apple reference doc for each. The principles map control type to use case: toggles for binary on/off states (applying immediately in Settings-style screens, on confirmation in modal forms), segmented controls for 2-5 mutually exclusive, roughly equal-importance options with short labels, sliders for continuous values where precise numeric input isn't critical, pickers for option sets too long for a segmented control (dates, times, structured data), steppers for small fixed-step adjustments with a visible current value, text fields for short single-line input with keyboard type matched to content versus text views for multi-line, combo boxes (macOS-only, type or choose from a list) and token fields (macOS-only, chips for recipients or tags), and gauges and rating indicators as display-only unless paired with an interactive variant. A cross-cutting rule: prefer standard system controls over custom ones, since custom controls add a learning curve and can break assistive technologies.

Use it when choosing which selection or input control fits a given piece of data - boolean, a fixed choice set, a numeric value, or free text - and when writing its accompanying labels and validation messaging, across iOS, iPadOS, macOS, and other Apple platforms. Two controls are macOS-only (combo boxes and token fields) and won't apply on iOS/iPadOS/tvOS/watchOS/visionOS layouts. Virtual keyboards should be matched to the expected input type rather than left at the system default - Apple defines eleven distinct keyboard types (ASCII capable, ASCII capable number pad, decimal pad, default, email address, name-phone pad, number pad, numbers-and-punctuation, phone pad, Twitter, URL, web search) - and a custom input view should only replace the system keyboard when it delivers app-specific value people will understand, not merely for novelty.

There is no API - output is a control recommendation with rationale, per the skill's own Output Format, covering how the control communicates and commits its current state (immediately versus on confirmation), a validation approach for when to surface errors, and accessibility guidance for labels, traits, and hints for VoiceOver. The questions the skill poses before recommending: what type of data is being captured, how many options exist, which platforms are targeted (since combo boxes and token fields are macOS-only), and whether the control sits in a Settings-style screen or an inline form.

Names the relevant SwiftUI, UIKit, and AppKit developer hooks per control where Apple's docs specify them - keyboardType(_:) and textContentType(_:) in SwiftUI, UIKeyboardType and UITextContentType in UIKit for matching a keyboard to expected input, and submitLabel(_:)/UIReturnKeyType for customizing the Return key. It cross-references four sibling HIG skills: hig-components-menus for buttons and pop-up buttons that complement these controls, hig-components-dialogs for the sheets and popovers that often contain them, hig-inputs for keyboard, pointer, and gesture interaction rules, and hig-foundations for the typography, color, and layout that style them.

Designers and developers building native Apple-platform forms and settings screens who need to pick the correct control for a given data type and get its state-management, validation, and accessibility behavior right per Apple's own guidance, rather than re-deriving it from the documentation site.