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 besteht aus SpeechAnalyzer und den Modulen (SpeechTranscriber, SpeechDetector), die sich darum herum komponieren lassen¹. Apple selbst beschreibt SpeechAnalyzer als den modernen Weg: ein neues On-Device-Modell, Unterstützung für Langform-Audio, automatische Sprachverwaltung, niedrige Latenz für Echtzeitszenarien und eine modulare Architektur, die sich im Laufe der Zeit um weitere Analysearten erweitern lässt. SFSpeechRecognizer wird weiterhin ausgeliefert und funktioniert; für einen Verbleib sprechen die Unterstützung älterer Betriebssystemversionen und eine eng umrissene Lücke – benutzerdefiniertes Vokabular beim Langform-Modell SpeechTranscriber des neuen Frameworks, denn der Kurzform-Pfad über DictationTranscriber nimmt contextual strings sehr wohl entgegen.

Dieser Beitrag stellt das neue Framework dem alten gegenüber. Der Rahmen lautet „wann migrieren?“ statt „wie nutze ich die neue API?“, 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 benutzerdefiniertes Vokabular den Verbleib?

Kurzfassung

• SpeechAnalyzer (ab 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 Gegenstück zu SFSpeechRecognizer) und SpeechDetector (Sprachaktivitätserkennung, muss mit einem Transcriber kombiniert werden)².
• Das neue Framework ist auf Langform-Audio zugeschnitten: Vorlesungen, Besprechungen, Gespräche mit mehreren Sprechern. Es läuft vollständig auf dem Gerät, verwaltet die Modell-Assets pro Sprachregion automatisch und bringt ein neues, proprietäres Apple-Modell mit, das bei vergleichbaren Transkriptionsaufgaben Berichten zufolge 2× schneller arbeitet als Whisper Large V3 Turbo³.
• SFSpeechRecognizer wird weiterhin ausgeliefert und funktioniert – und benutzerdefiniertes Vokabular ist längst nicht mehr allein ihm vorbehalten. AnalysisContext.contextualStrings des neuen Frameworks (gesetzt über SpeechAnalyzer.setContext(_:)) registriert bis zu 100 domänenspezifische Formulierungen für den DictationTranscriber-Pfad⁶. Die verbleibende Lücke ist das Langform-Modell SpeechTranscriber, das keine contextual strings entgegennimmt.
• Migriert wird pro Funktion, nicht nach dem Alles-oder-nichts-Prinzip. Apps, die Langform-Transkription, geringere Latenz oder bessere Qualität bei entfernten Audioquellen brauchen, wechseln zu SpeechAnalyzer. Apps mit Investitionen in benutzerdefiniertes Vokabular können das Kurzform-Diktat über DictationTranscriber plus contextual strings migrieren; nur Langform-Transkription mit benutzerdefiniertem Vokabular spricht noch für die alte API.
• Der Beitrag zum Vision-Framework aus diesem Cluster behandelt Apples anderes geräteinternes Wahrnehmungsprimitiv; SpeechAnalyzer überträgt dasselbe On-Device-Muster ohne Cloud auf Audio.

Die Architektur: Analyzer + Module

SpeechAnalyzer transkribiert nicht selbst. Es ist ein Koordinator, der eine Audioanalyse-Sitzung verwaltet und den Audiopuffer an ein oder mehrere Module weiterreicht². Module werden bei der Initialisierung über den Initializer init(modules:) konfiguriert; die Analyse startet, indem eine AsyncSequence von AnalyzerInput-Werten – jeder umschließt einen Audiopuffer – über start(inputSequence:) eingespeist wird:

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 liefert iOS 26 aus:

SpeechTranscriber. Das Speech-to-Text-Modul für Langform-Audio (Vorlesungen, Besprechungen, Gespräche mit mehreren Sprechern). Es liefert Streaming-Ergebnisse mit Zeitangaben pro Token, Konfidenzwerten und einer results-AsyncSequence, die die App per for try await konsumiert. Jedes Ergebnis trägt ein isFinal-Flag, das flüchtige Teilhypothesen von finalisiertem Text trennt.

DictationTranscriber. Das Drop-in-Gegenstück für den älteren SFSpeechRecognizer-Anwendungsfall: Transkription kurzer Äußerungen mit demselben On-Device-Modell, das SFSpeechRecognizer verwendet. Apps, die kurze Anfragen von SFSpeechRecognizer migrieren, greifen zu DictationTranscriber; Apps, die das Framework für lange Aufnahmen übernehmen, greifen zu SpeechTranscriber. Diese Trennung ist relevant, weil SpeechTranscriber und DictationTranscriber unterschiedliche Sprachabdeckung und unterschiedliche Modellpfade nutzen.

SpeechDetector. Sprachaktivitätserkennung. Meldet Ereignisse, wenn im Audiostrom Sprache beginnt und endet. Der Detektor kann nicht allein laufen; er muss in derselben SpeechAnalyzer-Instanz mit einem der Transcriber-Module kombiniert werden. Apps nutzen ihn, um Rechenaufwand für die Transkription zu sparen (Stille wird nicht transkribiert) oder um Bedienelemente zu steuern („Jetzt sprechen“-Anzeigen).

Die modulare Architektur ist die strukturelle Verbesserung gegenüber SFSpeechRecognizer. Die alte API bündelt Konfiguration, Pufferverarbeitung und Ergebnisauslieferung in einem Paar aus Recognizer und Request und setzte darauf, dass Benutzer Sprachen in den Einstellungen aktivieren; die neue API trennt den Sitzungskoordinator von seinen Analysemodulen, sodass Apps genau das zusammenstellen, was sie brauchen.

Was das neue Modell bringt

Das Transkriptionsmodell hinter SpeechTranscriber ist ein neues On-Device-Modell, das Apple eigens für dieses Framework entwickelt hat⁴. Diese Verbesserungen hebt Apple auf der WWDC 2025 hervor:

Qualität bei Langform-Audio. Das Modell ist auf anhaltende Transkription über Minuten oder Stunden trainiert, nicht nur auf kurze Anfragen. Vorlesungen, Podcasts, Besprechungen mit mehreren Sprechern und Diktiersitzungen werden mit einer Genauigkeit transkribiert, die Apple gegen Modelle der Whisper-Klasse positioniert. Ein unabhängiger Test von MacStories maß bei vergleichbaren Transkriptionsaufgaben rund 2,2× höhere Geschwindigkeit als der Large-V3-Turbo-Build von MacWhisper³.

Umgang mit entfernten Audioquellen. Mikrofone quer durch den Raum, Konferenztisch-Audio mit mehreren Sprechern, Aufnahmen mit Umgebungsgeräuschen. Auf diese Bedingungen ist das Modell trainiert; das ältere Modell von SFSpeechRecognizer kommt damit weniger elegant zurecht.

Echtzeitbetrieb mit niedriger Latenz. Die Streaming-Ergebnisse von SpeechTranscriber treffen schneller ein als die SFSpeechRecognitionRequest.shouldReportPartialResults-Callbacks des alten Frameworks. Apps, die Live-Transkription anzeigen (Untertitel, sprachgesteuerte Oberflächen, Diktat), erhalten flüssigere Aktualisierungen.

Automatische Sprachverwaltung. Apples Formulierung (meine Umschreibung, nicht ihr Begriff) meint Modell- und Asset-Verwaltung, kein Umschalten mitten im Datenstrom. Das Betriebssystem lädt und installiert über AssetInventory die passenden Modell-Assets für eine Sprachregion, sodass Apps die Modellverfügbarkeit pro Sprache nicht mehr von Hand pflegen. Eine Transcriber-Instanz arbeitet weiterhin mit jeweils einer Sprachregion – genau wie im alten Framework –, doch die Asset-Logistik, die Mehrsprachigkeit mühsam machte, übernimmt jetzt das System.

Keine Kosten bei der App-Größe. Das Modell kommt mit dem Betriebssystem, nicht mit der App. Apps, die SpeechAnalyzer übernehmen, bündeln keine zusätzlichen Modellgewichte. Der Kontrast zum Ausliefern eines Modells der Whisper-Klasse im App-Bundle ist erheblich: Ein konkurrenzfähiger geräteinterner Transkriptionsstack kostet null Bundle-Bytes.

Was das alte Framework weiterhin bietet

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

Benutzerdefiniertes Vokabular bei Langform-Audio. Mit SFSpeechRecognitionRequest.contextualStrings registriert die App eine Liste bekannter Schlüsselwörter (Eigennamen, Fachbegriffe, Produktnamen), die das Modell mit höherer Wahrscheinlichkeit korrekt erkennt. Die Funktion verbessert die Genauigkeit domänenspezifischer Apps erheblich (medizinisches Diktat mit Wirkstoffnamen, Jura-Apps mit Fundstellen, Technik-Apps mit Teilenummern). Das neue Framework hat dafür eine eigene Variante auf dem Diktatpfad: AnalysisContext.contextualStrings nimmt bis zu 100 nach Tag gruppierte Formulierungen entgegen, wird über SpeechAnalyzer.setContext(_:) am Analyzer gesetzt, und dort registrierte Formulierungen lassen sich selbst dann erkennen, wenn sie im Systemvokabular fehlen⁶. DictationTranscriber akzeptiert zusätzlich eine eigene Sprachmodell-Konfiguration über den Content-Hint ContentHint.customizedLanguage(modelConfiguration:)⁷. Kein Gegenstück gibt es bislang für contextual strings beim Langform-Modell SpeechTranscriber – eine App, die benutzerdefiniertes Vokabular bei der Langform-Transkription braucht, würde sich mit einer Migration dieses Pfads verschlechtern.

Unterstützung älterer Betriebssysteme. SFSpeechRecognizer ist ab iOS 10 verfügbar; SpeechAnalyzer setzt iOS 26 voraus. Apps, die iOS 18 und älter adressieren, brauchen das alte Framework.

Bestehende Integration, die funktioniert. Apps mit stabilen, geprüften und performanten SFSpeechRecognizer-Integrationen haben keinen dringenden Grund zu migrieren. Die Verbesserungen des neuen Frameworks zählen vor allem für neue Anwendungsfälle (Langform-Transkription, entfernte Audioquellen, Gespräche mit mehreren Sprechern); Apps, die kurze Sprachanfragen über die alte API abwickeln, gewinnen womöglich zu wenig, um den Aufwand zu rechtfertigen.

Wann eine Migration sinnvoll ist

Drei Auslöser für eine Migration verdienen es, benannt zu werden:

Die App verarbeitet Langform-Audio. Ein Besprechungsrekorder, eine App zur Vorlesungstranskription, ein Werkzeug von Podcast zu Text. Das Training des neuen Modells auf anhaltendes Audio passt genau; das alte Modell fällt über lange Sitzungen ab. Hier zuerst migrieren.

Die App braucht entfernte oder verrauschte Audioquellen. Transkription im Konferenzraum, Interviewaufnahmen mit einem einzelnen entfernten Mikrofon, Aufnahmen in Umgebungen mit Hintergrundgeräuschen. Mit diesen Bedingungen kommt das neue Modell merklich besser zurecht.

Die App zeigt eine Oberfläche mit Live-Transkription. Untertitel-Overlays, Diktatoberflächen, sprachgesteuerte assistive Oberflächen. Die geringere Latenz der Streaming-Ergebnisse von SpeechTranscriber lässt die Oberfläche reaktionsfreudiger wirken.

Fälle, die eine Migration nicht zwingend rechtfertigen:

• Langform-Transkription, die auf benutzerdefiniertem Vokabular beruht (ein Besprechungsrekorder, der Wirkstoffnamen oder Fundstellen treffen muss). Das Langform-Modell SpeechTranscriber nimmt keine contextual strings entgegen, deshalb bleibt diese Kombination bei SFSpeechRecognizer, bis Apple die Lücke schließt. Kurze Sprachanfragen mit benutzerdefiniertem Vokabular migrieren sauber – DictationTranscriber plus AnalysisContext.contextualStrings deckt sie ab⁶.
• Apps, die iOS 18 und älter unterstützen müssen. SpeechAnalyzer gibt es nur ab iOS 26; für ältere Ziele braucht die Codebasis ohnehin das alte Framework.

Das Side-by-Side-Muster

Für Apps, die sowohl ältere Betriebssystemversionen adressieren als auch ab iOS 26 die Qualität des neuen Frameworks nutzen wollen, ist das Side-by-Side-Muster der richtige Ansatz:

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 ist für den iOS-26-Zweig die richtige Wahl, weil das Migrationsziel der SFSpeechRecognizer-Anwendungsfall ist (kurze Anfragen mit demselben Diktatmodell). Apps, die auf Langform-Audio zielen, tauschen im iOS-26-Zweig DictationTranscriber gegen SpeechTranscriber.

Die beiden Frameworks koexistieren; die Laufzeitprüfung wählt anhand der Verfügbarkeit das passende aus. Keines blockiert das andere; die Transkriptionspipeline der App passt sich an.

Datenschutz und die Berechtigungsebene für Spracherkennung

Die beiden Frameworks unterscheiden sich auf der Berechtigungsebene. SFSpeechRecognizer behält seine eigene Spracherkennungs-Berechtigung: NSSpeechRecognitionUsageDescription in der Info.plist plus die Abfrage SFSpeechRecognizer.requestAuthorization(_:)⁵. SpeechAnalyzer nutzt diese Ebene nicht – eine App, die damit Live-Audio transkribiert, braucht die Mikrofonberechtigung (NSMicrophoneUsageDescription), und darüber hinaus nichts, um bereits vorhandenes Audio zu transkribieren. Beim Datenschutz gilt für beide dasselbe: Verarbeitung auf dem Gerät. SpeechAnalyzer arbeitet konstruktionsbedingt ausschließlich geräteintern; SFSpeechRecognizer läuft dann auf dem Gerät, wenn das Flag requiresOnDeviceRecognition am SFSpeechRecognitionRequest selbst auf true gesetzt wird – erforderlich, nicht voreingestellt –, andernfalls kann er einen serverseitigen Pfad nehmen.

Was das für das Side-by-Side-Muster bedeutet: Eine App, die beide Frameworks betreibt, trägt beide Berechtigungsflächen – die Mikrofonabfrage für den SpeechAnalyzer-Zweig und die Spracherkennungs-Berechtigung für den alten Zweig – und das Datenschutz-Label im App Store sollte beides abbilden.

Für Apps, die Mikrofon-Audio an den Analyzer streamen, gilt die übliche AVAudioSession-Konfiguration. Der Beitrag zum Privacy Manifest aus diesem Cluster behandelt die Manifest-Einträge für Apps mit Speech-Nutzung; beide Frameworks fallen unter dieselben Datenschutzerklärungen.

Die Verbindung zu Agenten-Workflows

Das On-Device-Modell und die strukturierte Ausgabe von SpeechAnalyzer passen sauber zu zwei Mustern aus dem Cluster:

Foundation Models für Reasoning in der App. Eine Pipeline, die Audio mit SpeechTranscriber transkribiert und das Transkript anschließend mit dem lokalen LLM zusammenfasst (behandelt in Foundation Models: On-Device-LLM), läuft vollständig auf dem Gerät. Netzwerkaufrufe insgesamt: null. Datenweitergabe an Dritte insgesamt: null.

App Intents für sprachgesteuerte Aktionen. Ein AppIntent, der ein Transkript als Eingabe entgegennimmt, lässt sich über Vocal Shortcuts (behandelt in Barrierefreiheit als Plattform) oder über die Aktionsebene von Apple Intelligence aufrufen. Die perform-Methode des Intents lässt SpeechAnalyzer die Eingabe transkribieren und übergibt danach an die Logik der App. Der gesamte Ablauf bleibt privat und lokal.

Das Muster: Das neue Speech-Framework vervollständigt das geräteinterne Wahrnehmungsdreieck (Vision für Bilder, Foundation Models für sprachliches 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. Für neuen Code standardmäßig SpeechAnalyzer. Das moderne Modell, die modulare Architektur und die bessere Leistung bei Langform-, Distanz- und Live-Audio machen es zum richtigen Ausgangspunkt. Das alte Framework ist der Rückfallweg, wenn Unterstützung älterer Betriebssysteme oder benutzerdefiniertes Vokabular bei Langform-Transkription gefordert ist.

2. Vokabularabhängige Apps teilen sich nach Audiolänge auf. Kurzform-Diktat mit benutzerdefiniertem Vokabular migriert: DictationTranscriber plus AnalysisContext.contextualStrings trägt die Fachbegriffe⁶. Langform-Transkription mit benutzerdefiniertem Vokabular bleibt bei SFSpeechRecognizer, bis das Modell SpeechTranscriber contextual strings entgegennimmt. Die beiden Frameworks koexistieren; sie pro Funktion zu mischen, ist das richtige Muster.

3. Der geräteinterne Datenschutz reicht von Vision bis Speech. Apps, die rund um Visions Bildverarbeitung auf dem Gerät gebaut wurden, haben nun das Äquivalent für Audio. Zusammen mit Foundation Models für Reasoning kann die gesamte Kette von Wahrnehmung bis Sprache lokal laufen, ohne Daten an Dritte weiterzugeben.

Der vollständige Cluster „Apple Ecosystem“: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung zwischen Laufzeit- und Werkzeug-LLM; drei Oberflächen; das Muster einer einzigen Wahrheitsquelle; zwei MCP-Server; Hooks für die Apple-Entwicklung; Live Activities; der watchOS-Laufzeitvertrag; SwiftUI-Interna; RealityKits räumliches Denkmodell; SwiftData-Schemadisziplin; Liquid-Glass-Muster; Ausliefern auf mehreren Plattformen; die Plattformmatrix; Vision-Framework; Symbol Effects; Core-ML-Inferenz; Writing Tools API; Swift Testing; Privacy Manifest; Barrierefreiheit als Plattform; SF-Pro-Typografie; räumliche visionOS-Muster; worüber ich nicht schreibe. Der Knotenpunkt liegt bei der Serie Apple Ecosystem. Für den größeren Zusammenhang von iOS und KI-Agenten siehe den Leitfaden zur iOS-Agentenentwicklung.

Häufige Fragen

Ist SFSpeechRecognizer veraltet?

Apple hat SFSpeechRecognizer nicht offiziell als veraltet markiert. Es wird in iOS 26 weiterhin ausgeliefert und bleibt unterstützt. Die Darstellung auf der WWDC 2025 lautet, dass SpeechAnalyzer der moderne, empfohlene Weg für neuen Code ist; das alte Framework ist das richtige Werkzeug für bestimmte Fälle (benutzerdefiniertes Vokabular bei Langform-Transkription, Unterstützung älterer Betriebssysteme).

Kann ich SpeechAnalyzer mit vorab aufgezeichneten Audiodateien verwenden?

Ja. SpeechAnalyzer.start(inputSequence:) akzeptiert eine AsyncSequence von AnalyzerInput-Werten, von denen jeder einen Audiopuffer umschließt. Apps verpacken beliebige Audioquellen (Mikrofon über AVAudioEngine, URLs vorab aufgezeichneter Dateien, AVAsset-Instanzen) in einen AsyncSequence-Adapter und speisen ihn in den Analyzer ein. Der Transkriptionsstrom wird unabhängig von der Eingabequelle über dasselbe for try await result in transcriber.results konsumiert.

Was passiert bei einer Migration mit benutzerdefiniertem Vokabular?

Das hängt davon ab, bei welchem Transcriber die Migration landet. Der Diktatpfad unterstützt es: bis zu 100 Formulierungen über AnalysisContext.contextualStrings registrieren, den Kontext über SpeechAnalyzer.setContext(_:) setzen – und DictationTranscriber verwendet sie⁶. Das Langform-Modell SpeechTranscriber nimmt keine contextual strings entgegen, deshalb sollte vokabularsensible Langform-Transkription mit contextualStrings bei SFSpeechRecognizer bleiben, bis Apple diese Lücke schließt. Ein hybrider Ansatz (neues Framework für allgemeine Transkription, alte API für den vokabularsensiblen Langform-Pfad) funktioniert in iOS 26.

Kann ich SpeechAnalyzer serverseitig betreiben?

Nein. SpeechAnalyzer ist ein Framework, das ausschließlich auf dem Gerät läuft. Einen serverseitigen Pfad gibt es nicht. 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 genau im Datenschutz auf dem Gerät und darin, dass pro Aufruf keine Kosten anfallen.

Wie funktioniert die Erkennung der gesprochenen Sprache?

SpeechTranscriber(locale:) nimmt pro Transcriber-Instanz eine Sprachregion entgegen, und ein Sprachwechsel mitten im Datenstrom ist nicht vorgesehen. Was iOS 26 automatisiert, ist die Asset-Seite: AssetInventory lädt und verwaltet die Modell-Assets pro Sprachregion, sodass Unterstützung mehrerer Sprachen nicht mehr bedeutet, die Modellverfügbarkeit von Hand zu pflegen. Wo die Sprache von vornherein feststeht (die Diktatfunktion einer lokalisierten App), geben Sie sie explizit an. In mehrsprachigen Kontexten (ein Besprechungstranskriptor, bei dem Sprecher wechseln können) erkennen Sie die Sprache oder lassen Benutzer sie wählen und instanziieren dann den Transcriber für diese Sprachregion.

Wie fügt sich das in die anderen Beiträge des Clusters zu geräteinternem ML ein?

SpeechAnalyzer ist die dritte Säule des geräteinternen Wahrnehmungsstapels: Vision (behandelt im Vision-Framework) verarbeitet Bilder, Speech verarbeitet Audio, und Core ML (behandelt in Core ML: Inferenz auf dem Gerät) ist die Maschine unter beiden. Foundation Models (behandelt in Foundation Models: On-Device-LLM) übernimmt das sprachliche Reasoning. Zusammen bilden sie eine vollständige KI-Pipeline auf dem Gerät, die ohne Netzwerkaufrufe auskommt.

Quellen