Apple's New Speech Framework: SpeechAnalyzer vs SFSpeechRecognizer

iOS 26 introduces a new speech-recognition framework alongside the existing SFSpeechRecognizer. The new API surface is SpeechAnalyzer plus modules (SpeechTranscriber, SpeechDetector) that compose around it¹. Apple’s own framing is that SpeechAnalyzer is the modern path: a new on-device model, long-form audio support, automatic language management, low latency for real-time use cases, and a modular architecture that supports adding more analysis types over time. SFSpeechRecognizer continues to ship and work; the reasons to stay are older-OS support and one narrower gap – custom vocabulary on the new framework’s long-form SpeechTranscriber model, since the short-form DictationTranscriber path does take contextual strings.

The post walks the new framework against the old one. The frame is “when to migrate” rather than “how to use the new API,” because every team with a working SFSpeechRecognizer integration faces the same triage decision: is the new framework’s modern model and architecture worth the migration cost, or do existing custom-vocabulary investments justify staying?

TL;DR

• SpeechAnalyzer (iOS 26+) is Apple’s modern on-device speech-recognition framework. It coordinates analysis modules configured at init; iOS 26 ships three: SpeechTranscriber (long-form), DictationTranscriber (short-utterance, the SFSpeechRecognizer-equivalent), and SpeechDetector (voice activity detection, must pair with a transcriber)².
• The new framework is built around long-form audio: lectures, meetings, multi-speaker conversations. It runs entirely on-device, handles per-locale model assets automatically, and ships with a new proprietary Apple model that is reportedly 2× faster than Whisper Large V3 Turbo on equivalent transcription tasks³.
• SFSpeechRecognizer continues to ship and work – and custom vocabulary is no longer exclusive to it. The new framework’s AnalysisContext.contextualStrings (set via SpeechAnalyzer.setContext(_:)) registers up to 100 domain-specific phrases for the DictationTranscriber path⁶. The remaining gap is the long-form SpeechTranscriber model, which does not take contextual strings.
• Migration is per-feature, not all-or-nothing. Apps that need long-form transcription, lower latency, or better distant-audio quality migrate to SpeechAnalyzer. Apps with custom-vocabulary investments can migrate short-form dictation via DictationTranscriber plus contextual strings; only long-form transcription with custom vocabulary still argues for the legacy API.
• The cluster’s Vision framework post covers Apple’s other on-device perception primitive; SpeechAnalyzer extends the same on-device, no-cloud pattern to audio.

The Architecture: Analyzer + Modules

SpeechAnalyzer is not a transcriber by itself. It is a coordinator that manages an audio analysis session and dispatches the audio buffer to one or more modules². Modules are configured at init through the init(modules:) initializer, and analysis starts by feeding an AsyncSequence of AnalyzerInput values – each wrapping an audio buffer – via start(inputSequence:):

import Speech

let transcriber = SpeechTranscriber(
    locale: .current,
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],
    attributeOptions: []
)
let analyzer = SpeechAnalyzer(modules: [transcriber])

try await analyzer.start(inputSequence: audioInputSequence)

for try await result in transcriber.results {
    if result.isFinal {
        print(result.text)
    }
}

Three modules ship in iOS 26:

SpeechTranscriber. The speech-to-text module designed for long-form audio (lectures, meetings, multi-speaker conversations). Returns streaming results with timing per token, confidence scores, and a results AsyncSequence the app consumes through for try await. Each result has an isFinal flag separating volatile partial hypotheses from finalized text.

DictationTranscriber. The drop-in equivalent for the older SFSpeechRecognizer use case: short-utterance transcription with the same on-device model SFSpeechRecognizer uses. Apps migrating from SFSpeechRecognizer for short queries reach for DictationTranscriber; apps adopting the framework for long-form recording reach for SpeechTranscriber. The split matters because SpeechTranscriber and DictationTranscriber use different language coverage and different model paths.

SpeechDetector. Voice activity detection. Reports events when speech starts and ends within the audio stream. The detector cannot run alone; it must be paired with one of the transcriber modules in the same SpeechAnalyzer instance. Apps use it to gate transcription compute (don’t transcribe silence) or to drive UI affordances (“speak now” indicators).

The modular architecture is the structural improvement over SFSpeechRecognizer. The old API concentrates configuration, buffer handling, and result delivery in a recognizer-and-request pair, and relied on the user enabling languages in Settings; the new API separates the session coordinator from its analysis modules, so apps compose what they need.

What the New Model Brings

The transcription model behind SpeechTranscriber is a new on-device model Apple developed specifically for this framework⁴. The improvements Apple highlights at WWDC 2025:

Long-form audio quality. The model is trained for sustained transcription over minutes or hours, not just short queries. Lectures, podcasts, multi-speaker meetings, and dictation sessions transcribe with accuracy that Apple positions against Whisper-class models. MacStories’ independent test measured roughly 2.2× faster than MacWhisper’s Large V3 Turbo build on equivalent transcription tasks³.

Distant audio handling. Microphones placed across a room, conference-table audio with multiple speakers, audio with environmental noise. The model is trained for these conditions; SFSpeechRecognizer’s older model handles them less gracefully.

Real-time low-latency operation. The streaming results from SpeechTranscriber arrive faster than the old framework’s SFSpeechRecognitionRequest.shouldReportPartialResults callbacks. Apps that surface live transcription (captioning, voice-driven UIs, dictation) get smoother updates.

Automatic language management. Apple’s framing here (my paraphrase, not their term) refers to model and asset management, not mid-stream switching. The OS downloads and installs the right model assets for a locale through AssetInventory, so apps stop hand-managing per-language model availability. A transcriber instance still works one locale at a time – same as the old framework – but the asset plumbing that made multi-language support painful is now the system’s job.

No app-size cost. The model ships with the OS, not with the app. Apps adopting SpeechAnalyzer do not bundle additional model weights. The contrast with shipping a Whisper-class model in the app bundle is significant: a competitive on-device transcription stack costs zero bundle bytes.

What the Old Framework Still Offers

SFSpeechRecognizer continues to ship and work in iOS 26. Three reasons an app might keep using it:

Custom vocabulary on long-form audio. SFSpeechRecognitionRequest.contextualStrings lets the app register a list of known keywords (proper nouns, technical terms, product names) that the model will be more likely to recognize accurately. The feature substantially improves accuracy for domain-specific apps (medical dictation with drug names, legal apps with case citations, engineering apps with part numbers). The new framework has its own version of this for the dictation path: AnalysisContext.contextualStrings takes up to 100 phrases grouped by tag, set on the analyzer via SpeechAnalyzer.setContext(_:), and phrases registered there can be recognized even when they are absent from the system vocabulary⁶. DictationTranscriber additionally accepts a custom language-model configuration through its ContentHint.customizedLanguage(modelConfiguration:) content hint⁷. What has no equivalent yet is contextual strings on the long-form SpeechTranscriber model – so an app that needs custom vocabulary on long-form transcription would regress by migrating that path.

Older OS support. SFSpeechRecognizer is available on iOS 10+; SpeechAnalyzer requires iOS 26+. Apps targeting iOS 18 and earlier need the legacy framework.

Existing integration that works. Apps with stable, audited, performant SFSpeechRecognizer integrations have no urgent reason to migrate. The new framework’s improvements matter most for new use cases (long-form transcription, distant audio, multi-speaker conversations); apps that handle short voice queries through the legacy API may not gain enough to justify the migration.

When To Migrate

Three migration triggers worth naming:

The app processes long-form audio. A meeting recorder, a lecture transcription app, a podcast-to-text tool. The new model’s training on sustained audio is the right fit; the old model degrades over long sessions. Migrate first.

The app needs distant or noisy audio. Conference-room transcription, interview recording with a single distant mic, audio captured in environments with ambient noise. The new model handles these conditions noticeably better.

The app surfaces live transcription UI. Caption overlays, dictation interfaces, voice-driven assistive UIs. The lower latency of streaming results from SpeechTranscriber makes the UI feel more responsive.

Cases that don’t necessarily warrant migration:

• Long-form transcription that depends on custom vocabulary (a meeting recorder that must catch drug names or case citations). The long-form SpeechTranscriber model does not take contextual strings, so this combination stays on SFSpeechRecognizer until Apple closes the gap. Short voice queries with custom vocabulary migrate cleanly – DictationTranscriber plus AnalysisContext.contextualStrings covers them⁶.
• Apps that need to support iOS 18 and earlier. SpeechAnalyzer is iOS 26-only; the codebase needs the legacy framework for older targets regardless.

The Side-By-Side Pattern

For apps that both target older OS versions and want the new framework’s quality on iOS 26+, the side-by-side pattern is the right approach:

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current, preset: .shortDictation)
    let analyzer = SpeechAnalyzer(modules: [transcriber])
    try await analyzer.start(inputSequence: audioInputSequence)
    for try await result in transcriber.results {
        if result.isFinal {
            handleTranscription(result.text)
        }
    }
} else {
    let recognizer = SFSpeechRecognizer(locale: .current)!
    let request = SFSpeechAudioBufferRecognitionRequest()
    request.shouldReportPartialResults = true
    request.requiresOnDeviceRecognition = true
    let task = recognizer.recognitionTask(with: request) { result, error in
        guard let result else { return }
        handleTranscription(result.bestTranscription.formattedString)
    }
}

DictationTranscriber is the right choice for the iOS 26+ branch because the migration target is the SFSpeechRecognizer use case (short queries with the same dictation model). Apps targeting long-form audio swap DictationTranscriber for SpeechTranscriber in the iOS 26 branch.

The two frameworks coexist; the runtime check picks the right one based on availability. Neither blocks the other; the app’s transcription pipeline adapts.

Privacy and the Speech Authorization Surface

The two frameworks differ at the authorization layer. SFSpeechRecognizer keeps its dedicated speech-recognition authorization: NSSpeechRecognitionUsageDescription in Info.plist plus the SFSpeechRecognizer.requestAuthorization(_:) prompt⁵. SpeechAnalyzer does not use that surface – an app transcribing live audio with it needs microphone permission (NSMicrophoneUsageDescription), and nothing further for transcribing audio the app already has. The privacy story is on-device for both: SpeechAnalyzer is on-device-only by design; SFSpeechRecognizer runs on-device when the request’s requiresOnDeviceRecognition flag is set to true on the SFSpeechRecognitionRequest itself – required, not the default – otherwise it can use a server-side path.

The implication for the side-by-side pattern: an app running both frameworks carries both permission surfaces – the microphone prompt for the SpeechAnalyzer branch and speech-recognition authorization for the legacy branch – and the App Store privacy nutrition label should reflect both.

For apps that stream microphone audio to the analyzer, the standard AVAudioSession configuration applies. The cluster’s Privacy Manifest post covers the manifest entries for Speech-using apps; both frameworks fall under the same privacy declarations.

The Agent-Workflow Connection

SpeechAnalyzer’s on-device model and structured output pair cleanly with two cluster patterns:

Foundation Models for in-app reasoning. A pipeline that transcribes audio with SpeechTranscriber, then summarizes the transcript with the on-device LLM (covered in Foundation Models on-device LLM), runs entirely on-device. Total network calls: zero. Total third-party data exposure: zero.

App Intents for voice-driven actions. An AppIntent that takes a transcript as input can be invoked through Vocal Shortcuts (covered in Accessibility as platform) or through Apple Intelligence’s action surface. The intent’s perform method runs SpeechAnalyzer to transcribe the input, then dispatches to the app’s logic. The whole flow is private and local.

The pattern: the new Speech framework completes the on-device perception triangle (Vision for images, Foundation Models for language reasoning, Speech for audio) that makes fully-local AI features practical for iOS apps.

What This Pattern Means For iOS 26+ Apps

Three takeaways.

1. Default to SpeechAnalyzer for new code. The modern model, modular architecture, and improved long-form / distant / live performance make it the right starting point. The legacy framework is the fallback when older OS support or custom vocabulary on long-form transcription is required.

2. Vocabulary-dependent apps split by audio length. Short-form dictation with custom vocabulary migrates: DictationTranscriber plus AnalysisContext.contextualStrings carries the domain terms⁶. Long-form transcription with custom vocabulary keeps SFSpeechRecognizer until the SpeechTranscriber model takes contextual strings. The two frameworks coexist; mixing them per-feature is the right pattern.

3. The on-device privacy story extends from Vision to Speech. Apps that built around Vision’s on-device CV now have the equivalent for audio. Combined with Foundation Models for reasoning, the full perception-to-language pipeline can run locally without third-party data exposure.

The full Apple Ecosystem cluster: typed App Intents; MCP servers; the routing question; Foundation Models; the runtime vs tooling LLM distinction; three surfaces; the single source of truth pattern; Two MCP Servers; hooks for Apple development; Live Activities; the watchOS runtime; SwiftUI internals; RealityKit’s spatial mental model; SwiftData schema discipline; Liquid Glass patterns; multi-platform shipping; the platform matrix; Vision framework; Symbol Effects; Core ML inference; Writing Tools API; Swift Testing; Privacy Manifest; Accessibility as platform; SF Pro typography; visionOS spatial patterns; what I refuse to write about. The hub is at the Apple Ecosystem Series. For broader iOS-with-AI-agents context, see the iOS Agent Development guide.

FAQ

Is SFSpeechRecognizer deprecated?

Apple has not formally deprecated SFSpeechRecognizer. It continues to ship in iOS 26 and remains supported. The framing in WWDC 2025 is that SpeechAnalyzer is the modern, recommended path for new code; the legacy framework is the right tool for specific cases (custom vocabulary on long-form transcription, older OS support).

Can I use SpeechAnalyzer with pre-recorded audio files?

Yes. SpeechAnalyzer.start(inputSequence:) accepts an AsyncSequence of AnalyzerInput values, each wrapping an audio buffer. Apps wrap any audio source (microphone via AVAudioEngine, pre-recorded file URLs, AVAsset instances) into an AsyncSequence adapter and feed it to the analyzer. The transcription stream produces the same for try await result in transcriber.results consumption regardless of input source.

What happens to custom vocabulary if I migrate?

It depends on which transcriber the migration lands on. The dictation path supports it: register up to 100 phrases through AnalysisContext.contextualStrings, set the context via SpeechAnalyzer.setContext(_:), and DictationTranscriber consumes them⁶. The long-form SpeechTranscriber model does not take contextual strings, so vocabulary-sensitive long-form transcription should stay on SFSpeechRecognizer with contextualStrings until Apple closes that gap. A hybrid approach (new framework for general transcription, legacy API for the vocabulary-sensitive long-form path) works in iOS 26.

Can I run SpeechAnalyzer server-side?

No. SpeechAnalyzer is an on-device-only framework. It does not have a server-side path. For server-side transcription, the right tools are cloud APIs (OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) or self-hosted models. The Apple framework’s value is precisely the on-device privacy and zero-cost-per-call story.

How does language detection work?

SpeechTranscriber(locale:) takes one locale per transcriber instance, and there is no mid-stream language switching. What iOS 26 automates is the asset side: AssetInventory downloads and manages the per-locale model assets, so supporting several languages no longer means hand-managing model availability. For apps where the language is known up front (a localized app’s dictation feature), specify it explicitly. For multilingual contexts (a meeting transcriber where speakers may switch), detect or let the user pick the language, then instantiate the transcriber for that locale.

Where does this fit with the cluster’s other on-device ML posts?

SpeechAnalyzer is the third pillar of the on-device perception stack: Vision (covered in Vision Framework) handles images, Speech handles audio, and Core ML (covered in Core ML On-Device Inference) is the engine underneath both. Foundation Models (covered in Foundation Models on-device LLM) handles language reasoning. Together they form a complete on-device AI pipeline that does not require network calls.

References