iOS UI Refactor

Apple HIG SwiftUI iOS 26 / Swift 6.2 Best Practices

A principal designer's lens for evaluating and refactoring SwiftUI interfaces to Apple-quality standards, grounded in Rams, Segall, and Edson. Contains 51 rules across 8 categories, each grounded in specific principles from three foundational design texts:

• Dieter Rams — Ten Principles for Good Design ("less, but better," "design should be honest")
• Ken Segall — Insanely Simple (simplicity as a core principle for intuitive, beautiful products)
• John Edson — Design Like Apple (design-focused culture, prototyping to perfection, the product is the marketing)

Categories are ordered by a visual review process: start with what to remove, then what to clarify, then what to make honest, invisible, systematic, thorough, enduring, and finally what to refine.

Scope & Relationship to Sibling Skills

This skill is the refactoring and review lens — it evaluates existing UI and identifies visual anti-patterns to fix. When loaded alongside ios-design (building new UI), ios-hig (HIG compliance), or swift-refactor (code-level refactoring), this skill supersedes overlapping rules with more detailed "incorrect -> correct" transformations and "When NOT to apply" guidance. Use this skill for auditing and improving existing screens; use the siblings for greenfield implementation.

Clinic Architecture Contract (iOS 26 / Swift 6.2)

All guidance in this skill assumes the clinic modular MVVM-C architecture:

• Feature modules import Domain + DesignSystem only (never Data, never sibling features)
• App target is the convergence point and owns DependencyContainer, concrete coordinators, and Route Shell wiring
• Domain stays pure Swift and defines models plus repository, *Coordinating, ErrorRouting, and AppError contracts
• Data owns SwiftData/network/sync/retry/background I/O and implements Domain protocols
• Read/write flow defaults to stale-while-revalidate reads and optimistic queued writes
• ViewModels call repository protocols directly (no default use-case/interactor layer)

When to Apply

Reference these guidelines when:

• Reviewing existing SwiftUI screens for visual quality issues
• Auditing whether every element on screen earns its place (Rams #10)
• Evaluating if the interface is self-explanatory without tooltips (Rams #4)
• Checking that colors, states, and hierarchy tell the truth (Rams #6)
• Ensuring animations and materials are invisible, not decorative (Rams #5)
• Verifying spacing, radii, and colors form a coherent system (Edson "Systems Thinking")
• Confirming edge cases — reduce motion, touch targets, safe areas — are handled (Rams #8)
• Adopting iOS 26 / Swift 6.2 APIs that refine previously impossible interactions (Edson "Design Out Loud")

Rule Categories by Priority

Quick Reference

1. Less, But Better (CRITICAL)

Rams #10: "Good design is as little design as possible." Segall: Apple succeeded by saying no to a thousand things.

• less-single-focal - One primary focal point per screen
• less-type-restraint - Limit to 3-4 distinct type treatments per screen
• less-one-typeface - One typeface per app, differentiate with weight and size
• less-color-restraint - Reserve saturated colors for small interactive elements
• less-one-color-purpose - Each semantic color serves exactly one purpose
• less-purposeful-motion - Every animation must communicate state change or provide feedback
• less-fewer-controls - Remove controls that do not serve the core task

2. Self-Evident Design (CRITICAL)

Rams #4: "Good design makes a product understandable." Segall: interfaces must speak in terms people understand.

• evident-visual-weight - Combine size, weight, and contrast for hierarchy
• evident-whitespace-grouping - Use whitespace to separate conceptual groups
• evident-progressive-disclosure - Use progressive disclosure for dense information
• evident-reading-order - Align visual weight with logical reading order
• evident-navigation-intent - Sheets for tasks and creation, push for drill-down hierarchy
• evident-label-clarity - Use clear labels over ambiguous icons