@Test func featureRequiresDevice() async throws {
    guard await DeviceCapability.isSupported else {
        Test.current?.cancel()
        return
    }
    // test body runs only when supported
}

This is different from #require (which records a failure) or throwing a Skip (which marks the test skipped). Test.cancel() cancels the underlying task — the test shows up as cancelled in the report, signalling “not applicable” rather than “broken.”

Because it goes through Swift concurrency cancellation, any try await after the call will throw CancellationError — so a bare cancel() followed by return is the safest pattern.

Cancellation also propagates to child tests in a suite:

@Test func suite() async {
    if ProcessInfo.processInfo.environment["CI"] == nil {
        Test.current?.cancel()
        return
    }
    // child tests run only in CI
}

Takeaway: use Test.cancel() when a test is conditionally irrelevant — not wrong, just not applicable. Reserve #require for preconditions that should hold, and keep cancel() for environment or capability gates.

The problem it solves: cleanup and rollback work that must finish even when a task has been cancelled. Without a shield, awaits inside cancelled tasks can skip or short-circuit unexpectedly.

func closeConnection() async {
    await withTaskCancellationShield {
        await database.close()   // runs to completion even if outer task is cancelled
    }
    // Task.isCancelled reflects the real state again here
}

A good one-two punch is pairing it with defer:

func performWork() async throws {
    defer {
        withTaskCancellationShield {
            cleanup()   // deferred cleanup that must not be skipped
        }
    }
    try await doTheWork()
}

The shield also prevents cancellation from propagating into child tasks — async let bindings and task groups inside the closure won’t be automatically cancelled.

Constraints worth knowing:

• Keep shielded regions short — finish or roll back work already started, not hide cancellation from long-running operations
• Once the closure returns, the outer task’s cancellation state is restored

Takeaway: reach for withTaskCancellationShield when you have cleanup that cannot be skipped on cancellation — it’s the missing piece for reliable resource teardown in structured concurrency.

The problem it solves: Social engineering attacks where the user performs the action themselves (authenticated, legitimate), so MFA/biometrics are useless. Need a signal for coerced vs. genuine intent.

Integration flow:

• Requires an entitlement/capability in Xcode
• Client-side Swift API only (no server integration needed)
• Create InsightContext with operationCategory (payment, account, resourceUse, communication, other) + InsightEvaluation
• Call requestEvaluation() async — takes a few seconds, needs internet
• Check authorization status first (user can disable it in Settings)

guard await InsightContext.authorizationStatus == .authorized else { return }

let context = InsightContext(
    operationCategory: .payment,
    evaluation: InsightEvaluation()
)
let insight = try await context.requestEvaluation()

switch insight.isLikelyBeingCoached {
case .high:    showCoercionWarning()
case .medium:  requireAdditionalVerification()
case .unknown: break  // no evidence — not a green light
}

insight.reportConsumption()  // mandatory

Result values for IsLikelyBeingCoachedInsight:

• unknown — no evidence, but not to be treated as low risk
• medium — introduce friction, additional verification, adjust risk scoring
• high — warn the user before proceeding

Feedback (mandatory):

• reportConsumption() must be called per evaluation or you get rate-limited
• Offline fraud labels submitted via Apple Business Register (server-to-server) — optional but helps the model

Privacy architecture:

• Device-sourced signals (interaction patterns, timing, sensors) processed locally, inputs discarded immediately
• Only the single output value leaves the device
• Apple Account signals + velocity checks may be incorporated server-side
• Never touches Photos, Messages, Mail content
• User can disable in Settings (cooldown applies to prevent coaching into disabling it)

Best practices:

• Use it at high-value moments: P2P payments, irreversible actions, remote access grants, sensitive data sharing
• Never sole decision factor — integrate into existing risk logic
• Never treat unknown or missing value as safe
• Test with Xcode scheme launch argument overrides (sandbox in dev, production on App Store)

Related: App Attest for verifying requests come from legitimate app instances.

let numbers = [1, 2, 3, 4, 5]
let span: Span<Int> = numbers.span   // zero-copy view, no allocation

print(span[0])      // 1
print(span.count)   // 5

for value in span {
    process(value)
}

The key property is that Span is ~Escapable — it cannot outlive the storage it views. The compiler rejects any attempt to escape it:

func leakedSpan() -> Span<Int> {   // ❌ Span<Int> is non-escapable
    let numbers = [1, 2, 3, 4, 5]
    return numbers.span             // compile error: span would outlive numbers
}

This makes the entire class of dangling-pointer bugs a compile-time error rather than a runtime crash. Compare with the old approach:

// Before: no safety net
func riskyWork(buffer: UnsafeBufferPointer<Int>) { ... }
numbers.withUnsafeBufferPointer { riskyWork(buffer: $0) }  // easy to misuse

// Swift 6.2: lifetime tracked by the compiler
func safeWork(span: Span<Int>) { ... }
safeWork(span: numbers.span)

For byte-level access there is RawSpan, and MutableSpan<T> covers write-enabled views (with the same lifetime guarantees).

Takeaway: prefer Span<T> over UnsafeBufferPointer whenever you need a performant, zero-copy read over contiguous memory — the ~Escapable constraint gives you the speed without the footguns.

The trick is constraining the generic parameter so the State and Action types match, while letting the concrete reducer vary at the call site.

struct CounterView<R: Reducer>: View where R.State == CounterFeature.State,
                                            R.Action == CounterFeature.Action {
    @Bindable var store: Store<R.State, R.Action>

    var body: some View {
        VStack {
            Text("\(store.count)")
            Button("+") { store.send(.increment) }
        }
    }
}

Now define two reducers with the same State/Action but different logic:

@Reducer
struct CounterFeature {
    struct State: Equatable { var count = 0 }
    enum Action { case increment }

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .increment:
                state.count += 1
                return .none
            }
        }
    }
}

@Reducer
struct PreviewCounterFeature {
    typealias State = CounterFeature.State
    typealias Action = CounterFeature.Action

    var body: some Reducer<State, Action> {
        Reduce { state, action in
            state.count += 10
            return .none
        }
    }
}

Inject whichever reducer the context needs:

// Production
CounterView(store: Store(initialState: .init()) { CounterFeature() })

// Preview / test
CounterView(store: Store(initialState: .init()) { PreviewCounterFeature() })

The view has no knowledge of which reducer it received. The generic constraint guarantees both reducers speak the same State and Action, so the view compiles against either without change.

Takeaway: make a TCA view generic over R: Reducer with where constraints on State and Action to decouple the view from any specific reducer implementation.

Serial vs. concurrent — how many tasks the queue runs at once.
Sync vs. async — whether the caller blocks until the task finishes.

let serial     = DispatchQueue(label: "serial")
let concurrent = DispatchQueue(label: "concurrent", attributes: .concurrent)

Serial + sync — caller blocks, queue runs one task at a time.

serial.sync { work() } // caller waits; next line runs only after work() returns
serial.sync { moreWork() }
// work() always finishes before moreWork() starts

Useful when you need a result immediately and can afford to block the calling thread. Deadlocks if you call serial.sync from a task already running on serial.

Serial + async — caller returns immediately, queue still runs one task at a time.

serial.async { work() }
serial.async { moreWork() }
// caller continues; work() finishes before moreWork() starts, but caller doesn't wait

The classic pattern for thread-safe state mutation without blocking. All mutations are serialized; no locks needed.

Concurrent + sync — caller blocks until its task finishes; other tasks on the queue may overlap.

concurrentQueue.async { longTask() }  // already running
concurrentQueue.sync  { quickTask() } // caller blocks for quickTask(); longTask() may still be running

Rarely the right tool. If you need the result synchronously, you probably want a serial queue or just inline the work.

Concurrent + async — caller returns immediately, tasks may run in parallel.

for item in items {
    concurrent.async { process(item) } // all items may process simultaneously
}

Maximum throughput for independent work. Order of completion is not guaranteed.

The mental model:

Sync/async is about the submitter’s thread. Serial/concurrent is about the queue’s parallelism. They compose independently.

The defining design choice: the protected value lives inside the lock, not alongside it. You get it only by going through withLock:

let counter = OSAllocatedUnfairLock(initialState: 0)

counter.withLock { value in
    value += 1
}

let snapshot = counter.withLock { $0 }

Compare that to NSLock, where nothing stops you from reading the value without locking:

var count = 0
let lock = NSLock()

lock.lock()
count += 1
lock.unlock()

print(count) // compiles fine — lock is bypassed entirely

“Unfair” means threads don’t get the lock in arrival order. The OS picks freely, which avoids the overhead of maintaining a queue. In practice this gives it much lower latency than NSLock for uncontended cases.

It’s non-recursive. Calling withLock again from inside withLock on the same lock is a deadlock, not a re-entry.

Sendable conformance

OSAllocatedUnfairLock is Sendable when State: Sendable. Because the state is only reachable through withLock, the compiler can verify that sharing the lock across concurrency boundaries is safe — no @unchecked Sendable needed.

This makes it a clean fit for Swift 6 strict concurrency. A class that holds mutable state and an NSLock forces you to suppress the warning yourself:

// Swift 6 — compiler complains
class Counter: Sendable {
    private var value = 0        // ⚠️ stored property 'value' of 'Sendable'-conforming class is mutable
    private let lock = NSLock()
}

With OSAllocatedUnfairLock the state is inside the lock, so the compiler is satisfied without any suppression:

final class Counter: Sendable {
    private let lock = OSAllocatedUnfairLock(initialState: 0) // ✅

    func increment() { lock.withLock { $0 += 1 } }
    func value() -> Int { lock.withLock { $0 } }
}

Takeaway: reach for OSAllocatedUnfairLock when you need a fast, struct-friendly mutex and want the compiler to make it hard to access shared state without holding the lock.

// Callbacks — this made sense
service.fetch { [weak self] result in
    guard let self else { return }
    self.update(result) // synchronous, done immediately
}

The pattern got carried into Swift concurrency by reflex, and it’s worth questioning it there.

func load() {
    Task { [weak self] in
        guard let self else { return }
        let data = await fetchData()
        let processed = await process(data)
        update(processed)
    }
}

guard let self at the top promotes the weak reference back to a strong one immediately. Self is now strongly retained for the entire task — across every suspension point, for however long the task runs. The weak capture only did work for the instant before the guard.

More importantly: Task { } doesn’t get stored by anyone externally the way a completion handler does, so there’s rarely a retain cycle to break in the first place.

What to do instead

If the task represents work that belongs to the object, just capture strongly:

func load() {
    Task {
        let data = await fetchData()
        update(data) // self kept alive for as long as the work runs — that's fine
    }
}

If you want to discard results when the object is gone by the time the async work finishes, check at the point where it matters — after the await:

func load() {
    Task { [weak self] in
        let data = await fetchData() // do the work regardless
        guard let self else { return } // discard if object is gone by now
        update(data)
    }
}

That said, the scheduling behavior this reveals is worth understanding.

class ViewModel {
    func work() {
        Task { [weak self] in
            guard let self else { print("No self"); return }
            doWork()
        }
    }
}

var vm: ViewModel? = ViewModel()
vm?.work()
vm = nil

Without @MainActor: work() is nonisolated, so the task runs on the cooperative thread pool. It may start executing before the main thread processes vm = nil. Self is still alive — the guard passes silently.

With @MainActor in: the task is queued on the main actor. The main thread finishes its current job first — including vm = nil — then picks up the task. By that point self is nil, and the guard catches it.

Task { [weak self] in           // thread pool — races with vm = nil on main thread
    guard let self else { ... } // self may still be alive
}

Task { @MainActor [weak self] in  // queued after current main actor job completes
    guard let self else { ... }   // vm = nil has already run
}

The point isn’t weak self — it’s that a task bound to the main actor can only run after the main actor finishes its current work. Switching actor context changes the scheduling order, which changes what state the world is in when the task body starts.

The rule: @MainActor in doesn’t change capture semantics — it changes when the task runs relative to everything else on the main actor.

func crunchNumbers() async {
    for i in 0..<1_000_000 {
        process(i)
        if i.isMultiple(of: 1000) {
            await Task.yield() // give other tasks a turn
        }
    }
}

Without the yield, a long CPU-bound loop holds the thread uninterrupted. Other tasks in the same cooperative thread pool can starve. Yielding periodically makes the loop cooperative.

It also acts as a cancellation checkpoint:

func crunchNumbers() async throws {
    for i in 0..<1_000_000 {
        try Task.checkCancellation()
        process(i)
        if i.isMultiple(of: 1000) {
            await Task.yield()
        }
    }
}

After resuming from yield, the task checks cancellation on the next checkCancellation() call. Without any suspension point, a cancelled task runs to completion anyway.

Red flags

Task.yield() is not a background escape. On @MainActor, the task resumes back on the main thread. The main thread is freed only for the brief window between suspend and reschedule — not long enough for heavy computation to stop being a problem.

There’s also no fairness guarantee — if nothing else is waiting, yield resumes immediately. It’s a hint to the scheduler, not a timed pause.

The testing trap

Task.yield() sometimes shows up in tests to “flush” unstructured tasks:

func testSomething() async {
    var result = 0
    Task { result = 42 }
    await Task.yield()
    XCTAssertEqual(result, 42) // passes... sometimes
}

This is a code smell. yield gives the scheduled task a chance to run, but offers no delivery guarantee — the test is racing the scheduler. It can pass locally and fail on CI under load.

The real fix is to not lose the handle:

func testSomething() async {
    var result = 0
    let task = Task { result = 42 }
    await task.value
    XCTAssertEqual(result, 42) // deterministic
}

If you see Task.yield() in a test, it’s almost always papering over an unstructured task that should either be awaited directly or replaced with structured concurrency.

The rule: use yield to keep CPU-bound loops cooperative and cancellation-responsive. In tests, treat it as a red flag.