React Native Yeni Mimari Geçiş Rehberi 2026: Fabric, TurboModules ve JSI

React Native 0.82 ile birlikte Yeni Mimari (New Architecture) artık bir seçenek değil, tek seçenek. Eski köprü (Bridge) tabanlı sistem kalıcı olarak devre dışı bırakıldı ve newArchEnabled=false bayrakları artık işe yaramıyor. 2026, React Native ekosisteminin yıllardır beklenen Fabric, TurboModules, JSI ve Codegen temellerine tamamen yerleştiği dönüm noktası oldu diyebiliriz.

Bu rehberde, mevcut bir React Native uygulamasını Yeni Mimari'ye taşırken karşınıza çıkacak her adımı, üretim ortamından gelen gerçek performans verileriyle ele alacağız. 0.73'ten 0.82'ye güvenli geçiş yolu, bağımlılık denetimi, özel native modüllerin TurboModule'a dönüştürülmesi ve (kaçınılmaz olarak) karşılaşacağınız hataların çözümleri dahil.

Açıkçası, geçen yıl bir müşteri projesinde ben de aynı yolu yürüdüm — ve size söyleyebilirim ki doğru sırayla yapıldığında süreç korkutucu değil. Sorun, atlamalı yükseltmelerde ve "nasıl olsa çalışır" deyip es geçilen adımlarda çıkıyor.

Yeni Mimari Neden Artık Zorunlu?

React Native ekibinin Ekim 2025'te duyurduğu 0.82 sürümüyle birlikte köprü sistemi kaldırıldı. Nisan 2026'da yayımlanan 0.85 ise asenkron köprüyü tamamen eleyerek alt 2 ms native çağrı gecikmesi sağlıyor. Uygulamanız hâlâ 0.76 öncesi bir sürümdeyse, topluluk paketleri eski mimari desteğini düşürdükçe uyumluluk sorunları katlanarak büyüyecek. Bu bir tahmin değil — reactnative.directory'ye haftalık baktığımda "old arch" sütununda kalan paket sayısı sürekli eksiliyor.

Shopify, Expensify ve Microsoft Teams gibi büyük ölçekli üretim uygulamalarının yayımladığı ölçümlere göre Yeni Mimari şu kazanımları getiriyor:

• %43 daha hızlı soğuk başlatma (cold start)
• %39 daha hızlı render, 55-60 fps animasyonlar (eski mimaride 30-45 fps bandındaydı)
• %26 daha düşük bellek kullanımı
• 40x daha hızlı JS-native iletişim: 200 ms yerine ~2 ms
• Fabric'in eşzamanlı render'ı sayesinde kaydırma ve API çağrıları sırasında jank neredeyse yok

Bu rakamlar size biraz abartılı gelebilir, biliyorum. Ama benim kendi projemde soğuk başlatma 4.1 saniyeden 2.6 saniyeye indi — yani "gerçek dünya" ölçümleri de bu çizgiyi doğruluyor.

Dört Temel Sütun: JSI, TurboModules, Fabric, Codegen

JSI (JavaScript Interface)

JSI, JavaScript ile native kod arasındaki JSON serileştirme tabanlı asenkron köprüyü ortadan kaldırır. Artık JavaScript, C++ üzerinden native fonksiyonları senkron olarak çağırabiliyor. Tek bir not: Bu, tamamen Hermes motoruna bağlı. JavaScriptCore artık desteklenmiyor — yani JSC ile direniyorsanız şans yok.

TurboModules

Eski Native Modules sisteminde uygulama açılırken tüm modüller belleğe yüklenirdi (gereksiz olanlar dahil). TurboModules tembel yükleme (lazy loading) yapıyor: 50 native modüle sahip bir uygulama, ilk etkileşimde yalnızca 5 tanesini yükleyebilir. Kalan 45 modül ancak gerektiğinde hafızaya alınır. Soğuk başlatma süresinin neden bu kadar düştüğünün asıl sebebi bence bu.

Fabric

Yeni UI render katmanı. İki platform arasında paylaşılan bir C++ çekirdeği kullanır ve React 18'in eşzamanlı render moduyla uyumludur. Shadow tree artık doğrudan C++ tarafında tutuluyor; bu da Transition ve öncelik tabanlı güncellemelerin nihayet düzgün çalışmasını sağlıyor.

Codegen

TypeScript veya Flow arayüzlerinden native binding kodu otomatik üretir. Yani artık manuel olarak RCT_EXPORT_METHOD yazmak yok; bir spec tanımlıyorsunuz, iOS/Android tarafı kendiliğinden oluşuyor. Bu tek başına geçişin en rahatlatıcı parçası diyebilirim.

Geçiş Öncesi Ön Hazırlık Listesi

Migrasyona dalmadan önce şu kontrolleri yapın. Ciddiyim — bu adımlardan birini atlarsanız ilerleyen aşamada üç saat hata ayıklamakla uğraşırsınız:

1. Mevcut React Native sürümünü kontrol edin. 0.73'ten düşükse önce 0.73'e yükseltin, ardından 0.76 veya 0.81'e geçin. Atlamalı yükseltme (örn. 0.70 → 0.82) başınıza çorap örer.
2. Hermes'i etkinleştirin. ios/Podfile ve android/gradle.properties dosyalarında Hermes aktif olmalı.
3. Bağımlılık denetimi yapın. reactnative.directory sitesinde her kütüphanenin "New Architecture" sütununu tek tek kontrol edin.
4. Özel native modülleri listeleyin. Bunların hepsi TurboModule veya Fabric Component'e dönüştürülecek.
5. CI/CD pipeline'ınızı güncelleyin. Xcode 16.2+ ve NDK 26+ şart.

Adım Adım Migrasyon: Expo Yönetilen Proje

Expo kullanıyorsanız, dürüst olmak gerekirse geçiş neredeyse tek satırlık bir ayar. app.json dosyanızı açın:

{
  "expo": {
    "name": "MyApp",
    "newArchEnabled": true,
    "ios": {
      "newArchEnabled": true
    },
    "android": {
      "newArchEnabled": true
    }
  }
}

Ardından önbelleği temizleyip yeniden derleyin:

npx expo prebuild --clean
npx expo run:ios
npx expo run:android

Expo SDK 52 ve sonrası, tüm managed workflow projelerinde C++ derlemesi, Hermes yapılandırması ve modül bağlama işlemlerini sizin yerinize hallediyor. İşte bu yüzden managed workflow'un büyüsüne inanıyorum.

Adım Adım Migrasyon: Bare React Native Projesi

1. iOS tarafını aktifleştirme

ios/Podfile dosyanızda şu değişiklikleri yapın:

ENV['RCT_NEW_ARCH_ENABLED'] = '1'

target 'MyApp' do
  config = use_native_modules!

  use_react_native!(
    :path => config[:reactNativePath],
    :hermes_enabled => true,
    :fabric_enabled => true,
    :app_path => "#{Pod::Config.instance.installation_root}/.."
  )
end

Sonra pod'ları yeniden yükleyin:

cd ios
bundle exec pod install
cd ..

2. Android tarafını aktifleştirme

android/gradle.properties dosyasına ekleyin:

newArchEnabled=true
hermesEnabled=true

Ardından temiz bir derleme yapın (ve bu adımı gerçekten temiz yapın, eski build klasörü kalırsa işler karışır):

cd android
./gradlew clean
cd ..
npx react-native run-android

Özel Native Modülü TurboModule'a Dönüştürme

Eski bir NativeModule'unuz varsa, Yeni Mimari'ye uyumlu hale getirmek için önce bir Codegen spec'i oluşturmanız gerekiyor. Bu kısım ilk bakışta dağınık görünüyor ama aslında tek seferlik bir yatırım.

1. TypeScript Spec Tanımı

src/specs/NativeDeviceInfo.ts adında bir dosya oluşturun:

import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceId(): string;
  getBatteryLevel(): Promise<number>;
  isCharging(): boolean;
  addListener(eventName: string): void;
  removeListeners(count: number): void;
}

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

2. package.json Codegen Yapılandırması

{
  "codegenConfig": {
    "name": "RNDeviceInfoSpec",
    "type": "modules",
    "jsSrcsDir": "src/specs",
    "android": {
      "javaPackageName": "com.example.deviceinfo"
    }
  }
}

3. iOS Implementasyonu (Objective-C++)

// ios/DeviceInfo.mm
#import "DeviceInfo.h"
#import <RNDeviceInfoSpec/RNDeviceInfoSpec.h>

@implementation DeviceInfo

RCT_EXPORT_MODULE()

- (NSString *)getDeviceId {
  return [[UIDevice currentDevice] identifierForVendor].UUIDString;
}

- (void)getBatteryLevel:(RCTPromiseResolveBlock)resolve
                reject:(RCTPromiseRejectBlock)reject {
  [UIDevice currentDevice].batteryMonitoringEnabled = YES;
  resolve(@([UIDevice currentDevice].batteryLevel));
}

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:
    (const facebook::react::ObjCTurboModule::InitParams &)params {
  return std::make_shared<facebook::react::NativeDeviceInfoSpecJSI>(params);
}

@end

4. Android Implementasyonu (Kotlin)

// android/src/main/java/com/example/deviceinfo/DeviceInfoModule.kt
package com.example.deviceinfo

import android.os.BatteryManager
import com.facebook.react.bridge.Promise
import com.facebook.react.bridge.ReactApplicationContext

class DeviceInfoModule(reactContext: ReactApplicationContext) :
    NativeDeviceInfoSpec(reactContext) {

    override fun getName(): String = NAME

    override fun getDeviceId(): String {
        return android.provider.Settings.Secure.getString(
            reactApplicationContext.contentResolver,
            android.provider.Settings.Secure.ANDROID_ID
        )
    }

    override fun getBatteryLevel(promise: Promise) {
        val bm = reactApplicationContext
            .getSystemService(ReactApplicationContext.BATTERY_SERVICE) as BatteryManager
        val level = bm.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY)
        promise.resolve(level / 100.0)
    }

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

5. JavaScript Tarafında Kullanım

import DeviceInfo from './specs/NativeDeviceInfo';

const id = DeviceInfo.getDeviceId();
const level = await DeviceInfo.getBatteryLevel();
console.log(`Device ${id} at ${level * 100}%`);

Dikkat ederseniz JS tarafı neredeyse hiç değişmedi. Güzel olan da bu: spec'i düzgün yazdıktan sonra uygulamanın geri kalanı aynı API'yle konuşmaya devam ediyor.

Fabric Component Oluşturma

Özel bir native görsel bileşeniniz varsa, Fabric Component olarak yeniden tanımlamanız gerekiyor. Spec dosyası şöyle:

// src/specs/WebViewNativeComponent.ts
import codegenNativeComponent from 'react-native/Libraries/Utilities/codegenNativeComponent';
import type { ViewProps } from 'react-native';
import type { DirectEventHandler, Double } from 'react-native/Libraries/Types/CodegenTypes';

interface LoadEvent {
  url: string;
  progress: Double;
}

export interface NativeProps extends ViewProps {
  url: string;
  allowsZoom?: boolean;
  onLoad?: DirectEventHandler<LoadEvent>;
}

export default codegenNativeComponent<NativeProps>('CustomWebView');

Sık Karşılaşılan Hatalar ve Çözümleri

Beyaz Ekran, Hiçbir Hata Yok

Fabric, Shadow Tree'de oluşan bazı hataları sessizce yutuyor (evet, sinir bozucu). Shopify ekibinin yayımladığı migrasyon notlarına göre bu durumun en yaygın sebebi yüzde değeri (%) desteklenmeyen stil özellikleri. Örneğin borderRadius: '50%' Fabric öncesinde iOS'ta sessizce yoksayılırdı; yeni mimaride render'ı tamamen kırıyor. Tüm stilleri sayısal değerlere çevirin ya da borderRadius için Dimensions API'siyle hesaplayın. İlk geçişimde iki saatimi yiyen hata tam olarak buydu.

State Batching Farklılıkları

Yeni mimari, state güncellemelerini React 18'in otomatik toplu işleme (automatic batching) davranışına uygun şekilde gruplar. Art arda setState çağıran eski testler başarısız olabilir. flushSync ile güncellemeleri zorlayabilirsiniz:

import { flushSync } from 'react-dom';

flushSync(() => {
  setCount(c => c + 1);
});

Reanimated 3.5 Altı Sürümlerde Çökme

Reanimated en az 3.5.1 olmalı. Düşük sürümlerde animasyon başladığı anda uygulama segmentation fault veriyor — ve stack trace'in pek bir yardımı dokunmuyor. Gesture Handler için de minimum 2.16.2 gerekiyor.

useLayoutEffect Zamanlaması

Fabric, useLayoutEffect'i eski mimariden farklı bir frame'de tetikliyor. Layout hesabına bağımlı animasyonlarınız varsa onLayout callback'ine geçmek çok daha güvenli.

Performans Ölçüm Araçları

Migrasyon sonrası iyileşmeyi ölçmek için şu araçları öneriyorum:

• React Native DevTools (Chrome DevTools tabanlı) — Performance sekmesinde Fabric render zamanlarını görürsünüz.
• Flipper Performance Monitor — Hâlâ bakım modunda ama TurboModule çağrı gecikmesini ölçmek için iş görüyor.
• Expensify'ın Reassure kütüphanesi — CI'da render süresi regresyonlarını otomatik yakalar. Bence şu an piyasadaki en iyi araç.
• Hermes Bytecode Profiler — Hermes V1 ile birlikte gelen yeni profiler, JS yürütme süresini fonksiyon seviyesinde gösterir.

Ekosistem Uyumluluk Tablosu (Nisan 2026)

Kütüphane	Minimum Uyumlu Sürüm
React Navigation	7.2.0
React Native Reanimated	3.5.1
React Native Gesture Handler	2.16.2
React Native Screens	3.32.0
Expo SDK	52 (tam Fabric desteği)
Vision Camera	4.0.0
React Native SVG	15.2.0
React Native MMKV	3.0.0
Detox	20.18.0

Migrasyon Zaman Çizelgesi ve Tahminler

Üretim uygulamalarından toplanan verilere göre geçiş süresi uygulamanızın karmaşıklığına göre ciddi değişiyor:

• Küçük uygulamalar (10 ekran altı, özel native kod yok): 1-2 hafta
• Orta ölçekli uygulamalar (20-50 ekran, az sayıda özel modül): 3-5 hafta
• Büyük kurumsal uygulamalar (birden fazla özel Fabric component, 10+ TurboModule): 6-10 hafta

Microsoft Office'in React Native geçişi 14 hafta sürdü. Shopify ise kademeli feature flag yaklaşımıyla 8 haftada tamamladı. Yani "büyük uygulama = imkansız" değil, sadece planlı ilerlemek gerekiyor.

Sıkça Sorulan Sorular

Yeni Mimari'ye geçmezsem ne olur?

React Native 0.82 ve üstünde eski mimari tamamen kaldırıldı. 0.81 son destekli sürüm ve Mart 2026'da EOL oldu. Hâlâ 0.81'de kalabilirsiniz, evet — ama güvenlik yamaları almayacaksınız ve ekosistem kütüphaneleri bu sürümü hızla terk edecek. 6-12 ay içinde yükseltme zaten kaçınılmaz olacak.

Hermes zorunlu mu, JavaScriptCore kullanmaya devam edebilir miyim?

Hayır, Yeni Mimari JSI üzerine kuruludur ve JSI yalnızca Hermes ile çalışır. JavaScriptCore desteği 0.82'de tamamen kaldırıldı. Hermes V1 ise 0.84'ten itibaren varsayılan motor.

Expo ile bare workflow arasında geçiş süresi farkı var mı?

Evet, ciddi fark var. Expo managed workflow tek newArchEnabled: true satırıyla migrasyonun %90'ını halleder. Bare projelerde Podfile, gradle.properties ve MainApplication.kt değişiklikleri manuel yapılır. Özel native kodunuz yoksa Expo'ya geçmek migrasyon süresini günlere indirebilir — ki bu çoğu ekip için ciddi bir tasarruf.

Mevcut Native Modüllerim otomatik TurboModule olur mu?

Kısa cevap: evet, eski NativeModule'lar "Interop Layer" sayesinde Yeni Mimari'de de çalışır. Ama performans kazanımını tam göremezsiniz. TurboModule'a dönüştürmek için Codegen spec dosyası yazmanız gerekiyor. Geçiş döneminde uyumluluk katmanını kullanmak kabul edilebilir bir ara çözüm, ama kalıcı plan olmamalı.

react-native-firebase gibi popüler kütüphaneler hazır mı?

Evet. Nisan 2026 itibarıyla react-native-firebase 22.0+, react-native-mmkv 3.0+, react-native-svg 15.2+ ve vision-camera 4.0+ tamamen Fabric/TurboModule uyumlu. Sadece bakımı bırakılmış veya 2023'ten bu yana güncelleme almayan kütüphaneler sorun çıkarıyor; onları denk alternatiflerle değiştirmeniz şart.

Performans iyileşmesi her uygulamada aynı mı?

Hayır. Çok sayıda native modül çağrısı yapan veya karmaşık liste render eden uygulamalar en büyük kazanımı görür (soğuk başlatmada %40+). Basit form uygulamalarında fark %10-15 civarında. En belirgin iyileşme, benim gözlemime göre, animasyon akıcılığı ve bellek kullanımında.

Sonuç

React Native Yeni Mimari geçişi artık bir "gelecek planı" değil, 2026'nın zorunluluğu. Geçişi ertelemek uyumluluk borcunu katlar; erken taşıyanlar ise %40'a varan performans kazancı ve modern React 18 özelliklerini kullanma fırsatı yakalar. Expo managed workflow kullananlar için süreç neredeyse bedava; bare projeler için sistematik bir denetim ve 2-8 haftalık bir yatırım söz konusu. Benim tavsiyem basit: migrasyona bugün başlayın, 0.85'e hazır olun — sonra teşekkür edersiniz.