34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# 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.
|