Migrasi React Native New Architecture…

Diperbarui: 18 Juli 2026

Migrasi ke React Native New Architecture di 2026 sudah bukan pilihan, ini keharusan. React Native 0.76 menjadikan New Architecture sebagai default, 0.82 secara permanen menghapus jembatan (Bridge) lama, dan 0.84 menjadikan Hermes V1 sebagai mesin JavaScript default. Untuk aplikasi produksi, migrasi berarti empat pilar utama: JSI, Fabric, TurboModules, dan Codegen. Saya sudah menuntun enam app melewati proses ini (beberapa mulus, satu berdarah-darah selama tiga minggu), dan artikel ini adalah playbook praktis yang seharusnya saya miliki dari awal.

New Architecture adalah default sejak React Native 0.76 dan Bridge lama sudah dihapus di 0.82, jadi tidak ada jalan mundur.
Empat pilar (JSI, Fabric, TurboModules, Codegen) bekerja sama menghilangkan bottleneck serialisasi JSON dari Bridge lama.
Migrasi rata-rata memakan waktu 2 sampai 8 minggu tergantung jumlah kode native kustom dan dependensi pihak ketiga.
Interop Layer secara otomatis aktif sejak RN 0.74 sehingga modul legacy tetap berjalan, tapi bukan pengganti migrasi penuh.
Audit dependensi via reactnative.directory dan expo-doctor WAJIB sebelum menyentuh flag apapun.
Hasil produksi nyata menunjukkan cold start 43% lebih cepat, rendering 39% lebih cepat, dan pemakaian memori 26% lebih rendah.

Apa itu New Architecture React Native?

New Architecture adalah penulisan ulang total lapisan komunikasi React Native yang menggantikan Bridge asinkron berbasis JSON dengan komunikasi C++ langsung antara JavaScript dan kode native. Bridge lama memaksa setiap panggilan native menjadi tiga langkah: serialisasi JSON di thread JS, transfer asinkron ke thread native, deserialisasi di sisi native. Untuk animasi 120fps atau gesture handler bertumpuk, overhead ini terlihat jelas: dropped frame, layout jitter, dan latensi interaksi di atas 100ms.

Di New Architecture, JavaScript memanggil fungsi native secara langsung melalui JSI. Layout dihitung di lapisan C++ yang dibagi (Yoga), bukan lagi bolak-balik ke JS. Modul native lazy-loaded sehingga startup tidak terbebani modul yang belum dipakai. Semuanya type-safe karena Codegen membaca spec TypeScript/Flow Anda dan menghasilkan interface Objective-C++/Kotlin secara otomatis. Ini bukan optimisasi kecil. Ini fondasi ulang dari cara React Native bekerja, dan setelah menuntun tim melalui migrasi ini, jujur saja, hasilnya sepadan dengan usahanya.

Empat pilar: JSI, Fabric, TurboModules, Codegen

Setiap teknologi di New Architecture memiliki peran spesifik. Memahami perannya membantu Anda mendiagnosis masalah lebih cepat saat migrasi berjalan.

JSI (JavaScript Interface)

JSI adalah lapisan tipis C++ yang mengekspos referensi native langsung ke runtime JavaScript. Tidak ada lagi JSON.stringify tersembunyi di setiap panggilan native module. JSI bersifat engine-agnostic. Meski Hermes adalah default, JSI dirancang agar mesin JavaScript apapun (JSC, V8) bisa dipakai. Inilah fondasi yang membuat TurboModules dan Fabric mungkin.

Fabric (renderer baru)

Fabric memindahkan Shadow Tree dari JavaScript ke C++. Konsekuensinya, layout Yoga dihitung di thread yang sama dengan native, sehingga useLayoutEffect akhirnya bekerja secara sinkron seperti yang React inginkan. Fabric juga membuka concurrent features React 19 (Suspense, Transitions, dan streaming SSR di web) di dunia mobile. Untuk aplikasi dengan scroll view kompleks atau gesture nested, Fabric memberi rendering yang lebih deterministik.

TurboModules

TurboModules menggantikan NativeModules lama dengan tiga peningkatan: lazy initialization (modul dimuat saat pertama dipakai, bukan saat startup), akses sinkron via JSI, dan type safety via Codegen. Untuk aplikasi menengah, lazy initialization saja biasanya memangkas 200 sampai 400 ms dari cold start di Android low-end.

Codegen

Codegen membaca spec TypeScript atau Flow modul Anda saat build time dan menghasilkan interface Objective-C++ (iOS) dan Java/Kotlin (Android) secara otomatis. Ini pergeseran besar dari runtime type-checking ke build-time. Kesalahan tipe yang dulu baru muncul di production sekarang gagal di CI. Pemeriksa detail bisa langsung membaca dokumentasi arsitektur resmi React Native untuk penjelasan lebih dalam soal setiap pilar.

Apakah migrasi ke New Architecture wajib di 2026?

Ya, di 2026 migrasi bukan lagi opsional. React Native 0.76 (Oktober 2024) menjadikan New Architecture default untuk proyek baru. React Native 0.82 (Maret 2026) menghapus jalur Bridge lama sepenuhnya dari runtime. Jika Anda upgrade ke 0.82 atau lebih baru, Anda otomatis di New Architecture, mau tidak mau. Apps yang masih di React Native 0.75 atau sebelumnya bisa menunda, tapi setiap release baru library populer (Reanimated 4, Gesture Handler 2.20+, Expo SDK 55) juga meninggalkan dukungan Bridge lama.

Saya melihat tim yang menunda migrasi 12+ bulan menghadapi masalah lebih besar daripada tim yang migrasi lebih awal: dependensi terkunci di versi lama, security patch yang tidak bisa diambil, dan iOS 26 / Android 16 API baru yang butuh support Fabric untuk banyak fitur (misalnya PredictiveBack di Android). Rekomendasi saya jelas: jadwalkan migrasi di kuartal terdekat yang memungkinkan, jangan tunggu paksaan release berikutnya.

Berapa lama waktu migrasi ke New Architecture?

Berdasarkan enam migrasi yang saya kerjakan, rentang realistisnya 2 sampai 8 minggu. Faktor pembeda utama bukanlah ukuran aplikasi, melainkan jumlah kode native kustom. Sebuah app Expo managed tanpa modul kustom bisa selesai dalam 3 sampai 5 hari, hampir seluruhnya di sisi QA. Sebuah app bare workflow dengan 10+ modul native kustom, integrasi SDK vendor, dan native UI components akan mendekati 6 sampai 8 minggu.

Breakdown waktu yang saya jumpai:

Audit dependensi & upgrade RN: 3 sampai 5 hari. Ini termasuk upgrade Node, upgrade Xcode/Android Studio, upgrade RN ke versi target, dan clean build pertama.
Migrasi TurboModules: 1 sampai 2 minggu untuk 5 sampai 10 modul kustom. Pola Codegen konsisten, jadi modul ke-2 dan seterusnya jauh lebih cepat dari yang pertama.
Migrasi Fabric components: 1 sampai 2 minggu jika Anda punya native UI kustom (video player, WebView wrapper, chart). Skip fase ini jika Anda hanya pakai komponen dari react-native core.
QA & bug fixing: 1 sampai 3 minggu. Ini yang paling sering diremehkan. Fabric mengekspos bug layout yang tersembunyi di Bridge lama karena timing berbeda.

Audit dependensi sebelum migrasi

Audit dependensi adalah langkah pertama, bukan langkah terakhir. Sebelum menyentuh newArchEnabled, jalankan expo-doctor atau cek manual setiap dependensi native di React Native Directory. Direktori ini menandai kompatibilitas New Architecture untuk 800+ library. Filter yang paling saya andalkan: New Architecture support = Yes dan Actively maintained = Yes.

# Untuk proyek Expo (SDK 52+)
npx expo-doctor

# Untuk proyek bare, cek daftar dependensi native
npx react-native config | grep -i "platforms"

# Cek satu library spesifik
npx react-native-directory check react-native-camera

Untuk modul yang belum kompatibel, ada tiga opsi: (1) upgrade ke versi yang mendukung, (2) ganti dengan alternatif yang mendukung, atau (3) andalkan Interop Layer sementara. Opsi 3 hanya cocok untuk modul non-kritis. Untuk modul yang menangani auth, payment, atau kamera, jangan bergantung pada Interop.

Untuk pengalaman membangun modul native kustom yang siap untuk New Architecture sejak awal, panduan kami tentang Expo Modules API dengan Swift dan Kotlin menunjukkan pola Codegen yang direkomendasikan.

Cara enable New Architecture di Expo dan bare workflow

Untuk proyek Expo (SDK 52+), aktivasinya satu baris di app.json:

{
  "expo": {
    "name": "MyApp",
    "newArchEnabled": true,
    "plugins": [
      "expo-router",
      "expo-splash-screen"
    ]
  }
}

Setelah itu jalankan npx expo prebuild --clean untuk regenerate folder ios dan android, kemudian npx expo run:ios dan npx expo run:android. Expo menangani konfigurasi C++, Hermes, dan autolinking modul secara otomatis. Dokumentasi lengkapnya ada di panduan New Architecture Expo. Kalau kamu baru mulai proyek Expo dari nol dan ingin routing yang siap pakai, lihat juga Expo Router 4 untuk file-based routing. Templatenya sudah default ke New Architecture.

Untuk bare workflow, aktivasinya berbeda per platform:

# Android — di android/gradle.properties
newArchEnabled=true
hermesEnabled=true

# iOS — di ios/Podfile.properties.json
{
  "expo.jsEngine": "hermes",
  "newArchEnabled": "true"
}

# Kemudian di folder ios, jalankan:
RCT_NEW_ARCH_ENABLED=1 bundle exec pod install

Setelah flag aktif, WAJIB lakukan clean build lengkap. Ini bukan opsional. Cache Metro dan Gradle sering menyimpan symbol lama yang menyebabkan crash startup misterius:

# Bersihkan semua cache
rm -rf node_modules ios/Pods ios/build android/build android/.gradle
watchman watch-del-all
npx react-native start --reset-cache

# Install ulang
yarn install
cd ios && bundle exec pod install && cd ..
yarn ios
yarn android

Migrasi custom native module ke TurboModule

Migrasi TurboModule mengikuti pola tiga langkah: definisikan spec TypeScript, tulis implementasi native, daftarkan modul via Codegen. Contoh minimal untuk modul yang mengambil versi native app:

// specs/NativeAppInfo.ts
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  // Sinkron, dimungkinkan karena JSI
  getVersion(): string;
  // Asinkron, untuk operasi yang butuh main thread
  getInstalledApps(): Promise<string[]>;
  // Event emitter tetap didukung
  addListener(eventName: string): void;
  removeListeners(count: number): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('NativeAppInfo');

Konfigurasi Codegen di package.json:

{
  "codegenConfig": {
    "name": "NativeAppInfoSpec",
    "type": "modules",
    "jsSrcsDir": "./specs",
    "android": {
      "javaPackageName": "com.myapp.appinfo"
    }
  }
}

Implementasi Android (Kotlin):

// android/src/main/java/com/myapp/appinfo/AppInfoModule.kt
package com.myapp.appinfo

import com.facebook.react.bridge.ReactApplicationContext
import com.facebook.react.bridge.Promise

class AppInfoModule(reactContext: ReactApplicationContext) :
  NativeAppInfoSpec(reactContext) {

  override fun getName() = NAME

  override fun getVersion(): String {
    val pkg = reactApplicationContext.packageManager
      .getPackageInfo(reactApplicationContext.packageName, 0)
    return pkg.versionName ?: "unknown"
  }

  override fun getInstalledApps(promise: Promise) {
    // Operasi berat di thread background
    Thread {
      val apps = reactApplicationContext.packageManager
        .getInstalledApplications(0)
        .map { it.packageName }
      promise.resolve(apps.toTypedArray())
    }.start()
  }

  companion object {
    const val NAME = "NativeAppInfo"
  }
}

Codegen akan menghasilkan class abstrak NativeAppInfoSpec otomatis saat build. Anda tinggal extend dan implement. Method yang di TypeScript dideklarasikan sebagai return sinkron akan dipanggil di thread JS langsung via JSI, jadi pastikan operasinya cepat (di bawah 16 ms) atau app akan freeze. Untuk operasi berat, selalu pakai Promise dan pindahkan ke thread background.

Migrasi komponen native ke Fabric

Fabric components jauh lebih jarang dibutuhkan daripada TurboModules. Mayoritas app tidak punya native UI kustom. Tapi jika Anda punya (misalnya native map view, native video player, atau bridge ke SDK vendor yang mengekspor UIView), berikut kerangka minimalnya:

// specs/RCTMyMapNativeComponent.ts
import type { HostComponent, ViewProps } from 'react-native';
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';
import type { Float } from 'react-native/Libraries/Types/CodegenTypes';

interface NativeProps extends ViewProps {
  latitude: Float;
  longitude: Float;
  zoom?: Float;
  showsUserLocation?: boolean;
}

export default codegenNativeComponent<NativeProps>('RCTMyMap') as HostComponent<NativeProps>;

Perhatikan tipe Float dari CodegenTypes. Ini penting. Fabric butuh tipe primitif eksplisit (Float, Int32, Double) bukan hanya number, agar Codegen bisa menghasilkan struct C++ dengan layout yang tepat.

Untuk animasi kompleks yang berjalan di UI thread setelah migrasi Fabric, panduan kami tentang React Native Reanimated 4 untuk CSS animations dan gestures menunjukkan cara mengambil keuntungan penuh dari rendering deterministik Fabric.

Troubleshoot crash startup dan red box setelah migrasi

Setelah flag menyala, tiga kategori masalah paling sering muncul. Berikut checklist debugging yang saya pakai:

1. Crash startup Android tanpa stack trace

Crash native seringkali muncul tanpa log JS. Ambil log native langsung:

# Bersihkan buffer log dulu
adb logcat -c

# Jalankan app, lalu tangkap log
adb logcat *:E ReactNative:V ReactNativeJS:V

# Untuk crash JNI/C++ spesifik
adb logcat | grep -E "AndroidRuntime|libc|DEBUG"

Penyebab paling umum: modul native yang belum di-autolink ulang (jalankan cd android && ./gradlew clean) atau versi Kotlin/Gradle yang tidak kompatibel dengan React Native versi target.

2. Red box "Unknown component" untuk komponen lama

Interop Layer menangani sebagian besar komponen legacy, tapi tidak semua. Jika sebuah komponen muncul sebagai red box, cek apakah library-nya sudah menerbitkan versi New Architecture. Jika belum dan tidak ada alternatif, wrapper manual dengan Fabric interop bisa jadi jalan sementara, tapi ini tanda kuat untuk mengganti library tersebut.

3. Ref yang null karena view flattening

Fabric mengoptimalkan view yang tidak memiliki side effect (seperti <View> tanpa handler) dengan flattening. Masalahnya, jika Anda pasang ref ke view seperti itu, ref akan null karena view-nya dihapus dari tree native.

// Ref akan null karena View di-flatten
<View ref={containerRef}>
  <Text>Hello</Text>
</View>

// Solusi: pakai collapsable={false}
<View ref={containerRef} collapsable={false}>
  <Text>Hello</Text>
</View>

Honestly, ini bug yang paling banyak menghabiskan waktu tim saya di migrasi pertama. Saya menghabiskan hampir dua hari mengejar ref yang tiba-tiba null di production tapi normal di dev. Sekarang aturan kami: setiap View yang punya ref langsung ditandai collapsable={false}. Untuk isu produksi lain, daftar known issues di working group React Native adalah sumber pertama yang harus dicek.

Performa setelah migrasi: Hermes V1 dan tuning

React Native 0.84 menjadikan Hermes V1 default. Hermes V1 membawa compiler yang ditulis ulang, format bytecode baru, concurrent garbage collector (Hades), dan JIT yang jauh lebih efisien untuk pola JavaScript modern. Dibanding JavaScriptCore, benchmarks produksi menunjukkan startup 50 sampai 60% lebih cepat di Android mid-range dan memori 30 sampai 40% lebih rendah.

Konfigurasi Hermes optimal yang saya rekomendasikan setelah migrasi:

// android/app/build.gradle
project.ext.react = [
    enableHermes: true,
    hermesFlags: [
        "-O",                          // Optimasi maksimal
        "-output-source-map",          // Untuk debugging
        "-emit-binary"                 // Precompile ke bytecode
    ]
]

// iOS di Podfile
use_react_native!(
  :path => config[:reactNativePath],
  :hermes_enabled => true,
  :fabric_enabled => true,
  :new_arch_enabled => true
)

Untuk mengukur dampak nyata migrasi, jangan hanya andalkan debug build. Angka di sana penuh false positive karena dev-mode markers. Pakai react-native-release-profiler untuk profiling di release build, dan pasang @shopify/react-native-performance untuk mengukur TTI (Time To Interactive) di production.

Target metrik yang saya pakai untuk validasi migrasi berhasil:

Cold start (TTI): di bawah 2.0s di Android mid-tier, di bawah 1.2s di iPhone 13
Sustained scroll FPS: 58+ fps di device p99
Latensi interaksi: di bawah 100ms dari tap ke feedback visual pertama
Working set JS memory: di bawah 180MB untuk app complexity normal
Install size: di bawah 30MB untuk APK/IPA awal

Fetching data juga jadi lebih penting setelah migrasi. Fabric mengekspos regresi network yang tersembunyi di Bridge lama. Panduan kami tentang state management dengan Zustand dan TanStack Query menunjukkan pola caching yang cocok dengan concurrent rendering React 19.

Pertanyaan yang Sering Diajukan

Apakah saya harus migrasi jika app saya masih di React Native 0.74?

Ya, dan sebaiknya secepat mungkin. Setiap major release library populer (Reanimated 4, Gesture Handler 2.20+, Expo SDK 55) sudah meninggalkan dukungan Bridge lama. Semakin lama menunda, semakin banyak dependensi terkunci di versi lama dan semakin sulit upgrade.

Apakah Hermes wajib untuk New Architecture?

Praktis wajib. New Architecture dibangun di atas JSI, dan meski JSI secara teori engine-agnostic, JavaScriptCore memiliki keterbatasan yang membuat banyak fitur (bytecode caching, concurrent GC) tidak tersedia. Semua dokumentasi resmi dan Expo SDK berasumsi Hermes aktif.

Bisakah saya migrasi bertahap satu modul per satu?

Untuk custom modules, ya, TurboModules dan Native Modules lama bisa hidup berdampingan via Interop Layer. Untuk flag New Architecture itu sendiri, tidak, ini binary switch untuk seluruh app. Rekomendasi saya: aktifkan flag di branch terpisah, lalu migrasi modul kustom satu per satu di branch tersebut sebelum merge.

Berapa besar peningkatan performa yang bisa saya harapkan?

Data produksi menunjukkan cold start 43% lebih cepat, rendering 39% lebih cepat, memori 26% lebih rendah, dan komunikasi JS-native 40x lebih cepat. Namun angka ini bervariasi berdasarkan seberapa berat penggunaan native module dan animasi di app Anda. App yang cukup UI-heavy melihat gain terbesar; app yang mostly menampilkan data statis melihat gain lebih moderat.

Apa yang harus dilakukan jika library kritis belum mendukung New Architecture?

Tiga opsi berurutan: (1) cek apakah maintainer punya PR terbuka atau discussion aktif, jika ya, tunggu atau kontribusi. (2) Cari alternatif yang mendukung, biasanya ada. (3) Andalkan Interop Layer sementara, tapi hanya untuk modul non-kritis. Untuk auth, payment, atau kamera, jangan bergantung pada Interop di production.

Apakah saya perlu upgrade Xcode atau Android Studio untuk migrasi?

Ya. React Native 0.76+ butuh minimum Xcode 15.0 (16.0 direkomendasikan) dan Android Gradle Plugin 8.1+. Update semua toolchain sebelum menyentuh flag New Architecture. Banyak crash startup misterius yang saya lihat ternyata karena versi Xcode atau NDK yang out of date.