Barrierefreiheit als Plattform: Personal Voice, Live Speech, Eye Tracking, Music Haptics

Personal Voice (iOS 17), Live Speech (iOS 17), Eye Tracking (iOS 18), Music Haptics (iOS 18), Vocal Shortcuts (iOS 18). Der Bogen der jüngsten Barrierefreiheits-Releases von Apple ist konsistent: Funktionen, die früher Drittanbieter-Apps, dedizierte Hardware oder spezialisierte Integrationen erforderten, werden zu Plattformfähigkeiten, die das OS übernimmt. Das Ergebnis sind weniger zu installierende Apps für den Benutzer und ein anderes Beteiligungsmodell für den Entwickler: Statt die Funktion zu bauen, entscheidet sich der Entwickler entweder für eine Systemoberfläche (Personal-Voice-Autorisierung) oder folgt den Standards, die jede App ohnehin erfüllen sollte (korrekte Barrierefreiheits-Labels und Trefferflächen für Eye Tracking).

Der Beitrag geht die Entwickleroberfläche für jede Funktion durch. Der Rahmen lautet „Was muss meine App tun, um teilzunehmen?” statt „Wie implementiere ich diese Funktion?”. Apple hat die Funktion gebaut; die Frage ist, ob die App bereit ist, sie zu nutzen.

TL;DR

• Personal Voice (iOS 17+) ermöglicht es einem Benutzer, 15 Minuten Audio aufzunehmen, um eine geräteinterne synthetisierte Stimme für AAC- und assistive Kommunikations-Apps zu erstellen. Apps integrieren sich über AVSpeechSynthesizer.requestPersonalVoiceAuthorization() und prüfen voiceTraits auf .isPersonalVoice¹.
• Live Speech (iOS 17+) ist eine Systemfunktion: Der Benutzer tippt Text und das Gerät spricht ihn aus (optional mit seiner Personal Voice). Apps integrieren Live Speech nicht direkt; die Funktion arbeitet auf OS-Ebene über Anrufe, FaceTime und persönliche Kommunikation hinweg.
• Eye Tracking (iOS 18+) steuert das Gerät über Blick + Verweilsteuerung durch die Frontkamera. Apps beteiligen sich, indem sie Barrierefreiheitsstandards befolgen (korrekte Barrierefreiheits-Labels, Trefferflächen-Dimensionierung, Fokusreihenfolge); für die meisten Apps ist keine dedizierte API erforderlich².
• Music Haptics (iOS 18+) übersetzt die Musikwiedergabe in Vibrationen der Taptic Engine, die über die API MAMusicHapticsManager im MediaAccessibility.framework synchron zum Audio sind. Jede Musik-App kann sich integrieren, indem sie MusicHapticsSupported in der Info.plist setzt, zur aktiven Now-Playing-App wird und einen ISRC liefert³.
• Vocal Shortcuts (iOS 18+) ermöglichen es Benutzern, benutzerdefinierte Phrasen zuzuweisen, um Siri-Kurzbefehle auszulösen, einschließlich AppIntent-Aktionen von Drittanbietern. Die Funktion verstärkt sich mit der Einführung von App Intents (behandelt in App Intents Are Apple’s New API to Your App).

Personal Voice: Das Autorisierungsmuster

Personal Voice ist die Barrierefreiheitsfunktion mit der direktesten Entwickleroberfläche¹. Der Benutzer entscheidet sich über Einstellungen > Bedienungshilfen > Personal Voice dafür, nimmt etwa 15 Minuten Audio mit zufällig ausgewählten Vorlesetexten auf, und das Gerät generiert lokal eine synthetisierte Stimme mittels geräteinternem maschinellen Lernen. Die Stimme ist privat für den Benutzer; sie verlässt das Gerät nicht, es sei denn, der Benutzer teilt sie ausdrücklich mit iCloud-gekoppelten Geräten.

Damit eine App die Personal Voice des Benutzers in AVSpeechSynthesizer verwenden kann, muss sie:

1. Die Autorisierung über AVSpeechSynthesizer.requestPersonalVoiceAuthorization(completionHandler:) anfordern.
2. Warten, bis der Benutzer die Erlaubnis über die Systemabfrage erteilt.
3. Bei Genehmigung AVSpeechSynthesisVoice.speechVoices() abfragen und nach Stimmen filtern, deren voiceTraits .isPersonalVoice enthalten.
4. Die resultierende AVSpeechSynthesisVoice wie jede andere Stimme in AVSpeechUtterance verwenden.

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)
    }
}

Die Autorisierung ist sensibel. Apples Leitlinie besagt, dass Personal Voice primär augmentativen und alternativen Kommunikations-Apps (AAC) und ähnlichen assistiven Kontexten dienen sollte. Eine allgemein einsetzbare Voice-over-App, die eine Personal-Voice-Autorisierung anfordert, wird wahrscheinlich von Benutzern abgelehnt und kann im App Store Review unter besondere Beobachtung geraten.

Die On-Device-First-Architektur ist hier wichtig. Die Sprachtrainingsdaten des Benutzers und das resultierende Stimmmodell verlassen den Bereich der Secure Enclave des Geräts nicht, es sei denn, der Benutzer entscheidet sich ausdrücklich für die iCloud-Freigabe. Die Privacy-Nutrition-Labels im App Store für Apps, die Personal Voice verwenden, sollten keine Datenerfassung ausweisen, da die Synthese lokal stattfindet und die Audioausgabe an den Lautsprecher und nicht an das Netzwerk geht.

Live Speech: Die Systemfunktion ohne Integration

Live Speech ist das verbraucherorientierte Pendant zu Personal Voice⁴. Der Benutzer tippt Text, das Gerät spricht ihn aus, optional unter Verwendung seiner Personal Voice. Live Speech funktioniert während Telefonanrufen, FaceTime-Anrufen, Mac-SharePlay und persönlichen Gesprächen über den Gerätelautsprecher.

Apps integrieren Live Speech nicht direkt. Die Funktion arbeitet auf OS-Ebene, fängt getippten Text aus der System-Live-Speech-UI ab und leitet ihn durch den Audio-Stack. Aus Sicht einer App ist Live Speech unsichtbar: Der Audiostream, der durch den Anruf kommt (oder der für die persönliche Nutzung aus dem Gerätelautsprecher abgespielt wird), klingt wie der Benutzer, aber kein App-Code ist beteiligt.

Die Implikation für App-Entwickler: Wenn Ihre App Sprache verarbeitet (eine Telefonie-App, eine Videochat-App, ein Barrierefreiheits-Helfer), muss die Audio-Pipeline der App das Systemaudio-Routing respektieren, damit Live Speech über denselben Kanal ausgeben kann. Apps, die gegen die Audio-Session arbeiten (exklusive Kontrolle beanspruchen, ohne Rücksicht auf System-Overlay-Sounds), brechen Live Speech.

Eye Tracking: Die standardgetreue Funktion

Eye Tracking, eingeführt in iOS 18, ermöglicht Benutzern die Steuerung von iPhone und iPad über Blickrichtung plus Verweilsteuerung². Der Benutzer kalibriert die Frontkamera in wenigen Sekunden und navigiert dann durch die Benutzeroberfläche, indem er Elemente ansieht; das Verweilen des Blicks auf einem Element für die konfigurierte Verweildauer aktiviert es (Tippen, Wischen oder andere Gesten, in der Switch Control konfigurierbar).

Die Implementierung erfolgt geräteintern. Die Frontkamera verarbeitet Blickdaten durch geräteinternes maschinelles Lernen; die Daten verlassen das Gerät nicht. Es ist keine zusätzliche Hardware erforderlich.

Für die meisten Apps erfordert die Unterstützung von Eye Tracking keinen dedizierten Code. Die Funktion arbeitet mit jeder Benutzeroberfläche, die den Standardkonventionen für Barrierefreiheit folgt:

• Korrekte Trefferflächen. Die Apple Human Interface Guidelines spezifizieren minimale Trefferflächen von 44pt × 44pt für antippbare Elemente. Eye Tracking respektiert diese. Schaltflächen, die kleiner als das Minimum sind, lassen sich schwerer präzise per Verweilen anvisieren.
• Barrierefreiheits-Labels. Jedes interaktive Element sollte ein nützliches accessibilityLabel (SwiftUI) oder eine accessibilityLabel-Eigenschaft (UIKit) haben. Eye Tracking zeigt das Label als Tooltip-Äquivalent an, wenn der Benutzer in der Nähe des Elements verweilt.
• Logische Fokusreihenfolge. Die Tab-Taste auf dem Mac und die Fokus-Engine auf tvOS verwenden dieselbe Fokusreihenfolge, die Eye Tracking nutzt, um zwischen Elementen zu springen. Apps, die SwiftUIs Standard-Layout-Primitive verwenden, erhalten dies kostenlos; Apps, die das Fokusverhalten überschreiben, müssen es überprüfen.
• Verweilfreundliche modale Muster. Ein Modal, das beim Tippen außerhalb automatisch geschlossen wird, kann Eye-Tracking-Benutzer frustrieren, deren Verweilpunkt den Modalbereich kurzzeitig verlassen kann. Apps mit modaler UI sollten explizite Schließen-Schaltflächen bereitstellen.

Apps, die Eye Tracking für bestimmte Ansichten ausschließen möchten (sensible Inhalte, komplexe gestenbasierte Spiele), haben keine dokumentierte Opt-out-API speziell für Eye Tracking. Die Funktion arbeitet auf jedem sichtbaren Inhalt, und die Verantwortung der App besteht darin, sicherzustellen, dass die Standard-Barrierefreiheitsoberfläche korrekt ist.

Der Beitrag zu Three Surfaces of an iOS App behandelt das übergreifende Muster: Die sichtbare UI ist eine Oberfläche, App Intents sind eine weitere, Barrierefreiheit ist die dritte. Eye Tracking nimmt an der sichtbaren UI-Oberfläche teil; diese Oberfläche richtig hinzubekommen ist das, was Eye Tracking, Switch Control, VoiceOver und Voice Control gleichzeitig ermöglicht.

Music Haptics: Die Audio-zu-Haptik-Brücke

Music Haptics übersetzt die Musikwiedergabe in Vibrationen der Taptic Engine, die mit dem Audio synchronisiert sind³. Die Funktion ist pro Benutzer optional (Einstellungen > Bedienungshilfen > Music Haptics) und funktioniert für jede Musik-App, die die API korrekt integriert, nicht nur für Apple Music.

Die Entwickleroberfläche befindet sich im MAMusicHapticsManager des MediaAccessibility.framework (iOS 18+). Eine Musik-App integriert Music Haptics in drei Schritten:

1. Unterstützung in Info.plist deklarieren. Fügen Sie den Schlüssel MusicHapticsSupported mit dem Wert YES hinzu. Das System verwendet dies, um zu wissen, ob die App am Music-Haptics-Rendering teilnimmt.
2. Zur aktiven Now-Playing-App werden. Die App muss Wiedergabe-Metadaten über MPNowPlayingInfoCenter.default().nowPlayingInfo veröffentlichen und die Now-Playing-Audio-Session besitzen. Das System benötigt eine bekannte aktive Now-Playing-Quelle, um die haptische Synthese zu steuern.
3. Einen ISRC für den abgespielten Track bereitstellen. Der Schlüssel MPNowPlayingInfoPropertyInternationalStandardRecordingCode (der International Standard Recording Code) ermöglicht es dem System, den haptischen Track nachzuschlagen, der zum Audio passt. Apple unterhält eine nach ISRC indexierte Bibliothek haptischer Assets; Tracks ohne ISRC erhalten keine Haptik, aber der Rest der Now-Playing-Integration funktioniert weiterhin.

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

Die Integration gilt für jede Musik-App: einen Streaming-Client basierend auf AVAudioEngine, eine DJ-App mit benutzerdefinierten Decodern, eine Musiklern-App mit Sample-Wiedergabe. Die Einschränkung ist der ISRC und die aktive Now-Playing-Rolle, nicht die zugrunde liegende Audio-API. Apps ohne ISRCs (vom Benutzer hochgeladene Musik ohne Metadaten, generative Musik) erhalten einfach keine Haptik; der Rest der Wiedergabe-Integration ist davon nicht betroffen.

Für Apps in angrenzenden Bereichen (Rhythmus-Spiele, Musikvisualisierungen, Soundeffekt-Engines) ist das Audio nicht das, wofür Music Haptics konzipiert ist. Diese Apps greifen direkt auf CHHapticEngine mit handgefertigten haptischen Mustern zurück, die mit ihrer Audioquelle synchronisiert sind.

Vocal Shortcuts: Wo Barrierefreiheit auf App Intents trifft

Vocal Shortcuts ermöglichen es Benutzern, benutzerdefinierte Sprachphrasen zu Siri-Kurzbefehlen zuzuweisen, einschließlich solcher, die durch Drittanbieter-AppIntent-Typen unterstützt werden⁵. Ein Benutzer kann „Marker” so konfigurieren, dass es einen AddTodoIntent auslöst, der von einer To-Do-App registriert wurde; das Sagen von „Marker” — wo immer der Benutzer ist, ohne Siris Aktivierungsphrase aufzurufen — löst den Intent aus.

Die Integration verwendet das App-Intents-Framework, das der Cluster ausführlich behandelt hat, mit einem strukturellen Element, das leicht übersehen wird: Die App muss einen AppShortcutsProvider deklarieren, der AppShortcut-Einträge mit expliziten phrases bereitstellt. Ein bloßer AppIntent existiert im System, ist aber nur über den Shortcuts-Editor aufrufbar, in dem der Benutzer manuell einen Kurzbefehl zusammenstellt. Ein AppShortcutsProvider registriert systemweit sichtbare Kurzbefehle, die der Benutzer sofort einem Vocal Shortcut, der Action Button, Siri oder Spotlight zuweisen kann.

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

Das phrases-Array ist das, was das System gegenüber Siri und Vocal Shortcuts bereitstellt. Mit dem Provider an Ort und Stelle ist der App Intent sofort für die Sprachaktivierung berechtigt. Ohne ihn funktioniert der Intent über die manuelle Shortcuts-Einrichtung, aber der Weg ist länger und viele Benutzer erreichen ihn nie.

Das Muster verstärkt sich mit App Intents und App Intents vs MCP Tools. Ein App Intent, der sich seinen Platz in der Apple-Intelligence-Oberfläche des Benutzers verdient hat, gepaart mit einem AppShortcutsProvider, der deklariert, wie der Benutzer ihn aufruft, verdient sich auch seinen Platz als Vocal-Shortcut-Ziel. Das Argument des Clusters, dass App Intents der systemübergreifende Vertrag dafür sind, „was eine App tun kann”, gilt hier: Vocal Shortcuts sind ein weiterer Konsument desselben Vertrags.

Das übergreifende Muster: Standards sind die Integration

Die obigen Barrierefreiheitsfunktionen teilen eine strukturelle Eigenschaft: Jede ist auf Standards aufgebaut, die Apps ohnehin erfüllen sollten, mit einer kleinen Opt-in-API-Oberfläche für Fälle, in denen die App ausdrücklich kooperieren muss (Personal-Voice-Autorisierung, Music Haptics über MPMusicPlayerController).

Die Implikation für Entwicklerteams: Barrierefreiheitsarbeit ist kein separater Arbeitsstrom, der erledigt wird, nachdem die App ausgeliefert wurde. Die Barrierefreiheits-Labels, Trefferflächen, Fokusreihenfolge und die standardmäßige System-API-Nutzung der App sind das, was Eye Tracking funktionieren lässt, Live Speech korrekt routet, Music Haptics aktiviert und Vocal Shortcuts die richtigen Intents bereitstellt. Apps, die Barrierefreiheit als Häkchen am Ende des Zyklus behandeln, liefern Funktionen aus, die für VoiceOver funktionieren, aber nicht für Eye Tracking, oder die Audio auf Weisen routen, denen Live Speech nicht folgen kann.

Der Beitrag des Clusters What I Refuse to Write About plädiert für Verweigerung als Positionierungsmaßnahme. Barrierefreiheits-Verweigerungen sind das Gegenstück: nicht „Ich weigere mich, dies hinzuzufügen”, sondern „Ich weigere mich, etwas auszuliefern, das die Standards nicht erfüllt, die jede iOS-App bereits erfüllen sollte”.

Wann Apps benutzerdefinierten Barrierefreiheitscode benötigen

Drei Fälle, in denen das standardgetreue Muster nicht alles abdeckt:

Benutzerdefinierte Zeichenflächen. Eine Zeichen-App, ein Diagramm, eine benutzerdefiniert gerenderte Spiel-UI umgehen den SwiftUI/UIKit-Barrierefreiheitsbaum. Die App muss ihren eigenen Barrierefreiheitsbaum mit UIAccessibilityCustomAction, UIAccessibilityElement und expliziten Barrierefreiheitseigenschaften für jedes bedeutsame Element aufbauen. Eye Tracking, VoiceOver und Switch Control verlassen sich alle darauf, dass der Barrierefreiheitsbaum gefüllt ist.

Echtzeit-gestische Interaktionen. Ein Spiel mit kontinuierlicher Gesteneingabe (Zeichnen, Drag-to-Aim) lässt sich nicht natürlich auf verweilbasierte oder schalterbasierte Eingabe abbilden. Der richtige Ansatz ist, alternative Steuerungsschemata bereitzustellen (schaltflächenbasierte Eingabe als Option), anstatt gegen das Barrierefreiheitssystem zu arbeiten.

Barrierefreiheitsspezifische Funktionen. AAC-Apps, Sprachverstärkungs-Apps, Apps zur Gebärdensprachen-Übersetzung. Diese Apps sind eigenständige Barrierefreiheitsprodukte und integrieren sich tief mit Systemframeworks (Personal Voice, Speech-Framework, Vision-Framework zur Gebärdenspracherkennung). Die Integrationsarbeit ist real und beabsichtigt.

Was dieses Muster für iOS 26+ Apps bedeutet

Drei Erkenntnisse.

1. Barrierefreiheits-Beteiligung bedeutet hauptsächlich Standardbefolgung, nicht Funktionsentwicklung. Apple verlagert Barrierefreiheit zunehmend in die Plattformschicht. Die Arbeit besteht darin, sicherzustellen, dass Ihre App die Standards erfüllt, auf die Eye Tracking, Switch Control, VoiceOver und Voice Control angewiesen sind: korrekte Labels, Trefferflächen, Fokusreihenfolge, Systemaudio-Routing.

2. Die Personal-Voice-Integration ist sensibel. Wenn Ihre App einen echten AAC-Anwendungsfall hat (assistive Kommunikation, Sprachverstärkung, Barrierefreiheits-Tools), ist die Personal-Voice-Autorisierung die richtige Integration. Für allgemein einsetzbare Apps wird die Anforderung einer Personal-Voice-Autorisierung Benutzer eher verwirren als ihnen helfen.

3. App Intents sind Barrierefreiheits-Infrastruktur. Ein sauberer AppIntent ist automatisch für Vocal Shortcuts berechtigt, erhält über Shortcuts eine zugängliche UI-Oberfläche und integriert sich mit den sprachgesteuerten und schaltergesteuerten Steuerungsmodi des Systems. Das Argument des Clusters für die Einführung von App Intents gilt auch für Barrierefreiheit.

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; Two MCP Servers; Hooks für Apple-Entwicklung; Live Activities; die watchOS-Laufzeit; SwiftUI-Interna; RealityKits räumliches mentales Modell; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattformmatrix; Vision-Framework; Symbol Effects; Core-ML-Inferenz; Writing-Tools-API; Swift Testing; Privacy Manifest; worüber ich mich weigere zu schreiben. Der Hub befindet sich unter der Apple Ecosystem Series. Für einen breiteren Kontext zu iOS mit AI-Agents siehe den iOS Agent Development guide.

FAQ

Muss ich Code schreiben, um Eye Tracking zu unterstützen?

Für die meisten Apps nein. Eye Tracking funktioniert automatisch mit jeder Benutzeroberfläche, die den Standardkonventionen für Barrierefreiheit folgt: korrekte Trefferflächen (44pt Minimum), nützliche Barrierefreiheits-Labels, logische Fokusreihenfolge und standardmäßige Systemsteuerelemente. Apps, die ihre eigene UI zeichnen (benutzerdefinierte Views, Spiele, Diagramme), müssen den Barrierefreiheitsbaum explizit mit UIAccessibilityElement oder den Barrierefreiheits-Modifiern von SwiftUI füllen; diese Arbeit ist auch das, was die App für VoiceOver und Switch Control funktionieren lässt.

Kann ich Personal Voice in einer allgemein einsetzbaren Voice-over-App verwenden?

Das System erlaubt es über AVSpeechSynthesizer.requestPersonalVoiceAuthorization(), aber Apples Leitlinie und der App-Store-Review-Prozess betonen Personal Voice für assistive Kontexte (AAC, augmentative und alternative Kommunikation). Allgemein einsetzbare Voice-over-Apps, die eine Personal-Voice-Autorisierung anfordern, stehen vor zwei Herausforderungen: Benutzer werden die Autorisierung wahrscheinlich nicht erteilen, und das Review kann die Anfrage als unangemessene Nutzung zurückweisen. Wenn Ihr Anwendungsfall wirklich assistiv ist, ist die Integration richtig; wenn es sich um allgemein einsetzbare Sprachausgabe handelt, sind Systemstimmen das richtige Werkzeug.

Was ist der Unterschied zwischen Live Speech und Personal Voice?

Personal Voice ist die geräteinterne synthetisierte Stimme, die wie der Benutzer klingt. Live Speech ist die Systemfunktion, die es dem Benutzer ermöglicht zu tippen und das Gerät sprechen zu lassen (entweder mit einer Systemstimme oder seiner Personal Voice). Sie sind komplementär: Personal Voice liefert die Stimme, Live Speech liefert die Tipp-zu-Sprache-UI. Apps integrieren Personal Voice über die Speech-Synthesizer-API; Live Speech ist für Apps unsichtbar und arbeitet auf OS-Ebene.

Wie füge ich Music Haptics zu einer Musik-App hinzu, die AVAudioEngine verwendet?

Sie können das. Music Haptics ist nicht auf eine bestimmte Wiedergabe-API beschränkt. Die Integration ist: Fügen Sie MusicHapticsSupported = YES zur Info.plist hinzu, veröffentlichen Sie die Metadaten des abgespielten Tracks über MPNowPlayingInfoCenter.default().nowPlayingInfo (damit das System Ihre App als aktive Now-Playing-Quelle erkennt) und schließen Sie MPNowPlayingInfoPropertyInternationalStandardRecordingCode mit dem ISRC des Tracks ein. Das System übernimmt von dort aus die haptische Synthese. Tracks ohne ISRC erhalten keine Haptik, aber der Rest der Now-Playing-Integration funktioniert normal.

Was ist das App-Intent-Design, das die beste Vocal-Shortcuts-Erfahrung bietet?

Vier Prinzipien. Erstens: Deklarieren Sie einen AppShortcutsProvider für die App und registrieren Sie AppShortcut-Einträge für die Intents, die Sie sprachzugänglich haben möchten. Ohne den Provider erreicht der Intent Vocal Shortcuts nur über die manuelle Shortcuts-Bearbeitung. Zweitens: title und shortTitle sollten kurze Verbphrasen sein („Add Todo”, „Start Timer”) und keine Beschreibungen. Drittens: Parameter sollten optional sein oder Standardwerte haben, damit der Benutzer den Intent aufrufen kann, ohne jedes Feld anzugeben. Viertens: Die description sollte ein einziger klarer Satz sein, der die Wirkung des Intents erklärt; dies erscheint als Kontext, wenn der Benutzer eine Phrase zur Zuweisung auswählt.

Quellen