React Native New Architecture: Fabric, TurboModule, JSI 2026

React Native New Architecture, 2024 Q3 itibarıyla 0.76 sürümüyle default hâline gelen ve Facebook’un (Meta) 2018’den beri geliştirdiği temel yeniden yazımdır; Fabric (yeni renderer), TurboModules (yeni native modül sistemi), JSI (JavaScript Interface) ve Codegen olmak üzere dört bileşenden oluşur. Eski “Bridge” mimarisinde asenkron JSON serileştirmesi nedeniyle ortalama 10-16 ms gecikme yaşanan native çağrılar, JSI sayesinde senkron C++ referanslarına dönüştü; Meta’nın resmi blog ölçümlerine göre TurboModule başlatma süresi 0.76’da Bridge’e göre yaklaşık 35-50% düştü, app start time iOS’ta 480 ms’den 320 ms’ye indi. Bu yazıda Fabric’in concurrent rendering modelini, TurboModule lazy loading mekaniğini, JSI HostObject API’sini ve migration sürecinde karşılaşılan brownfield app gotcha’larını gerçek benchmark verisi ve karar çerçeveleriyle ele alıyorum.

Eski Bridge mimarisinin somut bottleneck’leri

React Native’in 2015-2024 arası kullandığı klasik Bridge mimarisi, JavaScriptCore (iOS) veya Hermes (her iki platform) içindeki JS thread ile native UI thread arasında asenkron mesaj kuyruğu üzerinden iletişim kuruyordu. Her çağrı JSON formatına serileştirilip Bridge’e bırakılır, native taraf okur, işler, cevabı yine serileştirip JS thread’e geri gönderirdi. Bu desende üç ciddi problem birikti: (1) Serialization overhead: ScrollView’ün her frame’inde ölçülen ortalama 4-7 ms JSON parse maliyeti, 60 fps hedefinde frame budget’ın 16.6 ms olduğu düşünüldüğünde %25-40 oranında bütçeyi yiyordu. (2) Async-only contract: Senkron olması gereken işlemler (örneğin layout ölçümü, gesture handler ack) Promise zincirleriyle paketlenip frame gecikmelerine yol açıyordu. (3) Eager initialization: Tüm native modüller (Camera, Bluetooth, Maps) app açılışında belleğe yükleniyor, basit bir todo app’i bile 60-80 MB RAM ile başlıyordu.

Meta’nın 2019 React Conf’ta açıkladığı ve ardından 5 yıl boyunca incremental olarak ürettiği yeni mimari bu üç probleme birden cevap üretir: JSI synchronous C++ referansı, TurboModule lazy yükleme, Fabric concurrent renderer. Aşağıdaki tablo iki mimarinin temel karşılaştırmasını verir.

Özellik	Bridge (Eski)	New Architecture (Fabric+TurboModule)
JS ↔ Native iletişim	Asenkron JSON mesaj kuyruğu	Senkron JSI C++ HostObject
Modül yükleme	Eager (app start’ta hepsi)	Lazy (ilk erişimde)
Renderer	Paper (immediate mode, JS thread)	Fabric (concurrent, C++ shadow tree)
Type safety	Manuel, runtime hataları	Codegen ile compile-time
Tipik cold start (basit app)	~480 ms (iPhone 13)	~320 ms (iPhone 13)
Tipik RAM (idle)	60-80 MB	35-50 MB
Frame budget kullanımı (ScrollView)	%25-40 (serialization)	%5-10 (direkt referans)
Senkron API mümkün mü?	Hayır	Evet

Veri kaynakları: Meta Engineering Blog, React Native 0.76 release notes, Microsoft React Native Windows performance lab raporu, kendi production app’lerimdeki Firebase Performance Monitoring metrikleri.

JSI: JavaScript Interface ve C++ HostObject

JSI, React Native’in yeni mimari katmanında temel taştır; üzerine Fabric ve TurboModule kurulur. JSI, JS engine’den (Hermes veya JavaScriptCore) bağımsız bir C++ abstraction layer’dır: JS engine’i swap edilebilir kılar ve aynı zamanda native C++ nesnelerini doğrudan JavaScript değişkenleri olarak expose etmenizi sağlar. Anahtar primitif jsi::HostObject‘tir — bir C++ class’ı JS tarafında bir nesneymiş gibi davranır; get/set property çağrıları senkron şekilde C++ method’larına yönlendirilir.

Pratik fark: Eski Bridge’de bir SQLite query’sini çalıştırıp sonuç beklemek 8-12 ms (serialize → bridge → execute → deserialize) sürerken JSI tabanlı bir kütüphanede (örneğin op-sqlite veya WatermelonDB JSI mode) aynı sorgu 0.4-1.2 ms’de tamamlanır. 10-30x hızlanma. Bu fark sadece database’de değil; image processing, encryption, ML inference (TensorFlow Lite JSI bindings), real-time audio gibi her CPU-bound iş yükünde kendini gösterir. JSI ayrıca shared memory mantığı sağlar: bir ArrayBuffer’ı kopyalamadan native tarafa referans verebilirsiniz; 4K video frame işleme gibi senaryolarda 8-12 MB/frame kopyalama maliyeti sıfırlanır.

• Avantaj: Senkron çağrı, sıfır serialization, JS engine bağımsızlığı (Hermes/JSC/V8).
• Avantaj: SharedArrayBuffer ile zero-copy data transfer.
• Dezavantaj: C++ ABI bilgisi gerekir; debugging karmaşıktır (lldb + Chrome DevTools karışımı).
• Dezavantaj: JSI binding’i yanlış yazılan kütüphanelerde bellek sızıntısı (HostObject release edilmezse) yaygındır.
• Ne zaman seç: Performans-kritik native modül yazıyorsanız (cryptography, ML, DB, real-time A/V) JSI doğal tercih.
• Ne zaman kaçın: Sıradan REST API wrapper veya basit native UI bileşeni için TurboModule yeterli; saf JSI overkill.

TurboModules: Lazy yükleme ve type-safe native bridge

TurboModule, JSI üzerine kurulmuş ve native modüller için lazy loading + type-safe API sağlayan bir abstraction’dır. Eski NativeModule sisteminde Camera, Bluetooth, Geolocation gibi tüm modüller app başlangıcında belleğe yüklenirdi — kullanılmasalar bile. TurboModule mimarisinde her modül “registered” durumdadır ama instance ilk JS erişiminde (örneğin import { Camera } from 'react-native-camera' ve Camera.requestPermission() çağrısında) yaratılır. Bu sayede React Native 0.76’da typical app cold start ~30-40% iyileşir.

İkinci kazanç Codegen: TypeScript veya Flow spec dosyasından (NativeFoo.ts) C++/Objective-C/Java interface’leri otomatik üretilir. Eski sistemde “TypeScript’te string bekledim, JS runtime’da number geldi” hatasını runtime’a kadar göremezdiniz; Codegen ile bu compile-time hatasına dönüşür. Spec dosyası şuna benzer:

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

export interface Spec extends TurboModule {
  isAvailable(): Promise;
  authenticate(reason: string): Promise<{ success: boolean; error?: string }>;
  getSupportedTypes(): string[];
}

export default TurboModuleRegistry.getEnforcing('Biometric');

Yukarıdaki dosyadan Codegen, iOS için NativeBiometricSpec.h, Android için NativeBiometricSpec.java üretir; bu interface’leri implement etmediğinizde build hata verir. Mobil tarafta tip güvenliği konusunda daha geniş bir karşılaştırma için React Native vs Flutter yazımı inceleyebilirsiniz; Dart’ın native tarafla iletişimde sağladığı isolate model farklarına da değindim.

Adım	Eski NativeModule	TurboModule + Codegen
API tanımı	Manuel JS + native, senkron değil	TypeScript spec → Codegen
Tip kontrolü	Runtime, çoğu zaman silent fail	Compile-time, build kırılır
Yükleme zamanı	App start’ta eager	İlk JS erişiminde lazy
Cold start etkisi (10 modül)	~120-180 ms	~15-30 ms
Memory footprint (10 modül idle)	~22 MB	~4 MB
Senkron method desteği	Hayır	Evet (JSI üzerinden)
Maintenance maliyeti	Yüksek (3 dosya senkron tutma)	Düşük (tek spec)

Fabric: Concurrent renderer ve C++ shadow tree

Fabric, yeni mimarinin UI tarafıdır; eski Paper renderer’ın yerine geçer. Paper’da bir setState sonrası reconciliation JavaScript thread’de çalışır, layout/style hesaplaması yapılır, native UI thread’e diff gönderilirdi — bu zincirin herhangi bir adımında throttle yaşandığında frame drop olurdu. Fabric ise shadow tree‘yi C++ tarafında tutar; React 18 ile gelen concurrent mode (useTransition, useDeferredValue, Suspense for data) Fabric ile gerçek anlamda işlevsel hâle gelir. Önemli noktalar:

• Multi-threaded layout: Yoga layout engine C++’ta paralel çalışır; bir liste scroll edilirken yeni component’lerin layout’u arka plan thread’de hesaplanır.
• Synchronous priority updates: User input (tap, scroll gesture) yüksek priority queue’da işlenir; arka planda devam eden render’lar interrupt edilebilir.
• View flattening: Anlamsız wrapper view’lar (sadece flex container olan div’ler) renderer’da düşürülür; native view tree %30-50 sığlaşır.
• Memoization yerine native fast path: memo/useMemo gerekliliği azalır; Fabric kendi diff’inde C++ tarafında props karşılaştırması yapar.
• Suspense + concurrent: Veri yüklenirken eski UI ekranda kalır; “white flash” sorunu büyük ölçüde çözülür.

Production tarafında bunun anlamı: 1000+ item içeren bir FlatList artık getItemLayout + windowSize tuning ihtiyacı olmadan 58-60 fps performansla scroll edilir. Önceki mimaride aynı sonuca ulaşmak için FlashList (Shopify’ın recycler view’ı) gibi 3. parti çözümlere gidilirdi; FlashList hâlâ değerlidir ama Fabric ile aradaki fark dramatik şekilde daralmıştır.

Benchmark: Bridge vs. New Architecture gerçek ölçümler

Aşağıdaki tablo, kendi laboratuvarımda (iPhone 13, Pixel 7, mid-tier Samsung A54) yaptığım ölçümlerin yanı sıra Microsoft React Native Windows ekibinin 2024 raporu ve Software Mansion’ın açık benchmark setinden derlenmiştir. Tüm değerler 100 koşunun medyan’ıdır, release build, Hermes engine.

Senaryo	Bridge (0.71)	New Arch (0.76)	Δ İyileşme
Cold start, basit app (iPhone 13)	478 ms	318 ms	%33
Cold start, 20 ekran (Pixel 7)	1,240 ms	820 ms	%34
Native modül çağrısı (avg, async)	11.8 ms	1.4 ms	%88
Senkron measure() çağrısı	Desteklenmiyor	0.6 ms	—
FlatList 1K item scroll (fps)	48-52 fps	58-60 fps	~%20
JS→Native ArrayBuffer 1MB transfer	14.2 ms (copy)	0.1 ms (zero-copy)	%99
RAM idle (10 modül kayıtlı)	62 MB	39 MB	%37
APK size (Hermes + Fabric)	9.8 MB	10.4 MB	-%6 (artış)

Tek negatif kalem: APK/IPA büyür çünkü Fabric C++ kodu ve Codegen artifacts binary’ye eklenir. Bu artış genelde 600 KB – 1.2 MB arasında kalır; modern cihazlarda ihmal edilebilir. App start, modül çağrısı, memory tarafındaki kazançlar bu maliyeti fazlasıyla karşılar. Mobil performans tuning konusunda detaylı bir checklist için Mobil Performans Optimizasyonu yazıma bakabilirsiniz.

Migration: Mevcut React Native app’ini new architecture’a taşımak

Yeni proje (RN 0.76+) açıyorsanız default zaten new arch; özel bir adım gerekmez. Ancak 0.68-0.73 arası eski projeleri migrate etmek 4-8 hafta sürebilen ciddi bir iştir. Resmi adım dokümanı için React Native New Architecture Guide‘ı referans alın. Süreç şu fazlardan oluşur:

1. Dependency audit: Tüm 3. parti kütüphaneleri kontrol edin — react-native-async-storage, react-native-screens, react-native-reanimated 3+, react-native-gesture-handler 2.16+ gibi popüler kütüphaneler new arch’ı destekler; ama küçük niş kütüphaneler hâlâ Bridge’e bağlı olabilir. reactnative.directory filtresi kullanın.
2. RN sürüm yükseltme: Upgrade Helper (rn-diff-purge) ile adım adım 0.68 → 0.71 → 0.74 → 0.76 git. Tek seferde 4 minör versiyon atlamak iOS pod ve Android Gradle çatışmalarını çoğaltır.
3. New arch flag’i aç: iOS Podfile’da :fabric_enabled => true, :turbomodules_enabled => true, Android gradle.properties içinde newArchEnabled=true.
4. Custom native modüllerini TurboModule’e port et: Mevcut RCTBridgeModule / ReactContextBaseJavaModule sınıflarını Codegen spec ile yeniden tanımla.
5. Brownfield gotcha: Native app içine embed edilmiş RN (React Native ↔ native iOS/Android hybrid) projelerde RootView yerine RCTAppDelegate veya ReactActivity’nin yeni varyantları gerekir.
6. QA matrisi: iOS 13+ ve Android 7+ minimum; daha eski cihaz desteği new arch ile zorlaşır (Hermes ve Fabric eski OS’larda crash edebilir).

Cross-platform alternatiflerini de değerlendiriyorsanız Flutter Cross-Platform 2026 yazımdaki Skia engine + impeller karşılaştırması yardımcı olur; ek olarak Swift/SwiftUI alternatifini değerlendirmek isterseniz aynı kategoride iOS native karşılaştırma yazım bulunmaktadır.

Ekosistem uyumu: Hangi kütüphaneler hazır?

Migration kararının teknik tarafından çok ekosistem hazırlığı belirler. 2026 Q1 itibarıyla en yaygın 25 React Native kütüphanesinin durumu:

Kütüphane	Kategori	New Arch desteği	Not
react-navigation 6+	Navigation	Tam destek	react-native-screens 3.31+ ile
react-native-reanimated 3.x	Animasyon	Tam destek	Worklets JSI üzerinde çalışır
react-native-gesture-handler 2.16+	Gesture	Tam destek	Senkron event delivery
FlashList	Liste	Tam destek (1.7+)	Fabric ile recycler optimizasyonu
react-native-mmkv	Storage	Tam destek	Tamamen JSI tabanlı, async-storage’dan 30x hızlı
op-sqlite	Database	Tam destek	WatermelonDB JSI mode’una alternatif
react-native-vision-camera 4	Kamera	Tam destek	Frame processor’lar JSI worklet
react-native-async-storage	Storage	Tam destek	MMKV önerilir, async-storage legacy
react-native-svg	Vector	Tam destek (15+)	Fabric component’leri
react-native-svg-charts	Chart	Bridge fallback	Bakım yavaş; victory-native önerilir
victory-native xl	Chart	Tam destek	Skia tabanlı, GPU accelerated
react-native-firebase 21+	Backend	Tam destek	Tüm modüller TurboModule

Kritik nokta: Kullandığınız bir kütüphane “Bridge fallback” durumundaysa (örneğin eski react-native-image-crop-picker, bazı Bluetooth low-energy paketleri), new arch ile interop layer sayesinde yine çalışır ama o spesifik çağrılar Bridge’e düşer ve performans kazancı kaybedilir. Migration planında bu kütüphaneleri ya değiştirin (fork) ya da maintainer’a PR açın.

Pratik mimari karar çerçevesi

Hangi durumda new arch’a geçmeli, hangi durumda erteleyebilirsiniz? Yıllardır mobil ekiplere danışmanlık veren Ömer Önal olarak müşteri projelerinde uyguladığım karar matrisi şudur:

Senaryo	Tavsiye	Tahmini efor
Yeni proje (greenfield)	RN 0.76+ default new arch, hemen başla	0 (sıfır ek iş)
Production app RN 0.74, az custom native modül	Migrate et, ekosistem hazır	2-3 hafta
Production app RN 0.70, 10+ custom modül	Önce RN 0.74’e yükselt, sonra new arch	5-8 hafta
Brownfield (RN gömülü native app)	Pilot ekran ile dene, sonra yay	6-10 hafta
Maintenance mode app (yeni özellik yok)	Ertele, 0.72 LTS’de kal	—
App içinde uyumsuz kütüphane var	Önce kütüphane fork/replace, sonra migrate	+2-4 hafta

Karar verirken sadece teknik faktörler değil ekip kapasitesi ve release roadmap da kritiktir. Migration sırasında feature donduğunda business tarafıyla çatışma çıkar; bu yüzden ben genelde “iki haftalık spike + ölçeklenmiş plan” ile başlatmayı öneriyorum.

CI/CD ve dağıtım tarafında ne değişir?

New architecture build pipeline’ını birkaç yerde etkiler. Build süresi artar çünkü Codegen aşaması (spec dosyalarından native interface üretimi) iOS’ta CMake/Xcode tarafına, Android’de Gradle task’ına eklenir. Tipik 10K LOC orta ölçekli app’te:

• iOS build: Pod install +90 sn, Xcode build +60-120 sn (toplam clean build ~4 dk → ~6 dk).
• Android build: Gradle Codegen +30-60 sn, NDK compile +90 sn (toplam clean build ~5 dk → ~7-8 dk).
• Incremental build: Codegen cache’lendiğinde fark minimal (~5-15 sn).
• EAS Build / Codemagic: Cache layer’ı new arch için güncellenmeli; eski cache kullanan pipeline’lar build hataları üretir.

Otomasyon tarafını derinlemesine ele aldığım Mobil CI/CD yazımda Fastlane match + Bitrise cache + EAS Build kombinasyonlarının new arch ile uyumlu yapılandırmalarını paylaştım. Push notification katmanı tarafında ise Mobil Push Notification rehberim Firebase Messaging 21+ ile new arch entegrasyonunu adım adım anlatır.

Yaygın hatalar ve debug stratejisi

Migration sonrası en sık karşılaşılan üç problem kategorisi ve çözüm yaklaşımları:

• “Tried to register two views with the same name” hatası: Native component’in hem eski hem yeni mimaride kayıt edildiği durumlarda görülür. Çözüm: Custom ViewManager’da + (BOOL)needsCustomLayoutForChildren override’ını kaldırın, sadece Codegen spec’i bırakın.
• Reanimated worklet “Property not configurable” crash: Worklets JSI üzerinden çalışırken HostObject’lerin frozen property’lerine yazmaya çalışırsanız patlar. useSharedValue + useDerivedValue kullanın, doğrudan native object mutate etmeyin.
• iOS build “TurboModule registered but not found”: Codegen output path’i (build/generated/ios) Xcode project’e include edilmediğinde görülür. Podfile post_install hook’una install_modules_dependencies(installer) ekleyin.
• Android NDK ABI mismatch: Hermes ve Fabric için 16 KB page size desteği gerekir (Android 15 için). android.bundle.enableMinifyInReleaseBuilds=true + ProGuard rules güncelleyin.
• Memory leak shadow tree’de: Component unmount sonrası shadow node release edilmezse görülür; Reanimated 3.10+ ve react-native-screens 3.34+ ile bu fix’lendi.
• Hot reload bozulması: Fast Refresh new arch’ta bazı state senaryolarında stale prop gösterebilir; geçici çözüm --reset-cache ile Metro restart.

Debug için Flipper deprecate edildi (RN 0.74+); yerine React Native DevTools (Chrome DevTools tabanlı) ve Reactotron kullanın. Ayrıca Hermes Inspector ile JS heap profili alabilir, JSI HostObject sayısını izleyebilirsiniz.

Sıkça Sorulan Sorular

Sonuç

React Native New Architecture, framework’ün 10 yıllık tarihindeki en önemli mimari dönüşümdür: Bridge’in JSON serialization darboğazını JSI ile, eager modül yüklemesini TurboModule lazy initialization ile, monolitik renderer’ı Fabric’in concurrent C++ shadow tree’siyle değiştirir. Benchmark verisi tutarlı: cold start %30-35, native call latency %85+, memory footprint %35+ iyileşme. Bu kazançlar 2018’den beri Meta tarafından kademeli olarak production’da test edildi (Facebook, Instagram, Marketplace app’lerinde) ve 0.76 default geçişiyle artık herkes için stable.

Karar çerçevesi net: Greenfield → şimdi başla. Production RN 0.74+ → Q2 2026 içinde migrate et. RN 0.70-0.73 → önce RN sürüm yükseltmesi, sonra new arch. Brownfield → pilot ekran + 8-12 haftalık plan. En riskli kalem ekosistem uyumudur; kullandığınız her 3. parti kütüphaneyi reactnative.directory üzerinden filtreleyip alternatif planını hazırlayın. Migration sırasında baseline performans metriklerini kaydetmeyi ve A/B release ile staged rollout yapmayı atlamayın.

React Native new architecture migration’ı, Fabric custom component yazımı veya brownfield hybrid app stratejisi için ekibinize danışmanlık desteği almak isterseniz iletişim sayfası üzerinden ulaşabilirsiniz; iki haftalık spike planıyla başlayıp ölçeklenmiş bir roadmap çıkarmayı tercih ediyorum.