name: "Swift Concurrency Expert Guide"
description: "Deep dive into Swift's async/await runtime, Sendable enforcement, actors, and migration strategies."
version: "1.0.0"
dependencies: []
tags:
- swift
- concurrency
- async-await
- sendable
- migration

The Swift Concurrency Paradigm: A Comprehensive Architectural Analysis

Executive Summary

The introduction of native concurrency in Swift represents the most
significant architectural shift in the ecosystem's history, moving from
a library-based threading model (Grand Central Dispatch) to a
language-integrated, compiler-enforced model. This report provides an
exhaustive examination of this transition. It analyzes the theoretical
underpinnings of the cooperative thread pool, the state-machine
mechanics of async/await, and the enforcement of data safety through the
Actor model and Sendable protocol.

Crucially, this document addresses the \"strict concurrency\"
requirements of Swift 6, offering detailed strategies for migration,
handling reentrancy, and managing legacy interoperability. It explores
advanced synchronization primitives, contrasting the dangers of
DispatchSemaphore with modern CheckedContinuation patterns, and details
the use of OSAllocatedUnfairLock for high-performance critical sections.
Through this analysis, we establish a definitive guide for engineering
robust, race-free applications on Apple platforms.

1. Theoretical Foundations: The Cooperative Execution Model

1.1 From Preemptive to Cooperative Multitasking

To understand the architecture of Swift Concurrency, one must first
deconstruct the limitations of its predecessor, Grand Central Dispatch
(GCD). GCD operates on a preemptive model where the operating system
creates and manages threads. While this abstracted raw pthread
management, it did not solve the problem of \"thread explosion.\" In
GCD, if a thread blocks (e.g., waiting on a semaphore or synchronous
I/O), the system spawns a new thread to maintain concurrency. This often
results in applications spawning hundreds of threads, leading to
excessive memory overhead and context-switching latency that degrades
CPU efficiency.^1^

Swift Concurrency abandons this approach in favor of a cooperative
threading model. In this system, the runtime maintains a limited pool
of threads, roughly equal to the number of logical CPU cores.^2^ Tasks
in Swift do not map 1:1 to threads. Instead, tasks are multiplexed onto
this fixed pool.

The defining characteristic of this model is the prohibition of
blocking. Because the thread pool is fixed, blocking a single thread
(e.g., Thread.sleep or semaphore.wait) effectively removes a CPU core
from the application\'s available resources. If enough threads are
blocked, the application enters a state of starvation or deadlock, as
the runtime cannot spawn \"rescue\" threads to unblock the system.^3^
Consequently, the await keyword is not merely a pause; it is a
suspension point. It signals the runtime that the current task is
yielding its thread, allowing the executor to swap in another pending
task. This context switch happens at the user-space level (mostly),
which is significantly cheaper than a kernel-level thread context
switch.^2^

1.2 The async/await State Machine

The transformation of a function marked async is a compile-time
operation. The compiler effectively slices the function into multiple
\"partial tasks\" at every suspension point (await).

When a function hits an await:

1. State Preservation: The local variables and execution pointer
   are captured into a heap-allocated frame (a continuation).

2. Stack Release: The function returns, releasing the stack frame
   and freeing the underlying thread to process other work.

3. Resumption: Once the awaited operation completes, the runtime
   schedules the continuation for execution.

This mechanism implies that an async function may start on one thread,
suspend, and resume on a completely different thread from the
cooperative pool.^2^ This \"thread hopping\" is fundamental to the
model\'s efficiency but introduces complexity regarding thread-local
storage, which is no longer a viable mechanism for state persistence in
Swift Concurrency.

1.3 Continuation Passing Style (CPS)

Under the hood, Swift utilizes a form of Coroutine representation. This
eliminates the nested closure syntax (\"callback hell\") typical of GCD.
In GCD, handling errors and control flow across asynchronous boundaries
required complex, often duplicated logic. In Swift, the linear flow of
async/await allows standard Swift error handling (do-catch) to function
seamlessly across asynchronous boundaries.^2^

The implications for memory management are profound. In a closure-based
model, developers frequently had to manage capture lists ([weak self])
manually to avoid retain cycles. In structured concurrency, because the
child task's lifetime is bound to the parent's scope, self captures are
often implicit and safe, provided the task does not outlive the
object---a guarantee enforced by structured concurrency but not by
unstructured tasks.^5^

2. Structured Concurrency: Hierarchy and Control

Structured Concurrency is the enforcement of a parent-child relationship
on asynchronous operations. This philosophy dictates that a task cannot
complete until all tasks it has spawned have also completed. This
mirrors the behavior of synchronous code, where a function cannot return
until its internal statements have executed.

2.1 The Scope of async let

The simplest form of concurrency is async let, which allows for a fixed
number of child tasks to run in parallel.

Swift

async let image = downloadImage()\
async let metadata = downloadMetadata()\
let result = try await combine(image, metadata)

Here, image and metadata are child tasks of the surrounding function. If
the parent function exits (e.g., throws an error) before these tasks
complete, the Swift runtime automatically cancels the child tasks.^7^
This automatic cancellation propagation significantly reduces the risk
of \"orphaned\" background tasks consuming resources unnecessarily.

2.2 TaskGroups: Dynamic Concurrency

For scenarios where the number of concurrent operations is unknown at
compile time---such as processing a list of URLs---TaskGroup is the
required primitive. Accessed via withTaskGroup or withThrowingTaskGroup,
this construct creates a scope where tasks can be added dynamically.^8^

2.2.1 The Concurrency Window Pattern

A critical limitation of TaskGroup compared to OperationQueue is the
lack of a built-in maxConcurrentOperationCount property. If a developer
naïvely adds 10,000 tasks to a group in a loop, the runtime will accept
them, potentially leading to excessive memory consumption as 10,000
child tasks are initialized (though they may not all execute
simultaneously due to the thread pool limit).^9^

To mitigate this, developers must implement a \"sliding window\"
pattern. This involves filling the group up to a threshold (e.g., 10
tasks) and then waiting for one task to finish before adding the next.

Table 1: Managing Concurrency Limits

Pattern Mechanism Pros Cons

Unbounded for url in urls { Simple syntax; High memory
Addition group.addTask Maximizes usage; Potential
{... } } parallelism. server overload.

Sliding if tasks >= Constant memory More complex
Window limit { await footprint; implementation;
group.next() } Controlled load. Requires manual
loop management.

Batching Split input into Easier to reason \"Straggler\"
chunks, process about than tasks delay the
chunks windows. entire batch.
sequentially.

The \"Sliding Window\" approach is generally preferred for
high-throughput network operations.^9^

2.2.2 Dependency Chains in TaskGroups

While TaskGroup is designed for parallel execution, it can model complex
dependencies. For example, a login sequence requiring sequential steps
(Location -> Permissions -> API Auth -> Logging) can be modeled as a
single task within a group, or as a chain of tasks where the result of
one await feeds the next. Because the group handles error propagation,
if any step in the sequence fails (throws), the group catches the error,
and can be configured to cancel all other running sequences
immediately.^6^

2.3 Unstructured Concurrency: Task.init vs. Task.detached

When an asynchronous operation must extend beyond the current scope
(e.g., initiating a background download from a UI button press),
developers must break out of structured concurrency using
\"unstructured\" tasks.

1. Task.init (or Task { }): Creates a new top-level task that
   inherits the actor isolation and priority of the surrounding
   context. This is the standard tool for bridging synchronous UI code
   to async logic.^2^

2. Task.detached: Creates a task with no context inheritance. It
   does not run on the caller's actor and uses default priority. This
   is rarely needed unless the developer explicitly wants to avoid
   blocking the main thread with a computationally expensive operation
   that should not inherit the UI priority.

Warning: Unstructured tasks do not automatically cancel when the
creating scope ends. Developers must manually manage the Task handle and
call .cancel() if the operation should be terminated (e.g., when a view
controller deinitializes).^2^

3. The Actor Model: Isolation and State Integrity

The Actor model is Swift's primary mechanism for eliminating data races.
Conceptually, an actor is a reference type (like a class) that
serializes all access to its mutable state. It creates an \"island of
serialization\" in a concurrent sea.

3.1 The Mailbox Metaphor vs. Locks

Unlike a standard class protected by a lock (NSLock), an actor
integrates serialization into the function call itself. When code from
Task A calls a method on Actor B, the call is treated as a message sent
to Actor B\'s mailbox. If Actor B is processing another message, Task A
suspends.

This distinction is crucial: Locks block threads; Actors suspend tasks.

A lock-based approach waiting for a resource stalls the thread. An
actor-based approach yields the thread to other work.11

3.2 The Reentrancy Dilemma

The most significant source of logical errors in Swift Concurrency is
Actor Reentrancy. Swift actors are reentrant, meaning that if an
actor method suspends (encounters an await), the actor releases its
\"lock.\" Other tasks can then execute methods on the actor before the
original method resumes.^12^

Scenario: The Bank Account Overdraft

Consider a withdraw(amount:) method:

1. Check balance (balance >= amount).

2. await database.verify().

3. Deduct balance (balance -= amount).

If two withdrawal tasks (A and B) enter this method:

1. Task A checks balance (success).

2. Task A awaits database (suspends, releases lock).

3. Task B enters, checks balance (success, because A hasn\'t deducted
   yet).

4. Task B awaits database (suspends).

5. Task A resumes, deducts balance.

6. Task B resumes, deducts balance.

Result: A race condition resulting in a double spend or negative
balance. The state invariants validated in step 1 are no longer valid in
step 3.^12^

3.2.1 Architectural Solutions to Reentrancy

Developers cannot disable reentrancy in standard Swift actors. Instead,
they must adopt specific patterns:

1. Invariant Re-verification: After every await, re-check the
   conditions (e.g., is balance still sufficient?).

2. State Snapshotting: Perform all calculations and mutations
   synchronously before or after the async work, minimizing the
   split logic.

3. Task Queues: Implement a custom serial queue (e.g., using
   AsyncStream) inside the actor to process requests strictly
   one-by-one, essentially simulating non-reentrant behavior.^13^

3.3 nonisolated Access and Global Actors

Not all actor properties require isolation. Immutable data (let) is
inherently thread-safe. Marking a property or function as nonisolated
exempts it from the actor\'s protection domain, allowing synchronous
access from any thread.^15^ This is frequently used for protocol
conformance (e.g., CustomStringConvertible) where the protocol requires
a synchronous property (like description).^16^

Global Actors extend actor isolation to the entire program. The
\@MainActor is the most prominent example, ensuring that annotated types
and functions execute on the main thread. This effectively replaces
DispatchQueue.main logic with compiler-guaranteed safety.^18^

3.4 Custom Actor Executors (Swift 5.9+)

While standard actors run on the default cooperative pool, advanced use
cases (such as interacting with a database that requires thread
affinity) may demand specific execution contexts. Swift allows actors to
define a custom unownedExecutor.

By implementing the SerialExecutor protocol, an actor can route its
tasks to a specific DispatchQueue or a shared serial executor. This is
powerful for grouping multiple actors onto a single serial context to
ensure synchronous mutual exclusion across different objects without
context switching.^20^

4. Data Safety: The Sendable Protocol

Swift 6 strict concurrency relies on the Sendable protocol to verify
that data passed between isolation domains (e.g., from Actor A to Actor
B) cannot cause data races.

4.1 Value vs. Reference Semantics

• Value Types (Structs/Enums): Implicitly Sendable if all their
  properties are Sendable. Since copies are independent, they are safe
  to pass.^23^

• Reference Types (Classes): Not implicitly Sendable. Passing a
  class instance to a task creates a shared mutable reference, a classic
  race condition recipe.

To make a class Sendable, it must be:

1. final (to prevent inheritance subversion).

2. contain only immutable (let) properties.

3. ensure all properties are themselves Sendable.^23^

4.2 \@unchecked Sendable and Internally Synchronized Classes

There are cases where a class is thread-safe but the compiler cannot
prove it---typically because it uses internal locking (mutexes, queues).
In these instances, developers can apply \@unchecked Sendable. This
annotation disables compiler checks for that type, effectively placing
the burden of safety verification on the developer.^24^

Warning: Using \@unchecked Sendable without implementing rigorous
internal locking (via NSLock or OSAllocatedUnfairLock) defeats the
purpose of Swift concurrency and introduces undefined behavior.^26^

4.3 Region-Based Isolation (Swift 6)

Swift 6 introduces sophisticated flow analysis known as Region-Based
Isolation. This allows non-Sendable types to be passed between actors
if the compiler can prove that the sender explicitly gives up
ownership and retains no references to the object. This \"transfer\"
semantic allows for more performant patterns (like passing a mutable
buffer to a background worker) without requiring the type to be
fundamentally thread-safe, provided uniqueness is guaranteed.^27^

5. Migration Strategy: Moving to Swift 6

Adopting Swift 6 is not merely a version update; it is a compliance
audit for data safety. The migration process typically follows a phased
approach to manage the deluge of compiler warnings.

5.1 Concurrency Checking Modes

Migration is controlled via compiler flags in Swift 5 mode:

1. Minimal: Basic checks, enforcing explicit Sendable adoption but
   loose on inference.

2. Targeted: Enforces Sendable constraints on code that explicitly
   uses concurrency features (like Task or actor).

3. Complete (Strict): Approximates Swift 6 behavior. Every
   potential data race is flagged. Implicit \"Main Actor\" assumptions
   are removed.^27^

5.2 The \"Leaf Module\" Strategy

The most effective migration strategy is \"Outside-In\" or
\"Leaf-First.\"

1. Identify Leaf Modules: Start with low-level utility modules that
   have no dependencies.

2. Enable Complete Checking: Turn on strict concurrency for these
   modules.

3. Audit Public Types: Ensure public structs and classes conform to
   Sendable. If a type cannot be Sendable, consider if it should be an
   Actor.

4. Propagate Upward: Once the foundation is solid, move to feature
   modules. This prevents a cascade of warnings where higher-level
   modules complain about lower-level types being non-Sendable.^27^

5.3 Handling Common Migration Warnings

Warning: \"Capture of non-Sendable type in \@Sendable closure.\"

• Context: Often occurs when a closure captures self or a local
  variable that is mutable.

• Solution: Capture specific properties by value ([name =
  self.name]) or ensure the captured object is an actor (which is
  Sendable).^29^

Warning: \"Main actor-isolated property cannot be mutated from
non-isolated context.\"

• Context: A background task tries to update a UI property.

• Solution: Wrap the mutation in await MainActor.run {... } or mark
  the calling function as \@MainActor.^30^

The \@preconcurrency Escape Hatch

When a project depends on a third-party library that has not yet updated
to Swift 6 (i.e., its types are not marked Sendable), the compiler will
generate warnings for code using that library. By importing the module
with \@preconcurrency import ModuleName, developers can suppress these
warnings, instructing the compiler to downgrade strict checks to dynamic
runtime checks for that specific dependency.28

6. Advanced Synchronization Primitives

In the transition to Swift Concurrency, many legacy patterns must be
abandoned. The most dangerous among them is the use of
DispatchSemaphore.

6.1 The Hazard of DispatchSemaphore

In GCD, it was common to use a semaphore to force a synchronous wait for
an asynchronous callback.

Swift

// DANGEROUS IN SWIFT CONCURRENCY\
let sem = DispatchSemaphore(value: 0)\
asyncTask { sem.signal() }\
sem.wait() // Blocks the thread

In the cooperative pool, sem.wait() does not yield the thread; it holds
it hostage. If this pattern is used in a Task, it can deadlock the
system by consuming a thread that might be needed by the very asyncTask
it is waiting for (Priority Inversion/Starvation).^32^

6.2 The Solution: CheckedContinuation

To bridge legacy callback-based code to async/await without blocking,
Swift provides Continuations.

Swift

// CORRECT PATTERN\
func modernAsync() async -> ResultType {\
await withCheckedContinuation { continuation in\
legacyCallbackBasedAPI { result in\
continuation.resume(returning: result)\
}\
}\
}

withCheckedContinuation suspends the current task and provides a
continuation handle. The thread is freed. When the legacy API calls the
completion block, continuation.resume() is called, and the runtime
schedules the task to resume. This bridges the worlds safely.^34^

Note: CheckedContinuation performs runtime checks to ensure resume
is called exactly once. UnsafeContinuation skips these checks for
performance but yields undefined behavior if misused.^36^

6.3 Low-Level Locking: OSAllocatedUnfairLock

Sometimes, actors are too heavy. If a class needs to protect a single
integer or a small buffer synchronously, an actor\'s await requirement
is cumbersome. Swift 6 and recent OS versions introduce
OSAllocatedUnfairLock.

Unlike os_unfair_lock (which is a C-struct and unsafe to move/copy in
Swift), OSAllocatedUnfairLock is a managed object. It is safe to use in
Swift classes.

Swift

final class ThreadSafeCounter: \@unchecked Sendable {\
let lock = OSAllocatedUnfairLock(initialState: 0)\
\
func increment() {\
lock.withLock { state in\
state += 1\
}\
}\
}

This pattern is performant and correct for small critical sections. The
class is marked \@unchecked Sendable because the compiler doesn\'t
understand the lock\'s semantics, but the developer asserts safety via
the lock.^26^

7. Performance Optimization and UI Integration

7.1 View Lifecycle: .task vs. .onAppear

In SwiftUI, initiating async work is best done via .task.

• .onAppear: Synchronous. Executes when the view graph is updated.
  Work started here (e.g., via Task { }) is not automatically cancelled
  when the view disappears.

• .task: Asynchronous context. Automatically cancels the task when
  the view disappears.

Nuance: .task runs asynchronously. If a view relies on data loaded
in .task to render its initial frame, the user may see a flicker or a
placeholder. .onAppear runs eagerly during the view update cycle, which
can sometimes result in faster initial data readiness if the data is
locally cached, but .task is architecturally superior for network
operations due to lifecycle management.^38^

7.2 Priority Inversion and Thread Explosion

Swift Concurrency employs Priority Inheritance to mitigate inversions,
where a high-priority task blocked by a low-priority task boosts the
latter\'s priority. However, in a constrained thread pool, \"Thread
Explosion\" is the greater risk.

Thread explosion happens when tasks block on external resources (IO)
without suspending. The runtime may (in limited cases) spawn threads to
compensate, but generally, it relies on developers using await. To avoid
priority inversions:

1. Use specific Task priorities (.userInitiated, .background)
   appropriate to the work.

2. Use Task.yield() in long-running background loops to allow
   higher-priority tasks access to the CPU.^40^

3. Never perform blocking IO in a Task; use FileHandle.bytes or
   URLSession async APIs.^2^

7.3 Testing Concurrent Code

Testing async code requires the XCTest framework\'s support for async
test methods.

Swift

func testAsyncOperation() async throws {\
let result = try await myActor.doWork()\
XCTAssertTrue(result)\
}

Unit tests naturally support await. However, testing precise
interleaving (race conditions) remains difficult. Frameworks like Swift
Testing (the new testing framework) and Point-Free\'s Concurrency Extras
are evolving to provide deterministic control over the serial executor
for testing purposes.^2^

Conclusion

The transition to Swift Concurrency and Swift 6 is a fundamental
re-platforming of the Apple ecosystem. It trades the flexibility and
danger of raw pointer/thread manipulation for the safety and structure
of compiled-verified task graphs. By mastering Actors for state
isolation, TaskGroups for dynamic concurrency, and Continuations for
legacy interoperability, developers can construct applications that are
immune to entire categories of memory corruption and race conditions.
The cost is a stricter adherence to architectural rules---specifically
regarding locking and reentrancy---but the result is a codebase that
scales securely on modern multi-core silicon.

Citations:

Works cited

1. Swift 6 Incomplete Migration Guide for Dummies - BrightDigit,
   accessed November 24, 2025,
   [https://brightdigit.com/tutorials/swift-6-async-await-actors-fixes]{.underline}

2. Async await in Swift explained with code examples - SwiftLee,
   accessed November 24, 2025,
   [https://www.avanderlee.com/swift/async-await/]{.underline}

3. Basics of DispatchSemaphore: Synchronization in Swift - Medium,
   accessed November 24, 2025,
   [https://medium.com/@hyleedevelop/swift-basics-of-dispatchsemaphore-c1081d273806]{.underline}

4. In Swift async/await, can I use Lock or Semaphore - Stack Overflow,
   accessed November 24, 2025,
   [https://stackoverflow.com/questions/76562442/in-swift-async-await-can-i-use-lock-or-semaphore]{.underline}

5. Mastering Concurrency in iOS App Development: A Deep Dive into Swift
   Concurrency and Async/Await - 30 Days Coding, accessed November 24,
   2025,
   [https://30dayscoding.com/blog/developing-ios-apps-with-swift-concurrency-and-async-await]{.underline}

6. TaskGroup as a workflow design tool - try Code, accessed November
   24, 2025,
   [https://trycombine.com/posts/swift-concurrency-task-group-workflow/]{.underline}

7. Question about WWDC Video - Explore Structured Concurrency in Swift,
   accessed November 24, 2025,
   [https://forums.swift.org/t/question-about-wwdc-video-explore-structured-concurrency-in-swift/83145]{.underline}

8. Task Groups in Swift explained with code examples - SwiftLee,
   accessed November 24, 2025,
   [https://www.avanderlee.com/concurrency/task-groups-in-swift/]{.underline}

9. Mastering TaskGroups in Swift | Swift with Majid, accessed November
   24, 2025,
   [https://swiftwithmajid.com/2025/02/04/mastering-task-groups-in-swift/]{.underline}

10. What is the difference between .onAppear() and .task() in SwiftUI
    3? - Stack Overflow, accessed November 24, 2025,
    [https://stackoverflow.com/questions/68114509/what-is-the-difference-between-onappear-and-task-in-swiftui-3]{.underline}

11. Migrating to Swift 6: The Strict Concurrency You Must Adopt -
    Apiumhub, accessed November 24, 2025,
    [https://apiumhub.com/tech-blog-barcelona/migrating-to-swift-6/]{.underline}

12. Swift Actor Reentrancy Explained: Safer Concurrency With a Hidden
    ..., accessed November 24, 2025,
    [https://medium.com/@tungvt.it.01/swift-actor-reentrancy-explained-safer-concurrency-with-a-hidden-trap-3ef3259c0c6c]{.underline}

13. Blog - Actor Reentrancy in Swift - Michael Tsai, accessed November
    24, 2025,
    [https://mjtsai.com/blog/2024/07/29/actor-reentrancy-in-swift/]{.underline}

14. [Concurrency] Actors & actor isolation - Page 3 - Pitches - Swift
    Forums, accessed November 24, 2025,
    [https://forums.swift.org/t/concurrency-actors-actor-isolation/41613?page=3]{.underline}

15. How to Make Parts of an Actor Nonisolated in Swift - DhiWise,
    accessed November 24, 2025,
    [https://www.dhiwise.com/post/how-to-make-parts-of-an-actor-nonisolated-in-swift]{.underline}

16. Nonisolated and isolated keywords: Understanding Actor isolation -
    SwiftLee, accessed November 24, 2025,
    [https://www.avanderlee.com/swift/nonisolated-isolated/]{.underline}

17. when use nonisolated with stored properties of actor? - Stack
    Overflow, accessed November 24, 2025,
    [https://stackoverflow.com/questions/75651770/when-use-nonisolated-with-stored-properties-of-actor]{.underline}

18. MainActor usage in Swift explained to dispatch to the main thread,
    accessed November 24, 2025,
    [https://www.avanderlee.com/swift/mainactor-dispatch-main-thread/]{.underline}

19. SwiftUI Closures on the Main Thread: Why \@MainActor Is a
    Game-Changer - Medium, accessed November 24, 2025,
    [https://medium.com/@bala.mobdev/swiftui-closures-on-the-main-thread-why-mainactor-is-a-game-changer-c749ee79650c]{.underline}

20. SerialExecutor | Apple Developer Documentation, accessed November
    24, 2025,
    [https://developer.apple.com/documentation/swift/serialexecutor]{.underline}

21. swift-evolution/proposals/0392-custom-actor-executors.md at main -
    GitHub, accessed November 24, 2025,
    [https://github.com/swiftlang/swift-evolution/blob/main/proposals/0392-custom-actor-executors.md]{.underline}

22. Controlling Actors With Custom Executors | Jack Morris, accessed
    November 24, 2025,
    [https://jackmorris.xyz/posts/2023/11/21/controlling-actors-with-custom-executors/]{.underline}

23. Sendability and Reference Types in Swift | by abdul ahad - Medium,
    accessed November 24, 2025,
    [https://abdulahd1996.medium.com/sendability-and-reference-types-in-swift-56a793a3822d]{.underline}

24. Beware \@unchecked Sendable, or Watch Out for Counterintuitive
    Implicit Actor-Isolation, accessed November 24, 2025,
    [https://jaredsinclair.com/2024/11/12/beware-unchecked.html]{.underline}

25. Preventing regressions when conforming to `Sendable` with
    `@unchecked` - Swift Forums, accessed November 24, 2025,
    [https://forums.swift.org/t/preventing-regressions-when-conforming-to-sendable-with-unchecked/62137]{.underline}

26. Beware of os_unfair_lock - mcky.dev, accessed November 24, 2025,
    [https://mcky.dev/blog/beware-os-unfair/]{.underline}

27. Migration Strategy | Documentation - Swift Programming Language,
    accessed November 24, 2025,
    [https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/migrationstrategy/]{.underline}

28. Migrate Your App to Swift 6: A Comprehensive Guide - DEV Community,
    accessed November 24, 2025,
    [https://dev.to/arshtechpro/migrate-your-app-to-swift-6-a-comprehensive-guide-14df]{.underline}

29. Swift concurrency hack for passing non-sendable closures - Jesse
    Squires, accessed November 24, 2025,
    [https://www.jessesquires.com/blog/2024/06/05/swift-concurrency-non-sendable-closures/]{.underline}

30. Understanding the New Swift 6 Concurrency Features | by Anand
    Nimje - Medium, accessed November 24, 2025,
    [https://medium.com/@nimjea/understanding-the-new-swift-6-concurrency-features-3bff267426cc]{.underline}

31. Swift 6 strict concurrency : r/swift - Reddit, accessed November 24,
    2025,
    [https://www.reddit.com/r/swift/comments/1icj54z/swift_6_strict_concurrency/]{.underline}

32. Difference between Dispatch Groups and Semaphores? : r/swift -
    Reddit, accessed November 24, 2025,
    [https://www.reddit.com/r/swift/comments/7yyf7l/difference_between_dispatch_groups_and_semaphores/]{.underline}

33. Using `async` functions from synchronous functions (and breaking
    all the rules) - Using Swift, accessed November 24, 2025,
    [https://forums.swift.org/t/using-async-functions-from-synchronous-functions-and-breaking-all-the-rules/59782]{.underline}

34. withCheckedContinuation and [weak self] in Swift Concurrency? -
    Stack Overflow, accessed November 24, 2025,
    [https://stackoverflow.com/questions/78148038/withcheckedcontinuation-and-weak-self-in-swift-concurrency]{.underline}

35. How to create and async/await-based semaphore in Swift like this one
    in JavaScript which uses Promise? - Stack Overflow, accessed
    November 24, 2025,
    [https://stackoverflow.com/questions/76546496/how-to-create-and-async-await-based-semaphore-in-swift-like-this-one-in-javascri]{.underline}

36. Mastering SwiftUI: Understanding All Continuations in Swift | by
    ViralSwift - Medium, accessed November 24, 2025,
    [https://medium.com/@viralswift/mastering-swiftui-understanding-all-continuations-in-swift-6d8c94fd4453]{.underline}

37. OSAllocatedUnfairLock | Apple Developer Documentation, accessed
    November 24, 2025,
    [https://developer.apple.com/documentation/os/osallocatedunfairlock]{.underline}

38. Running Code When Your View Appears - Chris Eidhof, accessed
    November 24, 2025,
    [https://chris.eidhof.nl/post/swiftui-on-appear-vs-task/]{.underline}

39. Running Code Only Once in SwiftUI | Swiftjective-C, accessed
    November 24, 2025,
    [https://www.swiftjectivec.com/swiftui-run-code-only-once-versus-onappear-or-task/]{.underline}

40. How to Set Task Priority in SwiftUI for Better App Performance -
    DhiWise, accessed November 24, 2025,
    [https://www.dhiwise.com/post/how-to-set-task-priority-in-swiftui-for-better-app-performance]{.underline}

41. Concurrency Visualized --- Part 3: Pitfalls and Conclusion - Medium,
    accessed November 24, 2025,
    [https://medium.com/@almalehdev/concurrency-visualized-part-3-pitfalls-and-conclusion-2b893e04b97d]{.underline}