AsrManager needs Sendable conformance for Xcode 26.4 compatibility

[sebsto]

Summary

Xcode 26.4 (17E192) introduces stricter Swift 6 concurrency checking that causes build failures in FluidAudio 0.12.4. The AsrManager class is used from within StreamingAsrManager (an actor) via a nonisolated(unsafe) property, but the compiler now flags the await calls as sending 'asrManager' risks causing data races.

Errors

StreamingAsrManager.swift:622:38: error: sending 'asrManager' risks causing data races
StreamingAsrManager.swift:379:77: error: sending 'asrManager' risks causing data races
StreamingAsrManager.swift:258:34: error: sending 'asrManager' risks causing data races

Why 0.12.4 Specifically

FluidAudio 0.12.5+ likely fixes this but requires swift-transformers >= 1.2.0. Projects that also depend on WhisperKit are capped at FluidAudio 0.12.4 because WhisperKit pins swift-transformers to < 1.2.0 (see argmaxinc/WhisperKit#451).

A patch on the 0.12.x branch that adds Sendable conformance without bumping the swift-transformers requirement would unblock these projects.

Suggested Fix

Add @unchecked Sendable to AsrManager in Sources/FluidAudio/ASR/AsrManager.swift:

// Current
public final class AsrManager {

// Proposed
public final class AsrManager: @unchecked Sendable {

This is safe because AsrManager is only accessed from within StreamingAsrManager's actor isolation domain.

Environment

• Xcode 26.4 (17E192) — fails
• Xcode 26.3 (17C529) — succeeds
• FluidAudio 0.12.4
• macOS 26

[m13v]

hitting this exact pinch in our project too. we depend on WhisperKit for on-device transcription and FluidAudio for streaming ASR, and the swift-transformers version ceiling is painful. the @unchecked Sendable fix is correct and safe here since AsrManager access is already gated through the actor. one thing worth mentioning - when we ran into similar Sendable issues with Xcode 26.4 in our own codebase, we found that just adding the conformance wasn't enough in some cases. if AsrManager holds any mutable state that gets captured in closures passed across isolation boundaries, the compiler might still complain. wrapping internal state access with a dedicated lock (os_unfair_lock or an actor-internal serial queue) made the unchecked Sendable conformance actually safe rather than just shutting up the compiler.

[m13v]

we use WhisperKit for on-device transcription in our voice-first macOS agent - here's our transcription service that deals with similar Swift concurrency patterns: https://github.com/m13v/fazm/blob/main/Desktop/Sources/TranscriptionService.swift

[Alex-Wengg]

@sebsto @m13v
we have removed swift-transformer from the entire repo & verify the parakeet results against https://github.com/FluidInference/FluidAudio/blob/main/Documentation/ASR/benchmarks100.md to ensure WER and RTFx were not altered. please let us if anything else comes up

[m13v]

Great, clean removal and verified benchmarks is the right way to do it. Looks good from my side - the Sendable conformance should be solid now with that dependency gone.

[sebsto]

@Alex-Wengg Just updated to 0.13.4 and I confirm I don't have concurrency errors anymore (and not depending on swift-transformer helps for the WhisperKit dependency) - Thank you

[m13v]

Great to hear the concurrency errors are resolved! Dropping the swift-transformers dependency is a nice bonus too - cleaner dependency graph for WhisperKit builds. Are you using FluidAudio for real-time transcription or batch processing?

[sebsto]

@m13v I built (yet another) dictation app for macOS :-)

[m13v]

Nice! macOS dictation is a fun space to work in. What are you using for the speech engine - FluidAudio/Parakeet, WhisperKit, or Apple's built-in Speech framework? Curious how the latency feels for real-time use.

[sebsto]

The app is at https://wispr.stormacq.com It proposes both FluidAudio/Parakeet and WhisperKit. FluidAudio / Parakeet offers lower latency and higher precision for english and french.