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. Rate iOS interfaces or SwiftUI/UIKit code 0-10 against the principles below. Always state the current 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.

Why it works: When layouts respect safe areas and standard spacing, the app feels native and trustworthy---no content hides behind hardware features, and the visual rhythm matches the platform.

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:

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

Ethical boundary: Never hide critical content or controls behind hardware intrusions---every device deserves equal access to all functionality.

See: 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 semantic text styles that automatically scale for accessibility via Dynamic Type.

Why it works: Semantic styles create consistent hierarchy across the platform, and Dynamic Type lets every user---including those with visual impairments---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); minimum contrast 4.5:1 (WCAG AA)
• Line height at least 1.3x font size; optimal line length 35-50 characters on mobile
• Always left-aligned, non-justified text

Product applications:

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

Ethical boundary: Never disable Dynamic Type or fix font sizes that block accessibility scaling---every user deserves readable text.

See: 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 while preserving contrast and hierarchy.

Why it works: Semantic colors maintain readability across appearances without manual intervention, so Dark Mode users get a first-class experience and the app feels polished and native.

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:

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 Increase Contrast enabled

Ethical boundary: Dark Mode is not optional polish---never ship an app that is unreadable or broken in it.

See: 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: tab bars for primary destinations, navigation stacks for hierarchical drilling, and modals for focused tasks.

Why it works: Consistent navigation means users always know where they are, how they got there, and how to go back; violating these patterns 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 on scroll
• Modals for focused tasks; 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

Product applications:

Copy patterns:

• Back button text should be the previous screen's title, not "Back"
• Tab labels are single words ("Home", "Search"); modal titles describe the task ("New Message", "Edit Profile")
• Use NavigationStack (not deprecated NavigationView) in SwiftUI

Ethical boundary: Never trap users in flows without a clear exit---every screen needs an obvious way back or out.

5. Controls & Inputs

Core concept: iOS provides a rich library of native controls (buttons, lists, toggles, pickers, menus, text fields) that users already understand and expect.

Why it works: Native controls ship with built-in accessibility, haptics, and learned interaction patterns; custom controls create friction and miss edge cases Apple already solved.

Key insights:

• Page-level actions go in the nav bar (top) or action bar (bottom)
• Primary buttons are filled with the theme color; secondary are outlined or 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); use .textContentType for autofill

Product applications:

Copy patterns:

• Pair .keyboardType(.emailAddress) with .textContentType(.emailAddress)
• Prefer system confirmations: .alert() or .confirmationDialog(); use .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.

See: references/components.md for buttons, lists, input controls, menus, and confirmation dialogs. See also: references/keyboard-input.md for keyboard types and input patterns.

6. Accessibility

Core concept: iOS has world-class accessibility features (VoiceOver, Dynamic Type, Switch Control, Voice Control), and every app must support them as a first-class concern.

Why it works: Over 1 billion people live with some form of disability, and accessible apps benefit everyone (larger text in sunlight, VoiceOver while driving). App Store guidelines require it.

Key insights:

• Every interactive element needs an .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
• Minimum touch target 44 x 44pt; minimum text contrast 4.5:1 (WCAG AA)
• Never convey meaning through color alone

Product applications:

Copy patterns:

• Write labels as nouns ("Favorite", "Settings"); write 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

Ethical boundary: Shipping an inaccessible app excludes real people---treat VoiceOver testing as seriously as visual testing.

See: references/accessibility.md for VoiceOver implementation, Dynamic Type support, and the accessibility checklist.

7. Icons & Images

Core concept: iOS uses SF Symbols as the standard icon system and requires app icons in specific sizes with the signature superellipse ("squircle") mask applied automatically.

Why it works: SF Symbols align perfectly with San Francisco text, scale with Dynamic Type, and adapt to weights and sizes; consistent iconography makes the interface feel cohesive and native.

Key insights:

• Use SF Symbols (Image(systemName:)) for all standard icons---they scale with text
• App icons: export 1024x1024px square; iOS applies the squircle mask (corner radius = side x 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

Product applications:

Copy patterns:

• Use Image(systemName: "heart.fill"); apply .symbolRenderingMode(.hierarchical) for multi-color depth
• Size symbols relative to text with .imageScale(.large) or .font()
• Browse symbols in the free SF Symbols app from Apple

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

See: references/app-icons.md for icon size tables, shape specifications, and design guidelines.

8. Gestures & Haptics

Core concept: iOS defines standard gestures (swipe back, pull to refresh, long press for context menu) and haptic feedback patterns that must be respected and never overridden.

Why it works: Gestures are muscle memory---overriding swipe-back or repurposing pull-to-refresh disorients users. Haptics provide invisible confirmation that an action registered.

Key insights:

• Never override: 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
• Three haptic types: impact (physical actions), notification (outcomes), selection (UI changes)
• Haptics should be subtle and meaningful---never constant or annoying

Product applications:

Copy patterns:

• UIImpactFeedbackGenerator(style: .medium) for physical interactions; UISelectionFeedbackGenerator() for UI state changes
• UINotificationFeedbackGenerator() with .success, .warning, .error for outcomes
• Call .prepare() before triggering haptics to minimize latency

Ethical boundary: Haptic feedback should confirm, never coerce.

See: references/gestures.md for the standard gesture table, haptic patterns, and animation guidelines.

Common Mistakes

Quick Diagnostic

Audit any iOS interface design:

Reference Files

• typography.md: Text styles, font sizes, Dynamic Type, Dark Mode typography
• navigation.md: Tab bar, navigation bar, modals, search patterns, split views
• components.md: Buttons, lists, input controls, menus, confirmation dialogs
• colors-depth.md: Semantic colors, Dark Mode, contrast ratios
• gestures.md: Standard gestures, haptics, animations
• accessibility.md: VoiceOver, Dynamic Type, accessibility checklist
• app-icons.md: Icon sizes, shape, SF Symbols guidelines
• keyboard-input.md: Keyboard types, input accessory views, hardware keyboard support
• privacy-permissions.md: Permission request timing, pre-permission screens, handling denial
• widgets-extensions.md: Widget sizes, App Clips design, Live Activities
• system-integration.md: Siri, Shortcuts, Handoff, drag-drop, universal links

Further Reading

For the complete guidelines, platform-specific guidance, and latest updates:

• Apple Human Interface Guidelines --- the definitive reference for all Apple platforms
• SF Symbols --- Apple's icon system, 5,000+ configurable symbols
• Apple Design Resources --- official Figma/Sketch templates and UI kits
• WWDC Design Sessions --- videos on design principles and new features
• "Designed by Apple in California" --- photo book of Apple's design process
• "The Design of Everyday Things" by Don Norman --- the human-centered design text that influenced Apple
• "Universal Principles of Design" by William Lidwell, Kritina Holden, and Jill Butler --- 125 principles applicable to iOS

About the Author

The Apple Human Interface Guidelines are written and maintained by Apple's Human Interface Design team, one of the most influential design organizations in technology. First published in 1984 alongside the original Macintosh, the HIG established principles---direct manipulation, consistency, user control---that defined graphical interface design and have evolved through iPhone, iPad, Apple Watch, and Vision Pro. It remains freely available at developer.apple.com as the essential reference for Apple platforms.