Dostępność jako platforma: Personal Voice, Live Speech, śledzenie wzroku, Music Haptics

Personal Voice (iOS 17), Live Speech (iOS 17), śledzenie wzroku (iOS 18), Music Haptics (iOS 18), Vocal Shortcuts (iOS 18). Łuk najnowszych wydań Apple związanych z dostępnością jest spójny: funkcje, które wcześniej wymagały aplikacji firm trzecich, dedykowanego sprzętu lub specjalistycznych integracji, stają się możliwościami platformy obsługiwanymi przez system operacyjny. Skutek to mniej aplikacji do zainstalowania dla użytkownika oraz inny model uczestnictwa dla deweloperów: zamiast budować funkcję, deweloper albo wyraża zgodę na korzystanie z systemowej powierzchni (autoryzacja Personal Voice), albo stosuje się do standardów, które każda aplikacja powinna już spełniać (właściwe etykiety dostępności i rozmiary celów dotykowych dla śledzenia wzroku).

Niniejszy wpis omawia powierzchnię deweloperską każdej z tych funkcji. Ramą jest pytanie „co moja aplikacja musi zrobić, aby uczestniczyć”, a nie „jak zaimplementować tę funkcję”. Apple zbudowało funkcję; pytanie brzmi, czy aplikacja jest gotowa, by z niej skorzystać.

TL;DR

• Personal Voice (iOS 17+) pozwala użytkownikowi nagrać 15 minut audio, aby utworzyć syntezowany głos działający na urządzeniu, przeznaczony dla aplikacji AAC i komunikacji wspomagającej. Aplikacje integrują się przez AVSpeechSynthesizer.requestPersonalVoiceAuthorization() i sprawdzają voiceTraits pod kątem .isPersonalVoice¹.
• Live Speech (iOS 17+) to funkcja systemowa: użytkownik wpisuje tekst, a urządzenie go wypowiada (opcjonalnie z użyciem Personal Voice). Aplikacje nie integrują się z Live Speech bezpośrednio; funkcja działa na poziomie systemu operacyjnego podczas połączeń, FaceTime i komunikacji osobistej.
• Śledzenie wzroku (iOS 18+) umożliwia sterowanie urządzeniem za pomocą spojrzenia i Dwell Control przez aparat przedni. Aplikacje uczestniczą, stosując się do standardów dostępności (właściwe etykiety dostępności, odpowiednie rozmiary celów dotykowych, kolejność fokusu); w większości aplikacji nie jest wymagane dedykowane API².
• Music Haptics (iOS 18+) tłumaczy odtwarzanie muzyki na wibracje silnika Taptic zsynchronizowane z dźwiękiem za pośrednictwem API MAMusicHapticsManager z MediaAccessibility.framework. Każda aplikacja muzyczna może się zintegrować, ustawiając MusicHapticsSupported w Info.plist, stając się aktywną aplikacją Now Playing i dostarczając kod ISRC³.
• Vocal Shortcuts (iOS 18+) pozwalają użytkownikom przypisać własne frazy do uruchamiania skrótów Siri, w tym akcji AppIntent firm trzecich. Funkcja łączy się z adopcją App Intents (omówioną w App Intents to nowe API Apple do Twojej aplikacji).

Personal Voice: wzorzec autoryzacji

Personal Voice to funkcja dostępności o najbardziej bezpośredniej powierzchni deweloperskiej¹. Użytkownik włącza ją w Ustawieniach > Dostępność > Personal Voice, nagrywa około 15 minut audio czytając losowo wybrane podpowiedzi, a urządzenie generuje lokalnie syntezowany głos, korzystając z uczenia maszynowego na urządzeniu. Głos pozostaje prywatny dla użytkownika; nie opuszcza urządzenia, chyba że użytkownik świadomie udostępni go urządzeniom sparowanym przez iCloud.

Aby aplikacja mogła używać Personal Voice użytkownika w AVSpeechSynthesizer, musi:

1. Poprosić o autoryzację za pomocą AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:).
2. Poczekać, aż użytkownik wyrazi zgodę przez systemowy monit.
3. Po zatwierdzeniu odpytać AVSpeechSynthesisVoice.speechVoices() i odfiltrować głosy, których voiceTraits zawierają .isPersonalVoice.
4. Użyć uzyskanego AVSpeechSynthesisVoice jak każdego innego głosu w AVSpeechUtterance.

import AVFoundation

AVSpeechSynthesizer.requestPersonalVoiceAuthorization { status in
    guard status == .authorized else { return }

    let personalVoices = AVSpeechSynthesisVoice.speechVoices().filter { voice in
        voice.voiceTraits.contains(.isPersonalVoice)
    }

    if let voice = personalVoices.first {
        let utterance = AVSpeechUtterance(string: "Hello.")
        utterance.voice = voice
        synthesizer.speak(utterance)
    }
}

Autoryzacja jest sprawą wrażliwą. Zalecenia Apple wskazują, że Personal Voice powinno służyć przede wszystkim aplikacjom komunikacji wspomagającej i alternatywnej (AAC) oraz podobnym kontekstom asystującym. Aplikacja typu voice-over ogólnego przeznaczenia, która prosi o autoryzację Personal Voice, prawdopodobnie spotka się z odmową ze strony użytkowników i może podlegać szczegółowej kontroli w App Store.

Architektura „najpierw na urządzeniu” ma tu znaczenie. Dane treningowe głosu użytkownika i powstały model głosu nigdy nie opuszczają obszaru bezpiecznej enklawy urządzenia, chyba że użytkownik świadomie wyrazi zgodę na udostępnianie przez iCloud. Etykiety prywatności App Store dla aplikacji korzystających z Personal Voice powinny odzwierciedlać brak zbierania danych, ponieważ synteza odbywa się lokalnie, a wyjście audio trafia do głośnika, a nie do sieci.

Live Speech: systemowa funkcja bez integracji

Live Speech to konsumencki odpowiednik Personal Voice⁴. Użytkownik wpisuje tekst, a urządzenie go wypowiada, opcjonalnie używając Personal Voice. Live Speech działa podczas połączeń telefonicznych, połączeń FaceTime, Mac SharePlay i rozmów osobistych przez głośnik urządzenia.

Aplikacje nie integrują się z Live Speech bezpośrednio. Funkcja działa na poziomie systemu operacyjnego, przechwytując wpisany tekst z systemowego interfejsu Live Speech i kierując go przez stos audio. Z perspektywy aplikacji Live Speech jest niewidoczne: strumień audio docierający przez połączenie (lub odtwarzany z głośnika urządzenia w komunikacji osobistej) brzmi jak użytkownik, ale żaden kod aplikacji nie jest w to zaangażowany.

Implikacja dla deweloperów aplikacji: jeśli aplikacja obsługuje głos (aplikacja do połączeń, do wideoczatu, asystent dostępności), jej potok audio musi respektować systemowe routowanie dźwięku, aby Live Speech mogło wychodzić tym samym kanałem. Aplikacje, które walczą z sesją audio (rości sobie wyłączną kontrolę bez uwzględnienia systemowych dźwięków nakładkowych), psują Live Speech.

Śledzenie wzroku: funkcja oparta na standardach

Śledzenie wzroku, wprowadzone w iOS 18, pozwala użytkownikom sterować iPhonem i iPadem za pomocą kierunku spojrzenia oraz Dwell Control². Użytkownik kalibruje aparat przedni w kilka sekund, a następnie nawiguje po interfejsie, patrząc na elementy; utrzymanie spojrzenia na elemencie przez skonfigurowany czas Dwell aktywuje go (stuknięcie, przesunięcie lub inne gesty, konfigurowalne w Switch Control).

Implementacja działa na urządzeniu. Aparat przedni przetwarza dane spojrzenia za pomocą uczenia maszynowego na urządzeniu; dane nie opuszczają urządzenia. Nie jest wymagany dodatkowy sprzęt.

Większość aplikacji nie wymaga dedykowanego kodu, aby obsługiwać śledzenie wzroku. Funkcja działa z każdym interfejsem, który stosuje się do standardowych konwencji dostępności:

• Właściwe cele dotykowe. Wytyczne Apple Human Interface Guidelines określają minimalne cele dotykowe 44 pt na 44 pt dla elementów dotykowych. Śledzenie wzroku honoruje te wymiary. Przyciski mniejsze niż minimum są trudniejsze do precyzyjnego targetowania spojrzeniem.
• Etykiety dostępności. Każdy element interaktywny powinien mieć użyteczną właściwość accessibilityLabel (SwiftUI) lub accessibilityLabel (UIKit). Śledzenie wzroku wyświetla etykietę jako odpowiednik tooltipa, gdy użytkownik zatrzymuje spojrzenie w pobliżu elementu.
• Logiczna kolejność fokusu. Klawisz Tab na Macu i silnik fokusu w tvOS używają tej samej kolejności fokusu, której śledzenie wzroku używa do przeskakiwania między elementami. Aplikacje korzystające ze standardowych prymitywów układu SwiftUI dostają to za darmo; aplikacje nadpisujące zachowanie fokusu muszą to zweryfikować.
• Wzorce modali przyjazne dla Dwell. Modal, który automatycznie zamyka się po stuknięciu poza nim, może frustrować użytkowników śledzenia wzroku, których punkt spojrzenia może na chwilę opuścić obszar modala. Aplikacje z interfejsem modalnym powinny zapewniać jawne przyciski zamykania.

Aplikacje, które chcą wyłączyć śledzenie wzroku dla konkretnych widoków (treści wrażliwe, złożone gry oparte na gestach), nie mają udokumentowanego API rezygnacji specyficznego dla śledzenia wzroku. Funkcja działa na każdej widocznej zawartości, a obowiązkiem aplikacji jest zapewnienie, by standardowa powierzchnia dostępności była poprawna.

Wpis Trzy powierzchnie aplikacji iOS omawia szerszy wzorzec: widoczny interfejs to jedna powierzchnia, App Intents to druga, dostępność to trzecia. Śledzenie wzroku uczestniczy w widocznej powierzchni interfejsu; poprawne zaprojektowanie tej powierzchni jest tym, co umożliwia jednoczesne działanie śledzenia wzroku, Switch Control, VoiceOver i Voice Control.

Music Haptics: most z dźwięku do haptyki

Music Haptics tłumaczy odtwarzanie muzyki na wibracje silnika Taptic zsynchronizowane z dźwiękiem³. Funkcja jest opt-in dla każdego użytkownika (Ustawienia > Dostępność > Music Haptics) i działa dla każdej aplikacji muzycznej, która poprawnie zintegruje API, nie tylko dla Apple Music.

Powierzchnia deweloperska znajduje się w MAMusicHapticsManager z MediaAccessibility.framework (iOS 18+). Aplikacja muzyczna integruje Music Haptics w trzech krokach:

1. Zadeklarować wsparcie w Info.plist. Należy dodać klucz MusicHapticsSupported z wartością YES. System używa go, by wiedzieć, czy aplikacja uczestniczy w renderowaniu Music Haptics.
2. Zostać aktywną aplikacją Now Playing. Aplikacja musi publikować metadane odtwarzania przez MPNowPlayingInfoCenter.default().nowPlayingInfo i posiadać sesję audio Now Playing. System potrzebuje znanego, aktywnego źródła Now Playing, aby sterować syntezą haptyczną.
3. Dostarczyć ISRC dla odtwarzanego utworu. Klucz MPNowPlayingInfoPropertyInternationalStandardRecordingCode (Międzynarodowy Standardowy Kod Nagrania) pozwala systemowi wyszukać ścieżkę haptyczną sparowaną z dźwiękiem. Apple utrzymuje bibliotekę zasobów haptycznych indeksowaną przez ISRC; utwory bez ISRC nie otrzymują haptyki, ale reszta integracji Now Playing nadal działa.

import MediaPlayer
import MediaAccessibility

// Info.plist: MusicHapticsSupported = YES (boolean)

let info: [String: Any] = [
    MPMediaItemPropertyTitle: track.title,
    MPMediaItemPropertyArtist: track.artist,
    MPNowPlayingInfoPropertyInternationalStandardRecordingCode: track.isrc,
    // ... other now-playing properties
]
MPNowPlayingInfoCenter.default().nowPlayingInfo = info

Integracja dotyczy każdej aplikacji muzycznej: klienta strumieniowego zbudowanego na AVAudioEngine, aplikacji DJ z własnymi dekoderami, aplikacji do nauki muzyki z odtwarzaniem próbek. Ograniczeniem jest ISRC i rola aktywnego Now Playing, a nie podstawowe API audio. Aplikacje, które nie mają ISRC (muzyka wgrana przez użytkowników bez metadanych, muzyka generatywna), po prostu nie otrzymują haptyki; pozostała integracja odtwarzania pozostaje nienaruszona.

W przypadku aplikacji z sąsiednich obszarów (gier rytmicznych, wizualizacji muzycznych, silników efektów dźwiękowych) Music Haptics nie jest tym, do czego dźwięk został zaprojektowany. Te aplikacje sięgają bezpośrednio po CHHapticEngine z ręcznie tworzonymi wzorcami haptycznymi zsynchronizowanymi ze swoim źródłem audio.

Vocal Shortcuts: gdzie dostępność spotyka się z App Intents

Vocal Shortcuts pozwalają użytkownikom przypisać własne frazy głosowe do skrótów Siri, w tym tych opartych na typach AppIntent firm trzecich⁵. Użytkownik może skonfigurować „Marker”, aby uruchomić AddTodoIntent zarejestrowany przez aplikację to-do; powiedzenie „Marker” w dowolnym miejscu, bez przywoływania frazy budzącej Siri, uruchamia intent.

Integracja korzysta z frameworka App Intents, który klaster szeroko omawiał, z jednym strukturalnym elementem łatwym do przeoczenia: aplikacja musi zadeklarować AppShortcutsProvider udostępniający wpisy AppShortcut z jawnymi phrases. Sam AppIntent istnieje w systemie, ale jest wywoływalny tylko przez edytor Skrótów, gdzie użytkownik ręcznie składa skrót. AppShortcutsProvider rejestruje widoczne dla systemu skróty, które użytkownik może natychmiast przypisać do Vocal Shortcut, Action Button, Siri lub Spotlight.

struct TodoShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: AddTodoIntent(),
            phrases: [
                "Add a todo in \(.applicationName)",
                "\(.applicationName) marker"
            ],
            shortTitle: "Add Todo",
            systemImageName: "checkmark.circle"
        )
    }
}

Tablica phrases jest tym, co system udostępnia Siri i Vocal Shortcuts. Po zarejestrowaniu providera App Intent jest natychmiast kwalifikowalny do aktywacji głosowej. Bez niego intent działa przez ręczną konfigurację Skrótów, ale ścieżka jest dłuższa, a wielu użytkowników nigdy do niej nie dociera.

Wzorzec łączy się z App Intents oraz App Intents kontra narzędzia MCP. App Intent, który zasługuje na miejsce na powierzchni Apple Intelligence użytkownika, w połączeniu z AppShortcutsProvider deklarującym, jak użytkownik go wywołuje, zasługuje również na miejsce jako cel Vocal Shortcut. Argument klastra, że App Intents to międzysystemowy kontrakt na to, „co aplikacja potrafi”, stosuje się tutaj: Vocal Shortcuts to kolejny konsument tego samego kontraktu.

Wzorzec przekrojowy: standardy są integracją

Powyższe funkcje dostępności mają wspólną właściwość strukturalną: każda jest zbudowana na standardach, które aplikacje powinny już spełniać, z niewielką, opt-inową powierzchnią API dla przypadków, w których aplikacja musi jawnie współpracować (autoryzacja Personal Voice, Music Haptics przez MPMusicPlayerController).

Implikacja dla zespołów deweloperskich: praca nad dostępnością nie jest osobnym strumieniem prac wykonywanym po wydaniu aplikacji. Etykiety dostępności aplikacji, cele dotykowe, kolejność fokusu i standardowe użycie systemowego API to właśnie to, co sprawia, że śledzenie wzroku działa, Live Speech jest poprawnie kierowane, Music Haptics aktywuje się, a Vocal Shortcuts udostępnia właściwe intenty. Aplikacje traktujące dostępność jako pole do odhaczenia na końcu cyklu wydają funkcje, które działają dla VoiceOver, ale nie dla śledzenia wzroku, lub kierują dźwięk w sposób, którego Live Speech nie potrafi naśladować.

Wpis Czego odmawiam pisać z klastra argumentuje za odmową jako ruchem pozycjonującym. Odmowy w obszarze dostępności są odwrotnością: nie „odmawiam dodania tego”, ale „odmawiam wydania czegoś, co nie spełnia standardów, które każda aplikacja iOS powinna już spełniać”.

Kiedy aplikacje potrzebują własnego kodu dostępności

Trzy przypadki, w których wzorzec zgodności ze standardami nie obejmuje wszystkiego:

Powierzchnie własnego rysowania. Aplikacja do rysowania, wykres, niestandardowo renderowany interfejs gry omijają drzewo dostępności SwiftUI/UIKit. Aplikacja musi zbudować własne drzewo dostępności, używając UIAccessibilityCustomAction, UIAccessibilityElement oraz jawnych właściwości dostępności dla każdego znaczącego elementu. Śledzenie wzroku, VoiceOver i Switch Control polegają na zapełnionym drzewie dostępności.

Interakcje gestowe w czasie rzeczywistym. Gra z ciągłym wejściem gestowym (rysowanie, drag-to-aim) nie mapuje się naturalnie na wejście oparte na zatrzymaniu spojrzenia ani na przełącznikach. Właściwym podejściem jest zapewnienie alternatywnych schematów sterowania (wejście oparte na przyciskach jako opcja), a nie walka z systemem dostępności.

Funkcje specyficzne dla dostępności. Aplikacje AAC, aplikacje wzbogacające głos, aplikacje do interpretacji języka migowego. Te aplikacje są same w sobie produktami dostępności i głęboko integrują się z frameworkami systemowymi (Personal Voice, Speech framework, Vision framework do wykrywania języka migowego). Praca integracyjna jest tu rzeczywista i celowa.

Co ten wzorzec oznacza dla aplikacji w iOS 26+

Trzy wnioski.

1. Uczestnictwo w dostępności to przeważnie zgodność ze standardami, a nie budowanie funkcji. Apple przenosi dostępność do warstwy platformy. Praca polega na zapewnieniu, że aplikacja spełnia standardy, na których polegają śledzenie wzroku, Switch Control, VoiceOver i Voice Control: właściwe etykiety, cele dotykowe, kolejność fokusu, systemowe routowanie audio.

2. Integracja Personal Voice jest sprawą wrażliwą. Jeśli aplikacja ma rzeczywisty przypadek użycia AAC (komunikacja wspomagająca, wzbogacanie głosu, narzędzia dostępności), autoryzacja Personal Voice jest właściwą integracją. W przypadku aplikacji ogólnego przeznaczenia żądanie autoryzacji Personal Voice jest bardziej prawdopodobne, że zdezorientuje użytkowników, niż im pomoże.

3. App Intents są infrastrukturą dostępności. Czysty AppIntent jest automatycznie kwalifikowalny do Vocal Shortcuts, otrzymuje dostępną powierzchnię interfejsu przez Skróty i integruje się z trybami sterowania głosowego i przełącznikami systemu. Argument klastra na rzecz adopcji App Intents stosuje się również do dostępności.

Pełny klaster Apple Ecosystem: typowane App Intents; serwery MCP; pytanie o routing; Foundation Models; rozróżnienie LLM czasu wykonania od narzędziowego; trzy powierzchnie; wzorzec pojedynczego źródła prawdy; Dwa serwery MCP; hooki dla rozwoju Apple; Live Activities; kontrakt czasu wykonania watchOS; wnętrzności SwiftUI; przestrzenny model myślowy RealityKit; dyscyplina schematu SwiftData; wzorce Liquid Glass; wydawanie wieloplatformowe; matryca platform; Vision framework; Symbol Effects; inferencja Core ML; API Writing Tools; Swift Testing; Privacy Manifest; czego odmawiam pisać. Hub znajduje się w serii Apple Ecosystem. Aby uzyskać szerszy kontekst dotyczący iOS z agentami AI, należy zajrzeć do przewodnika po rozwoju agentów iOS.

FAQ

Czy muszę napisać jakikolwiek kod, aby obsługiwać śledzenie wzroku?

Większość aplikacji nie. Śledzenie wzroku działa automatycznie z każdym interfejsem, który stosuje się do standardowych konwencji dostępności: właściwych celów dotykowych (minimum 44 pt), użytecznych etykiet dostępności, logicznej kolejności fokusu i standardowych kontrolek systemowych. Aplikacje rysujące własny interfejs (widoki niestandardowe, gry, wykresy) muszą jawnie zapełnić drzewo dostępności, używając UIAccessibilityElement lub modyfikatorów dostępności SwiftUI; ta sama praca sprawia, że aplikacja działa z VoiceOver i Switch Control.

Czy mogę użyć Personal Voice w aplikacji typu voice-over ogólnego przeznaczenia?

System pozwala na to przez AVSpeechSynthesizer.requestPersonalVoiceAuthorization(), ale wytyczne Apple oraz proces przeglądu w App Store podkreślają stosowanie Personal Voice w kontekstach asystujących (AAC, komunikacja wspomagająca i alternatywna). Aplikacje typu voice-over ogólnego przeznaczenia, które proszą o autoryzację Personal Voice, stają wobec dwóch wyzwań: użytkownicy raczej nie udzielą autoryzacji, a przegląd może zakwestionować takie żądanie jako niewłaściwe użycie. Jeśli przypadek użycia jest naprawdę asystujący, integracja jest słuszna; jeśli to ogólnoprzeznaczeniowa narracja, głosy systemowe są właściwym narzędziem.

Jaka jest różnica między Live Speech a Personal Voice?

Personal Voice to syntezowany głos działający na urządzeniu, który brzmi jak użytkownik. Live Speech to funkcja systemowa pozwalająca użytkownikowi wpisywać tekst i sprawić, by urządzenie go wypowiadało (przy użyciu głosu systemowego lub Personal Voice). Są komplementarne: Personal Voice zapewnia głos, Live Speech zapewnia interfejs konwersji tekstu na mowę. Aplikacje integrują Personal Voice przez API Speech Synthesizer; Live Speech jest niewidoczne dla aplikacji i działa na poziomie systemu operacyjnego.

Jak dodać Music Haptics do aplikacji muzycznej korzystającej z AVAudioEngine?

Można to zrobić. Music Haptics nie jest ograniczone do konkretnego API odtwarzania. Integracja wygląda tak: dodać MusicHapticsSupported = YES do Info.plist, publikować metadane odtwarzanego utworu przez MPNowPlayingInfoCenter.default().nowPlayingInfo (aby system rozpoznał aplikację jako aktywne źródło Now Playing) oraz dołączyć MPNowPlayingInfoPropertyInternationalStandardRecordingCode z kodem ISRC utworu. System obsługuje syntezę haptyczną od tego momentu. Utwory bez ISRC nie otrzymują haptyki, ale reszta integracji Now Playing działa normalnie.

Jaki projekt App Intent zapewnia najlepsze doświadczenie Vocal Shortcuts?

Cztery zasady. Po pierwsze, należy zadeklarować AppShortcutsProvider dla aplikacji i zarejestrować wpisy AppShortcut dla intentów, które mają być dostępne głosowo. Bez providera intent dociera do Vocal Shortcuts wyłącznie przez ręczną edycję Skrótów. Po drugie, title i shortTitle powinny być krótkimi frazami czasownikowymi („Add Todo”, „Start Timer”) zamiast opisami. Po trzecie, parametry powinny być opcjonalne lub mieć wartości domyślne, aby użytkownik mógł wywołać intent bez podawania każdego pola. Po czwarte, description powinien być pojedynczym, jasnym zdaniem wyjaśniającym efekt intentu; pojawia się on jako kontekst, gdy użytkownik wybiera frazę do przypisania.

Bibliografia