Apple Human Interface Guidelines (HIG) Expert

A skill focused on shipping apps that feel native on Apple platforms. Covers the underlying HIG principles, platform-specific patterns, native component selection, and accessibility expectations.

This skill is opinionated about native conventions. It's not the right skill if your goal is to maximize cross-platform UX uniformity over native fit (see web design guides for that).

When to use this skill

Designing or reviewing an iOS / iPadOS / macOS / watchOS / tvOS / visionOS app
Auditing an existing app for HIG compliance
Picking the right native component (sheet vs popover vs full-screen)
Adapting an app from one Apple platform to another
Reviewing typography, color, spacing, and motion against HIG
Auditing accessibility against Apple's accessibility expectations
Onboarding a designer or PM new to Apple-platform design

Inputs the advisor expects

Target platform(s) and version range (iOS 17+, macOS 14+, etc.)
App type (utility, productivity, social, games, media)
Current designs / screenshots (described or referenced)
Stack: SwiftUI vs UIKit / AppKit, recent or legacy codebase
Accessibility maturity (WCAG audit done; VoiceOver tested)

Workflows

Workflow 1 — Audit screens for HIG compliance

Describe or reference each screen.
Run hig_compliance_checker.py with the screen inventory.
Address findings by category (navigation, typography, controls, spacing, motion).

python3 apple-hig-expert/scripts/hig_compliance_checker.py \
  --input screens.json --format markdown

Workflow 2 — Pick the right component for a flow

Describe the interaction goal.
Use component_pattern_lookup.py to surface candidate patterns, trade-offs, and platform-specific guidance.

python3 apple-hig-expert/scripts/component_pattern_lookup.py \
  --platform ios --goal "show options without leaving context" --format markdown

Workflow 3 — Audit accessibility against Apple expectations

Capture screen inventory + accessibility attributes (labels, hints, traits).
Run accessibility_auditor.py to surface gaps.
Use Apple Accessibility Inspector to validate.

python3 apple-hig-expert/scripts/accessibility_auditor.py \
  --input a11y_state.json --format markdown

Decision frameworks

Sheets vs popovers vs full-screen

Pattern	When to use	Platform
Sheet (medium / large)	Modal task with clear escape	iOS, iPadOS, macOS, visionOS
Popover	Context-anchored options, brief	iPadOS (compact: replaced with sheet), macOS
Full-screen cover	Immersive task, e.g., photo editing	iOS
Push (navigation stack)	Hierarchical drill-in	iOS, iPadOS
Inspector	Persistent secondary content	macOS, iPadOS
Toolbar item	Quick action on current context	All

Common mistake: popover on compact iPhone (it becomes a sheet automatically; design for both).

When to use SwiftUI vs UIKit

SwiftUI — new apps, simple-to-moderate complexity, multi-platform from one codebase
UIKit — legacy code, complex interactions not yet ergonomic in SwiftUI, performance-sensitive
Mixed — common; embed SwiftUI in UIKit hosts or vice versa

The trend (2026) is SwiftUI-first for new development; UIKit retains strength in performance-sensitive lists and complex gesture handling.

Color and dark mode

Use semantic colors (systemBackground, secondaryLabel) — they adapt to light/dark mode automatically
Avoid hardcoded hex values for system-feeling content
Test in both light + dark mode + increased contrast settings
Brand colors: assess contrast in both modes; use Asset Catalog with separate light/dark variants

Typography

Use Dynamic Type styles (largeTitle, body, caption) — they scale with user accessibility settings
Don't hardcode font sizes for body text
Custom fonts: still respect Dynamic Type through UIFontMetrics / SwiftUI dynamicTypeSize
Test at largest Dynamic Type setting; design must remain usable

Common engagements

"Help me adapt our iPhone app for iPad"

Identify navigation: sidebar (NavigationSplitView) vs tabs at iPad sizes
Use Inspector for secondary content
Convert sheets to popovers where appropriate
Adapt to multitasking (split view, slide over)
Add hardware support: Pencil, keyboard shortcuts, pointer interactions

"Our app feels un-Apple-y. What's wrong?"

Check typography — using Dynamic Type styles, not hardcoded sizes?
Check colors — semantic colors, dark mode parity?
Check spacing — multiples of 4 or 8; not custom every-screen
Check controls — using native ones, not custom toggles/buttons?
Check navigation — does back gesture work? Does state persist correctly?

"Make our app accessible"

Every interactive element has a label
Decorative images marked accessibilityHidden
Focus order makes sense for VoiceOver
Custom controls have correct accessibilityTraits
Touch targets ≥44pt × 44pt
Color isn't the only way information is conveyed
Reduced motion respected
Test with VoiceOver, Voice Control, Switch Control, Dynamic Type max

Anti-patterns to avoid

Custom UI for things iOS already provides. Use native; users expect it.
Hardcoded font sizes. Breaks Dynamic Type; breaks accessibility.
Same UI across all Apple platforms. Each platform has different conventions.
Hamburger menu on iOS. Tab bar is more discoverable.
Modal-heavy navigation. Apple's nav stack is the primary pattern.
Custom navigation bar. Use the system one; users know how it works.
Ignoring safe area insets. Content gets clipped behind notches and home indicators.
No haptic feedback on iOS. Apps that use it feel premium.
No keyboard support on iPad. Power users will leave.

References

references/hig-fundamentals.md — principles, design language, foundational patterns
references/ios-component-patterns.md — sheets, navigation, controls, gestures, lists
references/cross-platform-considerations.md — iPad, Mac, Watch, TV, Vision differences

Related skills

product-team/product-designer — broader product design
product-team/ui-design-system — design system construction
product-team/ux-researcher-designer — research informing design
engineering/senior-frontend — implementation