Langsung ke konten
Rangga Prastio
EN
← Kembali

React Native di Production: Pelajaran Dari Proyek Nyata

Pelajaran dari merilis aplikasi React Native untuk klien enterprise: jebakan performa, keputusan arsitektur, dan hal yang benar-benar penting.

Terbit , react-native, mobile, typescript, performa, arsitektur

Saya sudah merilis aplikasi React Native secara profesional, salah satunya untuk Serasi Auto Raya, perusahaan manajemen armada kendaraan terbesar di Indonesia. Saya juga ikut mengerjakan aplikasi mobile di Glovory dan Ako Media. Ini hal-hal yang jarang dibahas di tutorial.

Janji vs. Realita

Janji React Native memang menggoda: satu codebase, dua platform, dan ilmu React kamu tetap terpakai. Sebagian besar janji itu benar. Yang sering diremehkan adalah repotnya merawat aplikasi mobile di production: over-the-air update, kompatibilitas native module di berbagai versi OS, dan disiplin menjaga performa tetap mulus di HP Android kelas menengah.

Keputusan Arsitektur Yang Tahan Lama

Pisahkan navigation dari state

Kesalahan arsitektur terbesar yang saya lihat dalam codebase React Native adalah menggabungkan logika navigation dengan update state. Ketika aksi pengguna memicu navigasi DAN perubahan state sekaligus, mencampurnya menciptakan alur yang sulit di-debug.

Pola yang saya pakai:

// Action dispatch dulu, navigation adalah side effect
dispatch(submitOrder(payload));
// Navigation ditangani di saga/effect, bukan inline

Hasilnya, testing jadi jauh lebih mudah karena state machine-nya bisa dites tanpa perlu mock navigation.

TypeScript strict dari hari pertama

Mulai dengan "strict": true di tsconfig.json tidak bisa dinegosiasikan pada proyek mobile. Alasannya: bug mobile itu mahal. Bug web bisa dihotfix dalam hitungan menit; bug mobile mungkin memerlukan siklus review App Store. TypeScript menangkap kategori bug yang murah di web tapi mahal di mobile.

Perlakukan native layer sebagai dependency nyata

Setiap library pihak ketiga yang menyentuh kode native adalah dependency nyata, bukan sekadar npm install. Lacak dengan cermat. Test setelah setiap bump versi OS. Saya pernah terkena library yang diam-diam rusak di Android 14 dan iOS 17.

Jebakan Performa Yang Pernah Saya Alami

FlatList vs. FlashList

FlatList bawaan masih aman untuk list di bawah ~100 item. Lebih dari itu, frame drop mulai terasa di HP Android kelas menengah. FlashList dari Shopify bisa langsung menggantikannya dengan performa yang jauh lebih baik untuk list panjang. Pindahlah sejak awal, karena memasangnya belakangan di codebase besar itu menyiksa.

Bridge overhead pada animasi

Animasi yang digerakkan JavaScript melewati JS-to-native bridge dan akan patah pada layar yang berat. Gunakan Animated dengan useNativeDriver: true untuk animasi transform dan opacity, dan gunakan react-native-reanimated untuk yang lebih kompleks. Model worklet di Reanimated 2+ sangat bagus.

Penanganan gambar

Image bawaan React Native tidak menyimpan cache. Di aplikasi yang penuh feed, ini bikin performa anjlok. react-native-fast-image (atau Expo Image di proyek Expo) dengan cache header yang benar dari CDN kamu bukan pilihan tambahan. Ini wajib.

Yang Benar-Benar Penting untuk Production

Crash reporting sebelum segalanya. Sentry untuk React Native menangkap error JS dan native crash. Setup sebelum kamu mengirim satu fitur pun.

Over-the-air update itu senjata rahasia. CodePush (atau EAS Update di Expo) memungkinkan kamu mengirim update JS bundle tanpa menunggu review store. Pakai dengan bijak, cukup untuk perubahan yang tidak breaking, tapi tetap pakai. Bisa memperbaiki bug production dalam hitungan jam, bukan hari, itu keunggulan yang nyata.

Test pada perangkat nyata, bukan hanya simulator. Spesifiknya, test pada perangkat Android kelas menengah (Snapdragon seri 6xx). Simulator iPhone dan emulator Android high-end berbohong tentang performa.

Penanganan deep link lebih sulit dari yang terlihat. Rencanakan lebih awal. Universal links di iOS dan App Links di Android keduanya membutuhkan konfigurasi server-side dan setup native. Melakukan ini setelah launch itu menyakitkan.

Tradeoff Yang Jujur

React Native bukan tool yang tepat ketika:

  • Kamu butuh UI platform-spesifik yang sangat custom dan berbeda signifikan antara iOS dan Android
  • Kebutuhan performa kamu setingkat aplikasi kamera atau game
  • Tim kamu punya engineer native iOS/Android yang kuat dan tidak ada pengetahuan React

React Native adalah tool yang tepat ketika:

  • Tim kamu sudah mengenal React dan TypeScript
  • Aplikasimu terutama data-driven (form, list, dashboard, konten)
  • Kamu perlu ship di kedua platform dengan tim yang tidak mampu membiayai dua codebase native terpisah

Setelah bertahun-tahun mengirim aplikasi mobile, penilaian jujur saya: React Native di 2026 sudah production-ready, battle-tested, dan pilihan yang tepat untuk sebagian besar aplikasi bisnis.

Ada bagian yang bikin tim mentok? Kirim ke saya.

Terbuka untuk freelance dan kontrak, 20–40 jam per minggu. Biasanya saya balas dalam 24 jam.

Kirim email

ranggaprastio123@gmail.com

Jam kerja kita

Jam kamu
--:--
Jam Rangga
19:58
UTC+7