Swiftui Concurrency Tour Wwdc

# SwiftUI Concurrency Tour (Summary) Context: SwiftUI-focused concurrency overview covering actor isolation, Sendable closures, and how SwiftUI runs work off the main thread. ## Main-actor default in SwiftUI - `View` is `@MainActor` isolated by default; members and `body` inherit isolation. - Swift 6.2 can infer `@MainActor` for all types in a module (new language mode). - This default simplifies UI code and aligns with UIKit/AppKit `@MainActor` APIs. ## Where SwiftUI runs code off the main thread - SwiftUI may evaluate some view logic on background threads for performance. - Examples: `Shape` path generation, `Layout` methods, `visualEffect` closures, and `onGeometryChange` closures. - These APIs often require `Sendable` closures to reflect their runtime semantics. ## Sendable closures and data-race safety - Accessing `@MainActor` state from a `Sendable` closure is unsafe and flagged by the compiler. - Prefer capturing value copies in the closure capture list (e.g., copy a `Bool`). - Avoid sending `self` into a sendable closure just to read a single property. ## Structuring async work with SwiftUI - SwiftUI action callbacks are synchronous so UI updates (like loading states) can be immediate. - Use `Task` to bridge into async contexts; keep async bodies minimal. - Use state as the boundary: async work updates model/state; UI reacts synchronously. ## Performance-driven concurrency - Offload expensive work from the main actor to avoid hitches. - Keep time-sensitive UI logic (animations, gesture responses) synchronous. - Separate UI code from long-running async work to improve responsiveness and testability.