Lompat ke konten utama
Mobile Panduan

Lottie React Native

Panduan lengkap kami menunjukkan cara menggunakan Lottie React Native. Mencakup workflow Expo & bare, kontrol animasi, tuning performa, dan best practice untuk 2026.

Lottie React Native

Anda mungkin sedang berada di salah satu dari dua situasi ini. Entah ada desainer yang menyerahkan file JSON Lottie dan bertanya, “Bisa kita masukkan ini ke aplikasi hari ini?”, atau Anda sudah memasangnya dan menyadari animasinya jalan di development tapi mulai terasa berat begitu perangkat asli, waktu startup, dan release build ikut diperhitungkan.

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

Table of Contents

Mengapa Lottie Penting untuk Aplikasi React Native

Jika Anda pernah mencoba membuat animasi produk yang halus secara manual di React Native, Anda pasti tahu sulitnya. Detail gerakan kecil berubah menjadi tumpukan logika timing, interpolasi, dan quirk platform. Animasinya mungkin terlihat mirip, tapi kata "mirip" biasanya tidak sesuai dengan hasil desain aslinya.

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

Desain dan engineering tak lagi berkelahi soal hal yang sama

Keuntungan utama Lottie React Native bukan sekadar "animasi JSON yang cantik." Melainkan pemisahan tanggung jawabnya. Desainer bekerja di After Effects dan mengekspornya dengan Bodymovin. Developer merender hasilnya dengan playback berbasis native, bukan menerjemahkan gerakan ke dalam code kustom.

Hal ini penting karena pekerjaan animasi cenderung berdampak luas. Satu animasi state perayaan bisa memengaruhi review desain, review produk, perilaku Android, perilaku iOS, aksesibilitas, hingga performa startup. Lottie mempersempit cakupan tersebut.

Aturan praktis: Gunakan Lottie saat animasi merupakan bagian dari pengalaman produk, bukan saat Anda hanya butuh transisi opacity atau translate sederhana.

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

Di mana Lottie paling pas

Lottie React Native paling optimal untuk:

  • Micro-interaction brand seperti like, save, checkmark, dan status sukses pembelian
  • Ilustrasi onboarding yang ingin terasa custom tanpa harus kirim file 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 seringkali lebih simpel. Untuk sistem motion yang sangat besar atau sangat interaktif, format JSON bisa jadi sebuah trade-off alih-alih keuntungan. Trade-off ini makin krusial saat masuk tahap production, di mana kebanyakan tutorial berhenti terlalu cepat.

Menyiapkan Lingkungan Development Lottie Anda

Langkah instalasi bergantung pada satu keputusan awal: Expo managed workflow atau bare React Native. Jangan mencampuradukkan model mentalnya. Kebanyakan masalah setup terjadi saat developer mengikuti panduan bare workflow di dalam Expo, atau berasumsi Expo mengabstraksi semua detail native.

Flowchart yang menunjukkan langkah-langkah setup animasi Lottie di proyek Expo dan Bare React Native.

Pilih workflow sebelum instalasi

Jika aplikasi Anda menggunakan Expo dan ingin setup tercepat, tetaplah di jalur Expo kecuali Anda tahu butuh kustomisasi native. Jika Anda menggunakan bare app, atau sudah bergantung pada native module yang butuh kontrol langsung, instal sebagai dependency native biasa dan segera validasi build iOS serta Android.

Banyak tim meremehkan betapa jauh lebih mudahnya debugging jika setup Anda selaras dengan tipe proyek. Itulah alasan mengapa banyak tim yang membangun integrasi native kustom membandingkan Capgo sebagai alternatif Expo EAS sejak awal daripada menunggu sampai aplikasi semakin sulit diubah.

Setup Expo managed

Untuk aplikasi Expo-managed, buatlah seminimal mungkin.

  1. Instal paketnya

    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 kecil terlebih dahulu. Jangan debug aset besar dan instalasi baru secara bersamaan.

Beberapa catatan praktis penting di Expo:

  • Utamakan file lokal terlebih dahulu: Debugging animasi remote menambah noise jaringan saat Anda hanya ingin memastikan library berfungsi.
  • Tes perilaku release lebih awal: Mode development bisa menyembunyikan masalah terkait timing dan performa.
  • Perhatikan path aset: Salah lokasi file JSON adalah salah satu penyebab paling umum munculnya error “it renders nothing”.

Expo adalah rute tercepat menuju “it works.” Tapi itu bukan berarti rute tercepat menuju “it scales.”

Setup Bare React Native

Pada project bare, segera install dan validasi native dependencies.

  1. Instal paketnya

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

    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 full native rebuild sebelum menyimpulkan ada yang error. Hot reload tidak akan bisa memperbaiki native dependency yang belum terkompilasi dengan benar ke dalam aplikasi.

Cek workflow dasar untuk hemat waktu

Gunakan checklist singkat ini sebelum lanjut:

Cek Mengapa ini penting
Rebuild setelah instalasi Native module butuh kompilasi ulang
Jalankan pod install iOS tidak akan stabil 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 conditional playback, JSON remote, atau ekspor animasi dengan banyak layer.

Ruang kerja developer modern dengan laptop yang menampilkan code dan monitor yang menunjukkan aplikasi animasi mobile.

Tambahkan file animasi lokal

Create an asset folder if you don’t already have one:

assets/
  animations/
    success.json

Gunakan nama yang simpel. Hindari spasi, tanda baca aneh, dan folder dengan nesting terlalu dalam. Anda ingin require() jalur agar tetap optimal.

Jika Anda menggunakan Lottie untuk branded loading screen awal atau handoff setelah peluncuran, pertimbangkan matang-matang sebelum memasukkan animasi besar ke startup path. Hal ini sangat penting terutama saat Anda juga sedang menyetel perilaku splash screen React Native.

Render menggunakan LottieView

Buat komponen khusus alih-alih langsung memasukkannya ke dalam 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,
  },
});

Ini melakukan tiga hal berguna:

  • membuktikan library merender dengan benar
  • membuktikan asset path teresolusi dengan benar
  • memberikan satu tempat terisolasi untuk mengatur playback dan ukuran nanti

Beberapa kendala akan langsung muncul jika Anda melewatkan hal dasar:

  • Tanpa width atau height: Animasi mungkin berjalan tetapi tidak terlihat.
  • Buruk require() path: Metro tidak dapat menemukan file tersebut.
  • Export tidak valid: Beberapa file JSON secara teknis valid, namun memiliki fitur yang tidak berjalan semestinya di mobile.

Pastikan render pertama bersifat lokal dan deterministik. Anda sedang menguji integrasi, bukan arsitektur.

Tes layar pertama yang lebih baik

Letakkan komponen pada layar sederhana dengan background 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 berhasil di simulator iOS maupun Android, Anda telah melewati rintangan pertama yang nyata. Langkah selanjutnya bukan menambah lebih banyak animasi, melainkan belajar kapan harus menggunakan declarative props dan kapan harus menggunakan kontrol langsung dengan refs.

Menguasai Kontrol Animasi Lottie

Kebanyakan bug Lottie React Native muncul saat animasi perlu bereaksi terhadap state. Autoplay itu mudah. Namun, instruksi seperti “Putar segmen ini saat user menyukai item, putar balik saat tidak menyukai, dan jangan stutter saat komponen re-render” adalah bagian yang rumit.

Tabel perbandingan yang menjelaskan metode kontrol animasi declarative vs imperative di Lottie, beserta use case 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:

  • loading indicator
  • ilustrasi onboarding pasif
  • dekorasi empty state

Metodenya deklaratif dan mudah dibaca. Komponen di-mount, playback dimulai, dan React tetap memegang kendali. Jika logika animasi bisa dijelaskan sepenuhnya lewat props, gunakan cara ini.

Kasus deklaratif yang lebih lanjut adalah progress, di mana Anda menghubungkan frame animasi ke nilai lain. Ini bekerja baik jika gerakan harus mencerminkan progres eksternal, tapi kurang praktis untuk trigger event sekali jalan.

Berikut perbandingan visual singkat sebelum masuk ke refs:

Gunakan refs saat state menggerakkan animasi

Saat user melakukan tap, toggle, atau menyelesaikan aksi, ref biasanya menjadi tool yang lebih aman. Data di dunia nyata menunjukkan 68% developer yang menggunakan framework hybrid melaporkan kegagalan trigger animasi akibat penanganan ref yang salah di useEffect hooks, itulah sebabnya pola yang andal sangatlah animation.current.play() penting, seperti yang dibahas dalam diskusi Capacitor mengenai kegagalan trigger.

Masalah ini tidak hanya terjadi pada aplikasi hybrid. Hal ini juga muncul di React Native biasa, terutama saat developer membuat ulang ref, memicu playback sebelum mount, atau mengaitkan pemanggilan 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 tangguh di production daripada memanggilnya play() di dalam useEffect setiap kali state berubah.

Mengapa ini berhasil:

  • Event memegang kendali 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: Jangan sampai perilaku mount bentrok dengan perilaku trigger user.

Kesalahan umum yang perlu dihindari:

  1. Trigger sebelum ref tersedia
    Jika animationRef.current bernilai null, playback tidak akan jalan. Gunakan guard.

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

  3. Menggerakkan segalanya melalui useEffect
    Efek memang berguna, tapi untuk aksi UI, hal itu 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 termudah adalah memasukkan setiap animasi langsung ke JavaScript dan memuat semuanya terlalu dini. Menurut panduan tentang kesalahan pengiriman Lottie JSON 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 native assets untuk on-demand loading adalah optimasi yang krusial.

Hal ini sejalan dengan apa yang dialami banyak tim di lapangan. Masalahnya bukan pada satu animasi sukses yang kecil. Masalahnya adalah penumpukannya:

  • motion onboarding
  • state loader
  • reaksi e-commerce
  • layar kosong berlogo brand
  • file locale dan aset berat bundle lainnya yang ada di sampingnya

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

Apa yang harus dioptimasi lebih dulu

Mulai dari proses export itu sendiri. Export animasi yang berantakan membawa kompleksitas yang akan berdampak pada parsing, memori, dan stabilitas render nantinya. Jangan terima setiap export desainer apa adanya.

Gunakan checklist produksi ini:

  • Kompres JSON sebelum dikirim: File yang lebih kecil lebih mudah dimuat dan tidak membuat startup membengkak.
  • Pindahkan animasi non-kritis keluar dari JS bundle: Jaga agar 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 kritis 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 kenyataan pahit: Animasi cantik yang menunda interaksi pertama biasanya adalah bug produk, bukan kemenangan desain.

Anda juga harus berpikir melampaui React Native saja. Tim yang menggunakan hybrid stack menghadapi masalah loading aset serupa, dan panduan performa animasi yang lebih luas untuk aplikasi Capacitor juga sangat relevan untuk keputusan Lottie.

File lokal vs pengiriman remote

File lokal lebih terprediksi. Bisa jalan offline, bebas variasi jaringan, dan lebih mudah dites. Tapi, rawan membuat bundle terlalu besar.

Pengiriman remote menjaga binary tetap ringan, tapi animasi Anda kini punya isu ketersediaan, caching, dan fallback. Trade-off ini oke untuk motion non-kritis, tapi berisiko untuk UX utama seperti konfirmasi pembelian atau sukses autentikasi.

Pembagian praktis yang efektif:

Tipe aset Default terbaik
Animasi interaksi inti Lokal, optimal, tidak berlebih
Animasi promosi sesekali Remote dengan fallback
Animasi startup path Lokal hanya jika benar-benar perlu
Ilustrasi fitur yang jarang dipakai Load 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 bermasalah, penyebabnya biasanya biasa saja. Path salah. Ukuran hilang. Timing ref buruk. JSON terlalu berat. Cara tercepat untuk debug adalah mengurangi variabel.

Animasi tidak render di Android

Pertama, pastikan file JSON terdeteksi. Lalu berikan dimensi eksplisit pada komponennya.

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

Jika masih gagal, coba ganti dengan animasi lain yang sudah terbukti jalan. Ini untuk mengecek apakah masalahnya ada di file atau di setup.

Playback patah-patah di perangkat lama

Ini biasanya masalah pada asset, bukan pada komponen API.

Coba perbaikan berikut:

  • Kurangi kompleksitas animasi: Minta ekspor yang lebih ringan jika file sumber terlalu berat.
  • Load belakangan: Don’t compete with initial screen work.
  • Tes versi kompresi: Jika file kompresi berjalan lebih lancar, berarti di situlah bottleneck-nya.
  • Hapus penggunaan beberapa Lottie view secara bersamaan: Terlalu banyak animasi dalam 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 jika tidak perlu. Jika Anda sedang debugging error aneh pada local build, membersihkan cache lama bisa membantu. Cukup lakukan rutinitas pembersihan cache Yarn untuk mengatasi perilaku aset yang tidak sesuai 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 yang sadar aspect ratio untuk ilustrasi besar
  • Hindari stretching ke full width tanpa mengecek komposisi asli hasil export

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

Jika butuh cara cepat debugging, hapus semua prop advanced, render satu animasi lokal di view tengah, lalu bangun kembali dari sana. Pendekatan ini mengisolasi masalah lebih cepat daripada menatap layar produksi yang kompleks.


Capgo membantu tim mengirimkan 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 pemulihan cepat dari masalah front-end, Capgo layak untuk dicoba.

Live update untuk aplikasi Capacitor

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

Terbaru dari Blog kami

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