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
- Menyiapkan Lingkungan Development Lottie Anda
- Menampilkan Animasi Lottie Pertama Anda
- Menguasai Kontrol Animasi Lottie
- Optimasi Performa untuk Aplikasi Produksi
- Troubleshooting Masalah Umum Lottie
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.

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.
-
Instal paketnya
npx expo install lottie-react-native -
Restart Metro
npx expo start -c -
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.
-
Instal paketnya
npm install lottie-react-native -
Instal iOS pods
cd ios && pod install && cd .. -
Rebuild aplikasi
npx react-native run-iosatau
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.

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.

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:
useRefmenghindari rerender yang tidak perlu. - Komponen menghindari konflik autoplay: Jangan sampai perilaku mount bentrok dengan perilaku trigger user.
Kesalahan umum yang perlu dihindari:
-
Trigger sebelum ref tersedia
JikaanimationRef.currentbernilai null, playback tidak akan jalan. Gunakan guard. -
Menggunakan
autoPlaydengan kontrol imperatif
Pilih satu owner default untuk playback. -
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
useEffecthanya 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.

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.