ios-hig-design
This iOS design skill provides a framework for building native iPhone and iPad interfaces aligned with Apple's Human Interface Guidelines. Use it when designing SwiftUI or UIKit layouts, implementing navigation patterns, working with safe areas and Dynamic Island constraints, choosing system components like SF Symbols, or ensuring accessibility and dark mode support across different screen sizes.
git clone --depth 1 https://github.com/wondelai/skills /tmp/ios-hig-design && cp -r /tmp/ios-hig-design/ios-hig-design ~/.claude/skills/ios-hig-designSKILL.md
# 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 foundation:** The best iOS apps internalize this philosophy rather than following HIG rules mechanically. 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.** 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. Always state the score and the 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 every layout must respect.
**Key insights:**
- 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
**Product applications:**
| Context | Layout Pattern | Example |
|---------|---------------|---------|
| **Status bar** | 20pt classic, 44-54pt on Dynamic Island devices | Time, signal, battery area |
| **Navigation bar** | 44pt standard row + ~52pt large title (~96pt total) | 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 decoration, never interactive content
- Test on multiple sizes, including iPhone SE and Pro Max
See [references/navigation.md](references/navigation.md) when laying out chrome---exact nav bar and tab bar dimensions, large-title behavior, and split-view rules.
### 2. Typography & Dynamic Type
**Core concept:** iOS uses the San Francisco (SF Pro) typeface with semantic text styles that automatically scale for accessibility via Dynamic Type. Semantic styles give consistent platform hierarchy; Dynamic Type lets users read at their preferred size without breaking layouts.
**Key insights:**
- Large Title: 34pt Bold; Title: 17pt Medium; Body: 17pt Regular; Caption: 12-13pt; secondary text: 15pt at 60% opacity
- Minimum text size 11pt (captions/secondary only)
- Line height at least 1.3x font size; optimal line length 35-50 characters on mobile
- Always left-aligned, non-justified text
**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; `@ScaledMetric` for custom spacing that scales
- Prefer weight and color variation over extreme size differences for hierarchy
- Test all layouts at the largest Dynamic Type size
See [references/typography.md](references/typography.md) when matching a design to exact specs---per-style hex values and the Dark Mode text-color mapping.
### 3. Color & Dark Mode
**Core concept:** iOS provides semantic system colors that automatically adapt between light and dark appearances while preserving contrast and hierarchy.
**Key insights:**
- Use `Color(.label)`, `Color(.secondaryLabel)`, `Color(.systemBackground)` instead of hardcoded colors
- `Color(.systemBlue)` is the default tint; `.systemRed` for destructive actions; `.systemGreen` for success
- Dark Mode inverts text colors and shifts backgrounds darker while keeping relative hierarchy; accent colors need lower brightness and higher saturation to pop
- Maintain 4.5:1 contrast in both modes; preview both during development
**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 the Asset Catalog with light/dark variants, not in code
- Never assume a background is white or black; test with IncreBuild lean, opinionated products using the 37signals philosophy from "Getting Real", "Rework", and "Shape Up". Use when the user mentions "Getting Real", "Rework", "Shape Up", "37signals", "Basecamp method", "six-week cycles", "fixed time variable scope", "appetite vs estimates", "betting table", "breadboarding", "fat marker sketch", "build less", "underdo the competition", "opinionated software", "we have too many meetings", "how do we ship faster", or "stop overbuilding". Also trigger when cutting scope to ship sooner, running a small team, or avoiding long-term roadmaps. Covers shaping, betting, building, and the art of saying no. For MVP validation, see lean-startup. For design sprints, see design-sprint.
Create uncontested market space using value innovation instead of competing head-to-head. Use when the user mentions "blue ocean", "red ocean", "strategy canvas", "ERRC framework", "value innovation", "non-customers", "buyer utility map", "the market is too crowded", "how do we stand out", or "escape the price war". Also trigger when exploring a new market category, or finding underserved or non-customers. Covers the Four Actions Framework, Six Paths, buyer utility map, and value-cost trade-offs. For real strategy formulation and bad-strategy detection, see good-strategy-bad-strategy. For tech adoption strategy, see crossing-the-chasm. For product positioning, see obviously-awesome.
Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.
Write readable, maintainable code through disciplined naming, small functions, and clean error handling. Use when the user mentions "clean up this code", "this function is too long", "code smells", "naming conventions", "boy scout rule", "single responsibility", or "unit test quality". Also trigger when reviewing a pull request for readability, untangling a messy function, debating comment styles, or improving error-handling patterns. Covers SRP, comment discipline, formatting, and unit testing. For refactoring techniques, see refactoring-patterns. For architecture and dependency rules, see clean-architecture.
Engineer word-of-mouth and virality using the STEPPS framework (Social Currency, Triggers, Emotion, Public, Practical Value, Stories). Use when the user mentions "go viral", "word of mouth", "shareable content", "social currency", "why people share", "referral program", "nobody is sharing it", or "make this spread". Also trigger when designing shareable features, crafting social campaigns, or building products that spread through peer recommendation. Covers environmental triggers and high-arousal emotional content. For sticky messaging, see made-to-stick. For persuasion tactics, see influence-psychology.
Build a weekly cadence of customer touchpoints using Opportunity Solution Trees, assumption mapping, and interview snapshots. Use when the user mentions "continuous discovery", "opportunity solution tree", "weekly interviews", "assumption testing", "discovery habits", "product trio", "outcome-based roadmap", "how do I talk to customers regularly", "we keep building things nobody uses", or "connect research to the roadmap". Also trigger when setting up regular customer feedback loops, prioritizing which experiments to run, or tying discovery insights to delivery work. Covers experience mapping, co-creation, and prioritizing opportunities. For interview technique, see mom-test. For team structure, see inspired-product.
Audit websites and landing pages for conversion issues and design evidence-based A/B tests. Use when the user mentions "landing page isnt converting", "conversion rate", "A/B test", "why visitors leave", "objection handling", "bounce rate", "conversion funnel", "increase signups", or "people add to cart but dont buy". Also trigger when diagnosing why signups are low, designing experiment hypotheses, or auditing checkout flows for friction points. Covers funnel mapping, persuasion assets, and objection/counter-objection frameworks. For overall marketing strategy, see one-page-marketing. For usability issues, see ux-heuristics.
Navigate the technology adoption lifecycle from early adopters to mainstream market. Use when the user mentions "crossing the chasm", "beachhead segment", "whole product", "early adopters vs mainstream", "tech go-to-market", "bowling pin strategy", "technology adoption lifecycle", "pragmatist buyers", "growth stalled after early adopters", or "our go-to-market plan". Also trigger when planning go-to-market for a technical product. Covers the D-Day analogy, bowling-pin strategy, the tornado, and positioning against incumbents. For product positioning, see obviously-awesome. For new market creation, see blue-ocean-strategy.