Sheldon Wang

Sheldon Wang

Seasoned iOS Veteran, Mentor

🎯 Why Swift 6 Concurrency Matters

Swift 6 represents a fundamental shift in how we think about concurrent programming in iOS development. With strict concurrency checking enabled by default, the compiler now catches data races at compile time—preventing entire classes of bugs that have plagued iOS apps for years.

If you’ve ever experienced crashes from accessing UI elements off the main thread, or mysterious bugs that only appear “sometimes,” Swift 6’s concurrency model is designed to eliminate these issues at the source.

📊 What Changed in Swift 6?

Strict Concurrency Checking

Swift 6 enables strict concurrency checking by default, which means:

  • ✅ Compile-time data race detection - The compiler catches potential race conditions before your app runs
  • ✅ Sendable protocol enforcement - Types must explicitly conform to Sendable to be shared across concurrency domains
  • ✅ Actor isolation - Actors provide safe, isolated state that can only be accessed through their methods
  • ✅ Main actor annotations - UI code must be explicitly marked as running on the main actor

Key Concepts

ConceptDescriptionExample
ActorA reference type that provides isolated, thread-safe access to mutable stateactor DataManager { var data: [String] = [] }
SendableA protocol marking types safe to share across concurrency boundariesstruct User: Sendable { let name: String }
@MainActorAnnotation ensuring code runs on the main thread@MainActor func updateUI() { }
nonisolatedAllows specific methods to bypass actor isolationnonisolated func getID() -> String { }

🔧 Migration Strategy: Step by Step

Step 1: Enable Swift 6 Language Mode

First, update your project settings:

  1. Open your Xcode project
  2. Go to Build Settings
  3. Set Swift Language Version to Swift 6
  4. Enable Strict Concurrency Checking (set to Complete)

Warning: Your project will likely have many errors initially. Don’t panic—this is expected!

Step 2: Fix Sendable Conformances

Start with your data models. Types that are passed between threads must conform to Sendable:

// Before Swift 6
struct User {
    let id: String
    let name: String
}

// Swift 6 - Explicit Sendable conformance
struct User: Sendable {
    let id: String
    let name: String
}

Key Rules for Sendable:

  • ✅ Value types (structs, enums) are Sendable if all their properties are Sendable
  • ✅ Classes can be Sendable only if marked @unchecked Sendable (use with caution)
  • ✅ Functions can be Sendable if they don’t capture mutable state

Step 3: Convert Classes to Actors

Classes with mutable state that’s accessed from multiple threads should become actors:

// Before Swift 6
class DataManager {
    private var cache: [String: Data] = [:]
    
    func store(_ data: Data, for key: String) {
        cache[key] = data  // Potential race condition!
    }
    
    func retrieve(key: String) -> Data? {
        return cache[key]  // Potential race condition!
    }
}

// Swift 6 - Using Actor
actor DataManager {
    private var cache: [String: Data] = [:]
    
    func store(_ data: Data, for key: String) {
        cache[key] = data  // Thread-safe!
    }
    
    func retrieve(key: String) -> Data? {
        return cache[key]  // Thread-safe!
    }
}

// Usage (note the 'await' keyword)
let manager = DataManager()
await manager.store(data, for: "key")
let data = await manager.retrieve(key: "key")

Step 4: Mark UI Code with @MainActor

All UIKit and SwiftUI code that touches the UI must be on the main actor:

// Before Swift 6
class ViewController: UIViewController {
    func updateLabel() {
        DispatchQueue.main.async {
            self.label.text = "Updated"  // Easy to forget main queue
        }
    }
}

// Swift 6 - MainActor annotation
@MainActor
class ViewController: UIViewController {
    func updateLabel() {
        self.label.text = "Updated"  // Compiler ensures main thread
    }
}

// Or for individual methods
class ViewController: UIViewController {
    @MainActor
    func updateLabel() {
        self.label.text = "Updated"
    }
}

🎭 Understanding Actors in Depth

Actors are Swift 6’s solution to the “shared mutable state” problem. They provide:

  1. Isolation: Only one task can access an actor’s mutable state at a time
  2. Serialization: Requests are processed one at a time, preventing races
  3. Type Safety: The compiler enforces actor isolation rules

Actor Example: Network Manager

actor NetworkManager {
    private var activeRequests: Set<UUID> = []
    private var cache: [URL: Data] = [:]
    
    func fetch(url: URL) async throws -> Data {
        // Check cache first
        if let cached = cache[url] {
            return cached
        }
        
        // Track active request
        let requestID = UUID()
        activeRequests.insert(requestID)
        defer { activeRequests.remove(requestID) }
        
        // Perform network request
        let (data, _) = try await URLSession.shared.data(from: url)
        cache[url] = data
        
        return data
    }
    
    func clearCache() {
        cache.removeAll()
    }
    
    var requestCount: Int {
        activeRequests.count
    }
}

Key Points:

  • All mutable state (activeRequests, cache) is protected
  • Methods are automatically async when called from outside the actor
  • Properties accessed from outside require await

⚠️ Common Pitfalls and Solutions

Pitfall 1: Capturing Non-Sendable Types

// ❌ Error: 'ViewController' is not Sendable
Task {
    await someActor.doSomething(with: self)
}

// ✅ Solution: Capture only Sendable data
Task { [weak self] in
    guard let self = self else { return }
    let data = self.getSendableData()
    await someActor.doSomething(with: data)
}

Pitfall 2: Sharing Mutable Reference Types

// ❌ Error: 'NSMutableArray' is not Sendable
actor DataProcessor {
    func process(_ array: NSMutableArray) { }  // Error!
}

// ✅ Solution: Use value types or make immutable
actor DataProcessor {
    func process(_ array: [String]) { }  // Array is Sendable
}

Pitfall 3: Forgetting @MainActor

// ❌ Error: Main actor-isolated property accessed from non-isolated context
class ViewController: UIViewController {
    func backgroundTask() {
        Task {
            self.label.text = "Done"  // Error!
        }
    }
}

// ✅ Solution: Mark with @MainActor
class ViewController: UIViewController {
    func backgroundTask() {
        Task { @MainActor in
            self.label.text = "Done"  // OK!
        }
    }
}

📈 Performance Considerations

Actor Overhead

Actors serialize access, which means:

  • ⚠️ Sequential Processing: Only one task accesses an actor at a time
  • ✅ No Locks: Actors use cooperative scheduling (no expensive locks)
  • ✅ Compiler Optimizations: Swift can optimize actor calls

Best Practice: Keep actors focused. Don’t put heavy computation inside actors—extract data, process it outside, then store results back.

// ❌ Slow: Heavy computation inside actor
actor ImageProcessor {
    func process(_ image: UIImage) -> UIImage {
        // Heavy image processing blocks other tasks
        return applyFilters(to: image)
    }
}

// ✅ Fast: Extract, process, store
actor ImageProcessor {
    func process(_ image: UIImage) async -> UIImage {
        let data = extractImageData(image)
        let processed = await heavyProcessing(data)  // Outside actor
        return UIImage(data: processed)
    }
}

🛠️ Migration Checklist

Use this checklist when migrating your project:

  • Enable Swift 6 language mode
  • Fix all Sendable conformance errors
  • Convert shared mutable classes to actors
  • Mark all UI code with @MainActor
  • Review and fix data race warnings
  • Test thoroughly—concurrency bugs are subtle
  • Update dependencies to Swift 6 compatible versions
  • Document actor boundaries in your codebase

🎓 Real-World Example: Migrating a ViewModel

Here’s a complete example of migrating a typical ViewModel:

// Before Swift 6
class UserViewModel {
    private var users: [User] = []
    private var isLoading = false
    
    func loadUsers() {
        isLoading = true
        NetworkService.shared.fetchUsers { [weak self] users in
            self?.isLoading = false
            self?.users = users
            self?.delegate?.didUpdateUsers()
        }
    }
}

// Swift 6 - Using Actor and async/await
@MainActor
class UserViewModel: ObservableObject {
    @Published private(set) var users: [User] = []
    @Published private(set) var isLoading = false
    
    private let networkService: NetworkService
    
    init(networkService: NetworkService) {
        self.networkService = networkService
    }
    
    func loadUsers() async {
        isLoading = true
        defer { isLoading = false }
        
        do {
            users = try await networkService.fetchUsers()
        } catch {
            // Handle error
            print("Failed to load users: \(error)")
        }
    }
}

📚 Additional Resources

🎯 Conclusion

Swift 6’s strict concurrency model is a game-changer for iOS development. While migration requires effort, the benefits are enormous:

  • 🛡️ Safety: Catch data races at compile time
  • 🚀 Performance: Better concurrency patterns
  • 📖 Clarity: Explicit concurrency boundaries
  • 🐛 Fewer Bugs: Eliminate entire classes of concurrency bugs

Start migrating your projects now. The compiler is your friend—let it guide you to safer, more maintainable code.

Remember: Concurrency is hard, but Swift 6 makes it easier. Take it step by step, test thoroughly, and don’t hesitate to refactor when the compiler points out issues.

Have questions about Swift 6 concurrency? Share your migration experiences in the comments below!

You May Also Enjoy