Lottie React Native

Probablemente estés en una de estas dos situaciones. O un diseñador te entrega un JSON de Lottie y te pregunta: “¿Podemos meter esto en la app hoy?”, o ya lo implementaste y notaste que la animación funciona en desarrollo, pero se siente pesada cuando entran en juego los dispositivos reales, el tiempo de arranque y los release builds.

Ahí es donde Lottie React Native se pone interesante. La demo básica es fácil; una implementación lista para producción, no. La diferencia suele radicar en cómo lo instalas, cómo controlas el playback y si tratas los archivos de animación como assets inofensivos o como parte de tu presupuesto de rendimiento.

Por qué Lottie es esencial para apps de React Native
- Diseño e ingeniería dejan de pelear por lo mismo
- Dónde encaja mejor Lottie
Configuración de tu entorno de desarrollo de Lottie
Muestra tu primera animación Lottie
Domina los controles de animación Lottie
Optimización de rendimiento para apps en producción
Solución de problemas comunes de Lottie

Por qué Lottie es esencial para apps en React Native

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

Lottie cambió ese flujo de trabajo. Airbnb lanzó Lottie como open-source 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 frame a frame. En entornos enterprise, ese cambio redujo los costes de desarrollo de apps móviles en hasta un 40%, according to Resumen de Lottie de Airbnb.

Diseño e ingeniería dejan de pelear por lo mismo

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

Esto es importante porque el trabajo de animación suele expandirse. Una sola animación de estado de celebración puede afectar la revisión de diseño, la de producto, el comportamiento en Android, en iOS, la accesibilidad y el rendimiento de inicio. Lottie reduce ese alcance.

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

También hay un ángulo de experiencia de usuario. El movimiento da feedback, confirma acciones y hace que los estados de carga se sientan menos vacíos. Si tu equipo se toma en serio 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 de la app suele terminar en el mismo punto: el feedback rápido supera a las pantallas estáticas.

Dónde encaja mejor Lottie

Lottie React Native suele funcionar mejor para:

Microinteracciones de marca como likes, guardados, checks y estados de compra exitosa
Ilustraciones de onboarding que deben sentirse personalizadas sin usar video
Estados de carga y vacíos donde una UI estática se siente incompleta
Educación de funcionalidades cuando el producto requiere movimiento sin usar GIFs o MP4s

No resuelve todos los problemas de animación. Para transiciones de pantalla básicas, las 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 ser un compromiso en lugar de una ventaja. Ese balance es clave al llegar a producción, que es donde la mayoría de los tutoriales terminan demasiado pronto.

Configuración de tu entorno de desarrollo Lottie

La ruta de instalación depende de una decisión previa: 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 JSON local y renderiza una animación pequeña. No intentes debuguear un asset pesado y una instalación nueva a la vez.

Algunas notas prácticas para Expo:

Prioriza archivos locales: Debuguear animaciones remotas añade ruido de red cuando solo quieres probar que la librería funciona.
Prueba el comportamiento de release pronto: El modo development puede ocultar problemas de timing y performance.
Revisa las rutas de los assets: Tener mal ubicados los archivos JSON es una de las causas más comunes de que

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

Configuración Bare React Native

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 ..
```

Reconstruir la app

npx react-native run-ios

npx react-native run-android

Aquí está lo que muchos guías rápidas omiten: tras la instalación, haz un rebuild nativo completo antes de asumir que algo falla. El hot reload no salvará una dependencia nativa que no se haya compilado correctamente en la app.

Trucos de Bare workflow para ahorrar tiempo

Usa esta breve checklist antes de seguir:

Check	Por qué es importante
Rebuild tras la instalación	Los módulos nativos requieren una nueva compilación
Ejecuta `pod install`	iOS no será fiable sin esto
Usa primero un JSON local simple	Separa problemas de instalación de los de assets
Testea ambas plataformas pronto	Android e iOS pueden fallar por razones distintas

Si el paquete se instala bien pero tu primera animación no aparece, no suele ser un problema de instalación. Normalmente es la ruta del asset, el tamaño del componente o la configuración del playback.

Cómo mostrar tu primera animación Lottie

La primera animación que funcione debe ser aburrida. Archivo local. Tamaño fijo. Autoplay activado. Loop opcional. No empieces con playback condicional, JSON remoto o un export de animación con muchas capas.

Un espacio de trabajo moderno con un portátil mostrando code y un monitor con una app de animaciones móviles.

Añade un archivo de animación local

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

assets/
  animations/
    success.json

Usa nombres simples. Evita espacios, puntuación extraña y carpetas con muchos niveles de anidamiento. Lo que buscas es require() rutas para mantener la claridad.

Si usas Lottie para una pantalla de carga con branding o una transición tras el lanzamiento, piénsalo bien antes de meter una animación pesada en el flujo de inicio. Esto es clave si también estás ajustando tu 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 pesado:

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,
  },
});

Esto hace tres cosas útiles:

confirma que la librería renderiza correctamente
confirma que la ruta del asset se resuelve bien
te da un lugar aislado para ajustar el playback y el tamaño después

Aparecen algunos problemas comunes si te saltas lo básico:

Sin width ni height: 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óviles.

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

Una mejor prueba de la primera pantalla

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 esto funciona tanto en simuladores de iOS como de Android, habrás 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.

Dominando los controles de animación de Lottie

La mayoría de los bugs de Lottie React Native aparecen cuando la animación debe reaccionar al estado. El autoplay es fácil. El problema surge con casos como: “reproduce este segmento cuando el usuario dé like, inviértelo cuando le quite el like y no parpadees cuando el componente haga re-render”.

Una tabla comparativa que explica los métodos de control de animación declarativos frente a los imperativos en Lottie, destacando sus casos de uso específicos.

Usa props si la reproducción es simple

Para reproducciones no interactivas, basta con usar props.

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

Este estilo es ideal para:

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

Es declarativo y legible. El componente se monta, la reproducción inicia y React mantiene el control. Si la lógica de la animación se puede describir solo con props, mantenla 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 un progreso externo, pero es menos práctico para eventos de disparo únicos.

Aquí tienes una comparativa visual antes de pasar a los refs:

Usa refs cuando el estado controle la animación

Cuando el usuario pulsa, alterna o completa una acción, un ref suele ser la herramienta más segura. Los datos reales muestran El 68% de los desarrolladores que usan frameworks híbridos reportan fallos al activar animaciones por un mal manejo de refs en useEffect hooks, por lo que usar patrones fiables es fundamental, animation.current.play() tal como se menciona en esta discusión de Capacitor centrada en triggers fallidos.

Ese problema no se limita a las apps híbridas. También ocurre en React Native puro, especialmente cuando se recrean refs, se activa el playback antes del mount o se vinculan las animaciones 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 liked y unliked

Este patrón es más robusto en producción que llamar a play() dentro de useEffect cada vez que cambia el estado.

Por qué funciona:

El evento controla el trigger de la animación: Un evento de pulsación es un momento estable para iniciar la reproducción.
La ref se mantiene local y persistente: useRef evita rerenders innecesarios.
El componente evita conflictos de autoplay: No querrás que el comportamiento al montar compita con la acción del usuario.

Errores comunes que conviene evitar:

Se ejecuta antes de que exista la ref
Si animationRef.current es null, la reproducción no ocurrirá. Usa un guard.
Usando autoPlay con controles imperativos
Elige un único dueño por defecto para la reproducción.
Impulsando todo a través de useEffect
Los efectos son útiles, pero en acciones de UI suelen añadir problemas de timing en lugar de eliminarlos.

Si una animación responde a un tap, ejecútala primero dentro del tap handler. Recurre a useEffect solo cuando la fuente de verdad esté fuera de esa interacción.

Optimización de rendimiento para apps en producción

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

Una infografía que detalla tres beneficios clave de optimizar el rendimiento de Lottie: reducción del tamaño del bundle, mejora de los frame rates y menor uso de memoria.

Dónde suelen fallar los equipos

El error más común es incluir cada animación directamente en JavaScript y cargarlo todo demasiado pronto. Según esta guía sobre cómo enviar Lottie JSON incorrectamente, sobrecargar los bundles de JS con assets como Lottie JSONs puede aumentar los tiempos de inicio de la app hasta 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 pequeños cargan más rápido y no ralentizan el inicio.
Saca las animaciones no críticas del JS bundle: Mantén el code de inicio enfocado en lo que la app necesita ya.
Carga las animaciones bajo demanda: Renderiza solo cuando la pantalla o la acción lo requiera.
Audita el comportamiento en dispositivos antiguos: Un simulador moderno puede ocultar un playback costoso.
Evita usar archivos Lottie pesados para decorar el inicio: Si no es crítico para la primera interacción, no debe competir con el app launch.

Para equipos que trabajan en serio el performance móvil, La guía de AppLighter sobre performance móvil es una lectura complementaria útil, ya que sitúa las decisiones de animación en el contexto de startup, rendering y trade-offs del framework.

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

También debes pensar más allá de React Native. Los equipos que usan stacks híbridos enfrentan problemas similares de carga de assets, y las guías de rendimiento de animación para apps Capacitor también se aplican a las decisiones de Lottie.

Archivos locales vs. entrega remota

Los archivos locales son predecibles. Funcionan offline, eliminan la variabilidad de red y son fáciles de testear. También es fácil inflar el bundle.

La entrega remota mantiene el binario más ligero, pero añade problemas de disponibilidad, caché y fallbacks. Es un trade-off aceptable para motion no crítico, pero riesgoso para estados clave de UX como la confirmación de compra o el login.

Una división práctica funciona bien:

Tipo de asset	Mejor opción por defecto
Animación de interacción core	Local, optimizado y ligero
Motion promocional ocasional	Remoto con fallback
Animación en el startup-path	Local solo si es estrictamente necesario
Ilustración de feature poco usada	Carga on-demand

Si solo vas a aplicar una regla de esta sección, usa esta: trata los JSON de Lottie como assets sensibles al rendimiento, no como simple decoración.

Solución de problemas comunes de Lottie

Cuando Lottie falla, la causa suele ser común. Ruta incorrecta. Tamaño faltante. Timing de la ref. JSON muy pesado. La forma más rápida de debuguear es reducir variables.

La animación no renderiza en Android

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

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

Si sigue fallando, prueba con otra animación que sepas que funciona. Así sabrás si el problema es el archivo o la configuración.

Playback is choppy on older devices

Esto suele indicar un problema con el asset, no con el componente API.

Prueba estas soluciones:

Reduce la complejidad de la animación: Solicita un export más ligero si el archivo original es muy pesado.
Carga diferida: No compitas con la carga inicial de la pantalla.
Prueba una versión comprimida: Si el archivo comprimido funciona mejor, habrás encontrado el cuello de botella.
Evita múltiples vistas de 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 reportes de “Lottie no funciona” terminan siendo problemas de layout, de assets o de timing. La librería suele hacer exactamente lo que le pediste.

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

Capgo ayuda a los equipos a enviar fixes de JavaScript, assets y config a apps de Capacitor sin esperar la revisión de la store. Si mantienes una app híbrida y necesitas una forma más segura de lanzar updates, gestionar rollouts escalonados y recuperarte rápido de errores de front-end, Capgo vale la pena echarle un vistazo.