Ios Hig

iOS Human Interface Guidelines

Apple's Human Interface Guidelines define the visual language, interaction patterns, and accessibility standards that make iOS apps feel native and intuitive. The core principle: clarity and consistency through thoughtful design.

Reference Loading Guide

ALWAYS load reference files if there is even a small chance the content may be required. It's better to have the context than to miss a pattern or make a mistake.

Common Mistakes

1. Touch targets smaller than 44x44 points — Buttons and interactive elements must be at least 44x44 points (iOS) to accommodate thumbs. Smaller targets cause frustrated users and accessibility failures.

2. Ignoring Dynamic Type constraints — Text with fixed sizes doesn't respect user accessibility settings. Use Dynamic Type sizes, test with Large or Extra Large settings, and avoid hardcoded font sizes.

3. Insufficient color contrast in dark mode — Colors that work in light mode may fail accessibility in dark mode. Test with Reduce Contrast accessibility setting enabled for both modes.

4. Over-animating transitions — Animations that feel smooth at 60fps can trigger motion sickness in users with vestibular issues. Respect Reduce Motion settings and keep animations under 300ms.

5. Missing VoiceOver labels on custom controls — Custom buttons, toggles, or interactive views need .accessibilityLabel() and .accessibilityHint() or they're completely unusable to screen reader users.

6. Haptic overuse — Every action does NOT need haptic feedback. Reserve haptics for confirmations (purchase, critical action) and errors. Excessive haptics are annoying and drain battery.

Accessibility

Apple Human Interface Guidelines for accessible iOS app design.

Critical Rules

• Provide meaningful accessibility labels/hints for icon-only controls and custom components
• Ensure Dynamic Type works end-to-end; avoid layouts that collapse at larger sizes
• Maintain readable contrast and avoid conveying meaning by color alone
• Respect platform accessibility settings (Reduce Motion/Transparency) when relevant
• Prefer system controls that come with good accessibility defaults

Examples

Icon-Only Buttons

// ✅ Icon-only button with accessible label
Button(action: model.refresh) {
    Image(systemName: "arrow.clockwise")
}
.accessibilityLabel("Refresh")
.accessibilityHint("Reloads the list")

// ❌ Icon-only control with no label; VoiceOver reads "arrow.clockwise"
Button(action: model.refresh) {
    Image(systemName: "arrow.clockwise")
}

Dynamic Type Support

// ✅ Dynamic Type with proper layout
VStack(alignment: .leading, spacing: 8) {
    Text(item.title)
        .font(.headline)
        .lineLimit(2)

    if let summary = item.summary {
        Text(summary)
            .font(.body)
            .foregroundStyle(.secondary)
            .lineLimit(3)
    }
}

// ❌ Hard-coded sizes that don't scale
VStack(alignment: .leading) {
    Text(item.title)
        .font(.system(size: 14))
        .lineLimit(1)
}

Reduce Motion

// ✅ Respect Reduce Motion setting
@Environment(\.accessibilityReduceMotion) var reduceMotion

var body: some View {
    content
        .animation(reduceMotion ? .none : .spring, value: isExpanded)
}

// ❌ Always animate regardless of setting
var body: some View {
    content
        .animation(.spring, value: isExpanded)
}

Summary

Key Principles: 1. Use .accessibilityLabel() and .accessibilityHint() for icon-only controls 2. Support Dynamic Type with system font styles 3. Maintain sufficient color contrast 4. Respect accessibility settings like Reduce Motion 5. Prefer system controls with built-in accessibility

Content

Apple Human Interface Guidelines for content, empty states, writing, and typography.

Table of Contents

1. Empty States 2. Writing and Labels 3. Typography and Dynamic Type

Empty States

Critical Rules

• Use empty states to explain what this screen is and what to do next
• Prefer lightweight guidance (one sentence + primary action) over multi-step tutorials
• Keep onboarding contextual: explain features at the moment the user needs them
• Avoid placeholder junk content that looks real; make it obvious when content is sample/demo

Examples

// ✅ Helpful empty state with a clear next step
ContentUnavailableView {
    Label("No links yet", systemImage: "link")
} description: {
    Text("Save links to find them quickly later.")
} actions: {
    Button("Add link", systemImage: "plus") { model.presentAddLink() }
        .buttonStyle(.borderedProminent)
}

// ❌ Empty UI with no explanation
List { }

Writing and Labels

Critical Rules

• Prefer plain language and short phrases; avoid jargon and developer terms
• Buttons should describe the action ("Save", "Add link"), not vague labels ("OK", "Yes")
• Keep terminology consistent across the app (e.g., "Link" vs "URL"); choose one and stick to it
• Error messages should explain the problem and the next step, without blame

Examples

// ✅ Clear action labels and consistent terminology
Button("Add link", systemImage: "plus") { model.addLink() }
Button("Save", action: model.save)

// Error message example
Text("Could not save link. Check your connection and try again.")

// ❌ Vague and inconsistent
Button("OK") { model.save() }
Button("Add URL") { model.addLink() }

// Error message without guidance
Text("Error: Save failed")

Writing Guidelines

Button Labels:

• ✅ "Delete", "Save", "Add link"
• ❌ "OK", "Yes", "No"

Error Messages:

• ✅ "Could not load items. Pull to refresh."
• ❌ "Error code 404"

Terminology Consistency:

• Choose one term and use it throughout
• "Link" not "URL" or "Website"
• "Save" not "Add" or "Create" interchangeably

Typography and Dynamic Type

Critical Rules

• Use Dynamic Type styles (.body, .headline, .caption) instead of hard-coded sizes
• Prefer short, scannable labels; use secondary text (.secondary) for supporting detail
• Avoid truncation for critical info; if truncation can happen, provide an alternative (multi-line, disclosure, copy)
• Use appropriate alignment and line limits; avoid overly dense paragraphs
• Ensure text remains legible in accessibility sizes (test with larger sizes)

Examples

// ✅ Dynamic Type + predictable wrapping for important content
VStack(alignment: .leading, spacing: 8) {
    Text(item.title)
        .font(.headline)
        .lineLimit(2)

    if let summary = item.summary {
        Text(summary)
            .font(.body)
            .foregroundStyle(.secondary)
            .lineLimit(3)
    }
}

// ❌ Hard-coded sizes and single-line truncation for critical info
VStack(alignment: .leading) {
    Text(item.title)
        .font(.system(size: 14))
        .lineLimit(1)
    Text(item.summary ?? "")
        .font(.system(size: 11))
        .lineLimit(1)
}

Dynamic Type Styles

Use system text styles that scale with Dynamic Type:

• .largeTitle, .title, .title2, .title3
• .headline, .body, .callout
• .subheadline, .footnote, .caption, .caption2

// ✅ System styles that scale
Text("Main heading")
    .font(.title2)
Text("Body content")
    .font(.body)
Text("Supporting detail")
    .font(.caption)
    .foregroundStyle(.secondary)

Summary

Key Principles: 1. Use ContentUnavailableView for helpful empty states 2. Write clear, action-oriented button labels 3. Keep terminology consistent throughout the app 4. Error messages explain the problem and next step 5. Use Dynamic Type styles, never hard-coded sizes 6. Allow important text to wrap (don't truncate critical info)

Feedback

Apple Human Interface Guidelines for motion, haptics, loading states, and error handling.

Table of Contents

1. Motion and Haptics 2. Status and Error Feedback

Motion and Haptics

Critical Rules

• Motion should be purposeful: reinforce state change, hierarchy, or causality—not decoration
• Keep animations subtle and consistent; avoid stacking multiple effects (scale + rotate + blur) for routine interactions
• Respect accessibility settings (Reduce Motion); don't rely on animation as the only feedback
• Use haptics sparingly for meaningful moments (confirmations, errors), not for every tap

Examples

// ✅ Subtle animation tied to state change
withAnimation(.spring(response: 0.35, dampingFraction: 0.85)) {
    model.isExpanded.toggle()
}

// ❌ Excessive motion for routine UI; feels noisy and fatiguing
withAnimation(.easeInOut(duration: 2.0)) {
    model.isExpanded.toggle()
}
// Plus additional scale/rotation/blur effects on the entire screen

Motion Guidelines

Purposeful Animation:

• State transitions (expanding/collapsing)
• Hierarchy changes (list reordering)
• Causality (deletion leading to list reflow)

Animation Parameters:

• Spring response: 0.3-0.4 seconds
• Damping fraction: 0.8-0.9 (less bouncy)
• Easing: Prefer springs over linear or custom curves

Accessibility:

• Always respect @Environment(\.accessibilityReduceMotion)
• Provide non-animated alternatives
• Don't use motion as the only feedback mechanism

Status and Error Feedback

Critical Rules

• Always show state feedback for async work: loading, success, failure, and empty
• Prefer inline status for local issues (validation) and alerts for exceptional interruptions
• Make errors actionable: explain what happened in plain language and offer a next step (retry, fix input, dismiss)
• Avoid blaming the user; avoid exposing raw system error text
• Use system patterns for empty states (ContentUnavailableView) and progress (ProgressView)

Examples

// ✅ Clear empty state and recoverable error with retry
Group {
    if model.isLoading {
        ProgressView("Loading…")
    } else if model.items.isEmpty {
        ContentUnavailableView(
            "No items",
            systemImage: "tray",
            description: Text("Add your first item to get started.")
        )
    } else {
        List(model.items) { item in Text(item.title) }
    }
}
.alert("Couldn't load items", isPresented: $model.isShowingError) {
    Button("Retry", action: model.reload)
    Button("Cancel", role: .cancel) {}
} message: {
    Text("Check your connection and try again.")
}

// ❌ Silent failures and raw errors; no next step
List(model.items) { item in Text(item.title) }
// On error: print(error) and keep stale UI with no feedback

Status Guidelines

Loading States:

• Use ProgressView for async operations
• Show progress for operations >1 second
• Provide context ("Loading items…")

Empty States:

• Use ContentUnavailableView for empty collections
• Explain what the view is for
• Provide a primary action to get started

Error States:

• Use alerts for unexpected errors that interrupt flow
• Use inline validation for expected errors (form fields)
• Always provide a recovery action

Error Messages:

• ✅ "Couldn't save item. Check your connection and try again."
• ❌ "Error: NetworkError.timeout"

Next Steps:

• Retry button for transient failures
• Fix input guidance for validation errors
• Dismiss or cancel for unrecoverable errors

Summary

Key Principles: 1. Keep motion subtle, purposeful, and tied to state changes 2. Respect Reduce Motion accessibility setting 3. Always show feedback for async operations (loading, empty, error) 4. Make errors actionable with plain language and recovery steps 5. Use system patterns (ProgressView, ContentUnavailableView, alerts) 6. Prefer inline validation for expected errors, alerts for exceptional interruptions

Interaction

Apple Human Interface Guidelines for touch targets, input, navigation, layout, and hierarchy.

Table of Contents

1. Touch Targets and Input 2. Navigation and Flows 3. Layout, Hierarchy, and Grouping

Touch Targets and Input

Critical Rules

• Use system controls (Button, Toggle, TextField, Picker) rather than custom hit-testing
• Ensure comfortable hit targets; avoid tiny icons-only tap areas
• Prefer clear labels over icon-only actions; use SF Symbols consistently with text where appropriate
• Use appropriate keyboard/input behaviors (submit labels, autocorrection/capitalization) for the field's purpose
• Avoid gesture-only interactions for primary actions; make actions discoverable

Examples

// ✅ Tappable control with label + icon; clear intent
Button("Add item", systemImage: "plus") {
    model.add()
}
.buttonStyle(.borderedProminent)

// ✅ TextField with appropriate keyboard
TextField("Email", text: $email)
    .keyboardType(.emailAddress)
    .textInputAutocapitalization(.never)
    .autocorrectionDisabled()

// ❌ Tiny icon-only tap target; poor discoverability
Image(systemName: "plus")
    .onTapGesture {
        model.add()
    }

Navigation and Flows

Critical Rules

• Prefer NavigationStack + navigationDestination for drill-in flows; keep navigation shallow where possible
• Use modals for short, self-contained tasks (create, edit, pick); always provide a clear way to dismiss
• Keep back behavior predictable: don't override system expectations; preserve navigation state when reasonable
• Avoid "choice paralysis": limit top-level destinations; group related settings and utilities
• Prefer system placements: .confirmationAction for Save/Done, .cancellationAction for Cancel

Examples

// ✅ Predictable drill-in navigation; modal only for creation
NavigationStack {
    List(items) { item in
        NavigationLink(item.title, value: item.id)
    }
    .navigationDestination(for: Item.ID.self) { id in
        ItemDetailView(id: id)
    }
    .toolbar {
        ToolbarItem(placement: .primaryAction) {
            Button("Add", systemImage: "plus") { model.isPresentingCreate = true }
        }
    }
    .sheet(isPresented: $model.isPresentingCreate) {
        NavigationStack { CreateItemView() }
    }
}

// ✅ Modal with clear dismiss path
NavigationStack {
    CreateItemView()
        .navigationTitle("New Item")
        .toolbar {
            ToolbarItem(placement: .cancellationAction) {
                Button("Cancel", action: dismiss)
            }
            ToolbarItem(placement: .confirmationAction) {
                Button("Save", action: model.save)
            }
        }
}

// ❌ Everything is a modal; unclear back/exit paths
VStack {
    Button("Open item") { model.showItem.toggle() }
}
.sheet(isPresented: $model.showItem) {
    ItemDetailView(id: model.selectedID)
        .toolbar { Button("Save") {} } // no Cancel, no navigation context
}

Navigation Guidelines

Use NavigationStack for:

• Browsing hierarchical content
• Drill-down patterns
• Main app navigation

Use Modals (.sheet, .fullScreenCover) for:

• Creating new content
• Editing existing content
• Short, self-contained tasks
• Pickers and selections

Always provide:

• Clear dismiss buttons for modals
• Consistent back button behavior
• Confirmation for destructive actions

Layout, Hierarchy, and Grouping

Critical Rules

• Design around content first: prioritize the primary task and content; remove decorative UI that doesn't help comprehension
• Create clear hierarchy: one primary action per screen; secondary actions are visually subordinate
• Use consistent spacing and alignment to communicate grouping; avoid "random" padding values across the app
• Prefer system containers (List, Form, Section, Toolbar, NavigationStack) that encode platform layout conventions
• Avoid dense UI: keep line lengths readable and allow whitespace for scanning

Examples

// ✅ Hierarchy + grouping via Sections; one primary action in toolbar
NavigationStack {
    List {
        Section("Details") {
            TextField("Title", text: $model.title)
            TextField("Notes", text: $model.notes, axis: .vertical)
        }

        Section("Metadata") {
            Toggle("Pinned", isOn: $model.isPinned)
        }
    }
    .navigationTitle("New item")
    .toolbar {
        ToolbarItem(placement: .confirmationAction) {
            Button("Save", action: model.save)
        }
    }
}

// ✅ Clear visual hierarchy with system components
VStack(spacing: 16) {
    // Primary action
    Button("Continue", action: model.continue)
        .buttonStyle(.borderedProminent)
        .controlSize(.large)

    // Secondary action
    Button("Skip for now", action: model.skip)
        .buttonStyle(.borderless)
        .foregroundStyle(.secondary)
}

// ❌ Flat wall-of-controls with unclear priority
VStack(spacing: 3) {
    Text("New item").font(.title2)
    TextField("Title", text: $model.title).padding(1)
    TextField("Notes", text: $model.notes).padding(23)
    Toggle("Pinned", isOn: $model.isPinned)
    Button("Save", action: model.save)
    Button("Delete", action: model.delete)
}

Layout Guidelines

Visual Hierarchy:

• One primary action per screen (prominent button style)
• Secondary actions are visually subordinate (borderless, smaller)
• Destructive actions are clearly marked (.destructive role)

Spacing and Grouping:

• Use Section in List or Form to group related controls
• Consistent spacing values (8, 12, 16, 20, 24)
• Whitespace communicates relationships

System Containers:

• List for browsable content
• Form for data entry
• Section for grouping
• Toolbar for actions
• NavigationStack for hierarchies

Summary

Key Principles: 1. Use system controls with comfortable hit targets 2. NavigationStack for drill-down, modals for tasks 3. Always provide clear dismiss paths 4. One primary action per screen 5. Use sections and spacing for grouping 6. Prefer system containers over custom layouts

Performance and Platform Conventions

Apple Human Interface Guidelines for performance, responsiveness, and platform-native patterns.

Table of Contents

1. Performance and Responsiveness 2. Platform Conventions

Performance and Responsiveness

Critical Rules

• Optimize for perceived performance: show progress quickly, keep interactions responsive, and avoid blocking the main actor
• Use incremental loading patterns where appropriate; avoid doing heavy work during view rendering
• Prefer clear placeholder/progress UI over a frozen screen
• Avoid unnecessary animations, shadows, and effects that degrade scrolling performance

Examples

// ✅ Immediate feedback and non-blocking load
VStack {
    if model.isLoading {
        ProgressView("Loading…")
    } else {
        List(model.items) { item in Text(item.title) }
    }
}
.task { await model.loadIfNeeded() }

// ❌ Heavy synchronous work during view body; causes jank
var body: some View {
    let items = model.computeExpensiveListSynchronously()
    return List(items) { item in Text(item.title) }
}

Performance Guidelines

Perceived Performance:

• Show UI immediately, even if data isn't ready
• Use ProgressView or skeleton states while loading
• Keep interactions responsive (<100ms feedback)
• Avoid blocking the main thread

Async Work:

• Use .task { } for async loading in views
• Move heavy computation to background tasks
• Never do expensive work in body or computed properties

Rendering Performance:

• Avoid heavy shadows, blurs, or complex gradients in scrolling views
• Use LazyVStack/LazyHStack for large lists
• Profile with Instruments if scrolling feels janky

Loading Patterns:

• Show skeleton/placeholder UI immediately
• Load data incrementally when appropriate
• Provide progress indication for operations >1 second

Platform Conventions

Critical Rules

• Prefer system components before custom UI (Lists, Forms, toolbars, menus, context menus)
• Use SF Symbols consistently and pair icons with text for clarity when appropriate
• Keep controls and terminology consistent with iOS conventions (Done/Cancel, Back, Edit)
• Avoid recreating iOS UI patterns with bespoke visuals unless you have a strong UX reason

Examples

// ✅ System toolbar placements and familiar labels
.toolbar {
    ToolbarItem(placement: .cancellationAction) {
        Button("Cancel", role: .cancel) { model.cancel() }
    }
    ToolbarItem(placement: .confirmationAction) {
        Button("Done", action: model.done)
    }
}

// ❌ Custom "Close" / "Okay" in random placements; inconsistent with platform
.toolbar {
    ToolbarItem(placement: .automatic) { Button("Okay") {} }
    ToolbarItem(placement: .automatic) { Button("Close") {} }
}

Platform Guidelines

System Components:

• List for browsable content
• Form for settings and data entry
• Toolbar for actions
• NavigationStack for hierarchical navigation
• Menu and context menus for secondary actions

SF Symbols:

• Use SF Symbols for icons (system-provided, adapts to Dynamic Type)
• Pair icons with text labels for clarity
• Use consistent symbols throughout the app
• Prefer standard symbols over custom icons

Platform Terminology:

• ✅ "Done", "Cancel", "Save", "Delete", "Edit"
• ❌ "Okay", "Close", "Submit", "Remove", "Modify"

Standard Placements:

• .cancellationAction - Cancel/Back (leading on modals)
• .confirmationAction - Done/Save (trailing on modals)
• .destructive role for Delete actions
• .primaryAction for main toolbar actions

Consistency:

• Follow iOS patterns for common flows (creation, editing, deletion)
• Use standard gestures (swipe to delete, pull to refresh)
• Respect system settings (Dynamic Type, Reduce Motion, Reduce Transparency)

Summary

Key Principles: 1. Show UI immediately; load data asynchronously 2. Use ProgressView and skeleton states while loading 3. Avoid heavy work during view rendering 4. Prefer system components over custom UI 5. Use SF Symbols and standard terminology 6. Follow platform conventions for toolbar placements and actions 7. Keep controls and terminology consistent with iOS

Privacy and Permissions

Apple Human Interface Guidelines for requesting permissions and handling sensitive data.

Critical Rules

• Request permissions in context, right before the feature needs it—never at app launch without cause
• Explain why in user language and connect it to a clear benefit
• If denied, provide a functional fallback and a clear path to Settings when appropriate
• Minimize data collection; don't surface sensitive data in logs or UI where not needed

Examples

Permission Request Pattern

// ✅ Ask in context and handle denial gracefully
Button("Enable notifications") {
    model.requestNotifications()
}
// On denial: show a non-blocking explanation + "Open Settings" action

// ❌ Permission request on launch with no context
struct AppStart {
    func start() {
        model.requestNotifications()
        model.requestLocation()
    }
}

Complete Permission Flow

// ✅ Full permission flow with context and fallback
struct NotificationSettingsView: View {
    @State private var showingDeniedAlert = false

    var body: some View {
        VStack(spacing: 16) {
            Text("Get notified when items are shared with you")
                .font(.headline)

            Text("Turn on notifications to stay updated when friends share links and notes.")
                .font(.body)
                .foregroundStyle(.secondary)

            Button("Enable Notifications") {
                Task {
                    let granted = await requestNotificationPermission()
                    if !granted {
                        showingDeniedAlert = true
                    }
                }
            }
            .buttonStyle(.borderedProminent)
        }
        .alert("Notifications Disabled", isPresented: $showingDeniedAlert) {
            Button("Open Settings") {
                if let url = URL(string: UIApplication.openSettingsURLString) {
                    UIApplication.shared.open(url)
                }
            }
            Button("Not Now", role: .cancel) {}
        } message: {
            Text("To receive notifications, enable them in Settings.")
        }
    }

    func requestNotificationPermission() async -> Bool {
        let center = UNUserNotificationCenter.current()
        do {
            return try await center.requestAuthorization(options: [.alert, .sound, .badge])
        } catch {
            return false
        }
    }
}

Guidelines

When to Request Permissions

Good timing:

• Right before using the feature (user taps "Add location")
• During feature onboarding (user enters location-based feature)
• When user explicitly opts in (settings toggle)

Bad timing:

• App launch before any context
• Background without user interaction
• Bundled with other unrelated requests

How to Request Permissions

Clear value proposition:

• Explain the benefit in user terms
• Show what they'll gain, not what you need
• Use the feature's context to explain why

Examples:

• ✅ "Get notified when items are shared with you"
• ❌ "This app would like to send you notifications"
• ✅ "Save your location to remember where you found this"
• ❌ "Allow location access"

Handling Denial

Graceful fallback:

• Don't block the entire feature if possible
• Provide alternative workflows
• Only show Settings path if user might want to change their mind

Examples:

• Location denied → Manual address entry
• Notifications denied → In-app badge/indicator
• Camera denied → Photo library picker

Privacy Best Practices

Data minimization:

• Only request what you actually need
• Don't log sensitive data (passwords, tokens, personal info)
• Don't display sensitive data in UI unless necessary
• Clear sensitive data when no longer needed

User control:

• Provide clear settings to manage data
• Allow users to delete their data
• Respect system privacy settings

Common Permissions

Notifications

// Request with UNUserNotificationCenter
let granted = try await UNUserNotificationCenter.current()
    .requestAuthorization(options: [.alert, .sound, .badge])

When to ask: Before subscribing to notification topics or when user enables a notification-dependent feature

Location

// Request with CLLocationManager
locationManager.requestWhenInUseAuthorization()

When to ask: Right before adding a location-based item or enabling location features

Photos

// Request with PHPhotoLibrary
let status = await PHPhotoLibrary.requestAuthorization(for: .readWrite)

When to ask: When user taps "Add photo" or similar action

Camera

// Request with AVCaptureDevice
let granted = await AVCaptureDevice.requestAccess(for: .video)

When to ask: Right before showing camera interface

Summary

Key Principles: 1. Request permissions in context, never at app launch 2. Explain the benefit in user terms 3. Handle denial gracefully with fallbacks 4. Provide path to Settings when appropriate 5. Minimize data collection and logging 6. Respect system privacy settings 7. Give users control over their data

Visual Design

Apple Human Interface Guidelines for color, materials, and contrast.

Critical Rules

• Prefer semantic system styles (.tint, .secondary, .tertiary, Material) over custom colors
• Support light and dark mode; don't rely on "always light" colors
• Maintain sufficient contrast for text and controls, including in accessibility settings
• Use color to reinforce meaning, not as the only indicator (pair with text/icons)
• Avoid decorative gradients/materials that reduce readability or increase visual noise

Examples

Semantic System Styles

// ✅ Semantic styles that adapt automatically
HStack {
    Image(systemName: "link")
        .foregroundStyle(.tint)
    Text("Open link")
        .foregroundStyle(.primary)
    Spacer()
    Text("Optional")
        .foregroundStyle(.secondary)
}
.padding()
.background(.thinMaterial)
.clipShape(.rect(cornerRadius: 12))

// ❌ Hard-coded colors that can break contrast in dark mode
HStack {
    Text("Open link")
        .foregroundStyle(Color.white)
}
.padding()
.background(Color.yellow)
.clipShape(.rect(cornerRadius: 12))

Light and Dark Mode Support

// ✅ Adapts to light/dark mode automatically
VStack {
    Text("Title")
        .foregroundStyle(.primary)
    Text("Subtitle")
        .foregroundStyle(.secondary)
}
.background(.background)

// ❌ Hard-coded colors don't adapt
VStack {
    Text("Title")
        .foregroundStyle(Color.black)
    Text("Subtitle")
        .foregroundStyle(Color.gray)
}
.background(Color.white)

Color + Meaning

// ✅ Color reinforces meaning with text/icon
Label("Error occurred", systemImage: "exclamationmark.triangle")
    .foregroundStyle(.red)

// ❌ Color alone conveys meaning
Circle()
    .fill(Color.red)
    .frame(width: 8, height: 8)

Summary

Key Principles: 1. Use semantic color styles (.primary, .secondary, .tint) 2. Support both light and dark appearance modes 3. Ensure sufficient contrast for readability 4. Pair color with text or icons for meaning 5. Use materials (.thinMaterial, .regularMaterial) for depth