Fixing a streaming SwiftUI chat hang: stable scroll anchors and local/cloud cancellation

Greg Young — Sat, 07 Nov 2026 18:33:04 +0000

In a SwiftUI reference app, streamed model output and illustrated answer cards repeatedly change the transcript’s height. The assistant uses Apple Foundation Models when available, with a consent-controlled online fallback. A reproduced layout hang led to changes in both rendering and task lifetime.

The failure

Opening “Ask guide” from an entry could leave the process hung at roughly 99% CPU. The sampled main thread repeatedly hit SwiftUI lazy-stack placement/graph updates, and the observed process footprint reached 1.1 GB. Reopening returned to the same hung process. A UI reproduction also timed out while querying the app.

The transcript combined lazy height estimation, a scroll target on a growing answer, animated scrolling, and frequent streamed-text updates. This was a reproduced layout hang; I wouldn't generalize it into “LazyVStack is bad for chat.”

What changed

A measured VStack replaced the lazy transcript stack.
Every exchange gets a separate fixed-height anchor before its changing content.
Inserting an exchange triggers one nonanimated scroll to that anchor.
Streamed UI publications are spaced by at least 50 ms, apart from reset/final updates. This is an implementation bound, not a frame-rate benchmark.
Ask and the map mount on first use. A pending question is consumed only when Ask is visible, idle, and at its root navigation destination.

The anchor pattern, simplified from the view:

ForEach(exchanges) { exchange in
    Color.clear.frame(height: 1)
        .id("exchange-top-\(exchange.id)")
    exchangeView(exchange)
}
// On exchange-count change, inside ScrollViewReader:
// proxy.scrollTo("exchange-top-\(last.id)", anchor: .top)

Cancellation needed an identity check, too

Each generation has a UUID. After suspension, updates check that UUID and look up the exchange by its stable ID rather than retaining an array index:

private func publish(_ answer: GeneratedAnswer, id: UUID, run: UUID) {
    guard activeRun == run,
          let index = exchanges.firstIndex(where: { $0.id == id })
    else { return }
    exchanges[index].answer = answer.text
    exchanges[index].engine = answer.engine
}

Leaving Ask cancels the task, invalidates the run and clears unfinished text. The AsyncThrowingStream wrappers cancel their producer tasks in onTermination. Cancellation of on-device generation propagates out; it must not be treated as a reason to start a cloud request.

If local generation actually fails or returns empty, the service checks cancellation and consent before falling back, then clears partial local text before publishing cloud output. Interrupted SSE output is rejected unless the completion marker arrives. A completed, nonempty answer alone consumes a free answer allowance; retries use the exchange ID for deduplication.

The retrieval boundary

Both engines use up to four eligible local passages. The local prompt bounds the question, each passage and recent history, with a fresh session per turn. These are character/count limits, not a precise tokenizer budget. The cloud request sends a pinned snapshot and evidence IDs; the Worker resolves its own passage text and checks scope/quarantine eligibility rather than trusting client-supplied evidence text. Journal notes and progress aren't in the request contract. None of this proves every generated statement is supported.

Validation and remaining tradeoff

The regression coverage exercises entry → Ask handoffs, leaving and returning during generation, stale answers, relaunch, and cancellation of both local and cloud producers. The earlier hang was reproduced before the change. I don't have a controlled end-to-end latency or post-fix memory benchmark to claim here.

A measured stack also isn't a universal long-transcript solution: I'd want bounded/paginated history and memory profiling before treating this pattern as suitable for arbitrarily long conversations.

For people shipping streamed SwiftUI interfaces: what tests have caught layout feedback loops and late callbacks that your normal final-state UI assertions missed?

Disclosure: This article was written by an AI assistant, and the development used coding-agent assistance. The technical claims were checked against the Swift implementation and recorded regression audit. This is a scoped case study; it does not establish a universal SwiftUI chat architecture.

DEV Community: Greg Young

Fixing a streaming SwiftUI chat hang: stable scroll anchors and local/cloud cancellation