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.

Animations and Transitions

Prefer .animation(_:value:) scoped to a specific state value over broad withAnimation calls, especially inside body
Reserve withAnimation for animations explicitly triggered by user interaction
Implement custom transitions using AnyTransition; use matchedGeometryEffect for hero animations
Use TimelineView for high-frequency, time-driven visual updates instead of a Timer + published property

Swift 6 Concurrency & Data Flow

Annotate view models with @MainActor; all UI updates must happen on the main actor
Prefer .task(id:) over .onAppear for starting async work — it automatically cancels the task when the view disappears or the id changes, avoiding orphaned work
Use async/await for asynchronous operations and Result (or typed throws) for error handling
Prefer actor types for shared mutable state or services accessed from multiple tasks
Mark pure logic functions nonisolated when they don't touch the main actor, to avoid unnecessary hops
Never block the main thread — move heavy computation to a detached Task
Handle loading, error, and success states explicitly rather than leaving implicit/undefined states

Memory Management & Safety

Default to [weak self] in closures that outlive the current scope; use guard let self else { return } at the start of async closures
Only use [unowned self] when the closure's lifetime is provably shorter than self's
Handle optionals safely — no force unwrapping; use guard for early returns
For remote images, use AsyncImage (with a caching layer, or a library like Nuke/Kingfisher for production apps) and apply .resizable() immediately

Performance Optimization

Minimize view body recalculations; adopt Equatable conformance where it helps SwiftUI skip redundant diffing
Implement proper list diffing with Identifiable items and stable ids
Profile with Instruments before optimizing; cache expensive computations rather than recomputing them in body

Accessibility

Add accessibility labels, hints, and traits appropriately; support VoiceOver
Assign distinct accessibilityIdentifier strings to interactive elements so UI tests can target them reliably
Test with accessibility features (Dynamic Type, VoiceOver, Reduce Motion) enabled

Testing and Previews

Always provide a preview using #Preview (Xcode 15+) or PreviewProvider on older toolchains, injecting realistic mock data
Preview in multiple color schemes and device sizes
Structure unit tests with Given-When-Then; generate protocol-based mocks for external dependencies so view models can be tested without hitting real services

Code Quality

Write self-documenting code; add comments only for non-obvious logic
Follow the Swift API Design Guidelines
Use MARK: - Section Name to organize longer files, and place private helpers in a private extension

Common Patterns

View with @Observable ViewModel (iOS 17+)

@Observable
@MainActor
final class ContentViewModel {
    var items: [Item] = []
    var isLoading = false

    func loadItems() async {
        isLoading = true
        defer { isLoading = false }
        // Load items
    }
}

struct ContentView: View {
    @State private var viewModel = ContentViewModel()

    var body: some View {
        List(viewModel.items) { item in
            Text(item.name)
        }
        .task(id: viewModel.items.count) {
            await viewModel.loadItems()
        }
    }
}

View with ObservableObject ViewModel (pre-iOS 17 / legacy)

struct ContentView: View {
    @StateObject private var viewModel = ContentViewModel()

    var body: some View {
        // View implementation
    }
}

@MainActor
class ContentViewModel: ObservableObject {
    @Published var items: [Item] = []
    @Published var isLoading = false

    func loadItems() async {
        isLoading = true
        // Load items
        isLoading = false
    }
}

Reusable View Modifier

struct CardModifier: ViewModifier {
    func body(content: Content) -> some View {
        content
            .padding()
            .background(Color(.systemBackground))
            .cornerRadius(12)
            .shadow(radius: 4)
    }
}

extension View {
    func cardStyle() -> some View {
        modifier(CardModifier())
    }
}

</content>

swiftui-development