Apple Hig Expert

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