Apples neues Speech Framework: SpeechAnalyzer vs. SFSpeechRecognizer

iOS 26 führt neben dem bestehenden SFSpeechRecognizer ein neues Framework zur Spracherkennung ein. Die neue API-Oberfläche ist SpeechAnalyzer zusammen mit Modulen (SpeechTranscriber, SpeechDetector), die sich darum herum komponieren lassen¹. Apples eigene Positionierung: SpeechAnalyzer ist der moderne Weg – ein neues On-Device-Modell, Unterstützung für Langform-Audio, automatische Sprachverwaltung, geringe Latenz für Echtzeit-Anwendungsfälle sowie eine modulare Architektur, die das Hinzufügen weiterer Analysetypen im Laufe der Zeit ermöglicht. SFSpeechRecognizer wird weiterhin ausgeliefert und funktioniert; es bleibt das richtige Werkzeug für Apps, die auf seine Funktion „Custom Vocabulary” angewiesen sind, die das neue Framework noch nicht bietet.

Dieser Beitrag stellt das neue Framework dem alten gegenüber. Der Rahmen lautet „wann migrieren” und nicht „wie die neue API verwenden”, denn jedes Team mit einer funktionierenden SFSpeechRecognizer-Integration steht vor derselben Triage-Entscheidung: Sind das moderne Modell und die Architektur des neuen Frameworks die Migrationskosten wert, oder rechtfertigen bestehende Investitionen in Custom Vocabulary das Verbleiben?

TL;DR

• SpeechAnalyzer (iOS 26+) ist Apples modernes On-Device-Framework zur Spracherkennung. Es koordiniert Analysemodule, die bei der Initialisierung konfiguriert werden; iOS 26 liefert drei davon aus: SpeechTranscriber (Langform), DictationTranscriber (kurze Äußerungen, das SFSpeechRecognizer-Äquivalent) und SpeechDetector (Voice Activity Detection, muss mit einem Transcriber gepaart werden)².
• Das neue Framework ist auf Langform-Audio ausgelegt: Vorlesungen, Meetings, Mehrsprecher-Konversationen. Es läuft vollständig auf dem Gerät, verwaltet Sprachen automatisch und wird mit einem neuen proprietären Apple-Modell ausgeliefert, das Berichten zufolge bei vergleichbaren Transkriptionsaufgaben 2× schneller ist als Whisper Large V3 Turbo³.
• SFSpeechRecognizer wird weiterhin ausgeliefert und funktioniert. Das Legacy-Framework behält die Funktion Custom Vocabulary (Registrierung bekannter Schlüsselwörter für höhere Genauigkeit bei domänenspezifischen Begriffen), die das neue Framework noch nicht bietet.
• Die Migration erfolgt feature-weise, nicht ganz oder gar nicht. Apps, die Langform-Transkription, geringere Latenz oder bessere Qualität bei entferntem Audio benötigen, migrieren zu SpeechAnalyzer. Apps mit Investitionen in Custom Vocabulary behalten SFSpeechRecognizer für diese Funktionen und ergänzen SpeechAnalyzer für neue.
• Der Beitrag des Clusters zum Vision Framework behandelt Apples andere On-Device-Wahrnehmungsprimitive; SpeechAnalyzer erweitert dasselbe On-Device-, Cloud-freie Muster auf Audio.

Die Architektur: Analyzer + Module

SpeechAnalyzer ist für sich genommen kein Transcriber. Er ist ein Koordinator, der eine Audio-Analysesitzung verwaltet und den Audio-Puffer an ein oder mehrere Module weiterleitet². Module werden bei der Initialisierung über den Initializer init(modules:) konfiguriert, und die Analyse beginnt durch Einspeisen einer AsyncSequence von Audio-Puffern 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)
    }
}

Drei Module werden in iOS 26 ausgeliefert:

SpeechTranscriber. Das Speech-to-Text-Modul, konzipiert für Langform-Audio (Vorlesungen, Meetings, Mehrsprecher-Konversationen). Liefert Streaming-Ergebnisse mit Timing pro Token, Konfidenzwerten und einer results-AsyncSequence, die die App über for try await konsumiert. Jedes Ergebnis hat ein isFinal-Flag, das volatile vorläufige Hypothesen von finalisiertem Text trennt.

DictationTranscriber. Das Drop-in-Äquivalent für den älteren Anwendungsfall von SFSpeechRecognizer: Transkription kurzer Äußerungen mit demselben On-Device-Modell, das auch SFSpeechRecognizer verwendet. Apps, die für kurze Anfragen von SFSpeechRecognizer migrieren, greifen zu DictationTranscriber; Apps, die das Framework für Langform-Aufnahmen einsetzen, greifen zu SpeechTranscriber. Die Aufteilung ist relevant, da SpeechTranscriber und DictationTranscriber unterschiedliche Sprachabdeckungen und unterschiedliche Modellpfade verwenden.

SpeechDetector. Voice Activity Detection. Meldet Ereignisse, wenn Sprache im Audiostream beginnt und endet. Der Detektor kann nicht allein laufen; er muss mit einem der Transcriber-Module in derselben SpeechAnalyzer-Instanz gekoppelt werden. Apps nutzen ihn, um die Transkriptionsberechnung zu steuern (keine Transkription von Stille) oder um UI-Affordanzen zu treiben (Indikatoren wie „jetzt sprechen”).

Die modulare Architektur ist die strukturelle Verbesserung gegenüber SFSpeechRecognizer. Die alte API kombiniert Audiositzungsverwaltung, Spracherkennung und Transkription in einem einzigen Objekt; die neue API trennt die Belange, sodass Apps die Module komponieren, die sie benötigen.

Was das neue Modell bringt

Das Transkriptionsmodell hinter SpeechTranscriber ist ein neues On-Device-Modell, das Apple speziell für dieses Framework entwickelt hat⁴. Die Verbesserungen, die Apple auf der WWDC 2025 hervorhebt:

Qualität bei Langform-Audio. Das Modell ist auf nachhaltige Transkription über Minuten oder Stunden trainiert, nicht nur auf kurze Anfragen. Vorlesungen, Podcasts, Mehrsprecher-Meetings und Diktiersitzungen werden mit einer Genauigkeit transkribiert, die Apple gegenüber Whisper-Klasse-Modellen positioniert. Der unabhängige Test von MacStories ermittelte bei vergleichbaren Transkriptionsaufgaben rund 2,2× schnellere Ergebnisse als der Large-V3-Turbo-Build von MacWhisper³.

Verarbeitung von entferntem Audio. Mikrofone, die quer durch einen Raum platziert sind, Konferenztisch-Audio mit mehreren Sprechern, Audio mit Umgebungsgeräuschen. Das Modell ist für diese Bedingungen trainiert; das ältere Modell von SFSpeechRecognizer geht weniger elegant damit um.

Echtzeitbetrieb mit geringer Latenz. Die Streaming-Ergebnisse von SpeechTranscriber treffen schneller ein als die Callbacks von SFSpeechRecognitionTask.shouldReportPartialResults des alten Frameworks. Apps, die Live-Transkription anzeigen (Captioning, sprachgesteuerte UIs, Diktat), erhalten flüssigere Updates.

Automatische Sprachverwaltung. SpeechTranscriber(locale:) akzeptiert eine Start-Locale, doch das Modell kann sich an Sprachwechsel mitten im Stream anpassen. Das alte Framework verlangt vom Entwickler, sprachspezifische Recognizer zu instanziieren und zwischen ihnen zu wechseln.

Kein App-Größen-Aufschlag. Das Modell wird mit dem Betriebssystem ausgeliefert, nicht mit der App. Apps, die SpeechAnalyzer adoptieren, bündeln keine zusätzlichen Modellgewichte. Der Kontrast zum Ausliefern eines Whisper-Klasse-Modells im App-Bundle ist erheblich: Ein konkurrenzfähiger On-Device-Transkriptionsstack kostet null Bundle-Bytes.

Was das alte Framework noch bietet

SFSpeechRecognizer wird in iOS 26 weiterhin ausgeliefert und funktioniert. Drei Gründe, warum eine App es weiter verwenden könnte:

Custom Vocabulary. SFSpeechRecognitionRequest.contextualStrings erlaubt es der App, eine Liste bekannter Schlüsselwörter zu registrieren (Eigennamen, Fachbegriffe, Produktnamen), die das Modell mit höherer Wahrscheinlichkeit korrekt erkennt. Die Funktion verbessert die Genauigkeit für domänenspezifische Apps erheblich (medizinisches Diktat mit Medikamentennamen, Rechts-Apps mit Fallzitaten, Engineering-Apps mit Teilenummern). SpeechAnalyzer bietet Custom Vocabulary noch nicht; für Apps, die auf diese Funktion angewiesen sind, wäre eine Migration eine Regression bei der Genauigkeit.

Unterstützung älterer Betriebssysteme. SFSpeechRecognizer ist ab iOS 10 verfügbar; SpeechAnalyzer setzt iOS 26+ voraus. Apps, die iOS 18 und früher anvisieren, benötigen das Legacy-Framework.

Bestehende, funktionierende Integration. Apps mit stabilen, geprüften, performanten SFSpeechRecognizer-Integrationen haben keinen dringenden Grund zur Migration. Die Verbesserungen des neuen Frameworks zählen am meisten für neue Anwendungsfälle (Langform-Transkription, entferntes Audio, Mehrsprecher-Konversationen); Apps, die kurze Sprachanfragen über die Legacy-API verarbeiten, gewinnen womöglich nicht genug, um die Migration zu rechtfertigen.

Wann migrieren

Drei nennenswerte Migrationsauslöser:

Die App verarbeitet Langform-Audio. Ein Meeting-Recorder, eine App zur Vorlesungstranskription, ein Podcast-zu-Text-Werkzeug. Das Training des neuen Modells auf nachhaltigem Audio ist die richtige Passform; das alte Modell verschlechtert sich über lange Sitzungen. Zuerst migrieren.

Die App benötigt entferntes oder verrauschtes Audio. Konferenzraum-Transkription, Interviewaufnahmen mit einem einzelnen entfernten Mikrofon, in Umgebungen mit Hintergrundgeräuschen aufgenommenes Audio. Das neue Modell bewältigt diese Bedingungen merklich besser.

Die App zeigt eine Live-Transkriptions-UI an. Caption-Overlays, Diktatschnittstellen, sprachgesteuerte Hilfs-UIs. Die geringere Latenz der Streaming-Ergebnisse von SpeechTranscriber lässt die UI reaktionsfreudiger wirken.

Fälle, die nicht zwingend eine Migration rechtfertigen:

• Kurze Sprachanfragen mit Custom Vocabulary (Rezeptdiktat, juristische Terminologie). Behalten Sie SFSpeechRecognizer für die Vokabular-Funktion bei; greifen Sie zu SpeechAnalyzer, falls Apple in einer zukünftigen Version Vokabular-Unterstützung ergänzt.
• Apps, die iOS 18 und früher unterstützen müssen. SpeechAnalyzer ist ausschließlich iOS 26; die Codebasis benötigt das Legacy-Framework für ältere Targets ohnehin.

Das Side-by-Side-Muster

Für Apps, die sowohl ältere OS-Versionen anvisieren als auch die Qualität des neuen Frameworks auf iOS 26+ wünschen, ist das Side-by-Side-Muster der richtige Ansatz:

import Speech

if #available(iOS 26.0, *) {
    let transcriber = DictationTranscriber(locale: .current)
    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 ist die richtige Wahl für den iOS-26+-Zweig, da das Migrationsziel der SFSpeechRecognizer-Anwendungsfall ist (kurze Anfragen mit demselben Diktatmodell). Apps, die Langform-Audio anvisieren, tauschen DictationTranscriber im iOS-26-Zweig gegen SpeechTranscriber.

Die beiden Frameworks koexistieren; die Laufzeitprüfung wählt das richtige basierend auf der Verfügbarkeit. Keines blockiert das andere; die Transkriptions-Pipeline der App passt sich an.

Datenschutz und die Speech-Autorisierungsoberfläche

Beide Frameworks teilen sich dieselbe Speech-Framework-Berechtigung (NSSpeechRecognitionUsageDescription in der Info.plist) und denselben benutzerseitigen Autorisierungsfluss⁵. Die Datenschutzgeschichte ist dieselbe: Sprachtranskription geschieht bei beiden Frameworks auf dem Gerät. SpeechAnalyzer ist von Grund auf nur On-Device; SFSpeechRecognizer arbeitet standardmäßig auf dem Gerät, wenn das Flag requiresOnDeviceRecognition der Anfrage am SFSpeechRecognitionRequest selbst auf true gesetzt ist, andernfalls kann es auf einen serverseitigen Pfad zurückfallen.

Die Implikation: Apps, die SpeechAnalyzer verwenden, sollten die Speech-Autorisierung dennoch korrekt handhaben. Der Benutzerprompt, der Eintrag in den Einstellungen und das Privacy Nutrition Label im App Store nutzen alle denselben Autorisierungsmechanismus.

Für Apps, die Mikrofon-Audio zum Analyzer streamen, gilt die Standardkonfiguration von AVAudioSession. Der Beitrag des Clusters zum Privacy Manifest behandelt die Manifest-Einträge für Speech-nutzende Apps; beide Frameworks fallen unter dieselben Datenschutzdeklarationen.

Die Verbindung zum Agent-Workflow

Das On-Device-Modell und die strukturierte Ausgabe von SpeechAnalyzer lassen sich sauber mit zwei Cluster-Mustern paaren:

Foundation Models für In-App-Reasoning. Eine Pipeline, die Audio mit SpeechTranscriber transkribiert und das Transkript anschließend mit dem On-Device-LLM zusammenfasst (behandelt in Foundation Models On-Device LLM), läuft vollständig auf dem Gerät. Gesamtanzahl Netzwerkaufrufe: null. Gesamte Datenexposition gegenüber Dritten: null.

App Intents für sprachgesteuerte Aktionen. Ein AppIntent, das ein Transkript als Eingabe entgegennimmt, kann über Vocal Shortcuts (behandelt in Accessibility als Plattform) oder über die Aktionsoberfläche von Apple Intelligence aufgerufen werden. Die perform-Methode des Intents führt SpeechAnalyzer aus, um die Eingabe zu transkribieren, und leitet dann an die Logik der App weiter. Der gesamte Ablauf ist privat und lokal.

Das Muster: Das neue Speech-Framework vervollständigt das On-Device-Wahrnehmungsdreieck (Vision für Bilder, Foundation Models für Sprach-Reasoning, Speech für Audio), das vollständig lokale KI-Funktionen für iOS-Apps praktikabel macht.

Was dieses Muster für iOS-26+-Apps bedeutet

Drei Erkenntnisse.

1. Standardmäßig SpeechAnalyzer für neuen Code wählen. Das moderne Modell, die modulare Architektur und die verbesserte Leistung bei Langform / entferntem Audio / Live machen es zum richtigen Ausgangspunkt. Das Legacy-Framework ist die Rückfalloption, wenn Unterstützung älterer Betriebssysteme oder Custom Vocabulary erforderlich ist.

2. SFSpeechRecognizer für vokabularabhängige Apps beibehalten. Bis Apple Custom Vocabulary im neuen Framework ergänzt, behalten Apps, die für Genauigkeit bei domänenspezifischen Begriffen auf contextualStrings angewiesen sind, die alte API. Die beiden Frameworks koexistieren; das feature-weise Mischen ist das richtige Muster.

3. Die On-Device-Datenschutzgeschichte erstreckt sich von Vision auf Speech. Apps, die rund um Visions On-Device-CV gebaut wurden, haben nun das Äquivalent für Audio. Kombiniert mit Foundation Models für Reasoning kann die vollständige Pipeline von Wahrnehmung zu Sprache lokal laufen, ohne Datenexposition gegenüber Dritten.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung zwischen Laufzeit und Tooling-LLM; drei Oberflächen; das Single-Source-of-Truth-Muster; zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; der watchOS-Laufzeitvertrag; SwiftUI-Interna; RealityKits räumliches Mentalmodell; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattform-Matrix; Vision Framework; Symbol Effects; Core-ML-Inferenz; Writing Tools API; Swift Testing; Privacy Manifest; Accessibility als Plattform; SF-Pro-Typografie; visionOS-Raummuster; worüber ich nicht schreiben werde. Der Hub liegt unter der Apple Ecosystem Series. Für breiteren Kontext zu iOS mit KI-Agenten siehe den iOS Agent Development Guide.

FAQ

Ist SFSpeechRecognizer veraltet?

Apple hat SFSpeechRecognizer nicht formell als veraltet gekennzeichnet. Es wird weiterhin in iOS 26 ausgeliefert und bleibt unterstützt. Die Positionierung auf der WWDC 2025 lautet, dass SpeechAnalyzer der moderne, empfohlene Weg für neuen Code ist; das Legacy-Framework ist das richtige Werkzeug für spezifische Fälle (Custom Vocabulary, Unterstützung älterer Betriebssysteme).

Kann ich SpeechAnalyzer mit zuvor aufgenommenen Audiodateien verwenden?

Ja. SpeechAnalyzer.start(inputSequence:) akzeptiert eine AsyncSequence von Audio-Puffern. Apps verpacken jede beliebige Audioquelle (Mikrofon via AVAudioEngine, URLs zuvor aufgenommener Dateien, AVAsset-Instanzen) in einen AsyncSequence-Adapter und speisen diesen in den Analyzer ein. Der Transkriptionsstream erzeugt unabhängig von der Eingangsquelle dieselbe Konsumform for try await result in transcriber.results.

Was passiert mit Custom Vocabulary, wenn ich migriere?

Custom Vocabulary wird derzeit von SpeechAnalyzer / SpeechTranscriber nicht unterstützt. Apps, die zur domänenspezifischen Genauigkeit darauf angewiesen sind, sollten diesen Pfad nicht migrieren, bis Apple die Funktion ergänzt. Ein hybrider Ansatz (Verwendung von SpeechAnalyzer für die allgemeine Transkription und SFSpeechRecognizer mit contextualStrings für vokabularsensitive Transkription) funktioniert in iOS 26.

Kann ich SpeechAnalyzer serverseitig betreiben?

Nein. SpeechAnalyzer ist ein ausschließlich On-Device-Framework. Es hat keinen serverseitigen Pfad. Für serverseitige Transkription sind Cloud-APIs (OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) oder selbst gehostete Modelle die richtigen Werkzeuge. Der Wert des Apple-Frameworks liegt gerade in der On-Device-Privatsphäre und der Geschichte ohne Kosten pro Aufruf.

Wie funktioniert die Spracherkennung?

SpeechTranscriber(locale:) akzeptiert eine initiale Locale. Das Modell kann sich automatisch an Sprachwechsel mitten im Stream anpassen. Für Apps, bei denen die Sprache von Anfang an bekannt ist (Diktatfunktion einer lokalisierten App), geben Sie sie explizit an. Für mehrsprachige Kontexte (ein Meeting-Transcriber, in dem Sprecher die Sprache wechseln können) ist die automatische Verwaltung das richtige Verhalten.

Wo passt das zu den anderen On-Device-ML-Beiträgen des Clusters?

SpeechAnalyzer ist die dritte Säule des On-Device-Wahrnehmungsstacks: Vision (behandelt in Vision Framework) verarbeitet Bilder, Speech verarbeitet Audio, und Core ML (behandelt in Core ML On-Device-Inferenz) ist die Engine darunter. Foundation Models (behandelt in Foundation Models On-Device LLM) übernimmt das Sprach-Reasoning. Zusammen bilden sie eine vollständige On-Device-KI-Pipeline, die keine Netzwerkaufrufe erfordert.

References