ios-hig-design

What this skill does

# iOS Human Interface Guidelines Design Skill

Framework for designing native iOS app interfaces that feel intuitive, consistent, and aligned with Apple's design philosophy. Based on Apple's Human Interface Guidelines, the definitive resource for building apps that integrate seamlessly with iPhone, iPad, and the broader Apple ecosystem.

## Core Principle

Apple's iOS design philosophy rests on three foundational pillars: clarity, deference, and depth. Every element must be legible and purposeful (clarity). The interface should never overshadow the content it presents (deference). And layering, transitions, and realistic motion must provide hierarchy and spatial relationships (depth).

**The foundation:** The best iOS apps don't just follow HIG rules mechanically---they internalize the philosophy that the interface exists to serve the user's content and tasks. Native components, system conventions, and platform consistency aren't constraints---they're the reason iOS users trust and enjoy apps that feel like they belong.

## Scoring

**Goal: 10/10.** When reviewing or creating iOS interfaces or SwiftUI/UIKit code, rate them 0-10 based on adherence to the principles below. A 10/10 means full alignment with all guidelines; lower scores indicate gaps to address. Always provide the current score and specific improvements needed to reach 10/10.

## iOS Design Framework

### 1. Layout & Safe Areas

**Core concept:** iOS devices have specific screen dimensions, safe area insets, and hardware intrusions (notch, Dynamic Island, home indicator) that must be respected in every layout.

**Why it works:** When layouts respect safe areas and standard spacing, the app feels native and trustworthy. Users never have content hidden behind hardware features or system UI, and the visual rhythm matches the rest of the platform.

**Key insights:**

- Design for the smallest screen first (375pt width for iPhone SE)
- Safe areas protect content from hardware features---never place interactive elements under the notch, Dynamic Island, or home indicator
- Standard content margins are 16-20pt from screen edges
- Minimum touch target size is 44 x 44pt
- List row minimum height is 44pt
- Standard spacing increments: 8 / 16 / 24pt

**Product applications:**

| Context | Layout Pattern | Example |
|---------|---------------|---------|
| **Status bar** | 59pt height, always respected | Time, signal, battery area |
| **Navigation bar** | 44pt standard row + 58pt large title | Back button, title, actions |
| **Content area** | Flexible, scrollable, respects safe area | Main app content |
| **Tab bar** | 49pt height, translucent with blur | 2-5 primary destinations |
| **Home indicator** | 34pt inset at bottom | System gesture area |

**Copy patterns:**

- Use `VStack { }` which respects safe areas by default
- Use `.ignoresSafeArea()` only for backgrounds and decorative elements, never for interactive content
- Always test on multiple device sizes including iPhone SE and Pro Max

**Ethical boundary:** Never hide critical content or controls behind hardware intrusions. Users with any device should have equal access to all functionality.

See: [references/navigation.md](references/navigation.md) for detailed navigation bar and tab bar specifications.

### 2. Typography & Dynamic Type

**Core concept:** iOS uses the San Francisco (SF Pro) typeface with a semantic text style system that automatically scales for accessibility via Dynamic Type.

**Why it works:** Semantic text styles create consistent visual hierarchy across the platform. Dynamic Type ensures every user---including those with visual impairments---can read content at their preferred size without breaking layouts.

**Key insights:**

- Large Title: 34pt Bold; Title: 17pt Medium; Body: 17pt Regular
- Secondary text: 15pt Regular at 60% opacity; Caption: 12-13pt
- Minimum text size is 11pt (captions/secondary info only)
- Line height minimum 1.3x font size for body text
- Optimal line length: 35-50 characters per line on mobile
- Always use left-aligned, non-justified text
- Minimum contrast ratio: 4.5:1 (WCAG AA)

**Product applications:**

| Context | Typography Pattern | Example |
|---------|-------------------|---------|
| **Screen titles** | `.largeTitle` or `.title` style | Large title collapses on scroll |
| **Body content** | `.body` style, 17pt | List items, descriptions |
| **Secondary info** | `.subheadline` or `.footnote` | Timestamps, metadata |
| **Tab labels** | 10pt SF text | Tab bar item labels |
| **Buttons** | `.body` weight semibold | Primary action text |

**Copy patterns:**

- Use `.font(.title)`, `.font(.body)`, `.font(.caption)` instead of hardcoded sizes
- Prefer weight and color variation over extreme size differences for hierarchy
- Test all layouts at the largest Dynamic Type size to ensure nothing breaks
- Use `@ScaledMetric` for custom spacing that scales with Dynamic Type

**Ethical boundary:** Never disable Dynamic Type or set fixed font sizes that prevent accessibility scaling. Every user deserves readable text.

See: [references/typography.md](references/typography.md) for complete text styles, font sizes, and Dark Mode typography rules.

### 3. Color & Dark Mode

**Core concept:** iOS provides semantic system colors that automatically adapt between light and dark appearances, ensuring proper contrast and visual hierarchy in both modes.

**Why it works:** Semantic colors maintain readability and hierarchy across appearances without manual intervention. Users who prefer Dark Mode get a first-class experience, and apps that support both modes feel polished and native.

**Key insights:**

- Use `Color(.label)`, `Color(.secondaryLabel)`, `Color(.systemBackground)` instead of hardcoded colors
- `Color(.systemBlue)` is the default tint/accent; `.systemRed` for destructive actions; `.systemGreen` for success
- Dark Mode inverts text colors (dark to light) and shifts backgrounds darker while maintaining relative hierarchy
- Accent colors in Dark Mode need lower brightness and higher saturation to pop
- Always preview both modes during development
- Maintain 4.5:1 contrast ratio in both light and dark

**Product applications:**

| Context | Color Pattern | Example |
|---------|--------------|---------|
| **Primary text** | `Color(.label)` | Adapts white/black per mode |
| **Secondary text** | `Color(.secondaryLabel)` | 60% opacity in both modes |
| **Backgrounds** | `Color(.systemBackground)` / `.secondarySystemBackground` | Layered depth |
| **Destructive actions** | `Color(.systemRed)` | Delete buttons, warnings |
| **Interactive tint** | App accent color or `.systemBlue` | Links, toggle states |

**Copy patterns:**

- Use `.preferredColorScheme(.light)` and `.dark` in previews to test both modes side by side
- Define custom colors in Asset Catalog with light/dark variants, not in code
- Never assume a background is white or black---always use semantic colors
- Test with Increase Contrast accessibility setting enabled

**Ethical boundary:** Dark Mode is not optional polish---it is expected by users. Never ship an app that is unreadable or broken in Dark Mode.

See: [references/colors-depth.md](references/colors-depth.md) for semantic colors, Dark Mode palette, and contrast ratio guidelines.

### 4. Navigation Patterns

**Core concept:** iOS uses a layered navigation model with tab bars for primary destinations, navigation stacks for hierarchical drilling, and modals for focused tasks.

**Why it works:** Consistent navigation patterns mean users always know where they are, how they got there, and how to go back. Violating these patterns creates confusion and makes the app feel foreign on iOS.

**Key insights:**

- Tab bar: 2-5 primary destinations, always visible, remembers state per tab
- Navigation bar: back button (top-left), title (center or large), actions (top-right)
- Large title collapses to compact title on scroll with smooth animation
- Modals for focused tasks; dismiss via swipe-down or e