ios-hig-design

---
name: ios-hig-design
description: Use when designing native iOS interfaces: SwiftUI/UIKit layouts, safe areas, tab bars, Dark Mode, SF Symbols, haptics, or making an app feel native to Apple's Human Interface Guidelines.
category: Design
version: 1.0.0
tools: []
---

# iOS Human Interface Guidelines Design Skill

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

## Core Principle

Apple's iOS design philosophy rests on three pillars: **clarity** (every element legible and purposeful), **deference** (the interface never overshadows the content it presents), and **depth** (layering, transitions, and realistic motion convey hierarchy and spatial relationships). The best iOS apps internalize this philosophy rather than following HIG rules mechanically — native components, system conventions, and platform consistency are why iOS users trust apps that feel like they belong.

## Scoring

**Goal: 10/10.** Score 1 point per satisfied row of the Quick Diagnostic (6 rows), plus up to 4 points for native idiom: +1 semantic colors/text styles throughout (no hardcoded values), +1 system controls over custom reimplementations, +1 standard gestures and meaningful haptics, +1 SF Symbols and correct app-icon shape. Bands: **9-10** = native, accessible, adapts to Dark Mode and Dynamic Type, zero foreign patterns; **5-6** = works but leaks Android idioms or hardcodes color/size; **≤3** = fails safe areas, touch targets, or VoiceOver. State the score and the specific improvements needed to reach 10/10.

## iOS Design Framework

### 1. Layout & Safe Areas

Design for the smallest screen first (375pt width, iPhone SE). Safe areas protect content from the notch, Dynamic Island, and home indicator — never place interactive elements under them. Standard content margins: 16-20pt from screen edges; spacing increments: 8/16/24pt. Minimum touch target and list row height: 44pt.

| Context | Layout Pattern |
|---------|---------------|
| Status bar | 20pt classic, 44-54pt on Dynamic Island devices |
| Navigation bar | 44pt standard row + ~52pt large title (~96pt total) |
| Tab bar | 49pt height, translucent with blur; 2-5 primary destinations |
| Home indicator | 34pt inset at bottom, system gesture area |

Use `VStack { }` (respects safe areas by default); reserve `.ignoresSafeArea()` for backgrounds/decoration only, never interactive content. Test on iPhone SE and Pro Max.

### 2. Typography & Dynamic Type

iOS uses San Francisco (SF Pro) with semantic text styles that scale automatically via Dynamic Type. Large Title: 34pt Bold; Title: 17pt Medium; Body: 17pt Regular; Caption: 12-13pt; secondary text: 15pt at 60% opacity. Minimum text size 11pt (captions only). Line height ≥1.3x font size; optimal line length 35-50 characters on mobile. Always left-aligned, non-justified.

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

### 3. Color & Dark Mode

Use semantic system colors — `Color(.label)`, `Color(.secondaryLabel)`, `Color(.systemBackground)` — instead of hardcoded values. `Color(.systemBlue)` is the default tint; `.systemRed` for destructive actions; `.systemGreen` for success. Dark Mode inverts text colors and shifts backgrounds darker while preserving relative hierarchy; accent colors need lower brightness and higher saturation to pop. Maintain 4.5:1 contrast in both modes.

Define custom colors in the Asset Catalog with light/dark variants, not in code. Use `.preferredColorScheme(.light/.dark)` in previews to test both side by side. Never assume a background is white or black; test with Increase Contrast enabled.

### 4. Navigation Patterns

iOS uses a layered navigation model: tab bars for primary destinations, navigation stacks for hierarchical drilling, modals for focused tasks. Tab bar: 2-5 primary destinations, always visible, remembers state per tab. Navigation bar: back button (top-left), title (center or large, collapses on scroll), actions (top-right). Modals dismiss via swipe-down or explicit close button. Never use hamburger menus — iOS users expect tab bars. Search bar can sit below the nav bar, hidden until pulled down.

Back button text should be the previous screen's title, not "Back." Tab labels are single words; modal titles describe the task. Use `NavigationStack` (not deprecated `NavigationView`) in SwiftUI.

### 5. Controls & Inputs

iOS provides native controls (buttons, lists, toggles, pickers, menus, text fields) that ship with built-in accessibility, haptics, and learned interaction patterns — custom reimplementations create friction and miss edge cases Apple already solved. Page-level actions go in the nav bar or bottom action bar. Primary buttons are filled with the theme color; secondary are outlined/text-only. Destructive actions use red and require confirmation when irreversible. Lists (table views) are the fundamental iOS content pattern. Match keyboard type to input (`.emailAddress`, `.phonePad`, `.URL`) and pair with `.textContentType` for autofill.

Prefer system confirmations (`.alert()`, `.confirmationDialog()`) and `.swipeActions` on list rows. Place primary action buttons at the bottom of the screen within thumb reach.

**Ethical boundary:** never disguise ads as native controls or make destructive actions easy to trigger accidentally.

### 6. Accessibility

iOS has world-class accessibility features (VoiceOver, Dynamic Type, Switch Control, Voice Control) that every app must support as a first-class concern — App Store review can reject apps unusable with assistive technologies. Every interactive element needs `.accessibilityLabel`; use `.accessibilityValue` for state and `.accessibilityHint` for effect. Group related elements with `.accessibilityElement(children: .combine)`. Support Dynamic Type at all sizes, test at the largest setting. Honor the 44x44pt touch target and 4.5:1 contrast minimum as accessibility requirements, not just visual defaults. Never convey meaning through color alone.

Write labels as nouns ("Favorite," "Settings"), hints as actions ("Shares this item with others"). Test the complete app flow using only VoiceOver; use Xcode's Accessibility Inspector to audit contrast and labels.

### 7. Icons & Images

SF Symbols is the standard icon system — use `Image(systemName:)` for all standard icons, since they align optically with San Francisco text and scale with Dynamic Type. App icons: export 1024x1024px square; iOS applies the superellipse ("squircle") mask automatically (corner radius = side × 0.222 with 61% smoothing). iOS 18+ supports light, dark, and tinted icon variants. Avoid text in app icons; keep designs simple with recognizable silhouettes.

Use `.symbolRenderingMode(.hierarchical)` for multi-color depth; size symbols relative to text with `.imageScale(.large)` or `.font()`.

**Ethical boundary:** never use icons that suggest functionality that doesn't exist or contradict iOS conventions (trash = delete, not archive).

### 8. Gestures & Haptics

iOS defines standard gestures and haptic patterns that must never be overridden: swipe-right-from-edge (back), swipe-down on modal (dismiss), pull-down on list (refresh). Swipe-left on rows reveals actions; long press shows context menus; pinch zooms images and maps. Gestures are muscle memory — repurposing them disorients users.

Three haptic types: **impact** (physical actions), **notification** (outcomes), **selection** (UI changes). Haptics should be subtle and meaningful — never constant or annoying.

## Common Mistakes

| Mistake | Why It Fails | Fix |
|---------|-------------|------|
| Hardcoded colors/sizes | Breaks in Dark Mode and Dynamic Type | Use semantic colors and text styles |
| Custom-built controls | Misses accessibility, haptics, edge cases | Use native SwiftUI/UIKit controls |
| Hamburger menu | Foreign to iOS users | Use a tab bar for primary navigation |
| Overriding system gestures | Disorients users, breaks muscle memory | Reserve swipe-back, pull-to-refresh, swipe-dismiss |
| No VoiceOver testing | App Store rejection risk | Test full flow with VoiceOver + Accessibility Inspector |

## Quick Diagnostic

| Question | If No | Action |
|----------|-------|--------|
| Does layout respect safe areas at all screen sizes? | Content clipped by notch/indicator | Use safe-area-respecting containers; test SE and Pro Max |
| Do colors and text use semantic styles? | Breaks in Dark Mode | Replace hardcoded values with `Color(.label)` etc. |
| Are touch targets ≥44×44pt? | Missed taps, accessibility failure | Increase target size or padding |
| Does navigation follow tab bar/stack/modal conventions? | Feels foreign | Rebuild with `NavigationStack`, standard tab bar |
| Does the app work fully with VoiceOver? | App Store rejection risk | Add labels/hints; test the full flow |
| Are SF Symbols and the squircle icon mask used correctly? | Visual inconsistency | Use `Image(systemName:)`; export 1024px icon |