Custom vocabulary did not disappear from Apple's new SpeechAnalyzer stack. The important detail is module choice. Apple documents AnalysisContext.contextualStrings specifically with DictationTranscriber. If you are building around SpeechTranscriber, do not assume that attaching the same context gives you the same vocabulary behavior.

Short version: choose DictationTranscriber when contextual phrases are part of your recognition design. Keep the list short, keep phrases brief, and treat them as biasing hints rather than guaranteed replacements.

There are two transcription modules — and they are not interchangeable

iOS 26's Speech framework makes transcription modular. SpeechTranscriber is Apple's general-purpose transcriber for normal conversation. DictationTranscriber is closer to system dictation and exposes additional accuracy controls.

NeedModule to evaluate firstWhy
General conversation / long-form transcriptionSpeechTranscriberApple describes it as the general-purpose speech-to-text module.
Short dictation with app-specific names or termsDictationTranscriberApple explicitly documents AnalysisContext.contextualStrings with this module.
Custom pronunciation / language modelDictationTranscriberIt also exposes a customized-language content hint backed by SFSpeechLanguageModel.

How contextualStrings actually works

AnalysisContext.contextualStrings is a dictionary grouped by contextual-string tags. Apple says these words or phrases can be used with DictationTranscriber to improve the likelihood that app-specific names, products, places, domain terminology, or unusual words are recognized.

let context = AnalysisContext()
context.contextualStrings[.general] = [
    "Simple Memo",
    "Obsidian",
    "SpeechAnalyzer"
]

try await analyzer.setContext(context)

Three limits matter in practice:

  • Keep phrases brief. Apple recommends one or two words whenever possible.
  • Keep the total at 100 phrases or fewer across all tags.
  • These are hints, not guarantees. The API biases recognition; it does not promise an exact transcription.

setContext replaces the context — it does not append

SpeechAnalyzer.setContext(_:) replaces the analyzer's current context object. If you want to preserve earlier phrases while adding a new group, construct the complete new context you want to use and set that.

let next = AnalysisContext()
next.contextualStrings[.general] = baseTerms + currentScreenTerms
try await analyzer.setContext(next)

This also makes tags useful: you can maintain categories in your own state and rebuild the context deliberately rather than treating repeated setContext calls as incremental additions.

What about SpeechTranscriber?

Apple's current documentation for SpeechTranscriber does not document contextualStrings as one of that module's accuracy controls. By contrast, the DictationTranscriber documentation explicitly tells developers to create an AnalysisContext and add words to contextualStrings.

That distinction is the safe implementation boundary: do not design a SpeechTranscriber pipeline around contextual vocabulary unless you have independently verified the exact behavior you need on your target OS, locale, and device.

If you need vocabulary in long-form speech today

There is no universal migration rule. If your existing SFSpeechRecognizer path already depends on contextualStrings, moving to iOS 26 should be treated as a module-selection and regression-testing exercise rather than a mechanical API rename.

  1. Test whether DictationTranscriber fits the duration, latency, locale, and device range you need.
  2. If you need a richer vocabulary, evaluate its customized language-model option.
  3. If neither new-module path preserves the behavior your product depends on, keep the proven SFSpeechRecognizer path for that use case while you migrate other paths separately.

Minimal decision rule

Conversation-first: start with SpeechTranscriber. Vocabulary-first: start by evaluating DictationTranscriber. If vocabulary is critical, measure recognition on the actual words and locales you ship instead of assuming parity between modules.

Related implementation guide

For the live microphone pipeline — model assets, PCM conversion, volatile vs final results, stop/finalization behavior, and Swift 6 concurrency — see the full iOS 26 SpeechAnalyzer live-mic guide. The runnable sample is on GitHub (MIT).

Primary sources