Swiftui Development

SwiftUI Development

This skill covers best practices for building clear, performant, and maintainable SwiftUI applications, including architecture, state management, Swift 6 concurrency, layout, animation, and testing.

Key Principles

• Write correct, up-to-date, bug-free, fully functional, secure, and performant code
• Favor readability, but not at the expense of correctness or safety
• Fully implement all requested functionality — leave no TODOs, placeholders, or missing pieces
• Target Swift 6.0+ with strict concurrency checking enabled; treat concurrency warnings as errors
• Target iOS 17+ where possible to use modern APIs (@Observable, NavigationStack, #Preview); note the minimum deployment target when it forces older patterns

Architecture

• Use MVVM (Model-View-ViewModel) or Clean Architecture; introduce a Coordinator layer for complex, multi-screen navigation flows
• Apply SOLID principles to views and view models:
  • Single Responsibility — each view or view model has one reason to change
  • Open/Closed — extend behavior via composition and protocols rather than modifying existing types
  • Liskov Substitution — protocol conformances must be substitutable without surprising callers
  • Interface Segregation — keep protocols small and focused rather than one large "do everything" interface
  • Dependency Inversion — depend on protocol abstractions, not concrete types, and inject dependencies via init
• Implement protocol-oriented programming; prefer structs over classes for data models
• Use extensions for code organization and separation of concerns

SwiftUI View Structure

• Keep views small and focused on a single responsibility
• Treat 50 lines as a practical ceiling for a body property — past that, extract subviews into small, reusable structs or private extension functions
• Use @ViewBuilder for custom container views and complex conditional view logic
• Implement proper view composition patterns

State Management

• @State — local, value-type view state (Bool, Int, String, small structs)
• @Binding — two-way data binding with child views
• @StateObject — use only in the view that creates/owns the object's lifecycle
• @ObservedObject — use in child views that react to changes but don't own the object
• @EnvironmentObject / @Environment — use sparingly for broadly shared dependencies or system values; prefer explicit dependency injection via init when a dependency belongs to a specific view hierarchy rather than the whole app
• @Published — for observable properties on ObservableObject classes (pre-iOS 17 or when ObservableObject is otherwise required)
• @Observable macro (iOS 17+) — prefer this over ObservableObject/@Published for new view models; it removes the need for @Published on every property and only triggers view updates for properties actually read by that view, which reduces unnecessary redraws

Naming Conventions

• camelCase for variables, functions, and methods; PascalCase for types (classes, structs, enums, protocols)
• Use descriptive, verbose names — fetchUserData over getData
• Prefix boolean variables with is, has, should, etc.
• Use verb phrases for function names

SwiftUI Best Practices

• Use SF Symbols for system icons; use semantic colors from the asset catalog for automatic dark mode support
• Support Dynamic Type and implement proper keyboard avoidance
• Use NavigationStack (iOS 16+) over the deprecated NavigationView
• Prefer type-inferred shorthand dot syntax where available (e.g., .background(.blue))
• Add .contentShape(Rectangle()) to HStack/VStack rows that have transparent backgrounds, so taps register across the whole row rather than only on opaque content

Layout and Styling

• Use native SwiftUI layout containers (VStack, HStack, ZStack, Grid); use LazyVStack/LazyHStack for dynamic or long lists
• Use GeometryReader sparingly — it expands to fill all available space and can hurt layout performance; prefer .background(GeometryReader { ... }) scoped to a single view, or the Layout protocol for custom layouts
• Give list items stable, meaningful ids (from Identifiable) rather than \.self
• Implement adaptive layouts for different screen sizes
• Use ViewModifiers for reusable styling; create custom ButtonStyle, TextFieldStyle, etc.