Writing Tools API: cómo las apps se conectan a la capa de escritura de Apple Intelligence

La capa de escritura de Apple Intelligence, con la marca Writing Tools, está disponible en todos los dispositivos con iOS 18+ que tengan Apple Intelligence activado. El usuario selecciona texto, toca el menú Writing Tools y obtiene corrección, reescritura (amigable, profesional, conciso), resumen, generación de listas y tablas y (desde iOS 18.2) composición generativa¹. La capacidad reside en la capa del sistema, no en una app concreta, y el usuario espera que funcione en todas las entradas de texto.

Las apps que usan UITextView, NSTextView o WKWebView obtienen la integración sin escribir código, siempre que la vista de texto se ejecute sobre TextKit 2². Las apps con motores de texto personalizados necesitan el API UIWritingToolsCoordinator para conectar su almacenamiento y renderizado de texto con la experiencia de Writing Tools. Esta entrada recorre la superficie del API frente a la documentación de Apple, nombra los tres niveles de adopción y cubre cuándo desactivarlo (porque no toda entrada de texto debería aceptar reescrituras generativas).

TL;DR

• Las vistas de texto estándar (UITextView, NSTextView, WKWebView) sobre TextKit 2 obtienen Writing Tools de manera gratuita, con la experiencia completa de reescritura en línea con animación².
• Las vistas de texto personalizadas adoptan UITextInteraction para obtener la integración del callout/menú contextual sin más código; la integración en línea completa requiere el API UIWritingToolsCoordinator³.
• UIWritingToolsBehavior es una única propiedad enum que controla el nivel de la experiencia: .complete, .limited o .none⁴. El valor .default es una solicitud que el sistema resuelve en tiempo de ejecución a uno de esos tres; no es un cuarto nivel. Para texto sensible (contraseñas, editores de código fuente, campos de chat que los usuarios no quieren que se reescriban), establece .none.
• allowedWritingToolsResultOptions permite a las apps declarar qué formas de salida aceptan (texto plano, texto enriquecido, listas, tablas o .presentationIntent en iOS 26) para que Writing Tools no devuelva contenido que la app no puede renderizar⁵.
• La conexión con flujos de trabajo de agentes: Writing Tools es una superficie de Apple Intelligence como App Intents y Foundation Models, pero opera en la capa de entrada de texto en lugar de la capa de acción.

Qué hace realmente Writing Tools

El menú Writing Tools en iOS 18+ expone un conjunto de operaciones sobre el texto seleccionado. El conjunto público actual, según la documentación para desarrolladores de Apple y la presentación en WWDC 2024⁶:

Corrección. Corrige gramática, ortografía, puntuación y elección de palabras. Devuelve un diff que el usuario puede aceptar, rechazar o recorrer paso a paso.

Reescritura. Tres tonos predefinidos (amigable, profesional, conciso) más un prompt personalizado del estilo “describe tu cambio”. El modelo reescribe el texto seleccionado en el tono elegido.

Resumen. El texto largo se vuelve corto. Las variantes incluyen “resumen”, “puntos clave”, “lista”, “tabla”. El usuario elige la forma.

Composición. Escritura generativa a partir de un prompt (iOS 18.2+). El usuario describe lo que quiere; el modelo genera texto nuevo en lugar de reescribir el texto existente.

El modelo que ejecuta Writing Tools es el modelo de cimientos en dispositivo de Apple en hardware compatible, con un respaldo en nube privada para solicitudes más grandes¹. El texto del usuario nunca llega a un tercero, jamás. La historia de privacidad es parte de la propuesta de valor.

Los tres niveles de adopción

Las apps caen en uno de tres grupos según cuánta integración con Writing Tools necesitan.

Nivel 1: vista de texto estándar (cero código)

Las apps que usan UITextView, NSTextView o WKWebView para entrada de texto obtienen Writing Tools sin escribir código alguno, siempre que la vista de texto use TextKit 2². El sistema gestiona el menú, la interfaz de reescritura en línea, la animación y los resaltados de corrección en línea. El trabajo de la app es usar la vista de texto estándar.

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

El requisito de TextKit 2 importa porque TextKit 1 viene con una arquitectura de diseño distinta que no admite la animación de reescritura en línea. Las apps nuevas que apunten a iOS 18+ deberían usar TextKit 2 por defecto; las apps heredadas pueden necesitar un paso de migración. UITextView usa TextKit 2 por defecto en iOS 16+ cuando se inicializa a través de Interface Builder o el inicializador moderno.

Nivel 2: vista de texto personalizada con UITextInteraction (solo callout)

Las apps con vistas de texto personalizadas pueden adoptar UITextInteraction para obtener Writing Tools en la barra de callout y el menú contextual sin más código⁷. El usuario puede invocar Writing Tools, ver la interfaz tipo panel para corrección/reescritura/resumen y aceptar o rechazar el resultado. El resultado se entrega a la app a través del flujo estándar de pegar/reemplazar.

La integración es parcial: la app no obtiene la animación en línea ni los resaltados de corrección en línea. Esos requieren el coordinador completo. Para la mayoría de las apps con vistas de texto personalizadas, la adopción de UITextInteraction es suficiente.

Nivel 3: UIWritingToolsCoordinator (experiencia en línea completa)

Las apps que quieren la experiencia completa de Writing Tools con almacenamiento de texto personalizado adoptan UIWritingToolsCoordinator (o NSWritingToolsCoordinator en macOS)³. El coordinador gestiona la conversación bidireccional entre Writing Tools y la app:

• La app proporciona el contexto del texto (un NSAttributedString que representa la selección actual más párrafos circundantes opcionales) al coordinador.
• El coordinador gestiona la UI del panel y la animación en línea.
• El coordinador llama de vuelta a través de un delegado para insertar, reemplazar o animar cambios de texto en el almacenamiento de texto de la app.

Métodos clave del delegado en UIWritingToolsCoordinator.Delegate, verificados contra los encabezados del SDK de iOS 26³:

• writingToolsCoordinator(_:requestsContextsForScope:completion:). El método de entrada. Writing Tools le pide a la app los contextos de texto relevantes (cada uno un NSAttributedString más un rango de selección) dentro de un alcance dado. La app construye los contextos a partir de su almacenamiento de texto y los devuelve.
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:). El caballo de batalla para los cambios de texto. Writing Tools propone texto nuevo para un rango dentro de un contexto; la app aplica el cambio a su almacenamiento y lo confirma.
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:). Se llama cuando una animación de texto (la transición entre el texto original y el reescrito) se completa para un rango. No es la señal de fin de sesión.
• writingToolsCoordinator(_:willChangeToState:completion:). La señal del ciclo de vida de la sesión. El coordinador transita entre estados (inactivo, interactivo, no interactivo, etc.) y notifica al delegado antes de cada transición. Aquí es donde la app responde a “sesión iniciada” y “sesión terminada”.

El API del coordinador está diseñado para motores de texto serializados (al estilo TextKit), editores con forma de documento y editores de código que quieren integración parcial. La sesión de Apple “Dive deeper into Writing Tools” en WWDC 2025⁸ recorre los casos de varios párrafos y varios estilos. Ten en cuenta que UIWritingToolsCoordinator se lanzó por primera vez como API público en iOS 18.2; iOS 26 lo profundiza en lugar de introducirlo.

La propiedad de comportamiento: UIWritingToolsBehavior

El control de activación/desactivación más importante es la propiedad writingToolsBehavior en UITextView, UITextField y cualquier vista que se ajuste a 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

Tres valores son niveles reales de experiencia; .default es una solicitud que el sistema resuelve a uno de los otros tres según los rasgos de la entrada de texto:

• .complete. La experiencia completa de Writing Tools, incluyendo animación de reescritura en línea, resaltados de corrección en línea y el panel. Mejor para editores de texto extenso (compositor de Mail, Notas, editores de documentos).
• .limited. La experiencia solo de panel. El usuario obtiene Writing Tools en el menú, pero las reescrituras suceden en un panel en lugar de en línea. Mejor para campos de texto más cortos donde la animación en línea se sentiría desproporcionada.
• .none. Writing Tools está deshabilitado para esta entrada de texto. Úsalo para contenido sensible.
• .default. Una solicitud, no un nivel. El encabezado documenta que el valor resuelto siempre será uno de .none, .limited o .complete; la propiedad de solo lectura behavior nunca devuelve .default. La mayoría de las apps deberían dejar la propiedad en .default a menos que haya una razón específica para anularla.

Cuándo desactivarlo

Tres categorías de entradas de texto donde .none es la decisión correcta:

Contraseñas y credenciales sensibles. Un campo de contraseña nunca debería ofrecer “reescribe esto en un tono amigable” como opción. El usuario está introduciendo texto literal que no debe transformarse. El UITextField de Apple con isSecureTextEntry = true ya deshabilita Writing Tools por defecto; un .none explícito es cinturón y tirantes.

Editores de código fuente. A un editor de código SwiftUI o un editor de Markdown para contenido técnico no le mejora que se le pida reescribir el código seleccionado en un tono “profesional”. Las rutas de reescritura de Writing Tools están afinadas para lenguaje natural, no para estructuras sintácticas. Establece .none en vistas de texto cuyo contenido no sea lenguaje natural.

Campos de chat donde reescribir cambia la intención. Una app de mensajería o un campo de comentarios donde las palabras exactas del usuario importan (por tono, voz, responsabilidad) puede querer omitir la reescritura mientras mantiene la corrección. El API actual de Writing Tools no permite restringir por acción; el valor .none deshabilita toda la experiencia. La jugada pragmática es .limited (solo panel, que el usuario tiene que invocar deliberadamente) para campos donde la reescritura es ocasionalmente apropiada pero no debería ser el predeterminado en línea.

allowedWritingToolsResultOptions declara qué puede renderizar tu app

Un control más sutil reside en UITextInputTraits.allowedWritingToolsResultOptions (también expuesto como UITextView.allowedWritingToolsResultOptions)⁵. La propiedad es un conjunto de opciones UIWritingToolsResultOptions que declara qué formas de contenido puede renderizar la vista de texto de la app:

• .plainText. La vista de texto admite texto plano (sin atributos de formato).
• .richText. Admite texto con formato (negrita, cursiva, etc.).
• .list. Admite renderizado de listas (con viñetas, numeradas).
• .table. Admite renderizado de tablas.
• .presentationIntent (iOS 26+). Admite marcado semántico de intención enriquecido (encabezados, citas en bloque, bloques de código) usando los tipos PresentationIntent del framework Foundation, que es una superficie más rica que el texto enriquecido plano.

Cuando se establece, Writing Tools restringe su salida a las formas que la app acepta. Un editor de texto plano que declare solo .plainText no recibirá una sugerencia de “convierte esto en una tabla”. Un editor de texto enriquecido que declare .richText y .list pero no .table obtendrá salida de listas pero no de tablas.

El valor por defecto es .default, que deja al sistema elegir según los rasgos de la vista de texto. Establece la propiedad explícitamente cuando la detección automática produce formas erróneas (una vista de texto que podría renderizar texto enriquecido pero el modelo de datos de la app solo almacena texto plano).

Dónde aterriza la salida

Para apps de Nivel 1 (vistas de texto estándar), la salida reemplaza la selección en línea a través de la maquinaria estándar de la vista de texto. No interviene código de la app.

Para apps de Nivel 2 (vistas personalizadas con UITextInteraction), la salida llega a través del flujo estándar de pegar. La implementación del protocolo UITextInput de la vista de texto es la que procesa el cambio. Las apps que han implementado correctamente UITextInput obtienen la integración “gratis” una vez que se añade UITextInteraction.

Para apps de Nivel 3 (coordinador completo), la salida llega a través del método replaceRange: del delegado. La app aplica el cambio a su almacenamiento de texto, devuelve los nuevos límites del texto en el manejador de finalización, y el coordinador gestiona la transición visual. La app sigue siendo la fuente de verdad para el almacenamiento de texto.

Qué añadió la inmersión profunda de WWDC 2025

La sesión “Dive deeper into Writing Tools” de WWDC 2025⁸ amplió el API de iOS 18 a lo largo de tres ejes que vale la pena nombrar:

Contexto de varios párrafos. Las apps ahora pueden proporcionar más contexto circundante al coordinador, permitiendo que Writing Tools opere sobre selecciones que dependen de párrafos circundantes (una oración cuyo significado depende del párrafo anterior, por ejemplo).

Prompts personalizados de reescritura. La ruta “describe tu cambio” que estaba en beta en iOS 18.2 se hizo totalmente pública, con ganchos de delegado para apps que quieren inspeccionar o transformar el prompt del usuario antes de pasarlo al modelo.

Mejor manejo de contenido mixto. Las selecciones de texto que abarcan varios estilos o incluyen imágenes embebidas ahora fluyen a través del coordinador con el contenido embebido preservado como rangos opacos. El coordinador no intenta reescribir una imagen en línea; la conserva y reescribe el texto circundante.

Los deltas son extensiones del modelo de iOS 18 en lugar de un reemplazo. Las apps que adoptaron los APIs de Writing Tools de iOS 18 siguen funcionando; iOS 26 desbloquea una integración más profunda para las apps que la necesitan.

La conexión con flujos de trabajo de agentes

Writing Tools es una de las tres superficies de Apple Intelligence con las que una app de terceros puede integrarse:

Writing Tools. La capa de entrada de texto. El usuario selecciona texto, le pide al sistema que lo transforme y obtiene el resultado en línea. Las apps participan exponiendo vistas de texto bien formadas y (opcionalmente) implementando el coordinador. El usuario invoca; la app recibe el resultado.

App Intents. La capa de acción. El usuario (o un agente) le pide a Apple Intelligence que realice una acción; el sistema enruta la solicitud a un intent registrado en la app. Las apps participan declarando tipos AppIntent, esquemas de parámetros y tipos de resultado. Cubierto en App Intents son el nuevo API de Apple para tu app.

Foundation Models. La capa del LLM en tiempo de ejecución. Las apps invocan el LLM en dispositivo directamente a través del framework Foundation Models para la generación dentro de la app. Cubierto en Foundation Models LLM en dispositivo.

Las tres superficies se componen. Una app de toma de notas podría usar Writing Tools (para las reescrituras del usuario basadas en selección), App Intents (para “resume mis notas de ayer”) y Foundation Models (para una función generativa dentro de la app como el etiquetado automático). Cada capa es una integración distinta con un modelo mental de usuario distinto.

La entrada App Intents vs herramientas MCP cubre cuándo exponer una acción a través de App Intents (Apple Intelligence) frente a un servidor MCP (agentes generales). Writing Tools queda fuera de esa pregunta; es una superficie a nivel de sistema que no tiene un equivalente de agente de terceros en la cobertura del clúster.

Qué significa este patrón para apps de iOS 26+

Tres conclusiones.

1. Usa por defecto las vistas de texto estándar y TextKit 2. La mayoría de las apps no necesitan el API del coordinador. Si la entrada de texto de la app es un UITextView o un WKWebView, Writing Tools funciona sin código; el trabajo está en la migración a TextKit 2 si la app aún ejecuta TextKit 1.

2. Establece writingToolsBehavior = .none deliberadamente para entradas sensibles. Contraseñas, editores de código, campos de texto exacto. El predeterminado intenta hacer lo correcto, pero el ajuste explícito es una decisión de producto defendible que el equipo puede articular.

3. Recurre a UIWritingToolsCoordinator solo cuando el motor de texto de la app sea genuinamente personalizado. Editores de Markdown, editores de código, apps de documentos con renderizado personalizado, vistas de texto al estilo terminal. El coordinador es una inversión real de ingeniería; el Nivel 2 (UITextInteraction) es suficiente para la mayoría de las vistas personalizadas.

El clúster completo del Ecosistema Apple: App Intents tipados; servidores MCP; la pregunta del enrutamiento; Foundation Models; la distinción entre LLM en tiempo de ejecución y de herramientas; tres superficies; el patrón de fuente única de verdad; Dos servidores MCP; hooks para el desarrollo en Apple; Live Activities; el contrato del runtime de watchOS; interioridades de SwiftUI; el modelo mental espacial de RealityKit; disciplina de esquemas en SwiftData; patrones de Liquid Glass; envío multiplataforma; la matriz de plataformas; framework Vision; Symbol Effects; inferencia de Core ML; sobre lo que me niego a escribir. El hub está en la serie del Ecosistema Apple. Para un contexto más amplio sobre iOS con agentes de IA, consulta la guía de Desarrollo de agentes en iOS.

Preguntas frecuentes

¿Necesito Apple Intelligence para probar Writing Tools en mi app?

Para probar la experiencia completa del usuario, sí. El menú Writing Tools de cara al usuario solo aparece en dispositivos que tienen Apple Intelligence habilitado (iPhone 15 Pro o más nuevo, Mac M1 o más nuevo, con iOS 18+ / macOS 15+). Para fines de desarrollo, puedes probar la integración del API en cualquier simulador o dispositivo con iOS 18+ verificando que tu vista de texto exponga isWritingToolsActive y que los métodos del delegado estén conectados correctamente; el menú del sistema simplemente no aparecerá sin Apple Intelligence disponible.

¿Qué pasa si no hago nada respecto a Writing Tools en mi app de iOS 18+?

Para vistas de texto estándar (UITextView, WKWebView), Writing Tools aparece automáticamente. Para vistas de texto personalizadas sin UITextInteraction, Writing Tools no aparece en el menú y los usuarios no pueden invocarlo sobre el texto en tu app. No hacer nada es un predeterminado defendible para vistas donde Writing Tools sería inapropiado (campos de contraseña, editores de código); para entradas de texto generales, no hacer nada significa perderse una función del sistema que los usuarios buscarán.

¿Cuál es la diferencia entre .complete y .limited?

.complete ejecuta las reescrituras de Writing Tools en línea con una animación que transforma el texto original en la reescritura, además de resaltados de corrección en línea. .limited ejecuta Writing Tools a través de una UI de panel; el usuario ve la reescritura en una superficie separada y decide si aplicarla. Usa .complete para editores de texto extenso donde la animación en línea refuerza el flujo de edición; .limited para campos de texto más cortos donde el panel se siente apropiado.

¿Puedo personalizar los prompts o el comportamiento del modelo de Writing Tools?

El modelo y los prompts están controlados por el sistema. Las apps no pueden inyectar comportamientos de reescritura personalizados en el menú Writing Tools. Para funciones generativas de escritura específicas de la app, usa el framework Foundation Models directamente (cubierto en Foundation Models LLM en dispositivo) y expón la función a través de tu propia UI.

¿Cómo maneja Writing Tools selecciones mixtas (texto + imagen)?

Según “Dive deeper into Writing Tools” de WWDC 2025⁸, las selecciones mixtas que incluyen contenido embebido (imágenes, adjuntos) fluyen a través del coordinador con el contenido embebido preservado como rangos opacos. Writing Tools reescribe el texto circundante pero no intenta transformar el contenido embebido. Para apps que usan el coordinador, el delegado recibe cargas útiles de texto propuesto donde el rango del contenido embebido se marca como sin cambios.

Referencias