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

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.
-
Instal package
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 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.
-
Instal package
npm install lottie-react-native -
Install pods iOS
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 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.

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.

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:
useRefmenghindari rerender yang tidak perlu. - Komponen menghindari konflik autoplay: Anda tidak ingin perilaku mount bertentangan dengan perilaku yang dipicu pengguna.
Kesalahan umum yang perlu dihindari:
-
Triggering before the ref exists
JikaanimationRef.currentis null, playback tidak akan terjadi. Lindungi dengan guard. -
Menggunakan
autoPlaydengan kontrol imperatif
Pilih satu owner default untuk playback. -
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
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 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.