Writing Tools API: Wie Apps sich in die Schreibebene von Apple Intelligence einklinken

Die Schreibebene von Apple Intelligence, vermarktet als Writing Tools, ist auf jedem iOS-18+-Gerät mit aktiviertem Apple Intelligence verfügbar. Der Benutzer markiert Text, tippt auf das Writing-Tools-Menü und erhält Korrekturlesen, Umformulierungen (freundlich, professionell, prägnant), Zusammenfassungen, Listen- und Tabellenerstellung sowie (seit iOS 18.2) generative Komposition¹. Die Funktion liegt auf der Systemebene, nicht in einer einzelnen App, und der Benutzer erwartet, dass sie in jedem Texteingabefeld funktioniert.

Apps, die UITextView, NSTextView oder WKWebView verwenden, erhalten die Integration ohne Code, sofern die Textansicht auf TextKit 2 läuft². Apps mit eigenen Text-Engines benötigen die UIWritingToolsCoordinator-API, um ihren Textspeicher und ihr Rendering in das Writing-Tools-Erlebnis einzubinden. Dieser Beitrag geht die API-Oberfläche anhand von Apples Dokumentation durch, benennt die drei Adaptionsstufen und behandelt, wann ein Opt-out angebracht ist (denn nicht jedes Texteingabefeld sollte generative Umformulierungen akzeptieren).

TL;DR

• Standard-Textansichten (UITextView, NSTextView, WKWebView) auf TextKit 2 erhalten Writing Tools kostenlos, mit dem vollständigen Inline-Umformulierungserlebnis inklusive Animation².
• Eigene Textansichten übernehmen UITextInteraction, um die Callout-/Kontextmenü-Integration ohne weiteren Code zu erhalten; die vollständige Inline-Integration erfordert die UIWritingToolsCoordinator-API³.
• UIWritingToolsBehavior ist eine einzelne Enum-Eigenschaft, die die Erlebnisstufe steuert: .complete, .limited oder .none⁴. Der Wert .default ist eine Anfrage, die das System zur Laufzeit auf eine dieser drei Stufen auflöst; es handelt sich nicht um eine vierte Stufe. Für sensiblen Text (Passwörter, Quellcode-Editoren, Chat-Felder, in denen Benutzer keine Umformulierungen wünschen) setzen Sie .none.
• Mit allowedWritingToolsResultOptions können Apps deklarieren, welche Ausgabeformen sie akzeptieren (Klartext, Rich-Text, Listen, Tabellen oder .presentationIntent in iOS 26), damit Writing Tools keine Inhalte zurückgibt, die die App nicht rendern kann⁵.
• Die Verbindung zum Agenten-Workflow: Writing Tools ist eine Apple-Intelligence-Oberfläche wie App Intents und Foundation Models, operiert aber auf der Texteingabe-Ebene statt auf der Aktionsebene.

Was Writing Tools tatsächlich tut

Das Writing-Tools-Menü in iOS 18+ stellt eine Reihe von Operationen auf markiertem Text bereit. Der aktuelle öffentliche Funktionsumfang gemäß Apples Entwicklerdokumentation und der WWDC-2024-Einführung⁶:

Korrekturlesen. Behebt Grammatik, Rechtschreibung, Zeichensetzung und Wortwahl. Liefert ein Diff zurück, das der Benutzer akzeptieren, ablehnen oder schrittweise durchgehen kann.

Umformulieren. Drei voreingestellte Tonarten (freundlich, professionell, prägnant) plus eine eigene Aufforderung („Beschreiben Sie Ihre Änderung”). Das Modell formuliert den ausgewählten Text im gewählten Ton um.

Zusammenfassen. Aus langem Text wird kurzer. Varianten umfassen „Zusammenfassung”, „Kernpunkte”, „Liste”, „Tabelle”. Der Benutzer wählt die Form.

Verfassen. Generatives Schreiben aus einer Eingabeaufforderung (iOS 18.2+). Der Benutzer beschreibt, was er möchte; das Modell erzeugt neuen Text, statt bestehenden umzuformulieren.

Das Modell, das Writing Tools antreibt, ist Apples On-Device-Foundation-Modell auf unterstützter Hardware, mit einem Private-Cloud-Fallback für größere Anfragen¹. Der Text des Benutzers gelangt niemals zu Dritten. Die Privatsphären-Geschichte ist Teil des Wertversprechens.

Die drei Adaptionsstufen

Apps fallen je nach erforderlichem Integrationsumfang in eine von drei Kategorien.

Stufe 1: Standard-Textansicht (kein Code)

Apps, die UITextView, NSTextView oder WKWebView für Texteingaben verwenden, erhalten Writing Tools ohne Code, sofern die Textansicht TextKit 2 nutzt². Das System übernimmt das Menü, die Inline-Umformulierungs-UI, die Animation und die Inline-Hervorhebungen beim Korrekturlesen. Die Aufgabe der App besteht darin, die Standard-Textansicht zu verwenden.

let textView = UITextView()
textView.text = "Original content."
textView.isEditable = true
// Writing Tools just works.

Die TextKit-2-Voraussetzung ist relevant, weil TextKit 1 mit einer anderen Layout-Architektur ausgeliefert wird, die die Inline-Umformulierungs-Animation nicht unterstützt. Neue Apps mit Ziel iOS 18+ sollten standardmäßig auf TextKit 2 setzen; Legacy-Apps benötigen möglicherweise einen Migrationsschritt. UITextView verwendet auf iOS 16+ standardmäßig TextKit 2, wenn es über Interface Builder oder den modernen Initialisierer initialisiert wird.

Stufe 2: Eigene Textansicht mit UITextInteraction (nur Callout)

Apps mit eigenen Textansichten können UITextInteraction übernehmen, um Writing Tools in der Callout-Leiste und im Kontextmenü ohne weiteren Code zu erhalten⁷. Der Benutzer kann Writing Tools aufrufen, die panelartige Oberfläche für Korrekturlesen/Umformulieren/Zusammenfassen sehen und das Ergebnis akzeptieren oder ablehnen. Das Ergebnis wird der App über den Standard-Einfüge-/Ersetzungs-Fluss übergeben.

Die Integration ist partiell: Die App erhält weder die Inline-Animation noch die Inline-Hervorhebungen beim Korrekturlesen. Diese erfordern den vollständigen Coordinator. Für die meisten Apps mit eigenen Textansichten reicht die Übernahme von UITextInteraction aus.

Stufe 3: UIWritingToolsCoordinator (vollständiges Inline-Erlebnis)

Apps, die das vollständige Writing-Tools-Erlebnis mit eigenem Textspeicher wünschen, übernehmen UIWritingToolsCoordinator (oder NSWritingToolsCoordinator auf macOS)³. Der Coordinator verwaltet die bidirektionale Kommunikation zwischen Writing Tools und der App:

• Die App liefert Textkontext (eine NSAttributedString-Repräsentation der aktuellen Auswahl plus optionale umgebende Absätze) an den Coordinator.
• Der Coordinator verwaltet die Panel-UI und die Inline-Animation.
• Der Coordinator ruft über einen Delegate zurück, um Textänderungen im Textspeicher der App einzufügen, zu ersetzen oder zu animieren.

Wesentliche Delegate-Methoden auf UIWritingToolsCoordinator.Delegate, abgeglichen mit den iOS-26-SDK-Headern³:

• writingToolsCoordinator(_:requestsContextsForScope:completion:). Die Eingangsmethode. Writing Tools fragt die App nach den relevanten Textkontexten (jeweils ein NSAttributedString plus ein Auswahlbereich) innerhalb eines bestimmten Bereichs. Die App erstellt die Kontexte aus ihrem Textspeicher und gibt sie zurück.
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:). Die Arbeitsmethode für Textänderungen. Writing Tools schlägt neuen Text für einen Bereich innerhalb eines Kontexts vor; die App wendet die Änderung auf ihren Speicher an und bestätigt.
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:). Wird aufgerufen, wenn eine Textanimation (das Morphen zwischen Originaltext und umformuliertem Text) für einen Bereich abgeschlossen ist. Nicht das Sitzungsende-Signal.
• writingToolsCoordinator(_:willChangeToState:completion:). Das Signal für den Sitzungs-Lebenszyklus. Der Coordinator wechselt zwischen Zuständen (idle, interactive, noninteractive usw.) und benachrichtigt den Delegate vor jedem Übergang. Hier reagiert die App auf „Sitzung beginnt” und „Sitzung endet”.

Die Coordinator-API ist für serialisierte Text-Engines (im TextKit-Stil), dokumentförmige Editoren und Code-Editoren konzipiert, die eine partielle Integration wünschen. Apples Session „Dive deeper into Writing Tools” auf der WWDC 2025⁸ geht die Mehrabsatz- und Mehrstil-Fälle durch. Beachten Sie, dass UIWritingToolsCoordinator erstmals als öffentliche API in iOS 18.2 ausgeliefert wurde; iOS 26 vertieft sie, statt sie einzuführen.

Die Behavior-Eigenschaft: UIWritingToolsBehavior

Die wichtigste Opt-in/Opt-out-Steuerung ist die Eigenschaft writingToolsBehavior auf UITextView, UITextField und jeder Ansicht, die UITextInputTraits entspricht⁴:

textView.writingToolsBehavior = .complete   // full inline experience
textView.writingToolsBehavior = .limited    // panel-only (no inline rewrite)
textView.writingToolsBehavior = .none       // disabled entirely
textView.writingToolsBehavior = .default    // request system default

Drei Werte sind tatsächliche Erlebnisstufen; .default ist eine Anfrage, die das System anhand der Eigenschaften der Texteingabe auf eine der anderen drei auflöst:

• .complete. Das vollständige Writing-Tools-Erlebnis einschließlich Inline-Umformulierungs-Animation, Inline-Korrekturlese-Hervorhebungen und Panel. Am besten für Langform-Texteditoren (Mail-Verfasser, Notizen, Dokumenteditoren).
• .limited. Das reine Panel-Erlebnis. Der Benutzer erhält Writing Tools im Menü, aber Umformulierungen finden in einem Panel statt inline statt. Am besten für kürzere Textfelder, in denen eine Inline-Animation unverhältnismäßig wirken würde.
• .none. Writing Tools ist für diese Texteingabe deaktiviert. Verwenden Sie dies für sensible Inhalte.
• .default. Eine Anfrage, keine Stufe. Der Header dokumentiert, dass der aufgelöste Wert immer einer von .none, .limited oder .complete ist; die Read-only-Eigenschaft behavior gibt niemals .default zurück. Die meisten Apps sollten die Eigenschaft auf .default belassen, sofern es keinen spezifischen Grund zum Überschreiben gibt.

Wann Sie ein Opt-out wählen sollten

Drei Kategorien von Texteingaben, in denen .none die richtige Wahl ist:

Passwörter und sensible Anmeldedaten. Ein Passwortfeld sollte niemals „Diesen Text in einem freundlichen Ton umformulieren” als Option anbieten. Der Benutzer gibt buchstäblichen Text ein, der nicht transformiert werden darf. Apples UITextField mit isSecureTextEntry = true deaktiviert Writing Tools bereits standardmäßig; explizites .none ist Hosenträger und Gürtel.

Quellcode-Editoren. Ein SwiftUI-Code-Editor oder ein Markdown-Editor für technische Inhalte wird nicht besser, wenn man ihn bittet, den ausgewählten Code in einem „professionellen” Ton umzuschreiben. Die Umformulierungspfade von Writing Tools sind auf natürliche Sprache abgestimmt, nicht auf syntaktische Strukturen. Setzen Sie .none auf Textansichten, deren Inhalt keine natürliche Sprache ist.

Chat-Felder, in denen Umformulierungen die Absicht verändern. Eine Messaging-App oder ein Kommentarfeld, in dem die genauen Worte des Benutzers wichtig sind (für Tonfall, Stimme, Verantwortung), möchte möglicherweise auf Umformulierung verzichten und Korrekturlesen beibehalten. Die aktuelle API von Writing Tools erlaubt kein aktionsspezifisches Gating; der Wert .none deaktiviert das gesamte Erlebnis. Der pragmatische Ansatz ist .limited (nur Panel, das der Benutzer bewusst aufrufen muss) für Felder, in denen Umformulierung gelegentlich angemessen ist, aber nicht der Inline-Standard sein sollte.

allowedWritingToolsResultOptions deklariert, was Ihre App rendern kann

Eine subtilere Steuerung sitzt auf UITextInputTraits.allowedWritingToolsResultOptions (auch als UITextView.allowedWritingToolsResultOptions verfügbar)⁵. Die Eigenschaft ist ein UIWritingToolsResultOptions-Optionsset, das deklariert, welche Inhaltsformen die Textansicht der App rendern kann:

• .plainText. Die Textansicht unterstützt Klartext (ohne Formatierungsattribute).
• .richText. Unterstützt formatierten Text (fett, kursiv usw.).
• .list. Unterstützt Listendarstellung (Aufzählungspunkte, nummeriert).
• .table. Unterstützt Tabellendarstellung.
• .presentationIntent (iOS 26+). Unterstützt reichhaltige semantische Intent-Auszeichnung (Überschriften, Blockzitate, Codeblöcke) über die PresentationIntent-Typen des Foundation-Frameworks, was eine reichhaltigere Oberfläche als reiner Rich-Text darstellt.

Wenn gesetzt, beschränkt Writing Tools seine Ausgabe auf Formen, die die App akzeptiert. Ein Klartext-Editor, der nur .plainText deklariert, erhält keinen „Mache daraus eine Tabelle”-Vorschlag. Ein Rich-Text-Editor, der .richText und .list, aber nicht .table deklariert, erhält Listenausgabe, aber keine Tabellenausgabe.

Der Standardwert ist .default, wodurch das System anhand der Eigenschaften der Textansicht entscheidet. Setzen Sie die Eigenschaft explizit, wenn die automatische Erkennung falsche Formen produziert (eine Textansicht, die Rich-Text rendern könnte, deren Datenmodell der App aber nur Klartext speichert).

Wo die Ausgabe landet

Bei Stufe-1-Apps (Standard-Textansichten) ersetzt die Ausgabe die Auswahl inline über die Standard-Textansicht-Maschinerie. Es ist kein App-Code beteiligt.

Bei Stufe-2-Apps (eigene Ansichten mit UITextInteraction) gelangt die Ausgabe über den Standard-Einfüge-Fluss. Die UITextInput-Protokoll-Implementierung der Textansicht verarbeitet die Änderung. Apps, die UITextInput korrekt implementiert haben, erhalten die Integration „kostenlos”, sobald UITextInteraction hinzugefügt wird.

Bei Stufe-3-Apps (vollständiger Coordinator) kommt die Ausgabe über die replaceRange:-Methode des Delegates. Die App wendet die Änderung auf ihren Textspeicher an, gibt die neuen Textgrenzen im Completion-Handler zurück, und der Coordinator übernimmt die visuelle Transition. Die App bleibt die einzige Quelle der Wahrheit für den Textspeicher.

Was die WWDC-2025-Vertiefung hinzugefügt hat

Die Session „Dive deeper into Writing Tools” auf der WWDC 2025⁸ erweiterte die iOS-18-API entlang dreier nennenswerter Achsen:

Mehrabsatz-Kontext. Apps können dem Coordinator nun mehr umgebenden Kontext bereitstellen, sodass Writing Tools auf Auswahlen operieren kann, die von umgebenden Absätzen abhängen (etwa ein Satz, dessen Bedeutung vom Absatz darüber abhängt).

Eigene Umformulierungs-Aufforderungen. Der „Beschreiben Sie Ihre Änderung”-Pfad, der in iOS 18.2 noch in der Beta war, wurde vollständig öffentlich, mit Delegate-Hooks für Apps, die die Aufforderung des Benutzers vor der Übergabe an das Modell prüfen oder transformieren möchten.

Bessere Behandlung gemischter Inhalte. Textauswahlen, die mehrere Stile umfassen oder eingebettete Bilder enthalten, fließen nun durch den Coordinator, wobei der eingebettete Inhalt als opake Bereiche erhalten bleibt. Der Coordinator versucht nicht, ein Inline-Bild umzuschreiben; er bewahrt es und formuliert den umgebenden Text um.

Die Erweiterungen sind Ergänzungen des iOS-18-Modells, nicht ein Ersatz. Apps, die iOS-18-Writing-Tools-APIs übernommen haben, funktionieren weiterhin; iOS 26 schaltet tiefere Integration für Apps frei, die sie benötigen.

Die Verbindung zum Agenten-Workflow

Writing Tools ist eine von drei Apple-Intelligence-Oberflächen, mit denen sich eine Drittanbieter-App integrieren kann:

Writing Tools. Die Texteingabe-Ebene. Der Benutzer markiert Text, bittet das System um eine Transformation und erhält das Ergebnis inline. Apps beteiligen sich, indem sie wohlgeformte Textansichten bereitstellen und (optional) den Coordinator implementieren. Der Benutzer ruft auf; die App empfängt das Ergebnis.

App Intents. Die Aktionsebene. Der Benutzer (oder ein Agent) bittet Apple Intelligence, eine Aktion auszuführen; das System leitet die Anfrage an einen registrierten Intent in der App weiter. Apps beteiligen sich, indem sie AppIntent-Typen, Parameterschemas und Ergebnistypen deklarieren. Behandelt in App Intents Are Apple’s New API to Your App.

Foundation Models. Die Laufzeit-LLM-Ebene. Apps rufen den On-Device-LLM direkt über das Foundation-Models-Framework für In-App-Generierung auf. Behandelt in Foundation Models on-device LLM.

Die drei Oberflächen lassen sich kombinieren. Eine Notizen-App könnte Writing Tools (für auswahlbasierte Umformulierungen des Benutzers), App Intents (für „Fasse meine Notizen von gestern zusammen”) und Foundation Models (für eine In-App-Generierungsfunktion wie automatisches Tagging) verwenden. Jede Ebene ist eine eigenständige Integration mit einem eigenen mentalen Modell für den Benutzer.

Der Beitrag App Intents vs MCP Tools behandelt, wann eine Aktion über App Intents (Apple Intelligence) gegenüber einem MCP-Server (allgemeine Agenten) bereitgestellt werden sollte. Writing Tools steht außerhalb dieser Frage; es ist eine Oberfläche auf Systemebene, die in der Cluster-Abdeckung kein Drittanbieter-Agenten-Äquivalent hat.

Was dieses Muster für iOS-26+-Apps bedeutet

Drei Erkenntnisse.

1. Standardmäßig die Standard-Textansichten und TextKit 2 verwenden. Die meisten Apps benötigen die Coordinator-API nicht. Wenn die Texteingabe der App eine UITextView oder eine WKWebView ist, funktioniert Writing Tools ohne Code; die Arbeit liegt in der TextKit-2-Migration, falls die App noch TextKit 1 verwendet.

2. writingToolsBehavior = .none bewusst für sensible Eingaben setzen. Passwörter, Code-Editoren, Felder mit exaktem Text. Der Standard versucht, das Richtige zu tun, aber die explizite Einstellung ist eine begründbare Produktentscheidung, die das Team artikulieren kann.

3. Greifen Sie nur dann zu UIWritingToolsCoordinator, wenn die Text-Engine der App wirklich eigen ist. Markdown-Editoren, Code-Editoren, Dokumenten-Apps mit eigenem Rendering, terminalartige Textansichten. Der Coordinator ist eine echte Engineering-Investition; Stufe 2 (UITextInteraction) reicht für die meisten eigenen Ansichten.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents; MCP-Server; die Routing-Frage; Foundation Models; die Unterscheidung Laufzeit vs 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-Internas; RealityKits räumliches mentales Modell; SwiftData-Schema-Disziplin; Liquid-Glass-Muster; Multi-Plattform-Auslieferung; die Plattform-Matrix; Vision-Framework; Symbol Effects; Core-ML-Inferenz; worüber ich mich weigere zu schreiben. Der Hub liegt unter Apple Ecosystem Series. Für breiteren iOS-mit-AI-Agenten-Kontext siehe den iOS Agent Development guide.

FAQ

Brauche ich Apple Intelligence, um Writing Tools in meiner App zu testen?

Um das vollständige Benutzererlebnis zu testen, ja. Das benutzersichtbare Writing-Tools-Menü erscheint nur auf Geräten mit aktiviertem Apple Intelligence (iPhone 15 Pro oder neuer, M1 Mac oder neuer, mit iOS 18+ / macOS 15+). Für Entwicklungszwecke können Sie die API-Integration auf jedem iOS-18+-Simulator oder -Gerät testen, indem Sie prüfen, dass Ihre Textansicht isWritingToolsActive bereitstellt und die Delegate-Methoden korrekt verdrahtet sind; das Systemmenü erscheint einfach nicht, ohne dass Apple Intelligence verfügbar ist.

Was passiert, wenn ich nichts zu Writing Tools in meiner iOS-18+-App unternehme?

Bei Standard-Textansichten (UITextView, WKWebView) erscheint Writing Tools automatisch. Bei eigenen Textansichten ohne UITextInteraction erscheint Writing Tools nicht im Menü und Benutzer können es nicht auf Text in Ihrer App aufrufen. Nichts zu tun ist ein begründbarer Standard für Ansichten, in denen Writing Tools unangemessen wäre (Passwortfelder, Code-Editoren); für allgemeine Texteingaben bedeutet Nichtstun, eine Systemfunktion zu verfehlen, nach der Benutzer suchen werden.

Was ist der Unterschied zwischen .complete und .limited?

.complete führt Writing-Tools-Umformulierungen inline aus, mit einer Animation, die den Originaltext in die Umformulierung morpht, plus Inline-Korrekturlese-Hervorhebungen. .limited führt Writing Tools über eine Panel-UI aus; der Benutzer sieht die Umformulierung in einer separaten Oberfläche und entscheidet, ob er sie übernehmen möchte. Verwenden Sie .complete für Langform-Texteditoren, in denen die Inline-Animation den Bearbeitungsfluss verstärkt; .limited für kürzere Textfelder, in denen das Panel sich richtig anfühlt.

Kann ich die Writing-Tools-Aufforderungen oder das Modellverhalten anpassen?

Modell und Aufforderungen werden vom System gesteuert. Apps können keine eigenen Umformulierungs-Verhaltensweisen in das Writing-Tools-Menü einschleusen. Für app-spezifische generative Schreibfunktionen verwenden Sie das Foundation-Models-Framework direkt (behandelt in Foundation Models on-device LLM) und bringen die Funktion über Ihre eigene UI an die Oberfläche.

Wie behandelt Writing Tools gemischte Auswahlen (Text + Bild)?

Gemäß „Dive deeper into Writing Tools” auf der WWDC 2025⁸ fließen gemischte Auswahlen, die eingebettete Inhalte (Bilder, Anhänge) enthalten, durch den Coordinator, wobei der eingebettete Inhalt als opake Bereiche erhalten bleibt. Writing Tools formuliert umgebenden Text um, versucht aber nicht, den eingebetteten Inhalt zu transformieren. Bei Apps, die den Coordinator verwenden, erhält der Delegate vorgeschlagene Text-Payloads, in denen der Bereich des eingebetteten Inhalts als unverändert markiert ist.

References