Lottie React Native

Probabilmente ti trovi in una di queste due situazioni. O un designer ti ha passato un JSON di Lottie chiedendoti: “Possiamo inserirlo nell'app oggi?”, oppure l'hai già implementato e hai notato che l'animazione funziona in sviluppo, ma diventa pesante quando entrano in gioco dispositivi reali, tempi di avvio e build di rilascio.

È qui che Lottie React Native diventa interessante. La demo di base è facile, ma un'implementazione pronta per la produzione no. La differenza di solito dipende da come lo installi, come controlli il playback e se tratti i file delle animazioni come semplici asset o come parte del tuo budget di performance.

Indice dei contenuti

• Perché Lottie è essenziale per le app React Native
  • Design e ingegneria smettono di combattere la stessa battaglia
  • Il miglior utilizzo di Lottie
• Configurare l'ambiente di sviluppo per Lottie
  • Scegli il workflow prima dell'installazione
  • Setup gestito con Expo
  • Setup Bare React Native
  • Check per il Bare workflow per risparmiare tempo
• Visualizza la tua prima animazione Lottie
  • Aggiungi un file di animazione locale
  • Renderizzalo con LottieView
  • Un test migliore per la prima schermata
• Padroneggiare i controlli delle animazioni Lottie
  • Usa le props per la riproduzione semplice
  • Usa i ref quando lo stato guida l'animazione
  • Un pattern affidabile per like e unlike
• Ottimizzazione delle performance per app in produzione
  • Dove i team incontrano problemi
  • Cosa ottimizzare per primo
  • File locali vs delivery remota
• Risoluzione dei problemi comuni di Lottie
  • L'animazione non viene renderizzata su Android
  • Il playback è scattoso sui dispositivi datati
  • Il ref è null o play non fa nulla
  • L'animazione appare errata su diversi schermi

Perché Lottie è essenziale per le app React Native

Se hai mai provato a ricreare a mano un'animazione rifinita in React Native, conosci già il dolore. Piccoli dettagli di movimento si trasformano in un groviglio di logica di timing, interpolazioni e stranezze delle piattaforme. L'animazione può sembrare simile, ma

Lottie ha cambiato questo workflow. Airbnb ha rilasciato Lottie come open source nel 2016, e quel rilascio ha rivoluzionato le animazioni mobile permettendo ai designer di inviare le animazioni direttamente, invece di costringere gli ingegneri a ricostruirle frame per frame. In contesti enterprise, questo cambiamento ha ridotto i costi di sviluppo delle app mobile del fino al 40%, according to la panoramica di Lottie di Airbnb.

Design e engineering smettono di combattere la stessa battaglia

Un vantaggio chiave di Lottie React Native non è solo avere "animazioni JSON spettacolari". È la separazione delle responsabilità. I designer lavorano su After Effects ed esportano con Bodymovin. Gli sviluppatori renderizzano l'output con una riproduzione nativa invece di tradurre il movimento in code personalizzato.

Questo è importante perché il lavoro sulle animazioni tende a espandersi. Una singola animazione di stato può influenzare la revisione del design, quella del prodotto, il comportamento su Android e iOS, l'accessibilità e le performance all'avvio. Lottie riduce questa superficie di impatto.

Regola pratica: Usa Lottie quando l'animazione fa parte dell'esperienza prodotto, non quando ti serve solo una semplice transizione di opacità o di traslazione.

C'è anche un aspetto legato alla user experience. Il movimento fornisce feedback, conferma le azioni e rende meno statici gli stati di caricamento. Se il tuo team punta a rifiniture, retention o fiducia nell'interfaccia, l'animazione è parte integrante di questo processo. La più ampia discussione sulla user experience dell'app finisce solitamente nello stesso posto: un feedback rapido batte le schermate statiche.

Il miglior scenario per Lottie

Lottie React Native è ideale per:

• Micro-interazioni di brand come like, salvataggi, checkmark e stati di acquisto completato
• Illustrazioni di onboarding che devono sembrare custom senza usare video
• Stati di caricamento e vuoti dove una UI statica sembra incompleta
• Spiegazione delle feature quando il prodotto richiede motion senza usare GIF o MP4

Non risolve ogni problema di animazione. Per le transizioni di schermata base, gli strumenti di animazione di React Native sono spesso più semplici. Per sistemi di motion molto grandi o altamente interattivi, il formato JSON può diventare un limite anziché un vantaggio. Questo trade-off diventa cruciale in fase di produzione, punto in cui la maggior parte dei tutorial si ferma troppo presto.

Configurare l'ambiente di sviluppo Lottie

Il percorso di installazione dipende da una prima scelta: Expo managed workflow o bare React Native. Non mischiare i modelli mentali. La maggior parte dei problemi di setup nasce quando gli sviluppatori seguono una guida per bare workflow dentro Expo, o danno per scontato che Expo astragga ogni dettaglio nativo.

Scegli il workflow prima di installare

Se la tua app è in Expo e vuoi il setup più veloce, resta sul percorso Expo a meno che tu non sappia di aver bisogno di interventi nativi custom. Se usi un'app bare, o ti affidi già a moduli nativi che richiedono un controllo diretto, installalo come una normale dipendenza nativa e valida subito i build sia iOS che Android.

Molti team sottovalutano quanto diventi più semplice il debugging se mantieni il setup allineato al tipo di progetto. È anche per questo che molti team che sviluppano integrazioni native custom confrontano Capgo come alternativa a Expo EAS fin da subito, invece di aspettare che l'app diventi più difficile da modificare.

Setup Expo managed

Per le app gestite con Expo, mantienilo al minimo.

1. Installa il pacchetto

   npx expo install lottie-react-native

2. Riavvia Metro

   npx expo start -c

3. Verifica su dispositivo o simulatore Inizia con un file JSON locale e renderizza prima un'animazione molto piccola. Non debuggare un asset pesante e una nuova installazione contemporaneamente.

Alcune note pratiche su Expo:

• Preferisci prima i file locali: Il debug di animazioni remote aggiunge rumore di rete quando devi solo verificare che la libreria funzioni.
• Testa subito il comportamento in release: La modalità development può nascondere problemi di timing e performance.
• Controlla i percorsi degli asset: I file JSON posizionati male sono una delle cause più comuni del

Expo è la via più rapida per far funzionare tutto. Ma non è necessariamente la via più veloce per scalare.

Setup Bare React Native

In un progetto bare, installa e valida subito le dipendenze native.

1. Installa il pacchetto

   npm install lottie-react-native

2. Installa i pod di iOS

   cd ios && pod install && cd ..

3. Ricompila l'app

   npx react-native run-ios

   o

   npx react-native run-android

Ecco la parte che molti quick-start guide saltano: dopo l'installazione, esegui un rebuild nativo completo prima di pensare che qualcosa sia rotto. L'hot reload non può salvare una dipendenza nativa che non è stata compilata correttamente nell'app.

Bare workflow checks that save time

Usa questa breve checklist prima di procedere:

Se il pacchetto si installa correttamente ma la prima animazione non appare, di solito non è un problema di installazione. Spesso si tratta del percorso dell'asset, delle dimensioni del componente o della configurazione del playback.

Visualizzare la tua prima animazione Lottie

La prima animazione funzionante deve essere banale. File locale. Dimensione fissa. Autoplay attivo. Loop opzionale. Non iniziare con playback condizionali, JSON remoti o esportazioni con troppi livelli.

Aggiungi un file di animazione locale

Crea una cartella asset se non ne hai già una:

assets/
  animations/
    success.json

Usa nomi semplici. Evita spazi, punteggiatura strana e cartelle con troppi livelli di nesting. Vuoi require() percorsi che rimangano chiari.

Se usi Lottie per una splash screen brandizzata o per un passaggio fluido dopo il lancio, valuta bene prima di inserire un'animazione pesante nel percorso di startup. Questo è vero soprattutto se stai ottimizzando il tuo comportamento della splash screen in React Native.

Renderizzalo con LottieView

Crea un componente dedicato invece di inserirlo direttamente in un file di una schermata complessa:

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

Questo offre tre vantaggi:

• verifica che la libreria renderizzi correttamente
• conferma che il percorso dell'asset sia corretto
• ti offre un unico punto isolato per regolare playback e dimensioni in seguito

Alcuni problemi comuni emergono subito se salti le basi:

• Mancanza di width o height: L'animazione può esistere ma risultare invisibile.
• Errato require() path: Metro non troverà il file.
• Export non valido: Alcuni file JSON sono tecnicamente validi, ma contengono funzionalità che non si comportano come previsto su mobile.

Mantieni il primo render locale e deterministico. Stai testando l'integrazione, non l'architettura.

Un test migliore per la prima schermata

Inserisci il componente in una schermata semplice con uno sfondo 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',
  },
});

Se funziona sia nei simulatori iOS che Android, hai superato il primo vero ostacolo. Da qui, il passo successivo non è aggiungere altre animazioni. È imparare quando usare le props dichiarative e quando prendere il controllo diretto con i ref.

Padroneggiare i controlli delle animazioni Lottie

La maggior parte dei bug di Lottie React Native emerge quando l'animazione deve reagire allo stato. L'autoplay è facile. Il problema sorge quando devi: "Riproduci questo segmento se l'utente mette like, riavvolgi se toglie il like e non avere stutter quando il componente effettua il re-render".

Usa le props per la riproduzione semplice

Per una riproduzione non interattiva, le props sono sufficienti.

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

Questo stile è ideale per:

• indicatori di caricamento
• illustrazioni passive di onboarding
• empty states decorativi

È dichiarativo e leggibile. Il componente viene montato, la riproduzione parte e React mantiene il controllo. Se la logica dell'animazione può essere descritta interamente dalle props, usa quelle.

Un caso dichiarativo più avanzato è progress, dove colleghi il frame dell'animazione a un altro valore. Funziona bene quando il movimento deve riflettere una fonte di progresso esterna, ma è meno pratico per eventi trigger singoli.

Ecco un rapido confronto visivo prima di passare ai ref:

Usa i ref quando lo stato guida l'animazione

Quando l'utente tocca, alterna o completa un'azione, un ref è solitamente lo strumento più sicuro. I dati reali mostrano Il 68% degli sviluppatori che usano framework ibridi segnala errori nell'avvio delle animazioni a causa di una gestione errata dei ref negli useEffect hook, motivo per cui i pattern affidabili basati su animation.current.play() sono fondamentali, come evidenziato in questa discussione focalizzata su Capacitor e sui trigger falliti.

Il problema non riguarda solo le app ibride. Si presenta anche in React Native puro, specialmente quando i dev ricreano i ref, avviano il playback prima del mount o legano le chiamate delle animazioni a effect instabili.

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 pattern affidabile per liked e unliked

Questo pattern è più robusto in produzione rispetto alla chiamata di play() dentro useEffect ogni volta che cambia lo stato.

Perché funziona:

• L'evento gestisce il trigger dell'animazione: Un evento press è un momento stabile per avviare il playback.
• Il ref rimane locale e persistente: useRef evita rerender non necessari.
• Il componente evita conflitti con l'autoplay: Non vuoi che il comportamento al mount entri in conflitto con quello attivato dall'utente.

Errori comuni da evitare:

1. Triggerare prima che il ref esista
   Se animationRef.current se è null, il playback non partirà. Usa un guard.

2. Usare autoPlay con controlli imperativi
   Scegli un unico owner predefinito per il playback.

3. Gestire tutto tramite useEffect
   Gli effetti sono utili, ma per le azioni UI spesso creano problemi di timing invece di risolverli.

Se un'animazione risponde a un tap, attivala prima all'interno dell'handler del tap. Usa useEffect solo quando la source of truth si trova al di fuori di quell'interazione.

Performance Tuning per App in Produzione

Lottie React Native è una di quelle librerie che sembrano leggere finché i team non iniziano a inserire enormi file JSON nell'app bundle, chiedendosi perché le performance in startup siano peggiorate. Il problema non è sempre l'animazione in sé, ma la strategia di delivery.

Dove i team sbagliano

L'errore più comune è includere ogni animazione direttamente nel bundle JavaScript e caricarle tutte troppo presto. Secondo questa guida sull'uso errato dei file Lottie JSON, sovraccaricare i bundle JS con asset come i Lottie JSON può aumentare i tempi di avvio dell'app del 40% o più sui dispositivi di fascia media, e spostarli tra le native assets per il caricamento on-demand è un'ottimizzazione fondamentale.

È esattamente ciò che molte aziende riscontrano nella pratica. Il problema non è una singola micro-animazione di successo. È l'accumulo:

• motion di onboarding
• stati di caricamento
• reazioni e-commerce
• schermate empty branded
• file di localizzazione e altri asset pesanti che si sommano a loro

Se la tua app ha già problemi di startup budget, i file Lottie possono peggiorare rapidamente la situazione.

Cosa ottimizzare per primo

Parti dall'export stesso. Un export di un'animazione approssimativo comporta una complessità che pagherai in seguito in termini di parsing, memoria e stabilità del render. Non accettare ogni export del designer così com'è.

Usa questa checklist di produzione:

• Comprimi il JSON prima del deploy: File più piccoli si caricano più velocemente e non appesantiscono l'avvio.
• Sposta le animazioni non critiche fuori dal bundle JS: Mantieni il code di avvio focalizzato su ciò che serve subito all'app.
• Carica le animazioni on demand: Renderizzale solo quando lo schermo o l'azione lo richiedono.
• Verifica il comportamento sui dispositivi datati: Un simulatore moderno può nascondere un playback costoso.
• Evita di usare file Lottie pesanti per decorare l'avvio: Se non è fondamentale per la prima interazione, non deve competere con il lancio dell'app.

Per i team che lavorano seriamente sulle performance mobile, La guida di AppLighter alle performance mobile è una lettura utile perché inserisce le scelte sulle animazioni nel contesto più ampio dell'avvio dell'app, del rendering e dei compromessi del framework.

Una verità scomoda: Un'animazione bellissima che ritarda la prima interazione è solitamente un bug, non un successo di design.

Dovresti anche pensare oltre il solo React Native. I team che usano stack ibridi affrontano problemi simili di caricamento asset, e le guida alle performance delle animazioni per le app Capacitor si adatta bene anche alle decisioni su Lottie.

File locali vs caricamento remoto

I file locali sono prevedibili. Funzionano offline, eliminano la variabilità della rete e sono più facili da testare. Possono però appesantire troppo il bundle.

Il caricamento remoto mantiene il binario più leggero, ma introduce problemi di disponibilità, caching e fallback. È un compromesso accettabile per motion non critici, ma rischioso per stati UX primari come la conferma di acquisto o l'autenticazione.

Una suddivisione pratica funziona bene:

Se devi applicare una sola regola di questa sezione, usa questa: tratta i JSON di Lottie come asset critici per le performance, non come semplice decorazione.

Risoluzione dei problemi comuni con Lottie

Quando Lottie si rompe, la causa è solitamente banale. Path errato. Dimensioni mancanti. Timing dei ref sbagliato. JSON troppo pesante. Il modo più veloce per fare debug è ridurre le variabili.

L'animazione non viene renderizzata su Android

Per prima cosa, verifica che il file JSON sia corretto. Poi assegna dimensioni esplicite al componente.

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

Se il problema persiste, prova un'altra animazione funzionante. Capirai così se il problema è il file o il setup.

Il playback è scattoso sui dispositivi più vecchi

Di solito il problema riguarda l'asset, non il componente API.

Prova queste soluzioni:

• Riduci la complessità dell'animazione: Richiedi un export più leggero se il file sorgente è pesante.
• Carica più tardi: Non competere con il lavoro sulla schermata iniziale.
• Testa una versione compressa: Se il file compresso funziona meglio, hai individuato il collo di bottiglia.
• Rimuovi le viste Lottie multiple simultanee: Troppe animazioni in una singola schermata possono risultare eccessive.

Il ref è null o play non fa nulla

I ref null di solito indicano che il trigger scatta prima del mount o che il componente è stato rimosso condizionalmente.

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

Mantieni il ref stabile con useRef, e non ricreare il componente animato inutilmente. Se stai debuggando comportamenti strani nei build locali, pulire la cache può aiutare. Una semplice routine di pulizia della cache di Yarn a volte basta per risolvere problemi di asset durante lo sviluppo.

L'animazione appare errata su diverse dimensioni dello schermo

Non lasciare che l'animazione definisca il layout. Inseriscila in un container e impostane le dimensioni intenzionalmente.

• Usa dimensioni fisse per icone e reaction
• Usa wrapper che rispettino l'aspect ratio per illustrazioni più grandi
• Evita di estendere a tutta larghezza senza controllare la composizione originale dell'export

La maggior parte delle segnalazioni su "Lottie non funziona" si rivela essere un problema di layout, di asset o di timing. Spesso la libreria sta facendo esattamente ciò che le hai chiesto.

Se cerchi una scorciatoia per il debugging, rimuovi ogni prop avanzata, renderizza un'animazione locale in una view centrata e ricostruisci il tutto da lì. Questo approccio isola i problemi più velocemente che fissare uno schermo di produzione pieno di elementi.

Capgo aiuta i team a distribuire fix di JavaScript, asset e config alle app Capacitor senza attendere la revisione degli store. Se gestisci un'app ibrida e cerchi un modo più sicuro per pubblicare aggiornamenti, gestire rollout graduali e recuperare rapidamente da problemi front-end, Capgo vale la pena darci un'occhiata.