TipTap en React Native: editor de texto enriquecido móvil

Un memo no es solo texto sin formato. Es una idea estructurada: títulos, negritas, listas con viñetas, bloques de código... y sobre todo listas de verificación interactivas. En una aplicación colaborativa como TAMSIV, una lista de verificación se convierte en una verdadera herramienta de coordinación de equipo. ¿El problema? Integrar un editor de texto enriquecido completo en una aplicación React Native es un desafío técnico que pocos desarrolladores abordan de frente.

Pasé tres semanas construyendo este editor. Tres semanas de errores de WebView, problemas con el teclado móvil y sincronización en tiempo real. Esto es todo lo que aprendí.

Puntos clave a recordar:
- TipTap funciona en React Native a través de una WebView con un puente bidireccional JSON
- Las listas de verificación colaborativas requieren dos modos: validación "individual" y "todos"
- La sincronización se realiza a nivel de elementos individuales, no del documento completo
- El teclado móvil es el mayor desafío técnico de la integración
- Supabase Realtime permite la sincronización en tiempo real sin CRDT complejos

¿Por qué un editor de texto enriquecido en una aplicación móvil?

La respuesta corta: porque el texto sin formato no es suficiente. Cuando tomas un memo en una reunión, quieres poner un título, subrayar una idea importante, crear una lista de acciones. Un campo TextInput básico no permite nada de eso.

Evalué varias opciones antes de empezar. La conclusión fue simple: las aplicaciones de productividad exitosas en 2026 — Notion, Obsidian, Craft — todas ofrecen un editor enriquecido. Se ha convertido en un estándar. Un memo de voz que se transforma en texto sin formato, eso ya es historia.

En TAMSIV, el editor de texto enriquecido se utiliza principalmente en los memos — esas notas largas que dictas por voz y que luego quieres enriquecer manualmente. El pipeline de voz genera texto estructurado, y el editor permite ajustarlo.

¿Cómo funciona TipTap en React Native?

TipTap es un editor fantástico en la web. Se basa en ProseMirror, es extensible, está bien documentado y la comunidad es activa. El problema: React Native no tiene DOM. TipTap no puede funcionar de forma nativa.

La solución que elegí: una WebView que incorpora el editor TipTap completo. La arquitectura se descompone así:

• Lado de la WebView: TipTap se ejecuta en un entorno web clásico, con toda su potencia
• Puente bidireccional: los mensajes pasan entre React Native y la WebView a través de postMessage / onMessage
• Serialización JSON: el contenido del editor se serializa en JSON TipTap, se envía al puente y luego se almacena en HTML en la base de datos

Este patrón no es ideal — añade una capa de complejidad — pero es el único que permite tener un editor enriquecido completo en el móvil sin reescribir ProseMirror desde cero.

¿Qué funcionalidades soporta el editor?

El editor TAMSIV soporta un conjunto completo de formato:

• Títulos (H1, H2, H3) para estructurar memos largos
• Negrita y cursiva para énfasis
• Listas con viñetas y numeradas
• Bloques de código para desarrolladores (sí, incluso en una aplicación de productividad)
• Listas de verificación interactivas — el corazón del sistema colaborativo

La elección fue deliberada: sin tablas, sin incrustaciones, sin fórmulas. Cada funcionalidad añadida complejiza el puente de la WebView y aumenta el riesgo de errores. Opté por un editor potente pero enfocado.

¿Es el teclado móvil el mayor desafío técnico?

Sí, sin duda. Y si ya has desarrollado con WebViews en móvil, sabes de lo que hablo.

El problema fundamental: cuando el usuario escribe en la WebView, se abre el teclado nativo del smartphone. Pero la WebView no es un componente nativo — no se comunica de forma natural con el sistema de gestión del teclado de Android o iOS. Resultado:

• El cursor desaparece debajo del teclado
• El desplazamiento automático no sigue la entrada
• El redimensionamiento de la vista es incorrecto
• En algunos dispositivos Android, el teclado se cierra y se vuelve a abrir de forma aleatoria

La solución requirió código específico por plataforma. En Android, escucho los eventos resize en la WebView y ajusto manualmente la altura. En iOS, es un poco más predecible gracias a KeyboardAvoidingView, pero aún así hay que gestionar el desplazamiento del cursor manualmente.

Pasé casi una semana entera únicamente en los problemas del teclado. Es el tipo de tema invisible para el usuario final — cuando funciona, nadie lo nota — pero que puede arruinar la experiencia si se gestiona mal.

¿Cómo funcionan las listas de verificación colaborativas?

Las listas de verificación son el corazón del valor colaborativo de TAMSIV. Una lista de compras compartida, un acta de reunión con acciones, un protocolo de equipo — todos estos casos de uso se basan en listas de verificación. Pero una lista de verificación colaborativa no funciona como una lista de verificación personal.

Implementé dos modos de validación:

Modo "Single": uno solo es suficiente

Caso de uso: "Comprar el café". El primer miembro del equipo que lo hace marca el elemento. Se acabó. No es necesario que todos confirmen — una sola persona es suficiente.

En la base de datos, es simple: un booleano is_checked y un checked_by (UUID del usuario). El primero que marca "gana".

Modo "Everyone": todos deben validar

Caso de uso: "Leer el acta de la reunión". Queremos asegurarnos de que cada miembro del equipo ha leído y confirmado. El elemento solo está "hecho" cuando el 100% de los miembros lo han marcado.

En la base de datos, es más complejo: una tabla de validación almacena el estado por usuario y por elemento. Cada marca es independiente. La interfaz de usuario muestra una barra de progreso ("3/5 han validado") y colorea el elemento de forma diferente según el estado.

Este sistema de doble validación está inspirado en lo que hacen herramientas profesionales como Jira o Monday.com, pero adaptado a un uso más ligero — grupos familiares, equipos pequeños, asociaciones.

¿Cómo se realiza la sincronización en tiempo real?

La sincronización es la última pieza del rompecabezas. Cuando dos personas editan el mismo memo o marcan elementos al mismo tiempo, todo debe permanecer coherente.

Utilizo Supabase Realtime para propagar los cambios. La elección técnica importante: la sincronización se realiza a nivel de elementos individuales, no del documento completo. Cuando marcas un elemento, solo ese elemento se actualiza y propaga — no todo el memo.

¿Por qué esta elección? Porque sincronizar un documento completo crea conflictos de fusión imposibles de resolver sin un sistema de tipo CRDT (Conflict-free Replicated Data Types). Los CRDT son elegantes en teoría, pero añaden una complejidad enorme para un caso de uso que no lo necesita.

El flujo de sincronización:

1. El usuario marca un elemento en la WebView
2. El puente envía el cambio a React Native
3. React Native escribe en Supabase a través del servicio dedicado
4. Supabase Realtime propaga el cambio a todos los suscriptores
5. Los otros clientes reciben la actualización y actualizan su WebView

Latencia típica: 200 a 500ms. No es Google Docs, pero es más que suficiente para listas de verificación y memos colaborativos. Lo importante es que los cambios nunca se pierdan.

¿Qué trampas evitar con TipTap en móvil?

Después de tres semanas de integración, aquí están las trampas que me hubiera gustado conocer antes de empezar:

1. El tamaño del bundle de la WebView. TipTap con todas sus extensiones pesa mucho. Tuve que ser selectivo con las extensiones importadas. Cada extensión no utilizada añadía peso a la carga inicial de la WebView.

2. El tiempo de carga inicial. La primera apertura del editor es lenta (~300ms) porque la WebView debe cargar, analizar el HTML, inicializar TipTap. Añadí un skeleton loader para enmascarar este retraso.

3. La gestión de la memoria. Las WebViews consumen mucha memoria. En dispositivos de gama baja (Android Go, por ejemplo), esto puede ser un problema. Implementé un sistema de carga perezosa que solo carga la WebView cuando el usuario abre el editor.

4. Los atajos de teclado. En tabletas con teclado externo, los usuarios esperan Ctrl+B para negrita, Ctrl+I para cursiva. Estos atajos funcionan de forma nativa en la WebView de TipTap, pero hay que asegurarse de que no sean capturados por React Native antes de llegar a la WebView.

5. Copiar y pegar. El contenido copiado del editor debe formatearse correctamente como texto enriquecido Y texto sin formato. TipTap lo gestiona de forma nativa, pero el puente de la WebView a veces puede romper el formato.

¿Cómo se integra el pipeline de voz con el editor?

Aquí es donde todo se conecta. El pipeline de voz de TAMSIV permite dictar un memo por voz. La IA transcribe, estructura y genera texto formateado. Este texto llega al editor TipTap ya estructurado — con títulos, listas, a veces incluso listas de verificación pre-rellenadas.

El usuario puede luego modificar el contenido manualmente: añadir una lista de verificación, reformatear un párrafo, insertar un bloque de código. Es la combinación de voz + editor enriquecido lo que hace que TAMSIV sea único. La voz para la captura rápida, el editor para el pulido.

Este patrón se une a lo que explico en el artículo sobre el dictáfono de voz: la voz es una herramienta de captura, no una herramienta de edición. El editor de texto enriquecido llena exactamente esa brecha.

¿Qué alternativas a TipTap existen para React Native?

Antes de elegir TipTap + WebView, evalué otros enfoques:

• Markdown nativo: más ligero, pero la experiencia de edición es mediocre en móvil. El usuario debe conocer la sintaxis Markdown.
• React Native personalizado con TextInput: posible para negrita/cursiva básica, pero inmanejable para listas, bloques de código y listas de verificación.
• Quill.js en WebView: similar a TipTap, pero menos extensible y la comunidad es menos activa.
• Editor nativo (Swift/Kotlin): el mejor rendimiento, pero duplica el trabajo de desarrollo ya que hay que mantener dos bases de código.

TipTap + WebView es el mejor compromiso: un solo código para ambas plataformas, máxima extensibilidad y una comunidad activa para los errores.

Lo que aprendí sobre la deuda técnica de los editores

Un editor de texto enriquecido es el tipo de característica que parece simple en la superficie pero que esconde una inmensa complejidad. Cada nuevo formato soportado (tablas, imágenes en línea, menciones @) añade interacciones imprevistas con el resto del sistema.

La lección clave: empezar con lo mínimo y añadir progresivamente. Empecé con títulos + negrita + listas. Las listas de verificación vinieron después. Los bloques de código aún después. Con cada adición, validaba la estabilidad en ambas plataformas antes de pasar a la siguiente.

Es exactamente la misma filosofía que apliqué a la refactorización de la arquitectura: una complejidad controlada en lugar de una deuda técnica que se acumula. Esto también se alinea con los principios que detallo en el artículo sobre la reestructuración de la base de datos.

Si estás desarrollando una aplicación móvil y estás considerando un editor de texto enriquecido, mi consejo: empieza por validar el teclado móvil. Si esa parte funciona, el resto seguirá. Si no funciona, ninguna cantidad de características salvará la experiencia del usuario.

El editor de TAMSIV no es el más potente del mercado — Notion y Craft lo hacen mejor. Pero es suficiente para el caso de uso objetivo, funciona en modo colaborativo y se integra de forma nativa con el pipeline de voz. A veces, "suficiente y fiable" es mejor que "espectacular e inestable".

Preguntas frecuentes

¿TipTap es gratuito para uso comercial?

Sí. TipTap es de código abierto bajo licencia MIT. El núcleo del editor y la mayoría de las extensiones son gratuitas. Solo algunas extensiones "Pro" (colaboración avanzada, gestión de comentarios) son de pago, pero no son necesarias para la mayoría de los casos de uso.

¿El editor funciona sin conexión?

El editor en sí funciona perfectamente sin conexión, ya que se ejecuta en una WebView local. Solo la sincronización en tiempo real requiere una conexión. Las modificaciones se ponen en cola y se sincronizan cuando se restablece la red.

¿Cuál es la diferencia entre una lista de verificación "single" y "everyone"?

En el modo "single", un solo miembro debe marcar para validar el elemento (ej: "comprar el café"). En el modo "everyone", cada miembro debe marcar individualmente (ej: "leer el acta"). El modo es configurable por elemento en el editor.

¿El rendimiento es correcto en dispositivos de gama baja?

Sí, con precauciones. La carga perezosa de la WebView evita cargar el editor hasta que sea necesario. En los dispositivos más modestos, el tiempo de apertura inicial puede alcanzar los 500ms, pero la edición sigue siendo fluida una vez cargado.

¿Por qué no usar un CRDT para la sincronización?

Los CRDT (como Yjs o Automerge) son potentes pero añaden una complejidad significativa. Para listas de verificación y memos colaborativos, la sincronización por elemento a través de Supabase Realtime es suficiente y mucho más sencilla de mantener.