Writing Tools API : comment les apps se branchent sur la couche d'écriture d'Apple Intelligence

La couche d’écriture d’Apple Intelligence, sous la marque Writing Tools, est livrée dans chaque appareil iOS 18+ avec Apple Intelligence activé. L’utilisateur sélectionne du texte, appuie sur le menu Writing Tools, et obtient relecture, réécriture (amical, professionnel, concis), résumé, génération de listes et de tableaux, et (depuis iOS 18.2) composition générative¹. La capacité réside dans la couche système, pas dans une application particulière, et l’utilisateur s’attend à ce qu’elle fonctionne dans chaque champ de saisie de texte.

Les apps qui utilisent UITextView, NSTextView ou WKWebView obtiennent l’intégration sans écrire de code, à condition que la vue de texte tourne sur TextKit 2². Les apps avec des moteurs de texte personnalisés ont besoin du API UIWritingToolsCoordinator pour brancher leur stockage et leur rendu de texte sur l’expérience Writing Tools. Cet article parcourt la surface du API en regard de la documentation d’Apple, nomme les trois niveaux d’adoption, et couvre les cas où il faut désactiver l’intégration (parce que tous les champs de saisie de texte ne devraient pas accepter des réécritures génératives).

TL;DR

• Les vues de texte standard (UITextView, NSTextView, WKWebView) sur TextKit 2 obtiennent Writing Tools gratuitement, avec l’expérience complète de réécriture inline avec animation².
• Les vues de texte personnalisées adoptent UITextInteraction pour obtenir l’intégration au callout/menu contextuel sans code supplémentaire ; l’intégration inline complète nécessite le API UIWritingToolsCoordinator³.
• UIWritingToolsBehavior est une seule propriété enum qui contrôle le niveau d’expérience : .complete, .limited ou .none⁴. La valeur .default est une demande que le système résout à l’exécution vers l’une de ces trois ; ce n’est pas un quatrième niveau. Pour le texte sensible (mots de passe, éditeurs de code source, champs de chat que les utilisateurs ne veulent pas voir réécrits), définissez .none.
• allowedWritingToolsResultOptions permet aux apps de déclarer quelles formes de sortie elles acceptent (texte brut, texte riche, listes, tableaux, ou .presentationIntent dans iOS 26) afin que Writing Tools ne renvoie pas de contenu que l’app ne peut pas afficher⁵.
• Le lien avec les workflows d’agents : Writing Tools est une surface d’Apple Intelligence comme App Intents et Foundation Models, mais opère au niveau de la couche de saisie de texte plutôt qu’au niveau de la couche d’action.

Ce que fait réellement Writing Tools

Le menu Writing Tools dans iOS 18+ expose un ensemble d’opérations sur le texte sélectionné. L’ensemble public actuel, selon la documentation développeur d’Apple et la présentation WWDC 2024⁶ :

Relecture (Proofread). Corrige la grammaire, l’orthographe, la ponctuation et le choix des mots. Renvoie un diff que l’utilisateur peut accepter, rejeter ou parcourir étape par étape.

Réécriture (Rewrite). Trois tons préréglés (amical, professionnel, concis) plus une invite personnalisée « décrivez votre changement ». Le modèle réécrit le texte sélectionné dans le ton choisi.

Résumé (Summarize). Le texte long devient court. Les variantes incluent « résumé », « points clés », « liste », « tableau ». L’utilisateur choisit la forme.

Composition (Compose). Écriture générative à partir d’une invite (iOS 18.2+). L’utilisateur décrit ce qu’il veut ; le modèle génère un nouveau texte plutôt que de réécrire un texte existant.

Le modèle qui exécute Writing Tools est le modèle de fondation on-device d’Apple sur le matériel pris en charge, avec un fallback Private Cloud pour les requêtes plus volumineuses¹. Le texte de l’utilisateur ne va jamais à un tiers. L’argument vie privée fait partie de la proposition de valeur.

Les trois niveaux d’adoption

Les apps tombent dans l’un des trois paniers selon le niveau d’intégration de Writing Tools dont elles ont besoin.

Niveau 1 : vue de texte standard (zéro code)

Les apps qui utilisent UITextView, NSTextView ou WKWebView pour la saisie de texte obtiennent Writing Tools sans écrire de code, à condition que la vue de texte utilise TextKit 2². Le système gère le menu, l’UI de réécriture inline, l’animation et les surlignages de relecture inline. Le travail de l’app consiste à utiliser la vue de texte standard.

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

L’exigence TextKit 2 importe parce que TextKit 1 est livré avec une architecture de mise en page différente qui ne prend pas en charge l’animation de réécriture inline. Les nouvelles apps ciblant iOS 18+ devraient utiliser TextKit 2 par défaut ; les apps existantes peuvent nécessiter une étape de migration. UITextView utilise par défaut TextKit 2 sur iOS 16+ lorsqu’il est initialisé via Interface Builder ou l’initialiseur moderne.

Niveau 2 : vue de texte personnalisée avec UITextInteraction (callout uniquement)

Les apps avec des vues de texte personnalisées peuvent adopter UITextInteraction pour obtenir Writing Tools dans la barre de callout et le menu contextuel sans code supplémentaire⁷. L’utilisateur peut invoquer Writing Tools, voir l’interface de style panneau pour relecture/réécriture/résumé, et accepter ou rejeter le résultat. Le résultat est livré à l’app via le flux standard de coller/remplacer.

L’intégration est partielle : l’app n’obtient pas l’animation inline ni les surlignages de relecture inline. Ceux-ci nécessitent le coordinateur complet. Pour la plupart des apps avec des vues de texte personnalisées, l’adoption de UITextInteraction suffit.

Niveau 3 : UIWritingToolsCoordinator (expérience inline complète)

Les apps qui veulent l’expérience Writing Tools complète avec un stockage de texte personnalisé adoptent UIWritingToolsCoordinator (ou NSWritingToolsCoordinator sur macOS)³. Le coordinateur gère la conversation bidirectionnelle entre Writing Tools et l’app :

• L’app fournit le contexte textuel (un NSAttributedString représentant la sélection courante plus des paragraphes environnants optionnels) au coordinateur.
• Le coordinateur gère l’UI du panneau et l’animation inline.
• Le coordinateur rappelle via un délégué pour insérer, remplacer ou animer les changements de texte dans le stockage de texte de l’app.

Méthodes clés du délégué sur UIWritingToolsCoordinator.Delegate, vérifiées contre les en-têtes du SDK iOS 26³ :

• writingToolsCoordinator(_:requestsContextsForScope:completion:). La méthode d’entrée. Writing Tools demande à l’app les contextes textuels pertinents (chacun un NSAttributedString plus une plage de sélection) dans un périmètre donné. L’app construit les contextes à partir de son stockage de texte et les renvoie.
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:). La méthode de travail pour les changements de texte. Writing Tools propose un nouveau texte pour une plage dans un contexte ; l’app applique le changement à son stockage et confirme.
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:). Appelée lorsqu’une animation de texte (le morphing entre le texte original et le texte réécrit) se termine pour une plage. Ce n’est pas le signal de fin de session.
• writingToolsCoordinator(_:willChangeToState:completion:). Le signal du cycle de vie de la session. Le coordinateur passe par des états (idle, interactive, noninteractive, etc.) et notifie le délégué avant chaque transition. C’est là que l’app répond à « début de session » et « fin de session ».

Le API coordinateur est conçu pour les moteurs de texte sérialisés (de style TextKit), les éditeurs en forme de document, et les éditeurs de code qui veulent une intégration partielle. La session « Dive deeper into Writing Tools » d’Apple à la WWDC 2025⁸ parcourt les cas multi-paragraphes et multi-styles. À noter que UIWritingToolsCoordinator a d’abord été livré comme API public dans iOS 18.2 ; iOS 26 l’approfondit plutôt que de l’introduire.

La propriété de comportement : UIWritingToolsBehavior

Le contrôle d’opt-in/opt-out le plus important est la propriété writingToolsBehavior sur UITextView, UITextField et toute vue conforme à UITextInputTraits⁴ :

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

Trois valeurs sont de vrais niveaux d’expérience ; .default est une demande que le système résout vers l’une des trois autres en fonction des traits de la saisie de texte :

• .complete. L’expérience Writing Tools complète, y compris l’animation de réécriture inline, les surlignages de relecture inline et le panneau. Idéal pour les éditeurs de texte long (Mail composer, Notes, éditeurs de documents).
• .limited. L’expérience uniquement par panneau. L’utilisateur obtient Writing Tools dans le menu, mais les réécritures se produisent dans un panneau plutôt qu’inline. Idéal pour les champs de texte plus courts où l’animation inline semblerait disproportionnée.
• .none. Writing Tools est désactivé pour cette saisie de texte. À utiliser pour le contenu sensible.
• .default. Une demande, pas un niveau. L’en-tête documente la valeur résolue comme étant toujours l’une de .none, .limited ou .complete ; la propriété en lecture seule behavior ne renvoie jamais .default. La plupart des apps devraient laisser la propriété à .default à moins d’avoir une raison spécifique de la surcharger.

Quand désactiver l’intégration

Trois catégories de saisies de texte où .none est le bon choix :

Mots de passe et identifiants sensibles. Un champ de mot de passe ne devrait jamais offrir « réécrire ceci sur un ton amical » comme option. L’utilisateur saisit du texte littéral qui ne doit pas être transformé. Le UITextField d’Apple avec isSecureTextEntry = true désactive déjà Writing Tools par défaut ; un .none explicite est une ceinture-et-bretelles.

Éditeurs de code source. Un éditeur de code SwiftUI ou un éditeur Markdown pour le contenu technique n’est pas amélioré par le fait qu’on lui demande de réécrire le code sélectionné sur un ton « professionnel ». Les chemins de réécriture de Writing Tools sont calibrés pour le langage naturel, pas pour les structures syntaxiques. Définissez .none sur les vues de texte dont le contenu n’est pas du langage naturel.

Champs de chat où la réécriture change l’intention. Une app de messagerie ou un champ de commentaires où les mots exacts de l’utilisateur comptent (pour le ton, la voix, la responsabilité) pourrait vouloir omettre la réécriture tout en conservant la relecture. Le API actuel de Writing Tools ne permet pas un filtrage par action ; la valeur .none désactive toute l’expérience. Le mouvement pragmatique est .limited (uniquement par panneau, que l’utilisateur doit invoquer délibérément) pour les champs où la réécriture est occasionnellement appropriée mais ne devrait pas être l’inline par défaut.

allowedWritingToolsResultOptions déclare ce que votre app peut afficher

Un contrôle plus subtil se trouve sur UITextInputTraits.allowedWritingToolsResultOptions (également exposé en tant que UITextView.allowedWritingToolsResultOptions)⁵. La propriété est un option set UIWritingToolsResultOptions qui déclare quelles formes de contenu la vue de texte de l’app peut afficher :

• .plainText. La vue de texte prend en charge le texte brut (aucun attribut de formatage).
• .richText. Prend en charge le texte formaté (gras, italique, etc.).
• .list. Prend en charge le rendu de listes (à puces, numérotées).
• .table. Prend en charge le rendu de tableaux.
• .presentationIntent (iOS 26+). Prend en charge le balisage d’intention sémantique riche (titres, blocs de citation, blocs de code) en utilisant les types PresentationIntent du framework Foundation, qui constituent une surface plus riche que le simple texte riche.

Lorsqu’elle est définie, Writing Tools contraint sa sortie aux formes que l’app accepte. Un éditeur de texte brut déclarant uniquement .plainText n’obtiendra pas une suggestion « transforme ceci en tableau ». Un éditeur de texte riche déclarant .richText et .list mais pas .table obtiendra une sortie en liste mais pas une sortie en tableau.

La valeur par défaut est .default, qui laisse le système choisir en fonction des traits de la vue de texte. Définissez la propriété explicitement lorsque la détection automatique produit des formes erronées (une vue de texte qui pourrait rendre du texte riche mais dont le modèle de données de l’app ne stocke que du texte brut).

Où atterrit la sortie

Pour les apps de Niveau 1 (vues de texte standard), la sortie remplace la sélection inline via la machinerie standard de la vue de texte. Aucun code de l’app n’est impliqué.

Pour les apps de Niveau 2 (vues personnalisées avec UITextInteraction), la sortie arrive via le flux standard de collage. C’est l’implémentation du protocole UITextInput de la vue de texte qui traite le changement. Les apps qui ont correctement implémenté UITextInput obtiennent l’intégration « gratuitement » une fois UITextInteraction ajouté.

Pour les apps de Niveau 3 (coordinateur complet), la sortie arrive via la méthode replaceRange: du délégué. L’app applique le changement à son stockage de texte, renvoie les nouvelles limites du texte dans le gestionnaire de complétion, et le coordinateur gère la transition visuelle. L’app reste la source de vérité pour le stockage de texte.

Ce que la session approfondie de la WWDC 2025 a ajouté

La session « Dive deeper into Writing Tools » à la WWDC 2025⁸ a élargi le API d’iOS 18 selon trois axes qui méritent d’être nommés :

Contexte multi-paragraphes. Les apps peuvent désormais fournir davantage de contexte environnant au coordinateur, permettant à Writing Tools d’opérer sur des sélections qui dépendent des paragraphes environnants (une phrase dont le sens dépend du paragraphe au-dessus, par exemple).

Invites de réécriture personnalisées. Le chemin « décrivez votre changement » qui était en bêta dans iOS 18.2 est devenu pleinement public, avec des hooks de délégué pour les apps qui veulent inspecter ou transformer l’invite de l’utilisateur avant de la transmettre au modèle.

Meilleure gestion du contenu mixte. Les sélections de texte qui couvrent plusieurs styles ou incluent des images intégrées passent désormais par le coordinateur avec le contenu intégré préservé sous forme de plages opaques. Le coordinateur ne tente pas de réécrire une image inline ; il la préserve et réécrit le texte environnant.

Les évolutions sont des extensions du modèle iOS 18 plutôt qu’un remplacement. Les apps qui ont adopté les APIs Writing Tools d’iOS 18 continuent de fonctionner ; iOS 26 débloque une intégration plus profonde pour les apps qui en ont besoin.

Le lien avec les workflows d’agents

Writing Tools est l’une des trois surfaces d’Apple Intelligence avec lesquelles une app tierce peut s’intégrer :

Writing Tools. La couche de saisie de texte. L’utilisateur sélectionne du texte, demande au système de le transformer, obtient le résultat inline. Les apps participent en exposant des vues de texte bien formées et (optionnellement) en implémentant le coordinateur. L’utilisateur invoque ; l’app reçoit le résultat.

App Intents. La couche d’action. L’utilisateur (ou un agent) demande à Apple Intelligence d’effectuer une action ; le système route la requête vers une intention enregistrée dans l’app. Les apps participent en déclarant des types AppIntent, des schémas de paramètres et des types de résultat. Couvert dans App Intents Are Apple’s New API to Your App.

Foundation Models. La couche LLM d’exécution. Les apps invoquent directement le LLM on-device via le framework Foundation Models pour la génération in-app. Couvert dans Foundation Models on-device LLM.

Les trois surfaces se composent. Une app de prise de notes pourrait utiliser Writing Tools (pour les réécritures basées sur la sélection de l’utilisateur), App Intents (pour « résume mes notes d’hier »), et Foundation Models (pour une fonctionnalité générative in-app comme l’auto-tagging). Chaque couche est une intégration distincte avec un modèle mental utilisateur distinct.

L’article App Intents vs MCP Tools couvre quand exposer une action via App Intents (Apple Intelligence) versus un serveur MCP (agents généraux). Writing Tools se situe en dehors de cette question ; c’est une surface au niveau système qui n’a pas d’équivalent côté agent tiers dans la couverture du cluster.

Ce que ce pattern signifie pour les apps iOS 26+

Trois enseignements.

1. Utilisez par défaut les vues de texte standard et TextKit 2. La plupart des apps n’ont pas besoin du API coordinateur. Si la saisie de texte de l’app est un UITextView ou un WKWebView, Writing Tools fonctionne sans code ; le travail consiste à migrer vers TextKit 2 si l’app tourne encore sur TextKit 1.

2. Définissez writingToolsBehavior = .none délibérément pour les saisies sensibles. Mots de passe, éditeurs de code, champs à texte exact. Le défaut tente de faire la bonne chose, mais le réglage explicite est une décision produit défendable que l’équipe peut articuler.

3. N’utilisez UIWritingToolsCoordinator que lorsque le moteur de texte de l’app est véritablement personnalisé. Éditeurs Markdown, éditeurs de code, apps documentaires avec rendu personnalisé, vues de texte de style terminal. Le coordinateur est un véritable investissement d’ingénierie ; le Niveau 2 (UITextInteraction) suffit pour la plupart des vues personnalisées.

Le cluster Apple Ecosystem complet : App Intents typés ; serveurs MCP ; la question du routage ; Foundation Models ; la distinction LLM runtime versus tooling ; trois surfaces ; le pattern source unique de vérité ; Two MCP Servers ; hooks pour le développement Apple ; Live Activities ; le contrat runtime watchOS ; internals SwiftUI ; le modèle mental spatial de RealityKit ; discipline de schéma SwiftData ; patterns Liquid Glass ; livraison multiplateforme ; la matrice de plateforme ; framework Vision ; Symbol Effects ; inférence Core ML ; ce sur quoi je refuse d’écrire. Le hub se trouve à la Apple Ecosystem Series. Pour un contexte plus large iOS-avec-agents-IA, voir le iOS Agent Development guide.

FAQ

Ai-je besoin d’Apple Intelligence pour tester Writing Tools dans mon app ?

Pour tester l’expérience utilisateur complète, oui. Le menu Writing Tools côté utilisateur n’apparaît que sur les appareils dotés d’Apple Intelligence activé (iPhone 15 Pro ou plus récent, Mac M1 ou plus récent, avec iOS 18+ / macOS 15+). À des fins de développement, vous pouvez tester l’intégration du API sur n’importe quel simulateur ou appareil iOS 18+ en vérifiant que votre vue de texte expose isWritingToolsActive et que les méthodes du délégué sont correctement câblées ; le menu système ne s’affichera simplement pas sans Apple Intelligence disponible.

Que se passe-t-il si je ne fais rien à propos de Writing Tools dans mon app iOS 18+ ?

Pour les vues de texte standard (UITextView, WKWebView), Writing Tools s’affiche automatiquement. Pour les vues de texte personnalisées sans UITextInteraction, Writing Tools n’apparaît pas dans le menu et les utilisateurs ne peuvent pas l’invoquer sur le texte de votre app. Ne rien faire est un défaut défendable pour les vues où Writing Tools serait inapproprié (champs de mot de passe, éditeurs de code) ; pour la saisie de texte générale, ne rien faire revient à manquer une fonctionnalité système que les utilisateurs chercheront.

Quelle est la différence entre .complete et .limited ?

.complete exécute les réécritures de Writing Tools inline avec une animation qui transforme le texte original en réécriture, plus des surlignages de relecture inline. .limited exécute Writing Tools via une UI en panneau ; l’utilisateur voit la réécriture sur une surface séparée et décide de l’appliquer ou non. Utilisez .complete pour les éditeurs de texte long où l’animation inline renforce le flux d’édition ; .limited pour les champs de texte plus courts où le panneau semble plus approprié.

Puis-je personnaliser les invites de Writing Tools ou le comportement du modèle ?

Le modèle et les invites sont contrôlés par le système. Les apps ne peuvent pas injecter de comportements de réécriture personnalisés dans le menu Writing Tools. Pour des fonctionnalités d’écriture générative spécifiques à l’app, utilisez directement le framework Foundation Models (couvert dans Foundation Models on-device LLM) et exposez la fonctionnalité via votre propre UI.

Comment Writing Tools gère-t-il les sélections mixtes (texte + image) ?

Selon « Dive deeper into Writing Tools » de la WWDC 2025⁸, les sélections mixtes qui incluent du contenu intégré (images, pièces jointes) passent par le coordinateur avec le contenu intégré préservé sous forme de plages opaques. Writing Tools réécrit le texte environnant mais ne tente pas de transformer le contenu intégré. Pour les apps utilisant le coordinateur, le délégué reçoit des charges utiles de texte proposé où la plage du contenu intégré est marquée comme inchangée.

Références