Apple SpeechAnalyzer vs Whisper: On-Device Speech-to-Text in 2026

Apple shipped SpeechAnalyzer + SpeechTranscriber in iOS 26 / macOS 26 — and published no accuracy numbers. The first independent benchmark (July 2026) fills the gap: 2.12% word error rate on clean English (LibriSpeech test-clean), beating Whisper Small (3.74%), Base, Tiny, and the legacy engine — while running ~3x faster than Whisper Small on an M2 Pro, fully on-device. Ship SpeechAnalyzer for English/major-locale Apple apps. Stay on Whisper/WhisperKit if you need 100+ languages or custom vocabulary, and reach for Parakeet on disfluent real-world speech. None of them do speaker diarization — you bolt that on yourself.

By Rohit Raj — Founding Engineer · 10+ yrs MVP shipping · LinkedIn

Apple did a strange thing with SpeechAnalyzer. They replaced the decade-old SFSpeechRecognizer, shipped a genuinely modern on-device transcription stack in iOS 26 and macOS 26, demoed it at WWDC25, and then published not a single word error rate. The API landed with marketing adjectives — "fast", "on-device", "long-form" — and zero measured accuracy.

For anyone deciding what to put in a voice-notes app, a meeting recorder, or a dictation feature, that silence is the whole problem. "Better than the old one" is not a number you can design around. So this week an independent benchmark ran SpeechAnalyzer against the model everyone actually compares to — OpenAI's Whisper — on standard LibriSpeech audio, and the results made the Hacker News front page.

The short version: Apple's silence was hiding a win. SpeechAnalyzer scored 2.12% WER on clean speech — per the get-inscribe benchmark — better than every on-device Whisper variant tested, at roughly triple the speed of Whisper Small. But "best on-device English accuracy" is not the same as "the one you should ship", and the gap between those two claims is where this post lives: the real numbers, the Swift to wire it up, the diarization hole every writeup ignores, and the two production cases where I'd still pick Whisper.

Word error rate on LibriSpeech — the standard read-English corpus — split into test-clean (clean audio) and test-other (noisier, harder). Lower is better. From the July 2026 benchmark, every engine running fully on-device on an M2 Pro:

Two things jump out. First, SpeechAnalyzer beats every on-device Whisper size on both splits — not marginally, but by 43% relative on clean speech versus Whisper Small. Second, the old SFSpeechRecognizer you may still be shipping is 4.3x worse (9.02% vs 2.12%). If your app targets iOS 26, that migration is free accuracy.

The one caveat the number needs: Apple's 2.12% is *just shy of Whisper Large v3's ~2.1%* — but Large v3 typically needs a GPU and is not built for real-time on-device use. On the M2 Pro, SpeechAnalyzer transcribed a 34-minute video in 45 seconds; Whisper Large V3 Turbo took 101 seconds for the same clip. So Apple is matching the accuracy of a model class that usually needs a datacenter, at laptop speed, offline. That is the actual story, and it is a very good one.

Where the picture gets more honest is multilingual. A separate 4-engine test on 13,023 samples across five languages found SpeechAnalyzer winning German (6.7%) and Italian (4.0%), but WhisperKit taking English (5.2%) and Spanish (4.5%) in *their* harder real-world set. English clean-read audio and English messy-real audio are different games.

The new API is three types: `SpeechAnalyzer` (the session), `SpeechTranscriber` (the module that turns audio into text), and `AssetInventory` (downloads the on-device language model). You compose a module into an analyzer, feed it an async stream of audio, and read results off another async sequence — no completion-handler soup. This is the essential shape from WWDC25 session 277:

import Speech

// 1. A transcriber module bound to a locale.
let transcriber = SpeechTranscriber(
    locale: Locale(identifier: "en-US"),
    transcriptionOptions: [],
    reportingOptions: [.volatileResults],   // stream partials as the user speaks
    attributeOptions: [.audioTimeRange]      // word-level timestamps
)

// 2. Make sure the on-device model is installed (first run downloads it).
if let request = try await AssetInventory.assetInstallationRequest(
    supporting: [transcriber]
) {
    try await request.downloadAndInstall()
}

// 3. Wire the module into an analyzer.
let analyzer = SpeechAnalyzer(modules: [transcriber])

// 4. Read results off an async sequence — volatile (live) then finalized.
Task {
    for try await result in transcriber.results {
        let text = result.text                 // AttributedString, carries timings
        print(result.isFinal ? "FINAL: \(text)" : "…live: \(text)")
    }
}

// 5. Feed audio buffers as they arrive from AVAudioEngine.
let (stream, input) = AsyncStream<AnalyzerInput>.makeStream()
try await analyzer.start(inputSequence: stream)
// input.yield(AnalyzerInput(buffer: pcmBuffer))  // in your tap callback

Three things worth noting for production. The `.volatileResults` option is what gives you the live, updating caption effect — you get provisional text immediately and a corrected isFinal version a beat later. The `AssetInventory` download is a one-time per-locale cost you should trigger *before* the user hits record, not during. And because it is on-device with no server fallback, you get no Business Associate Agreement headaches for health or legal apps — the audio never leaves the phone. Compare that to running a large model locally, where "on-device" means a 600 GB machine; here it means an iPhone.

Three concrete workflows where it is now the obvious default:

1. Long-form dictation and transcription on Apple hardware. The old SFSpeechRecognizer had a ~1-minute practical ceiling and degraded on distant mics. SpeechAnalyzer is built for long-form audio with no duration cap and handles far-field audio better. A meeting recorder, a lecture-notes app, a podcast transcriber — this is the target. At 45 seconds for 34 minutes of audio, a one-hour recording transcribes in under a minute-and-a-half.

2. Privacy-sensitive verticals. Because processing is fully on-device with no cloud path, a therapy-notes app, a clinical scribe, or a legal dictation tool can transcribe without a single byte of audio leaving the device. That removes an entire compliance workstream — no data-processing addendum, no BAA, no "where is the audio stored" question in the security review.

3. Live captions with low latency. The .volatileResults stream gives you sub-second provisional text. On an M2 Pro the benchmark measured 12x to 40x real-time, so live captioning has enormous headroom even on a phone-class chip. For accessibility features and real-time subtitles, that latency budget is the difference between "usable" and "annoying".

The through-line: if your users are on iOS 26 / macOS 26 and speaking a supported locale, SpeechAnalyzer is faster, more accurate, and cheaper to operate (zero inference cost, zero servers) than anything you were running before. The reasons to look elsewhere are specific, and they are the next section.

Accuracy is one column. The decision is the whole row. Here is how the four on-device engines developers actually reach for compare across what matters in production (WER from get-inscribe; language + real-world notes from the 13,023-sample dicta.to test):

Read it by column, not by winner. Apple wins clean English accuracy and speed, but is locked to the newest OS and can't learn your product's brand names. Whisper/WhisperKit is the portability and vocabulary play — 100+ languages, custom terms, runs anywhere Core ML runs, and it took English and Spanish in the harder real-world set. Parakeet is the one that "wins when people actually talk" — disfluent, um-and-uh speech where clean-corpus scores stop predicting anything. Qwen3-ASR is the multilingual generalist at 30 languages.

The uncomfortable truth the single-number headlines miss: on your users' real audio, the LibriSpeech ranking may not hold. Clean read English is the easiest possible test. Pick two engines and run them on *your* recordings before you commit.

Skip it — or pair it — in four cases:

You need more than ~30 languages. SpeechTranscriber supports around 30 locales; Whisper covers 100+. If your user base is genuinely global, Apple's list will strand people. This is the single most common disqualifier.

You need custom vocabulary. SpeechAnalyzer has no custom-vocabulary or biasing API today. If your domain is full of drug names, ticker symbols, or product SKUs, a raw transcriber will mangle them — the dicta.to test saw jargon WER around 20% until a proofread layer cut it to ~10%. WhisperKit and Parakeet let you bias toward a term list; Apple does not.

You must run on older OSes or non-Apple platforms. SpeechAnalyzer is iOS 26 / macOS 26 and later, Apple-only. Shipping to iOS 17, Android, or a Linux server? WhisperKit (iOS 16+) or server-side Whisper is your floor.

And the gap every writeup skips: speaker diarization. None of these engines tell you *who* said each sentence. SpeechAnalyzer, WhisperKit, Parakeet, Qwen3 — all four transcribe, none diarize. For a solo dictation app that's fine. For a meeting recorder, "who said what" is the actual product, and you will need a separate diarization stage (pyannote, WhisperX, or a cloud API) layered on top. I have watched a "just use Apple's new API" plan quietly discover this three weeks in, after the demo worked and the real feature didn't. Budget for it up front.

If I were building a voice feature on Apple platforms this quarter, here is the exact wiring — because the model is the easy 20%, and the plumbing around it is the part that ships late.

Default to SpeechAnalyzer, gate it on OS + locale. Detect iOS 26 / macOS 26 and a supported locale at runtime; when both hold, use it — best accuracy, best speed, zero server cost, no compliance surface. Trigger the AssetInventory model download during onboarding, not at first record, so the user never waits on a cold model.

Keep WhisperKit as the fallback lane, not the main road. Older OS, unsupported language, or a user who needs custom vocabulary → route to WhisperKit with a biased term list. One transcription protocol, two implementations behind it, chosen by capability check. This is a half-day of abstraction that saves you a rewrite when Android shows up on the roadmap.

Treat diarization as a first-class stage, not a footnote. If the product is "who said what", the pipeline is *transcribe → diarize → align → label*, and the transcriber is one of four boxes. Prototype the diarization step in week one, on real multi-speaker audio, before you promise the feature — it is the piece most likely to be worse than the demo suggested.

Instrument WER on your own audio. LibriSpeech is not your users. Log a sample of transcripts (with consent), hand-correct a small held-out set, and measure real WER per engine per locale. The benchmark that made this post exists precisely because vendors don't publish the number that matters — yours; do the same internally.

That fallback routing, the capability gate, the diarization stage, the consent-gated measurement loop — that scaffolding is most of the real work in a voice feature, and it is what teams skip and then retrofit after a bad review. It's what I build: 6-week MVPs that ship with the fallback path and the measurement already wired, or a founding engineer embedded with your team to get the on-device speech stack right the first time. If you're choosing an STT engine for a product right now, that's a conversation worth having before you hard-code one API into every screen.