Langsung ke konten utama
Mobile Panduan

Lottie React Native

Panduan lengkap kami mengajarkan cara menggunakan lottie react native. Mencakup workflow Expo & bare, kontrol animasi, tuning performa, dan best practice untuk 2026.

Lottie React Native

Kamu kemungkinan besar sedang berada di salah satu dari dua situasi ini. Entah kamu menerima file Lottie JSON dari desainer dan diminta, “Bisakah ini masuk ke aplikasi hari ini?”, atau kamu sudah mengintegrasikannya dan menyadari bahwa animasinya berjalan lancar di development, tapi mulai terasa berat saat dihadapkan dengan perangkat nyata, waktu startup, dan release build.

Di sinilah Lottie React Native menjadi menarik. Demo dasarnya mudah. Implementasi yang siap produksi tidak. Perbedaannya biasanya terletak pada cara kamu menginstalnya, cara kamu mengontrol playback, dan apakah kamu memperlakukan file animasi sebagai aset yang tidak berbahaya atau sebagai bagian dari performance budget-mu.

Table of Contents

Mengapa Lottie Sangat Penting untuk Aplikasi React Native

Jika Anda pernah mencoba membuat ulang animasi produk yang mulus secara manual di React Native, Anda sudah tahu susahnya. Detail gerakan kecil berubah jadi tumpukan logika timing, interpolasi, dan quirk platform. Animasinya mungkin terlihat mirip, tapi “mirip” biasanya bukan yang dikirim desainer.

Lottie mengubah alur kerja tersebut. Airbnb merilis Lottie secara open-source pada 2016, dan rilis tersebut mengubah animasi mobile dengan memungkinkan desainer mengirimkan animasi secara langsung alih-alih memaksa engineer membangunnya ulang frame demi frame. Di beberapa lingkungan enterprise, perubahan ini mengurangi biaya pengembangan aplikasi mobile sebesar hingga 40%, menurut data Sekilas Lottie dari Airbnb.

Desain dan engineering tak lagi bertengkar soal hal yang sama

Manfaat utama Lottie React Native bukan sekadar "animasi cantik dalam format JSON". Intinya adalah separation of concerns. Desainer bekerja di After Effects dan mengekspor dengan Bodymovin. Developer merender hasilnya dengan playback berbasis native, bukan menerjemahkan motion jadi code kustom.

Ini penting karena pekerjaan animasi cenderung menyebar luas. Satu animasi state perayaan bisa menyentuh review desain, review produk, perilaku Android, perilaku iOS, aksesibilitas, dan performa startup. Lottie mempersempit cakupan itu.

Aturan praktis: Gunakan Lottie saat animasi menjadi bagian dari pengalaman produk, bukan hanya untuk transisi opacity atau translate yang sederhana.

Ada juga sisi user experience. Motion memberikan feedback, mengonfirmasi aksi, dan membuat loading state terasa lebih hidup. Jika tim Anda serius memikirkan polish, retensi, atau kepercayaan pada antarmuka, animasi adalah bagian dari diskusi itu. Diskusi yang lebih luas tentang pengalaman pengguna aplikasi biasanya berakhir di titik yang sama: feedback yang cepat lebih baik daripada layar statis.

Di mana Lottie paling cocok

Lottie React Native biasanya paling optimal untuk:

  • Micro-interaction khas brand seperti like, save, checkmark, dan status sukses pembelian
  • Ilustrasi onboarding yang perlu terasa custom tanpa harus mengirim video
  • Loading dan empty states di mana UI statis terasa kurang lengkap
  • Edukasi fitur saat produk butuh motion tanpa harus embed GIF atau MP4

Namun, ini bukan solusi untuk semua masalah animasi. Untuk transisi layar dasar, tool animasi bawaan React Native sering kali lebih simpel. Untuk sistem motion yang sangat besar atau sangat interaktif, format JSON bisa jadi trade-off, bukan keuntungan. Trade-off ini makin penting begitu masuk production, dan di sinilah kebanyakan tutorial berhenti terlalu cepat.

Menyiapkan Environment Development Lottie Anda

Langkah instalasi bergantung pada satu keputusan awal: Expo managed workflow atau bare React Native. Jangan campuradukkan mental modelnya. Sebagian besar masalah setup terjadi ketika developer mengikuti panduan bare workflow di dalam Expo, atau mengasumsikan Expo mengabstraksi semua detail native.

Diagram alur yang menunjukkan langkah setup untuk animasi Lottie di proyek Expo dan Bare React Native.

Pilih workflow sebelum instalasi

Jika aplikasi Anda menggunakan Expo dan Anda ingin setup tercepat, tetaplah di jalur Expo kecuali Anda tahu membutuhkan kerja native kustom. Jika Anda menggunakan bare app, atau sudah bergantung pada modul native yang membutuhkan kontrol langsung, install sebagai dependensi native biasa dan validasi build iOS dan Android segera.

Banyak tim meremehkan betapa lebih mudahnya debugging ketika setup Anda selaras dengan tipe proyek. Itulah mengapa banyak tim yang membangun integrasi native kustom membandingkan Capgo sebagai alternatif untuk Expo EAS sejak awal, bukan menunggu sampai aplikasi makin sulit diubah.

Setup Expo managed

For Expo-managed apps, keep it minimal.

  1. Instal package

    npx expo install lottie-react-native
  2. Restart Metro

    npx expo start -c
  3. Verifikasi di perangkat atau simulator Mulai dengan file JSON lokal dan render animasi yang sangat kecil terlebih dahulu. Jangan debug aset besar dan instalasi baru secara bersamaan.

Beberapa catatan praktis penting di Expo:

  • Utamakan file lokal dulu: Debugging animasi remote menambah noise jaringan saat Anda hanya ingin membuktikan bahwa library-nya berfungsi.
  • Uji perilaku release sejak awal: Mode development bisa menyembunyikan masalah terkait timing dan performa.
  • Path aset Watch: File JSON yang salah tempat adalah salah satu penyebab paling umum dari masalah “tidak ada yang dirender.”

Expo adalah jalur tercepat menuju “berjalan.” Tapi itu tidak berarti jalur tercepat menuju “bisa diskalakan.”

Setup Bare React Native

Di proyek bare, install dan validasi dependensi native segera.

  1. Instal package

    npm install lottie-react-native
  2. Install pods iOS

    cd ios && pod install && cd ..
  3. Rebuild aplikasi

    npx react-native run-ios

    atau

    npx react-native run-android

Ini bagian yang sering dilewati panduan quick-start: setelah instalasi, lakukan rebuild native penuh sebelum memutuskan sesuatu rusak. Hot reload tidak akan menyelamatkan dependensi native yang belum dikompilasi dengan benar ke dalam aplikasi.

Cek bare workflow yang hemat waktu

Gunakan checklist singkat ini sebelum lanjut:

Periksa Mengapa ini penting
Rebuild setelah install Modul native perlu kompilasi baru
Jalankan pod install iOS tidak akan andal tanpanya
Gunakan JSON lokal sederhana dulu Memisahkan masalah instalasi dari masalah aset
Tes kedua platform sejak awal Android dan iOS bisa gagal karena alasan berbeda

Jika package terinstal lancar tapi animasi pertama tidak muncul, biasanya itu bukan masalah instalasi. Biasanya karena path aset, ukuran komponen, atau konfigurasi playback.

Menampilkan Animasi Lottie Pertama Anda

Animasi pertama yang berhasil haruslah sederhana. File lokal. Ukuran tetap. Autoplay aktif. Loop opsional. Jangan mulai dengan playback kondisional, JSON remote, atau ekspor animasi dengan banyak layer.

Workspace developer modern dengan laptop yang menampilkan code dan monitor yang menampilkan aplikasi animasi mobile.

Tambahkan file animasi lokal

Buat folder asset jika Anda belum memilikinya:

assets/
  animations/
    success.json

Gunakan nama yang sederhana. Hindari spasi, tanda baca aneh, dan folder dengan banyak level nesting. Anda ingin require() path yang jelas.

Jika Anda menggunakan Lottie untuk layar loading berbranding awal atau transisi setelah launch, pertimbangkan dengan matang sebelum memasukkan animasi besar ke dalam jalur startup. Hal ini terutama berlaku jika Anda juga sedang menyetel perilaku splash screen React Native.

Render menggunakan LottieView

Buat komponen khusus alih-alih menaruhnya langsung di file layar yang besar:

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

Hal ini melakukan tiga hal berguna:

  • membuktikan bahwa library merender dengan benar
  • membuktikan bahwa path asset teresolve dengan benar
  • memberikan satu tempat terisolasi untuk menyesuaikan playback dan sizing nanti

Beberapa gotchas langsung muncul jika Anda melewatkan dasar-dasarnya:

  • Tanpa width atau height: Animasi bisa ada tapi tidak terlihat.
  • Salah require() path: Metro tidak akan menemukan file-nya.
  • Ekspor tidak valid: Beberapa file JSON secara teknis valid tetapi mencakup fitur yang tidak berperilaku sesuai harapan di mobile.

Jaga agar render pertama tetap lokal dan deterministik. Anda sedang menguji integrasi, bukan arsitektur.

Tes layar pertama yang lebih baik

Letakkan komponen di layar sederhana dengan latar netral:

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

Jika ini berjalan di simulator iOS dan Android, Anda sudah melewati rintangan pertama yang nyata. Langkah selanjutnya bukan menambah animasi, melainkan memahami kapan menggunakan props deklaratif dan kapan mengambil kendali langsung dengan refs.

Menguasai Kontrol Animasi Lottie

Sebagian besar bug Lottie React Native muncul saat animasi harus bereaksi terhadap state. Autoplay itu mudah. "Putar segmen ini saat user menyukai item, balikkan saat tidak menyukai, dan jangan patah saat komponen re-render" adalah bagian yang rumit.

Tabel perbandingan yang menjelaskan metode kontrol animasi deklaratif versus imperatif di Lottie, menyoroti kasus penggunaan spesifiknya.

Gunakan props untuk playback sederhana

Untuk playback non-interaktif, props sudah cukup.

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

Gaya ini cocok untuk:

  • indikator loading
  • ilustrasi onboarding pasif
  • empty state dekoratif

Ini deklaratif dan mudah dibaca. Komponen mount, playback dimulai, dan React tetap memegang kendali. Jika logika animasi bisa dijelaskan sepenuhnya dengan props, biarkan di sana.

Kasus deklaratif yang lebih lanjut adalah progress, di mana Anda mengaitkan frame animasi dengan nilai lain. Ini bekerja dengan baik ketika gerakan harus mencerminkan sumber progres eksternal, tetapi kurang nyaman untuk event trigger sekali jalan.

Berikut perbandingan visual singkat sebelum beralih ke refs:

Gunakan refs jika state mengontrol animasi

Ketika pengguna tap, toggle, atau menyelesaikan aksi, ref biasanya menjadi alat yang lebih aman. Data dunia nyata menunjukkan 68% developer yang menggunakan framework hybrid melaporkan trigger animasi yang gagal akibat penanganan ref yang tidak tepat di useEffect hooks, itulah mengapa pola andal yang dibangun di sekitar animation.current.play() penting, seperti yang dicatat dalam Diskusi berfokus pada Capacitor mengenai trigger yang gagal.

Masalah itu tidak terbatas pada aplikasi hybrid. Hal ini juga muncul di React Native biasa, terutama ketika developer membuat ulang refs, memicu playback sebelum mount, atau mengaitkan panggilan animasi ke effect yang tidak stabil.

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

Pola liked dan unliked yang andal

Pola ini lebih stabil di produksi daripada memanggil play() di dalam useEffect setiap kali state berubah.

Mengapa ini berhasil:

  • Event memiliki trigger animasi: Event press adalah momen stabil untuk memulai playback.
  • Ref tetap lokal dan persisten: useRef menghindari rerender yang tidak perlu.
  • Komponen menghindari konflik autoplay: Anda tidak ingin perilaku mount bertentangan dengan perilaku yang dipicu pengguna.

Kesalahan umum yang perlu dihindari:

  1. Triggering before the ref exists
    Jika animationRef.current is null, playback tidak akan terjadi. Lindungi dengan guard.

  2. Menggunakan autoPlay dengan kontrol imperatif
    Pilih satu owner default untuk playback.

  3. Mengendalikan semuanya lewat useEffect
    Efek memang berguna, tapi untuk aksi UI, efek sering kali malah menambah masalah timing.

Jika animasi merespons ketukan, picu animasi tersebut di dalam tap handler terlebih dahulu. Gunakan useEffect hanya jika source of truth berada di luar interaksi tersebut.

Optimasi Performa untuk Aplikasi Produksi

Lottie React Native adalah salah satu library yang terlihat ringan sampai tim mulai memasukkan file JSON besar ke dalam app bundle dan bingung kenapa startup melambat. Masalahnya bukan selalu pada animasinya, tapi pada strategi pengirimannya.

Infografis yang merinci tiga manfaat utama optimasi performa Lottie: ukuran bundle lebih kecil, frame rate lebih lancar, dan penggunaan memori lebih rendah.

Di mana tim sering mengalami masalah

Kesalahan paling umum adalah membundel setiap animasi langsung ke JavaScript dan memuat semuanya terlalu awal. Menurut panduan tentang pengiriman Lottie JSON yang salah ini, membebani JS bundle dengan aset seperti Lottie JSON dapat meningkatkan waktu startup aplikasi sebesar 40% atau lebih pada perangkat kelas menengah, dan memindahkannya ke aset native untuk on-demand loading adalah optimasi krusial.

Itu sejalan dengan apa yang banyak tim alami di lapangan. Masalahnya bukan satu animasi kecil yang sukses. Masalahnya adalah penumpukannya:

  • motion onboarding
  • state loader
  • reaksi e-commerce
  • layar kosong berbranding
  • file locale dan aset berat lainnya yang berdampingan

Jika aplikasi Anda sudah punya masalah budget startup, file Lottie bisa memperburuknya dengan cepat.

Apa yang harus dioptimasi lebih dulu

Mulai dari export-nya sendiri. Export animasi yang asal-asalan membawa kompleksitas yang nanti harus Anda bayar di parsing, memori, dan stabilitas render. Jangan terima setiap export desainer apa adanya.

Gunakan checklist produksi ini:

  • Kompres JSON sebelum dirilis: File yang lebih kecil lebih mudah dimuat dan tidak membuat startup membengkak.
  • Pindahkan animasi non-kritis keluar dari JS bundle: Jaga agar peluncuran code tetap fokus pada kebutuhan mendesak aplikasi.
  • Muat animasi sesuai kebutuhan: Render saat layar atau aksi membutuhkannya.
  • Audit perilaku pada perangkat lama: Simulator modern bisa menyembunyikan beban playback yang berat.
  • Hindari menggunakan file Lottie besar sebagai dekorasi startup: Jika tidak krusial untuk interaksi pertama, jangan biarkan ia menghambat app launch.

Bagi tim yang fokus pada optimasi performa mobile, Panduan AppLighter untuk performa mobile adalah bacaan pendamping yang berguna karena menempatkan keputusan animasi dalam konteks yang lebih luas terkait startup aplikasi, rendering, dan trade-off framework.

Satu fakta pahit: Animasi indah yang menunda interaksi pertama biasanya adalah bug produk, bukan kemenangan desain.

Anda juga harus berpikir melampaui React Native secara terpisah. Tim yang bekerja di stack hybrid menghadapi masalah pemuatan aset serupa, dan panduan yang lebih luas untuk kinerja animasi pada aplikasi Capacitor juga sangat relevan untuk keputusan Lottie.

File lokal vs pengiriman remote

File lokal itu dapat diprediksi. Mereka berfungsi offline, menghilangkan variabilitas jaringan, dan lebih mudah diuji. Namun, mereka juga mudah untuk di-bundle secara berlebihan.

Pengiriman remote membuat binary lebih ringan, tetapi sekarang animasi Anda memiliki masalah ketersediaan, caching, dan fallback. Trade-off ini dapat diterima untuk motion yang tidak kritis. Berisiko untuk status UX utama seperti konfirmasi pembelian atau keberhasilan autentikasi.

Pemisahan praktis bekerja dengan baik:

Jenis aset Default yang lebih baik
Animasi interaksi inti Lokal, optimal, tidak berlebih
Animasi promosi sesekali Remote dengan fallback
Animasi jalur startup Lokal hanya jika sangat perlu
Ilustrasi fitur yang jarang dipakai Muat on-demand

Jika Anda hanya menerapkan satu aturan dari bagian ini, gunakan yang satu ini: perlakukan JSON Lottie sebagai aset sensitif performa, bukan sekadar dekorasi.

Troubleshooting Masalah Umum Lottie

Saat Lottie error, penyebabnya biasanya sepele. Path salah. Ukuran hilang. Timing ref buruk. JSON terlalu berat. Cara tercepat untuk debug adalah dengan mengurangi variabel.

Animasi tidak render di Android

Pertama, pastikan file JSON ter-resolve. Lalu berikan dimensi eksplisit ke komponen.

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

Jika masih gagal, ganti dengan animasi lain yang sudah diketahui baik. Ini akan menunjukkan apakah masalahnya ada di file atau setup.

Playback patah-patah di perangkat lama

Ini biasanya menunjuk ke aset, bukan komponen API.

Coba perbaikan berikut:

  • Kurangi kompleksitas animasi: Minta ekspor yang lebih ringan jika file sumbernya berat.
  • Muat nanti: Jangan bersaing dengan pekerjaan layar awal.
  • Uji versi terkompresi: Jika file terkompresi berperilaku lebih baik, Anda telah menemukan bottleneck-nya.
  • Hapus beberapa view Lottie yang berjalan bersamaan: Beberapa animasi di satu layar bisa terasa berlebihan.

Ref bernilai null atau play tidak berfungsi

Null ref biasanya berarti trigger berjalan sebelum mount, atau komponen terhapus secara kondisional.

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

Jaga agar ref tetap stabil dengan useRef, dan jangan buat ulang komponen animasi tanpa perlu. Jika Anda sedang debugging keanehan berulang di local build, membersihkan cache lama bisa membantu. Sebuah rutinitas pembersihan cache Yarn sederhana kadang cukup untuk menghilangkan perilaku aset yang menyesatkan saat development.

Animasi terlihat berantakan di berbagai ukuran layar

Jangan biarkan animasi menentukan layout. Masukkan ke dalam container dan atur ukurannya secara sengaja.

  • Gunakan bounds tetap untuk ikon dan reaksi
  • Gunakan wrapper aspect-aware untuk ilustrasi yang lebih besar
  • Hindari stretching ke full width tanpa mengecek komposisi yang dimaksud dari export

Sebagian besar laporan “Lottie rusak” ternyata disebabkan oleh masalah layout, aset, atau timing. Library ini sering kali bekerja persis sesuai instruksi Anda.

Jika butuh jalan pintas debugging terakhir, hapus semua prop lanjutan, render satu animasi lokal di view yang di-center, lalu bangun lagi dari sana. Pendekatan ini mengisolasi masalah lebih cepat daripada menatap layar produksi yang penuh.


Capgo membantu tim mengirim perbaikan JavaScript, aset, dan konfigurasi ke aplikasi Capacitor tanpa menunggu review store. Jika Anda mengelola hybrid app dan butuh cara yang lebih aman untuk push update, menangani staged rollout, dan pulih cepat dari masalah front-end, Capgo layak untuk dicoba.

Live updates untuk aplikasi Capacitor

Saat bug web-layer sudah live, kirim perbaikannya lewat Capgo alih-alih menunggu berhari-hari untuk persetujuan app store. Pengguna mendapat update di background, sementara perubahan native tetap mengikuti jalur review normal.

Terbaru dari Blog kami

Capgo memberikan insight terbaik yang Anda butuhkan untuk membuat aplikasi mobile yang benar-benar profesional.