developing-with-swift

Swift Styleguide

Indentation

2 spaces, no tabs.

Code comments & code documentation

If a comment contains documentation or explanation, it must use a triple slash (///), regardless of its position in the source code.

Use double slash comments (//) only for Xcode directive comments ("MARK:", "TODO:", etc.) and for temporarily disabling blocks of code. You must never use double slash (//) for documentation comments.

guard clauses

guard clauses must be written multi-line. If a clause combines multiple conditions, each condition must be on its own line.

Examples

// ❌ Bad
guard somethingCondition else { return }

// ✅ Good
guard somethingCondition else {
  return
}

// ❌ Bad
guard !somethingCondition1, let something else { return }

// ✅ Good
guard !somethingCondition1,
      let something
else {
  return
}

Any guard clause must be followed by a blank line.

if blocks

if clauses must be written multi-line. If a clause combines multiple conditions, each condition should be on its own line. If there is more than one condition, the opening bracket ({) should be on its own line.

Examples

// ❌ Bad
if !somethingCondition1, let something {
  return
}

// ✅ Good
if !somethingCondition1,
   let something
{
  return
}

switch/case

Every case block must be followed by a blank line.

Modern Swift

Write idiomatic SwiftUI code following Apple's latest architectural recommendations and best practices.

Core Philosophy

• SwiftUI is the default UI paradigm for Apple platforms - embrace its declarative nature
• Avoid legacy UIKit patterns and unnecessary abstractions
• Focus on simplicity, clarity, and native data flow
• Let SwiftUI handle the complexity - don't fight the framework

Architecture Guidelines

1. Embrace Native State Management

For simple use cases that don't contain a lot of logic and state, use SwiftUI's built-in property wrappers appropriately:

• @State - Local, ephemeral view state
• @Binding - Two-way data flow between views
• @Observable - Shared state (iOS 17+)
• @ObservableObject - Legacy shared state (pre-iOS 17)
• @Environment - Dependency injection for app-wide concerns

For more complex use cases with lots of logic and interdependent states, use Composable Architecture. Before starting to write code, read the TCA documentation (see section "Read SDK/ package/ library/ framework documentation").

2. State Ownership Principles

• Views own their local state unless sharing is required
• State flows down, actions flow up
• Keep state as close to where it's used as possible
• Extract shared state only when multiple views need it

3. Modern Async Patterns

• Use async/await as the default for asynchronous operations
• Leverage .task modifier for lifecycle-aware async work
• Avoid Combine unless absolutely necessary
• Handle errors gracefully with try/catch

4. View Composition

• Build UI with small, focused views
• Extract reusable components naturally
• Use view modifiers to encapsulate common styling
• Prefer composition over inheritance

5. Code Organization

• Organize by feature, not by type (avoid Views/, Models/, ViewModels/ folders)
• Keep related code together in the same file when appropriate
• Use extensions to organize large files
• Follow Swift naming conventions consistently

Implementation Patterns

Simple State Example

struct CounterView: View {
  @State private var count = 0

  var body: some View {
    VStack {
      Text("Count: \(count)")
      Button("Increment") {
        count += 1
      }
    }
  }
}

Shared State with @Observable

@Observable
class UserSession {
  var isAuthenticated = false
  var currentUser: User?

  func signIn(user: User) {
    currentUser = user
    isAuthenticated = true
  }
}

struct MyApp: App {
  @State private var session = UserSession()

  var body: some Scene {
    WindowGroup {
      ContentView()
        .environment(session)
    }
  }
}

Async Data Loading

struct ProfileView: View {
  @State private var profile: Profile?
  @State private var isLoading = false
  @State private var error: Error?

  var body: some View {
    Group {
      if isLoading {
        ProgressView()
      } else if let profile {
        ProfileContent(profile: profile)
      } else if let error {
        ErrorView(error: error)
      }
    }
    .task {
      await loadProfile()
    }
  }

  private func loadProfile() async {
    isLoading = true
    defer { isLoading = false }

    do {
      profile = try await ProfileService.fetch()
    } catch {
      self.error = error
    }
  }
}

Best Practices

Do

• Write self-contained views when possible
• Use property wrappers as intended by Apple
• Test logic in isolation, preview UI visually
• Handle loading and error states explicitly
• Keep views focused on presentation
• Use Swift's type system for safety

Do not

• Create ViewModels for every view
• Move state out of views unnecessarily
• Add abstraction layers without clear benefit
• Use Combine for simple async operations
• Fight SwiftUI's update mechanism
• Overcomplicate simple features

Testing Strategy

• Unit test business logic and data transformations
• Use SwiftUI Previews for visual testing
• Test @Observable classes independently
• Keep tests simple and focused
• Don't sacrifice code clarity for testability

Modern Swift Features

• Use Swift Concurrency (async/await, actors)
• Leverage Swift 6 data race safety when available, i.e. when the project is built with Swift 6 or later
• Utilize property wrappers effectively
• Embrace value types where appropriate
• Use protocols for abstraction, not just for testing

Summary

Write SwiftUI code that looks and feels like SwiftUI. The framework has matured significantly - trust its patterns and tools. Focus on solving user problems rather than implementing architectural patterns from other platforms.