Nowy framework Speech od Apple: SpeechAnalyzer kontra SFSpeechRecognizer

iOS 26 wprowadza nowy framework rozpoznawania mowy obok istniejącego SFSpeechRecognizer. Nową powierzchnią API jest SpeechAnalyzer wraz z modułami (SpeechTranscriber, SpeechDetector), które komponują się wokół niego¹. Zgodnie z narracją samego Apple, SpeechAnalyzer to nowoczesna ścieżka: nowy model działający na urządzeniu, obsługa długich nagrań audio, automatyczne zarządzanie językami, niskie opóźnienia w zastosowaniach czasu rzeczywistego oraz architektura modułowa, która z czasem pozwala dodawać kolejne typy analizy. SFSpeechRecognizer nadal jest dostępny i działa; pozostaje właściwym narzędziem dla aplikacji, które polegają na funkcji własnego słownika, której nowy framework jeszcze nie oferuje.

Niniejszy wpis omawia nowy framework w zestawieniu ze starym. Punkt widzenia to „kiedy migrować”, a nie „jak korzystać z 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ż istniejące inwestycje w słownik własny uzasadniają pozostanie?

TL;DR

• SpeechAnalyzer (iOS 26+) to nowoczesny framework rozpoznawania mowy działający na urządzeniu od Apple. Koordynuje moduły analityczne konfigurowane podczas inicjalizacji; iOS 26 dostarcza trzy: SpeechTranscriber (długie nagrania), DictationTranscriber (krótkie wypowiedzi, odpowiednik SFSpeechRecognizer) oraz SpeechDetector (wykrywanie aktywności głosu, musi być sparowany z transkrybentem)².
• Nowy framework został zbudowany wokół długich nagrań audio: wykładów, spotkań, rozmów wieloosobowych. Działa w całości na urządzeniu, automatycznie zarządza językami i jest dostarczany z nowym, autorskim modelem Apple, który według doniesień jest 2-krotnie szybszy niż Whisper Large V3 Turbo w równoważnych zadaniach transkrypcji³.
• SFSpeechRecognizer nadal jest dostarczany i działa. Starszy framework zachowuje funkcję Custom Vocabulary (rejestrowanie znanych słów kluczowych dla większej dokładności w terminach branżowych), której nowy framework jeszcze nie oferuje.
• Migracja przebiega per funkcja, nie na zasadzie wszystko-albo-nic. Aplikacje wymagające transkrypcji długich nagrań, niższych opóźnień lub lepszej jakości audio z odległości migrują do SpeechAnalyzer. Aplikacje z inwestycjami w Custom Vocabulary zachowują SFSpeechRecognizer dla tych funkcji i dodają SpeechAnalyzer do nowych.
• Wpis o frameworku Vision z tego klastra omawia inny prymityw percepcji Apple działający na urządzeniu; SpeechAnalyzer rozszerza ten sam wzorzec — działanie na urządzeniu, bez chmury — na audio.

Architektura: Analyzer + Moduły

SpeechAnalyzer sam w sobie nie jest transkrybentem. To koordynator, który zarządza sesją analizy audio i przekazuje bufor audio do jednego lub kilku modułów². Moduły konfiguruje się podczas inicjalizacji za pomocą inicjalizatora init(modules:), a analiza rozpoczyna się przez podanie sekwencji AsyncSequence buforów 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 dostarczane są trzy moduły:

SpeechTranscriber. Moduł zamiany mowy na tekst zaprojektowany dla długich nagrań audio (wykłady, spotkania, rozmowy wieloosobowe). Zwraca strumieniowe wyniki z timingiem na token, wskaźnikami pewności oraz sekwencją AsyncSequence results, którą aplikacja konsumuje przez for try await. Każdy wynik zawiera flagę isFinal rozdzielającą ulotne częściowe hipotezy od tekstu sfinalizowanego.

DictationTranscriber. Bezpośredni odpowiednik dla starszego zastosowania SFSpeechRecognizer: transkrypcja krótkich wypowiedzi z tym samym modelem działającym na urządzeniu, którego używa SFSpeechRecognizer. Aplikacje migrujące z SFSpeechRecognizer dla krótkich zapytań sięgają po DictationTranscriber; aplikacje wdrażające framework do nagrań długich sięgają po SpeechTranscriber. Ten podział ma znaczenie, ponieważ SpeechTranscriber i DictationTranscriber korzystają z różnego pokrycia językowego i różnych ścieżek modeli.

SpeechDetector. Wykrywanie aktywności głosu. Raportuje zdarzenia, gdy mowa rozpoczyna się i kończy w strumieniu audio. Detektor nie może działać samodzielnie; musi być sparowany z jednym z modułów transkrybenta w tej samej instancji SpeechAnalyzer. Aplikacje używają go do bramkowania obliczeń transkrypcji (nie transkrybować ciszy) lub do sterowania elementami UI (wskaźniki „mów teraz”).

Architektura modułowa to strukturalne ulepszenie w stosunku do SFSpeechRecognizer. Stary API łączy zarządzanie sesją audio, wykrywanie języka i transkrypcję w jeden obiekt; nowy API rozdziela te odpowiedzialności, dzięki czemu aplikacje komponują potrzebne im moduły.

Co wnosi nowy model

Model transkrypcji stojący za SpeechTranscriber to nowy model na urządzeniu opracowany przez Apple specjalnie dla tego frameworka⁴. Ulepszenia, które Apple podkreśliło na WWDC 2025:

Jakość długich nagrań audio. Model jest trenowany pod kątem nieprzerwanej transkrypcji trwającej minuty lub godziny, nie tylko krótkich zapytań. Wykłady, podcasty, wieloosobowe spotkania i sesje dyktowania transkrybują się z dokładnością, którą Apple pozycjonuje na poziomie modeli klasy Whisper. Niezależny test MacStories zmierzył transkrypcję jako ok. 2,2-krotnie szybszą niż wersja MacWhisper z modelem Large V3 Turbo w równoważnych zadaniach³.

Obsługa odległego źródła audio. Mikrofony umieszczone w drugim końcu pomieszczenia, audio z konferencyjnego stołu z wieloma rozmówcami, audio z hałasem otoczenia. Model jest trenowany pod kątem tych warunków; starszy model SFSpeechRecognizer radzi sobie z nimi mniej elegancko.

Działanie w czasie rzeczywistym z niskim opóźnieniem. Strumieniowe wyniki z SpeechTranscriber przychodzą szybciej niż wywołania zwrotne SFSpeechRecognitionTask.shouldReportPartialResults ze starego frameworka. Aplikacje, które wyświetlają transkrypcję na żywo (napisy, interfejsy sterowane głosem, dyktowanie), otrzymują płynniejsze aktualizacje.

Automatyczne zarządzanie językami. SpeechTranscriber(locale:) przyjmuje początkowe ustawienia lokalne, ale model potrafi adaptować się do zmian języka w trakcie strumienia. Stary framework wymaga, aby programista instancjonował rozpoznawacze osobno dla każdego języka i przełączał się między nimi.

Brak kosztu rozmiaru aplikacji. Model jest dostarczany z systemem operacyjnym, a nie z aplikacją. Aplikacje wdrażające SpeechAnalyzer nie pakują dodatkowych wag modelu. Kontrast z dostarczaniem modelu klasy Whisper w pakiecie aplikacji jest znaczący: konkurencyjny stos transkrypcji na urządzeniu kosztuje zero bajtów pakietu.

Co stary framework nadal oferuje

SFSpeechRecognizer nadal jest dostarczany i działa w iOS 26. Trzy powody, dla których aplikacja może go zachować:

Custom Vocabulary. SFSpeechRecognitionRequest.contextualStrings pozwala aplikacji zarejestrować listę znanych słów kluczowych (nazw własnych, terminów technicznych, nazw produktów), które model będzie z większym prawdopodobieństwem rozpoznawał poprawnie. Funkcja istotnie poprawia dokładność w aplikacjach branżowych (dyktowanie medyczne z nazwami leków, aplikacje prawnicze z cytatami spraw, aplikacje inżynierskie z numerami części). SpeechAnalyzer jeszcze nie oferuje Custom Vocabulary; dla aplikacji zależnych od tej funkcji migracja byłaby regresem dokładności.

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

Istniejąca integracja, która działa. Aplikacje ze stabilnymi, audytowanymi, wydajnymi integracjami SFSpeechRecognizer nie mają pilnego powodu do migracji. Ulepszenia nowego frameworka mają największe znaczenie dla nowych zastosowań (transkrypcja długich nagrań, audio z odległości, rozmowy wieloosobowe); aplikacje, które obsługują krótkie zapytania głosowe przez starszy API, mogą nie zyskać wystarczająco wiele, by uzasadnić migrację.

Kiedy migrować

Trzy wyzwalacze migracji warte wymienienia:

Aplikacja przetwarza długie nagrania audio. Rejestrator spotkań, aplikacja do transkrypcji wykładów, narzędzie podcast-to-text. Trening nowego modelu na nagraniach trwających dłużej to właściwy wybór; stary model degraduje się przy długich sesjach. Migrować w pierwszej kolejności.

Aplikacja potrzebuje audio z odległości lub w warunkach hałaśliwych. Transkrypcja w salach konferencyjnych, nagrania wywiadów z pojedynczym, oddalonym mikrofonem, audio rejestrowane w środowiskach z hałasem otoczenia. Nowy model radzi sobie z tymi warunkami zauważalnie lepiej.

Aplikacja prezentuje UI transkrypcji na żywo. Nakładki napisów, interfejsy dyktowania, głosowe interfejsy wspomagające. Niższe opóźnienie strumieniowych wyników z SpeechTranscriber sprawia, że UI sprawia wrażenie bardziej responsywnego.

Przypadki, które niekoniecznie uzasadniają migrację:

• Krótkie zapytania głosowe z własnym słownikiem (dyktowanie recept, terminologia prawnicza). Warto zachować SFSpeechRecognizer dla funkcji słownika; sięgnąć po SpeechAnalyzer, gdy Apple doda obsługę słownika w przyszłym wydaniu.
• Aplikacje, które muszą wspierać iOS 18 i wcześniejsze. SpeechAnalyzer jest dostępny tylko od iOS 26; baza kodu i tak potrzebuje starszego frameworka dla starszych celów.

Wzorzec równoległy

Dla aplikacji, które jednocześnie celują w starsze wersje OS i chcą jakości nowego frameworka na iOS 26+, wzorzec równoległy to właściwe podejście:

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 to właściwy wybór dla gałęzi iOS 26+, ponieważ celem migracji jest zastosowanie SFSpeechRecognizer (krótkie zapytania z tym samym modelem dyktowania). Aplikacje celujące w długie nagrania audio zamieniają DictationTranscriber na SpeechTranscriber w gałęzi iOS 26.

Oba frameworki współistnieją; sprawdzenie w czasie wykonania wybiera właściwy w zależności od dostępności. Żaden nie blokuje drugiego; potok transkrypcji aplikacji adaptuje się.

Prywatność i powierzchnia autoryzacji Speech

Oba frameworki współdzielą to samo uprawnienie frameworka Speech (NSSpeechRecognitionUsageDescription w pliku Info.plist) oraz ten sam przepływ autoryzacji widoczny dla użytkownika⁵. Historia prywatności jest taka sama: transkrypcja mowy odbywa się na urządzeniu w obu frameworkach. SpeechAnalyzer jest z założenia wyłącznie na urządzeniu; SFSpeechRecognizer domyślnie pracuje na urządzeniu, gdy flaga requiresOnDeviceRecognition żądania jest ustawiona na true na samym SFSpeechRecognitionRequest, w przeciwnym razie może wrócić do ścieżki po stronie serwera.

Implikacja: aplikacje używające SpeechAnalyzer powinny nadal poprawnie obsługiwać autoryzację Speech. Monit dla użytkownika, wpis w Ustawieniach oraz etykieta wartości odżywczych prywatności w App Store wszystkie korzystają z tego samego mechanizmu autoryzacji.

Dla aplikacji, które strumieniują audio z mikrofonu do analizatora, obowiązuje standardowa konfiguracja AVAudioSession. Wpis Privacy Manifest deep dive z tego klastra omawia wpisy manifestu dla aplikacji korzystających z Speech; oba frameworki podlegają tym samym deklaracjom prywatności.

Połączenie z agentowymi przepływami pracy

Model na urządzeniu i ustrukturyzowane wyjście SpeechAnalyzer parują się czysto z dwoma wzorcami z klastra:

Foundation Models do rozumowania w aplikacji. Potok, który transkrybuje audio za pomocą SpeechTranscriber, a następnie podsumowuje transkrypcję za pomocą LLM na urządzeniu (omówiony w Foundation Models on-device LLM), działa w całości na urządzeniu. Łączna liczba wywołań sieciowych: zero. Łączna ekspozycja danych podmiotom trzecim: zero.

App Intents do działań sterowanych głosem. AppIntent, który przyjmuje transkrypcję jako wejście, można wywołać przez Vocal Shortcuts (omówione w Accessibility as platform) lub przez powierzchnię działań Apple Intelligence. Metoda perform tego intencji uruchamia SpeechAnalyzer, aby przetranskrybować wejście, a następnie deleguje do logiki aplikacji. Cały przepływ jest prywatny i lokalny.

Wzorzec: nowy framework Speech dopełnia trójkąt percepcji na urządzeniu (Vision dla obrazów, Foundation Models dla rozumowania językowego, Speech dla audio), który sprawia, że w pełni lokalne funkcje AI stają się praktyczne dla aplikacji iOS.

Co ten wzorzec oznacza dla aplikacji iOS 26+

Trzy wnioski.

1. Domyślnie używać SpeechAnalyzer dla nowego kodu. Nowoczesny model, modułowa architektura oraz lepsza wydajność dla długich nagrań / oddalonego audio / transkrypcji na żywo czynią z niego właściwy punkt wyjścia. Starszy framework jest rozwiązaniem awaryjnym, gdy wymagane jest wsparcie starszych OS lub Custom Vocabulary.

2. Zachować SFSpeechRecognizer dla aplikacji zależnych od słownika. Dopóki Apple nie doda Custom Vocabulary do nowego frameworka, aplikacje zależne od contextualStrings w celu uzyskania dokładności na terminach branżowych zachowują stary API. Oba frameworki współistnieją; mieszanie ich per funkcja to właściwy wzorzec.

3. Historia prywatności na urządzeniu rozszerza się z Vision na Speech. Aplikacje zbudowane wokół CV na urządzeniu z Vision mają teraz odpowiednik dla audio. W połączeniu z Foundation Models do rozumowania, pełen potok od percepcji do języka może działać lokalnie bez ekspozycji danych podmiotom trzecim.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; różnica między LLM jako runtime a oprzyrządowaniem; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; Dwa serwery MCP; hooki dla rozwoju Apple; Live Activities; kontrakt runtime watchOS; wewnętrzności SwiftUI; przestrzenny model mentalny RealityKit; dyscyplina schematu SwiftData; wzorce Liquid Glass; wieloplatformowy shipping; macierz platform; framework Vision; Symbol Effects; inferencja Core ML; adopcja Writing Tools API; Swift Testing; Privacy Manifest; Accessibility as platform; typografia SF Pro; przestrzenne wzorce visionOS; o czym odmawiam pisać. Hub znajduje się pod Apple Ecosystem Series. Szerszy kontekst iOS-z-agentami-AI znajduje się w przewodniku iOS Agent Development.

FAQ

Czy SFSpeechRecognizer jest deprecated?

Apple formalnie nie oznaczyło SFSpeechRecognizer jako deprecated. Nadal jest on dostarczany w iOS 26 i pozostaje wspierany. Narracja na WWDC 2025 jest taka, że SpeechAnalyzer to nowoczesna, rekomendowana ścieżka dla nowego kodu; starszy framework jest właściwym narzędziem dla konkretnych przypadków (Custom Vocabulary, wsparcie starszych OS).

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

Tak. SpeechAnalyzer.start(inputSequence:) przyjmuje AsyncSequence buforów audio. Aplikacje opakowują dowolne źródło audio (mikrofon przez AVAudioEngine, adresy URL plików nagranych wcześniej, instancje AVAsset) w adapter AsyncSequence i podają go analizatorowi. Strumień transkrypcji generuje tę samą konsumpcję for try await result in transcriber.results niezależnie od źródła wejścia.

Co stanie się z Custom Vocabulary, jeśli zmigruję?

Custom Vocabulary nie jest obecnie wspierane przez SpeechAnalyzer / SpeechTranscriber. Aplikacje, które polegają na tej funkcji w celu uzyskania dokładności branżowej, nie powinny migrować tej ścieżki, dopóki Apple nie doda tej funkcji. Hybrydowe podejście (używanie SpeechAnalyzer do transkrypcji ogólnej oraz SFSpeechRecognizer z contextualStrings do transkrypcji wrażliwej na słownik) działa 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 po stronie serwera. Dla transkrypcji po stronie serwera właściwymi narzędziami są chmurowe API (OpenAI Whisper API, Google Cloud Speech-to-Text, AWS Transcribe) lub modele self-hosted. Wartość frameworka Apple to właśnie historia prywatności na urządzeniu i zerowy koszt na wywołanie.

Jak działa wykrywanie języka?

SpeechTranscriber(locale:) przyjmuje początkową lokalizację. Model potrafi automatycznie adaptować się do zmian języka w trakcie strumienia. W aplikacjach, gdzie język jest znany z góry (funkcja dyktowania w lokalizowanej aplikacji), warto go określić jawnie. W kontekstach wielojęzycznych (transkrybent spotkań, gdzie mówcy mogą się przełączać), automatyczne zarządzanie to właściwe zachowanie.

Jak to wpisuje się w pozostałe wpisy klastra dotyczące ML na urządzeniu?

SpeechAnalyzer to trzeci filar stosu percepcji na urządzeniu: Vision (omówiony w Vision Framework) obsługuje obrazy, Speech obsługuje audio, a Core ML (omówiony w Core ML On-Device Inference) jest silnikiem leżącym u podstaw obu. Foundation Models (omówiony w Foundation Models on-device LLM) obsługuje rozumowanie językowe. Razem tworzą kompletny potok AI na urządzeniu, który nie wymaga wywołań sieciowych.

Bibliografia