Nowy framework Speech od Apple: SpeechAnalyzer kontra SFSpeechRecognizer

iOS 26 wprowadza nowy framework rozpoznawania mowy obok dotychczasowego SFSpeechRecognizer. Nową powierzchnię API tworzy SpeechAnalyzer wraz z modułami (SpeechTranscriber, SpeechDetector), które komponuje się wokół niego¹. Sam Apple przedstawia SpeechAnalyzer jako drogę nowoczesną: nowy model działający na urządzeniu, obsługa długich nagrań, automatyczne zarządzanie językami, niskie opóźnienia w zastosowaniach czasu rzeczywistego oraz modularna architektura, którą z czasem można rozszerzać o kolejne rodzaje analizy. SFSpeechRecognizer nadal jest dostarczany i działa; za pozostaniem przy nim przemawiają wsparcie starszych systemów oraz jedna węższa luka — własne słownictwo w długoformatowym modelu SpeechTranscriber nowego frameworka, ponieważ krótkoformatowa ścieżka DictationTranscriber przyjmuje contextual strings bez przeszkód.

Ten wpis zestawia nowy framework ze starym. Ramą jest pytanie „kiedy migrować”, a nie „jak używać nowego API”, ponieważ każdy zespół z działającą integracją SFSpeechRecognizer staje przed tą samą decyzją: czy nowoczesny model i architektura nowego frameworka są warte kosztu migracji, czy też dotychczasowe inwestycje we własne słownictwo uzasadniają pozostanie przy starym rozwiązaniu?

W skrócie

• SpeechAnalyzer (iOS 26+) to nowoczesny framework rozpoznawania mowy na urządzeniu od Apple. Koordynuje moduły analizy konfigurowane przy inicjalizacji; iOS 26 dostarcza trzy z nich: SpeechTranscriber (długie nagrania), DictationTranscriber (krótkie wypowiedzi, odpowiednik SFSpeechRecognizer) oraz SpeechDetector (wykrywanie aktywności głosowej, wymaga sparowania z transkrybentem)².
• Nowy framework zbudowano wokół długich nagrań: wykładów, spotkań, rozmów z wieloma mówcami. Działa w całości na urządzeniu, samodzielnie obsługuje zasoby modelu dla poszczególnych języków i przynosi nowy, autorski model Apple, który według doniesień jest 2× szybszy od Whisper Large V3 Turbo przy równoważnych zadaniach transkrypcji³.
• SFSpeechRecognizer nadal jest dostarczany i działa — a własne słownictwo przestało być jego wyłączną domeną. AnalysisContext.contextualStrings z nowego frameworka (ustawiany przez SpeechAnalyzer.setContext(_:)) rejestruje do 100 fraz specyficznych dla danej dziedziny na potrzeby ścieżki DictationTranscriber⁶. Pozostająca luka dotyczy długoformatowego modelu SpeechTranscriber, który contextual strings nie przyjmuje.
• Migracja przebiega funkcja po funkcji, nie na zasadzie wszystko albo nic. Aplikacje, które potrzebują transkrypcji długich nagrań, niższych opóźnień lub lepszej jakości przy dźwięku z oddali, przechodzą na SpeechAnalyzer. Aplikacje z inwestycjami we własne słownictwo mogą przenieść krótkie dyktowanie na DictationTranscriber wraz z contextual strings; jedynie transkrypcja długich nagrań z własnym słownictwem wciąż przemawia za starym API.
• Wpis o frameworku Vision z tego samego zbioru omawia drugi prymityw percepcji na urządzeniu od Apple; SpeechAnalyzer rozszerza ten sam lokalny wzorzec bez chmury na dźwięk.

Architektura: analizator i moduły

SpeechAnalyzer sam w sobie nie transkrybuje. Jest koordynatorem, który prowadzi sesję analizy dźwięku i rozsyła bufor audio do jednego lub wielu modułów². Moduły konfiguruje się przy inicjalizacji za pomocą inicjalizatora init(modules:), a analiza rusza po podaniu sekwencji AsyncSequence wartości AnalyzerInput — każda opakowuje bufor audio — przez 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)
    }
}

W iOS 26 dostarczono trzy moduły:

SpeechTranscriber. Moduł zamiany mowy na tekst zaprojektowany do długich nagrań (wykładów, spotkań, rozmów z wieloma mówcami). Zwraca wyniki strumieniowe wraz z czasem dla każdego tokenu, ocenami pewności oraz sekwencją results typu AsyncSequence, którą aplikacja konsumuje przez for try await. Każdy wynik niesie flagę isFinal, oddzielającą ulotne hipotezy cząstkowe od tekstu ostatecznego.

DictationTranscriber. Bezpośredni odpowiednik dawnego zastosowania SFSpeechRecognizer: transkrypcja krótkich wypowiedzi z użyciem tego samego modelu na urządzeniu, z którego korzysta SFSpeechRecognizer. Aplikacje migrujące z SFSpeechRecognizer w przypadku krótkich zapytań sięgają po DictationTranscriber; aplikacje wdrażające framework do długich nagrań sięgają po SpeechTranscriber. Ten podział ma znaczenie, ponieważ SpeechTranscriber i DictationTranscriber korzystają z odmiennego pokrycia językowego i odmiennych ścieżek modelu.

SpeechDetector. Wykrywanie aktywności głosowej. Zgłasza zdarzenia rozpoczęcia i zakończenia mowy w strumieniu audio. Detektor nie działa samodzielnie; trzeba go sparować z jednym z modułów transkrypcji w tej samej instancji SpeechAnalyzer. Aplikacje używają go, aby ograniczyć obliczenia transkrypcji (nie ma sensu transkrybować ciszy) albo aby sterować elementami interfejsu (wskaźnikami „mów teraz”).

Modularna architektura stanowi strukturalną poprawę względem SFSpeechRecognizer. Stare API skupia konfigurację, obsługę bufora i dostarczanie wyników w parze recognizer–request, a przy tym polegało na włączeniu języków przez użytkownika w ustawieniach; nowe API oddziela koordynatora sesji od modułów analizy, dzięki czemu aplikacja komponuje dokładnie to, czego potrzebuje.

Co wnosi nowy model

Model transkrypcji stojący za SpeechTranscriber to nowy model działający na urządzeniu, opracowany przez Apple specjalnie dla tego frameworka⁴. Usprawnienia, które Apple wyeksponowało na WWDC 2025:

Jakość przy długich nagraniach. Model wytrenowano pod kątem ciągłej transkrypcji trwającej minuty lub godziny, a nie wyłącznie krótkich zapytań. Wykłady, podcasty, spotkania z wieloma mówcami i sesje dyktowania są transkrybowane z dokładnością, którą Apple zestawia z modelami klasy Whisper. Niezależny test serwisu MacStories wykazał prędkość około 2,2× wyższą niż w wersji Large V3 Turbo używanej przez MacWhisper przy równoważnych zadaniach transkrypcji³.

Radzenie sobie z dźwiękiem z oddali. Mikrofony rozstawione po pokoju, dźwięk ze stołu konferencyjnego z wieloma mówcami, nagrania z hałasem otoczenia. Model wytrenowano pod takie warunki; starszy model z SFSpeechRecognizer radzi sobie z nimi mniej elegancko.

Praca w czasie rzeczywistym z niskim opóźnieniem. Strumieniowe wyniki z SpeechTranscriber napływają szybciej niż wywołania zwrotne SFSpeechRecognitionRequest.shouldReportPartialResults ze starego frameworka. Aplikacje pokazujące transkrypcję na żywo (napisy, interfejsy sterowane głosem, dyktowanie) otrzymują płynniejsze aktualizacje.

Automatyczne zarządzanie językami. Sformułowanie Apple (moja parafraza, nie ich termin) odnosi się do zarządzania modelami i zasobami, a nie do przełączania języka w trakcie strumienia. System pobiera i instaluje właściwe zasoby modelu dla danego języka przez AssetInventory, więc aplikacje przestają ręcznie pilnować dostępności modeli dla poszczególnych języków. Instancja transkrybenta wciąż obsługuje jeden język naraz — tak samo jak w starym frameworku — ale logistyka zasobów, która czyniła wielojęzyczność uciążliwą, spoczywa teraz na systemie.

Brak kosztu w rozmiarze aplikacji. Model przychodzi z systemem, a nie z aplikacją. Aplikacje wdrażające SpeechAnalyzer nie dołączają dodatkowych wag modelu. Kontrast z dostarczaniem modelu klasy Whisper w pakiecie aplikacji jest znaczący: konkurencyjny lokalny stos transkrypcji kosztuje zero bajtów pakietu.

Co nadal oferuje stary framework

SFSpeechRecognizer nadal jest dostarczany i działa w iOS 26. Są trzy powody, dla których aplikacja mogłaby przy nim pozostać:

Własne słownictwo przy długich nagraniach. SFSpeechRecognitionRequest.contextualStrings pozwala aplikacji zarejestrować listę znanych słów kluczowych (nazw własnych, terminów technicznych, nazw produktów), które model rozpozna poprawnie z większym prawdopodobieństwem. Funkcja istotnie podnosi dokładność w aplikacjach dziedzinowych (dyktowanie medyczne z nazwami leków, aplikacje prawnicze z sygnaturami spraw, aplikacje inżynierskie z numerami części). Nowy framework ma własną odmianę tego mechanizmu na ścieżce dyktowania: AnalysisContext.contextualStrings przyjmuje do 100 fraz pogrupowanych tagami, ustawia się go na analizatorze przez SpeechAnalyzer.setContext(_:), a zarejestrowane tam frazy dają się rozpoznać nawet wtedy, gdy brakuje ich w słowniku systemowym⁶. DictationTranscriber przyjmuje dodatkowo własną konfigurację modelu językowego przez wskazówkę treści ContentHint.customizedLanguage(modelConfiguration:)⁷. Odpowiednika wciąż nie mają contextual strings w długoformatowym modelu SpeechTranscriber — aplikacja, która potrzebuje własnego słownictwa przy transkrypcji długich nagrań, na migracji tej ścieżki by straciła.

Wsparcie starszych systemów. SFSpeechRecognizer jest dostępny od iOS 10; SpeechAnalyzer wymaga iOS 26 lub nowszego. Aplikacje celujące w iOS 18 i wcześniejsze potrzebują starego frameworka.

Istniejąca integracja, która działa. Aplikacje ze stabilnymi, zaudytowanymi i wydajnymi integracjami SFSpeechRecognizer nie mają pilnego powodu do migracji. Usprawnienia nowego frameworka liczą się przede wszystkim w nowych zastosowaniach (transkrypcja długich nagrań, dźwięk z oddali, rozmowy z wieloma mówcami); aplikacje obsługujące krótkie zapytania głosowe przez stare API mogą nie zyskać dość, by uzasadnić migrację.

Kiedy migrować

Warto nazwać trzy sygnały przemawiające za migracją:

Aplikacja przetwarza długie nagrania. Rejestrator spotkań, aplikacja do transkrypcji wykładów, narzędzie zamieniające podcast w tekst. Wytrenowanie nowego modelu na ciągłym dźwięku pasuje tu idealnie; stary model traci jakość w trakcie długich sesji. Tę ścieżkę należy migrować w pierwszej kolejności.

Aplikacja potrzebuje dźwięku z oddali lub zaszumionego. Transkrypcja w sali konferencyjnej, nagrywanie wywiadów pojedynczym oddalonym mikrofonem, dźwięk rejestrowany w otoczeniu z hałasem tła. Z takimi warunkami nowy model radzi sobie zauważalnie lepiej.

Aplikacja pokazuje interfejs transkrypcji na żywo. Nakładki z napisami, interfejsy dyktowania, wspomagające interfejsy sterowane głosem. Niższe opóźnienie strumieniowych wyników z SpeechTranscriber sprawia, że interfejs sprawia wrażenie bardziej responsywnego.

Przypadki, które niekoniecznie uzasadniają migrację:

• Transkrypcja długich nagrań zależna od własnego słownictwa (rejestrator spotkań, który musi wyłapać nazwy leków albo sygnatury spraw). Długoformatowy model SpeechTranscriber nie przyjmuje contextual strings, więc to połączenie pozostaje przy SFSpeechRecognizer, dopóki Apple nie zamknie luki. Krótkie zapytania głosowe z własnym słownictwem migrują bez problemu — pokrywa je DictationTranscriber wraz z AnalysisContext.contextualStrings⁶.
• Aplikacje, które muszą wspierać iOS 18 i wcześniejsze. SpeechAnalyzer istnieje wyłącznie w iOS 26; baza kodu i tak będzie potrzebowała starego frameworka dla starszych celów.

Wzorzec równoległy

W aplikacjach, które celują zarówno w starsze wersje systemu, jak i w jakość nowego frameworka na iOS 26+, właściwym podejściem jest wzorzec równoległy:

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 jest właściwym wyborem dla gałęzi iOS 26+, ponieważ celem migracji jest zastosowanie znane z SFSpeechRecognizer (krótkie zapytania z tym samym modelem dyktowania). Aplikacje nastawione na długie nagrania podmieniają w gałęzi iOS 26 DictationTranscriber na SpeechTranscriber.

Oba frameworki współistnieją; sprawdzenie w czasie działania wybiera właściwy na podstawie dostępności. Żaden nie blokuje drugiego; potok transkrypcji aplikacji dostosowuje się sam.

Prywatność i warstwa uprawnień do rozpoznawania mowy

Oba frameworki różnią się na warstwie uprawnień. SFSpeechRecognizer zachowuje własne uprawnienie do rozpoznawania mowy: NSSpeechRecognitionUsageDescription w pliku Info.plist oraz monit SFSpeechRecognizer.requestAuthorization(_:)⁵. SpeechAnalyzer z tej warstwy nie korzysta — aplikacja transkrybująca za jego pomocą dźwięk na żywo potrzebuje uprawnienia do mikrofonu (NSMicrophoneUsageDescription), a do transkrypcji dźwięku, który już posiada, niczego więcej. Pod względem prywatności oba działają lokalnie: SpeechAnalyzer z założenia pracuje wyłącznie na urządzeniu; SFSpeechRecognizer pracuje lokalnie wtedy, gdy flagę requiresOnDeviceRecognition ustawi się na true bezpośrednio na obiekcie SFSpeechRecognitionRequest — jest to wymagane, a nie domyślne — w przeciwnym razie może pójść ścieżką serwerową.

Wniosek dla wzorca równoległego: aplikacja korzystająca z obu frameworków niesie obie powierzchnie uprawnień — monit o mikrofon dla gałęzi SpeechAnalyzer oraz uprawnienie do rozpoznawania mowy dla gałęzi starszej — a etykieta prywatności w App Store powinna odzwierciedlać jedno i drugie.

W aplikacjach przesyłających dźwięk z mikrofonu do analizatora obowiązuje standardowa konfiguracja AVAudioSession. Wpis o Privacy Manifest z tego zbioru omawia wpisy manifestu dla aplikacji korzystających z frameworka Speech; oba frameworki podlegają tym samym deklaracjom prywatności.

Powiązanie z workflow agentowym

Lokalny model i ustrukturyzowane wyjście SpeechAnalyzer zgrabnie łączą się z dwoma wzorcami z tego zbioru:

Foundation Models do wnioskowania wewnątrz aplikacji. Potok, który transkrybuje dźwięk przez SpeechTranscriber, a następnie streszcza transkrypcję lokalnym modelem LLM (opisanym we wpisie Foundation Models: lokalny LLM), działa w całości na urządzeniu. Łączna liczba połączeń sieciowych: zero. Łączna ekspozycja danych na podmioty trzecie: zero.

App Intents do działań sterowanych głosem. Intencję AppIntent, która przyjmuje transkrypcję jako wejście, można wywołać przez Vocal Shortcuts (opisane we wpisie Dostępność jako platforma) albo przez warstwę akcji Apple Intelligence. Metoda perform intencji uruchamia SpeechAnalyzer, aby przepisać wejście, a potem przekazuje sterowanie logice aplikacji. Cały przepływ pozostaje prywatny i lokalny.

Wzorzec wygląda tak: nowy framework Speech domyka trójkąt lokalnej percepcji (Vision dla obrazów, Foundation Models dla rozumowania językowego, Speech dla dźwięku), który czyni w pełni lokalne funkcje AI praktycznymi w aplikacjach na iOS.

Co ten wzorzec oznacza dla aplikacji na iOS 26+

Trzy wnioski.

1. W nowym kodzie domyślnie SpeechAnalyzer. Nowoczesny model, modularna architektura i lepsze wyniki przy długim nagraniu, dźwięku z oddali oraz pracy na żywo czynią z niego właściwy punkt wyjścia. Stary framework pozostaje rozwiązaniem awaryjnym, gdy wymagane jest wsparcie starszych systemów albo własne słownictwo przy transkrypcji długich nagrań.

2. Aplikacje zależne od słownictwa dzielą się według długości nagrania. Krótkie dyktowanie z własnym słownictwem migruje: DictationTranscriber wraz z AnalysisContext.contextualStrings unosi terminy dziedzinowe⁶. Transkrypcja długich nagrań z własnym słownictwem zostaje przy SFSpeechRecognizer, dopóki model SpeechTranscriber nie zacznie przyjmować contextual strings. Oba frameworki współistnieją; mieszanie ich funkcja po funkcji to właściwy wzorzec.

3. Opowieść o lokalnej prywatności rozciąga się z Vision na Speech. Aplikacje zbudowane wokół lokalnego przetwarzania obrazu z Vision mają teraz odpowiednik dla dźwięku. W połączeniu z Foundation Models do wnioskowania cały łańcuch od percepcji do języka może działać lokalnie, bez ujawniania danych podmiotom trzecim.

Pełny zbiór Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie między LLM czasu działania a LLM narzędziowym; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; dwa serwery MCP; hooki w rozwoju na platformy Apple; Live Activities; kontrakt środowiska uruchomieniowego watchOS; wnętrzności SwiftUI; przestrzenny model myślowy RealityKit; dyscyplina schematu w SwiftData; wzorce Liquid Glass; wydawanie aplikacji na wiele platform; macierz platform; framework Vision; Symbol Effects; wnioskowanie z Core ML; API Writing Tools; Swift Testing; Privacy Manifest; dostępność jako platforma; typografia SF Pro; przestrzenne wzorce visionOS; o czym odmawiam pisać. Węzeł całości znajduje się w serii Apple Ecosystem. Szerszy kontekst iOS i agentów AI opisuje przewodnik po tworzeniu agentów na iOS.

Często zadawane pytania

Czy SFSpeechRecognizer jest przestarzały?

Apple formalnie nie oznaczyło SFSpeechRecognizer jako przestarzałego. Nadal jest dostarczany w iOS 26 i pozostaje wspierany. Przekaz z WWDC 2025 brzmi tak, że SpeechAnalyzer stanowi nowoczesną, zalecaną drogę dla nowego kodu; stary framework pozostaje właściwym narzędziem w konkretnych przypadkach (własne słownictwo przy transkrypcji długich nagrań, wsparcie starszych systemów).

Czy mogę użyć SpeechAnalyzer z wcześniej nagranymi plikami audio?

Tak. SpeechAnalyzer.start(inputSequence:) przyjmuje sekwencję AsyncSequence wartości AnalyzerInput, z których każda opakowuje bufor audio. Aplikacje opakowują dowolne źródło dźwięku (mikrofon przez AVAudioEngine, adresy URL wcześniej nagranych plików, instancje AVAsset) w adapter AsyncSequence i podają je analizatorowi. Strumień transkrypcji konsumuje się tak samo, przez for try await result in transcriber.results, niezależnie od źródła wejścia.

Co stanie się z własnym słownictwem po migracji?

Zależy to od tego, na którym transkrybencie migracja wyląduje. Ścieżka dyktowania je obsługuje: wystarczy zarejestrować do 100 fraz przez AnalysisContext.contextualStrings, ustawić kontekst przez SpeechAnalyzer.setContext(_:), a DictationTranscriber z nich skorzysta⁶. Długoformatowy model SpeechTranscriber nie przyjmuje contextual strings, więc wrażliwa na słownictwo transkrypcja długich nagrań powinna pozostać przy SFSpeechRecognizer z contextualStrings, dopóki Apple nie zamknie tej luki. Podejście hybrydowe (nowy framework do ogólnej transkrypcji, stare API do wrażliwej na słownictwo ścieżki długoformatowej) sprawdza się w iOS 26.

Czy mogę uruchomić SpeechAnalyzer po stronie serwera?

Nie. SpeechAnalyzer to framework działający wyłącznie na urządzeniu. Nie ma ścieżki serwerowej. Do transkrypcji po stronie serwera właściwymi narzędziami są API chmurowe (OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) albo modele hostowane we własnym zakresie. Wartość frameworka Apple polega właśnie na lokalnej prywatności i zerowym koszcie pojedynczego wywołania.

Jak działa wykrywanie języka?

SpeechTranscriber(locale:) przyjmuje jeden język na instancję transkrybenta i nie przewiduje przełączania języka w trakcie strumienia. To, co iOS 26 automatyzuje, dotyczy strony zasobów: AssetInventory pobiera zasoby modelu dla poszczególnych języków i nimi zarządza, więc obsługa kilku języków nie oznacza już ręcznego pilnowania dostępności modeli. Gdy język jest znany z góry (funkcja dyktowania w zlokalizowanej aplikacji), należy wskazać go wprost. W kontekstach wielojęzycznych (transkrybent spotkań, na których mówcy mogą zmieniać język) warto język wykryć albo pozwolić użytkownikowi go wybrać, a następnie utworzyć instancję transkrybenta dla tego języka.

Jak to się ma do pozostałych wpisów zbioru o lokalnym uczeniu maszynowym?

SpeechAnalyzer stanowi trzeci filar lokalnego stosu percepcji: Vision (opisany we wpisie Framework Vision) zajmuje się obrazem, Speech dźwiękiem, a Core ML (opisany we wpisie Lokalne wnioskowanie z Core ML) jest silnikiem pod oboma. Foundation Models (opisane we wpisie Foundation Models: lokalny LLM) odpowiadają za rozumowanie językowe. Razem tworzą kompletny lokalny potok AI, który nie wymaga połączeń sieciowych.

Źródła