Lottie React Native

Probablemente estés en una de dos situaciones. O tienes un diseñador que te pasa un JSON de Lottie y te pregunta: “¿Podemos meterlo en la app hoy?”, o ya lo integraste y notaste que la animación funciona en desarrollo, pero empieza a sentirse costosa cuando entran en juego dispositivos reales, tiempo de arranque y builds de release.

Es ahí donde Lottie React Native se pone interesante. La demo básica es fácil. Una implementación lista para producción no lo es. La diferencia suele depender de cómo lo instalas, cómo controlas la reproducción y si tratas los archivos de animación como assets inofensivos o como parte de tu presupuesto de rendimiento.

Tabla de contenidos

Por qué Lottie es esencial para apps de React Native
- Diseño e ingeniería dejan de librar la misma batalla
- Dónde encaja mejor Lottie
Configuración de tu entorno de desarrollo con Lottie
Muestra tu primera animación de Lottie
Dominar los controles de animación de Lottie
Optimización de rendimiento para apps de producción
Solución de problemas comunes de Lottie

Por qué Lottie es esencial para apps de React Native

Si alguna vez has intentado recrear a mano una animación de producto pulida en React Native, ya conoces el dolor. Los pequeños detalles de movimiento se convierten en un montón de lógica de temporización, interpolaciones y peculiaridades de plataforma. La animación puede parecer cercana, pero "cercana" normalmente no es lo que el diseñador entregó.

Lottie cambió ese flujo de trabajo. Airbnb abrió el código de Lottie en 2016, y ese lanzamiento transformó la animación móvil al permitir que los diseñadores entreguen animaciones directamente, en lugar de obligar a los ingenieros a reconstruirlas cuadro a cuadro. En algunos entornos empresariales, ese cambio redujo los costos de desarrollo de aplicaciones móviles en hasta un 40%, according to la presentación de Lottie de Airbnb.

Diseño e ingeniería dejan de librar la misma batalla

Un beneficio clave de Lottie React Native no es solo "animaciones bonitas en JSON". Es la separación de responsabilidades. Los diseñadores trabajan en After Effects y exportan con Bodymovin. Los desarrolladores renderizan la salida con reproducción respaldada por nativo, en lugar de traducir el movimiento a code personalizado.

Eso importa porque el trabajo de animación tiene la costumbre de extenderse. Una sola animación de estado celebratorio puede involucrar la revisión de diseño, la revisión de producto, el comportamiento en Android, el comportamiento en iOS, la accesibilidad y el rendimiento de inicio. Lottie reduce esa superficie de impacto.

Regla práctica: Usa Lottie cuando la animación sea parte de la experiencia del producto, no cuando solo necesites una transición simple de opacidad o translate.

También hay un ángulo de experiencia de usuario. El movimiento da feedback, confirma acciones y hace que los estados de carga no se sientan tan estáticos. Si tu equipo piensa en serio en el pulido, la retención o la confianza en la interfaz, la animación es parte de esa conversación. El debate más amplio sobre la experiencia de usuario en apps suele terminar en el mismo lugar: el feedback rápido gana a las pantallas estáticas.

Dónde encaja mejor Lottie

Lottie React Native suele funcionar mejor para:

Micro-interacciones de marca como likes, guardados, checkmarks y estados de éxito de compra
Ilustraciones de onboarding que deben sentirse personalizadas sin enviar video
Estados de carga y vacíos donde la UI estática se siente incompleta
Educación sobre la función cuando el producto quiere movimiento sin incrustar GIFs o MP4s

Lo que no resuelve es cada problema de animación. Para transiciones básicas de pantalla, las propias herramientas de animación de React Native suelen ser más simples. Para sistemas de movimiento muy grandes o altamente interactivos, el formato JSON puede convertirse en un contratiempo en lugar de una ventaja. Ese contratiempo se vuelve más importante una vez que llegas a producción, que es donde la mayoría de los tutoriales se detienen demasiado pronto.

Configuración de tu entorno de desarrollo con Lottie

La ruta de instalación depende primero de una decisión: Expo managed workflow o bare React Native. No mezcles los modelos mentales. La mayoría de los problemas de configuración ocurren cuando los devs siguen una guía de bare workflow dentro de Expo, o asumen que Expo abstrae cada detalle nativo.

Un diagrama de flujo con los pasos de configuración de animaciones Lottie en proyectos de Expo y Bare React Native.

Elige el workflow antes de instalar

Si tu app está en Expo y quieres la configuración más rápida, quédate en la ruta de Expo a menos que sepas que necesitas trabajo nativo personalizado. Si estás en una app bare, o ya dependes de módulos nativos que necesitan control directo, instálalo como una dependencia nativa normal y valida los builds de iOS y Android de inmediato.

Muchos equipos subestiman cuánto más fácil se vuelve el debugging cuando mantienes tu configuración alineada con el tipo de proyecto. Por eso también muchos equipos que construyen integraciones nativas personalizadas comparan Capgo como alternativa a Expo EAS antes de que sea más difícil realizar cambios en la app.

Configuración gestionada con Expo

Para apps gestionadas con Expo, mantenlo al mínimo.

Instala el paquete
```
npx expo install lottie-react-native
```
Reinicia Metro
```
npx expo start -c
```
Verifica en dispositivo o simulador Empieza con un archivo JSON local y renderiza primero una animación muy pequeña. No depures a la vez un asset grande y una instalación nueva.

Algunas notas prácticas para Expo:

Prioriza archivos locales: Depurar animaciones remotas añade ruido de red cuando solo intentas confirmar que la librería funciona.
Prueba pronto el comportamiento en release: El modo development puede ocultar problemas de timing y rendimiento.
Ojo con las rutas de assets: Los archivos JSON mal ubicados son una de las causas más comunes de que no se renderice nada.

Expo es el camino más rápido para que funcione. Eso no significa que sea el camino más rápido para que escale.

Configuración de React Native bare

En un proyecto bare, instala y valida las dependencias nativas de inmediato.

Instala el paquete
```
npm install lottie-react-native
```
Instalar pods de iOS
```
cd ios && pod install && cd ..
```

Recompilar la app

npx react-native run-ios

npx react-native run-android

Aquí está la parte que muchas guías de inicio rápido omiten: después de instalar, haz una recompilación nativa completa antes de dar por hecho que algo está roto. El hot reload no salva una dependencia nativa que no se haya compilado bien en la app.

Comprobaciones del flujo Bare que ahorran tiempo

Usa este checklist breve antes de continuar:

Verificar	Por qué es importante
Recompilar tras la instalación	Los módulos nativos necesitan una compilación nueva
Ejecuta `pod install`	iOS no será fiable sin ello
Usa primero un JSON local simple	Aísla los problemas de instalación de los de assets
Prueba ambas plataformas pronto	Android e iOS pueden fallar por razones diferentes

Si el paquete se instala correctamente pero tu primera animación no aparece, normalmente no es un problema de instalación. Suele ser la ruta del asset, el tamaño del componente o la configuración de reproducción.

Muestra tu primera animación de Lottie

La primera animación funcional debe ser aburrida. Archivo local. Tamaño fijo. Autoplay activado. Bucle opcional. No empieces con reproducción condicional, JSON remoto o una exportación de animación con muchas capas.

Un espacio de trabajo de desarrollo moderno con un portátil mostrando code y un monitor con una app de animación móvil.

Añade un archivo de animación local

Crea una carpeta de assets si aún no tienes una:

assets/
  animations/
    success.json

Mantén los nombres simples. Evita espacios, puntuación extraña y carpetas con muchos niveles de anidación. Quieres que las require() rutas sean evidentes.

Si usas Lottie para una pantalla de carga inicial con marca o para la transición tras el lanzamiento, piénsalo bien antes de meter una animación grande en la ruta de arranque. Eso es especialmente cierto si también estás ajustando el comportamiento de la splash screen en React Native.

Renderízalo con LottieView

Crea un componente dedicado en lugar de meterlo directamente en un archivo de pantalla grande:

import React from 'react';
import { View, StyleSheet } from 'react-native';
import LottieView from 'lottie-react-native';

export function SuccessAnimation() {
  return (
    <View style={styles.container}>
      <LottieView
        source={require('../assets/animations/success.json')}
        autoPlay
        loop={false}
        style={styles.animation}
      />
    </View>
  );
}

const styles = StyleSheet.create({
  container: {
    alignItems: 'center',
    justifyContent: 'center',
  },
  animation: {
    width: 220,
    height: 220,
  },
});

Eso hace tres cosas útiles:

demuestra que la librería renderiza correctamente
demuestra que la ruta del recurso se resuelve correctamente
te da un lugar aislado para ajustar la reproducción y el tamaño más adelante

Algunos problemas aparecen de inmediato si omites lo básico:

Sin ancho ni alto: La animación puede existir pero ser invisible.
Mal require() ruta: Metro no encontrará el archivo.
Exportación inválida: Algunos archivos JSON son técnicamente válidos pero incluyen funciones que no se comportan como se espera en móvil.

Mantén el primer render local y determinista. Estás probando la integración, no la arquitectura.

Una mejor prueba de pantalla inicial

Coloca el componente en una pantalla simple con un fondo neutro:

import React from 'react';
import { SafeAreaView, StyleSheet } from 'react-native';
import { SuccessAnimation } from './src/SuccessAnimation';

export default function App() {
  return (
    <SafeAreaView style={styles.screen}>
      <SuccessAnimation />
    </SafeAreaView>
  );
}

const styles = StyleSheet.create({
  screen: {
    flex: 1,
    justifyContent: 'center',
    alignItems: 'center',
    backgroundColor: '#fff',
  },
});

Si funciona en los simuladores de iOS y Android, has superado el primer obstáculo real. A partir de ahí, el siguiente paso no es añadir más animaciones. Es aprender cuándo usar props declarativas y cuándo tomar el control directo con refs.

Dominar los controles de animación de Lottie

La mayoría de los errores de Lottie en React Native aparecen cuando la animación debe reaccionar al estado. El autoplay es fácil. «Reproduce este segmento cuando al usuario le gusta un elemento, invierte cuando lo desmarca y que no se entrecorte al volver a renderizar el componente»: ahí es donde las cosas se complican.

Gráfico comparativo que explica los métodos de control de animación declarativos frente a imperativos en Lottie, destacando sus casos de uso específicos.

Usa props cuando la reproducción es simple

Para una reproducción no interactiva, las props son suficientes.

<LottieView
  source={require('../assets/animations/loading.json')}
  autoPlay
  loop
  speed={1}
/>

Este estilo es útil para:

indicadores de carga
ilustraciones pasivas de onboarding
estados vacíos decorativos

Es declarativo y legible. El componente se monta, la reproducción comienza y React mantiene el control. Si la lógica de la animación se puede describir completamente con props, déjala ahí.

Un caso declarativo más avanzado es progress, donde vinculas el frame de la animación a otro valor. Funciona bien cuando el movimiento debe reflejar una fuente de progreso externa, pero es menos conveniente para eventos de disparo únicos.

Aquí tienes una comparación visual rápida antes de pasar a refs:

Usa refs cuando el estado impulse la animación

Cuando el usuario toca, alterna o completa una acción, un ref suele ser la herramienta más segura. Los datos del mundo real muestran El 68% de los desarrolladores que usan frameworks híbridos reporta fallos en los triggers de animación por un manejo incorrecto de refs en useEffect hooks, por lo que los patrones confiables construidos en torno a animation.current.play() importan, como se señala en esta discusión centrada en Capacitor sobre disparos fallidos.

Ese problema no se limita a las apps híbridas. También aparece en React Native puro, especialmente cuando los desarrolladores recrean refs, disparan la reproducción antes del mount o vinculan llamadas de animación a efectos inestables.

import React, { useRef, useState } from 'react';
import { Pressable } from 'react-native';
import LottieView from 'lottie-react-native';

export function LikeButton() {
  const animationRef = useRef<LottieView>(null);
  const [liked, setLiked] = useState(false);

  const onPress = () => {
    if (!animationRef.current) return;

    if (liked) {
      animationRef.current.play(60, 0);
    } else {
      animationRef.current.play(0, 60);
    }

    setLiked(!liked);
  };

  return (
    <Pressable onPress={onPress}>
      <LottieView
        ref={animationRef}
        source={require('../assets/animations/like.json')}
        loop={false}
        autoPlay={false}
        style={{ width: 96, height: 96 }}
      />
    </Pressable>
  );
}

Un patrón fiable de like y unlike

Este patrón funciona mejor en producción que llamar play() dentro del useEffect cada vez que cambia el estado.

Por qué funciona:

El evento controla el disparo de la animación: Un evento de pulsación es un momento estable para iniciar la reproducción.
La ref permanece local y persistente: useRef evita rerenders innecesarios.
El componente evita conflictos de autoplay: No quieres que el comportamiento al montar compita con el disparado por el usuario.

Errores comunes que conviene evitar:

Disparar antes de que exista la ref
Si animationRef.current es null, la reproducción no ocurrirá. Protégelo.
Usando autoPlay con controles imperativos
Pick one default owner for playback.
Controlando todo a través de useEffect
Los efectos son útiles, pero para acciones de UI a menudo añaden problemas de temporización en lugar de eliminarlos.

Si una animación responde a un toque, disprátala primero dentro del manejador del toque. Recurre a useEffect solo cuando la fuente de verdad está fuera de esa interacción.

Optimización de rendimiento para apps de producción

Lottie React Native es una de esas librerías que parece ligera hasta que los equipos empiezan a meter archivos JSON grandes en el bundle de la app y se preguntan por qué el arranque empeoró. La animación en sí no siempre es el problema. La estrategia de entrega sí.

Infografía que detalla tres beneficios clave del ajuste de rendimiento de Lottie: menor tamaño del bundle, mejores tasas de fotogramas y menor uso de memoria.

Donde los equipos se complican la vida

El error más común es incluir todas las animaciones directamente en JavaScript y cargarlas demasiado pronto. Según esta guía sobre cómo empaquetar incorrectamente los JSON de Lottie, sobrecargar los bundles de JS con assets como JSON de Lottie puede aumentar el tiempo de arranque de la app en un 40% o más en dispositivos de gama media, y moverlas a assets nativos para carga bajo demanda es una optimización crítica.

Eso encaja con lo que muchos equipos ven en la práctica. El problema no es una pequeña animación de éxito. Es la acumulación:

motion de onboarding
estados de loader
reacciones de e-commerce
pantallas vacías con branding
archivos de localización y otros assets pesados que los acompañan

Si tu app ya tiene un problema de startup budget, los archivos Lottie pueden empeorarlo rápido.

Qué optimizar primero

Empieza por la propia exportación. Una exportación descuidada de la animación arrastra una complejidad que pagarás luego en parsing, memoria y estabilidad de render. No aceptes cualquier export de diseño tal cual.

Usa esta checklist de producción:

Comprime el JSON antes de publicar: Los archivos más pequeños se cargan más rápido y reducen el bloat al iniciar.
Mueve las animaciones no críticas fuera del bundle de JS: Mantén el lanzamiento code centrado en lo que la app necesita de inmediato.
Carga las animaciones bajo demanda: Renderiza cuando la pantalla o la acción lo requiera.
Audita el comportamiento en dispositivos antiguos: Un simulador moderno puede ocultar la reproducción costosa.
Evita usar archivos Lottie grandes como decoración de inicio: Si no es crítico para la primera interacción, no debe competir con el lanzamiento de la app.

Para equipos que trabajan en serio en el rendimiento móvil, la guía de rendimiento móvil de AppLighter es una lectura complementaria útil, ya que sitúa las decisiones de animación en el contexto más amplio del arranque de la app, el renderizado y las compensaciones del framework.

Una verdad incómoda: Una animación hermosa que retrasa la primera interacción suele ser un bug de producto, no una victoria de diseño.

También debes pensar más allá de React Native por sí solo. Los equipos que trabajan con stacks híbridos se enfrentan a problemas similares de carga de assets, y el contexto más amplio rendimiento de animaciones para apps de Capacitor se adapta bien a las decisiones de Lottie también.

Archivos locales frente a entrega remota

Los archivos locales son predecibles. Funcionan sin conexión, eliminan la variabilidad de red y son más fáciles de probar. También es fácil sobre-bundlear.

La entrega remota mantiene el binario más ligero, pero ahora tu animación tiene implicaciones de disponibilidad, caché y fallback. Ese trade-off es aceptable para movimiento no crítico. Es arriesgado para estados de UX principales como la confirmación de compra o el éxito de autenticación.

Una separación práctica funciona bien:

Tipo de asset	Mejor default
Animación de interacción principal	Local, optimizada, no sobredimensionada
Movimiento promocional ocasional	Remoto con fallback
Animación de la ruta de inicio	Local solo si es absolutamente necesario
Ilustración de función poco usada	Carga bajo demanda

Si solo aplicas una regla de esta sección, usa esta: trata los JSON de Lottie como activos sensibles al rendimiento, no como decoración inofensiva.

Solución de problemas comunes de Lottie

Cuando Lottie falla, la causa suele ser ordinaria. Ruta incorrecta. Tamaño faltante. Timing de ref malo. JSON pesado. La forma más rápida de depurar es reducir variables.

La animación no se renderiza en Android

Primero, confirma que el archivo JSON se resuelve. Luego, da al componente dimensiones explícitas.

<LottieView
  source={require('../assets/animations/success.json')}
  autoPlay
  style={{ width: 200, height: 200 }}
/>

Si aún así falla, cambia por una animación conocida y funcional. Eso te dirá si el problema es el archivo o la configuración.

La reproducción se traba en dispositivos antiguos

Esto suele indicar que el problema está en el activo, no en el componente API.

Prueba estas soluciones:

Reduce la complejidad de la animación: Pide una exportación más ligera si el archivo fuente es pesado.
Cargar más tarde: No compitas con el trabajo de la pantalla inicial.
Prueba una versión comprimida: Si el archivo comprimido se comporta mejor, encontraste el cuello de botella.
Elimina múltiples vistas Lottie simultáneas: Varias animaciones en una misma pantalla pueden ser excesivas.

El ref es null o play no hace nada

Los refs nulos suelen significar que el trigger se dispara antes del mount o que el componente se eliminó condicionalmente.

if (animationRef.current) {
  animationRef.current.play();
}

Mantén el ref estable con useRef, y no recrees el componente animado sin necesidad. Si estás depurando comportamientos extraños repetidos en builds locales, limpiar cachés obsoletas puede ayudar. Un simple Rutina de limpieza de caché de Yarn a veces basta para corregir comportamientos erróneos de los assets durante el desarrollo.

La animación se ve mal en distintos tamaños de pantalla

No dejes que la animación defina el layout. Ponla dentro de un contenedor y dale un tamaño intencional.

Usa dimensiones fijas para iconos y reacciones
Usa wrappers con relación de aspecto para ilustraciones grandes
Evita estirar a ancho completo sin revisar la composición prevista del export

La mayoría de los informes de «Lottie está roto» resultan ser problemas de layout, de assets o de timing. La biblioteca suele hacer exactamente lo que le pediste.

Si necesitas un atajo final para depurar, elimina todas las props avanzadas, renderiza una animación local en una vista centrada y reconstruye desde ahí. Ese enfoque aísla los problemas más rápido que quedarse mirando una pantalla de producción saturada.

Capgo ayuda a los equipos a publicar correcciones de JavaScript, assets y configuración en apps de Capacitor sin esperar a la revisión de la tienda. Si mantienes una app híbrida y necesitas una forma más segura de empujar actualizaciones, gestionar rollouts por etapas y recuperarte rápidamente de problemas de front-end, Capgo vale la pena echarle un vistazo.