React Native 0.87 Yükseltme: Strict TypeScript API Zorunlu

React Native 0.87, 11 Ağustos 2026'da yayınlandı ve ekosistemin en büyük tip-sistemi değişikliklerinden birini varsayılan hale getirdi: Strict TypeScript API. Bu yazıda React Native 0.87 yükseltme rehberini adım adım işliyoruz — neyin kırıldığını, hangi toolchain sürümlerinin zorunlu olduğunu ve mevcut kod tabanını nasıl güvenle taşıyacağını göreceksin.

💡 Pro Tip: Yükseltmeye başlamadan önce tsconfig.json dosyandaki compilerOptions.customConditions dizisine "react-native-legacy-deep-imports" koşulunu ekle; bu bir npm paketi değil, resmi opt-out anahtarıdır — strict API'nin kırdığı deep import'ları geçici olarak açık tutar ve migration'ı bölüm bölüm yapmana izin verir.

İçindekiler

• 0.87 neyi kırıyor
• Kaldırılan API'ler ve iOS header değişikliği
• Strict TypeScript API: deep import'lardan kök export'lara
• Kaynaktan üretilen tipler ne kazandırıyor, ne kırıyor
• Node 22 + AGP 9 + Kotlin 2.0 toolchain yükseltmesi
• Metro 0.87 ve cache sorunları
• iOS'ta deneysel SwiftPM: denemeli mi
• Upgrade Helper ile adım adım
• Yükseltme sonrası regresyon testi
• 0.85/0.86'dan gelenler için kısa yol
• SSS
• React Native 0.87'de hangi breaking change'ler var?
• Legacy deep imports opt-out'unu açmak zorunda mıyım?
• RN 0.87 için minimum Node ve Gradle sürümü nedir?
• React Native'de Swift Package Manager desteği kullanılabilir mi?
• 0.88'e mi yoksa 0.87'ye mi geçmeliyim?
• Expo kullanıyorsam RN'i doğrudan 0.87'ye çekebilir miyim?
• Sonuç
• Kaynaklar

0.87 neyi kırıyor

React Native ekibi 0.87'yi "ecosystem-wide" bir kırıcı değişiklik olarak tanımlıyor. Resmi duyuru şu ifadeyi kullanıyor: "This is an ecosystem-wide change and brings intentional breaking changes across the API surface." Bu tek cümle, sürümün neden bu kadar konuşulduğunu özetliyor: değişiklik yalnızca senin kod tabanını değil, bağımlı olduğun üçüncü parti kütüphaneleri de etkiliyor.

Bu ifadenin arkasında somut bir sonuç var: eğer projen doğrudan ya da bir bağımlılık üzerinden react-native/Libraries/* altındaki dosyalara erişiyorsa, npm install sonrası ilk tsc çalıştırmanda kırmızı satırlarla karşılaşman şaşırtıcı olmayacak. Bu yazı, o kırmızı satırları nereden bulacağını, hangi sırayla düzelteceğini ve toolchain'i nasıl senkronize edeceğini gösteriyor.

Aşağıdaki tablo 0.87'de değişen ana alanları özetliyor:

Bu tablodaki ilk satır seni en çok uğraştıracak olan: strict TypeScript API. Aşağıdaki bölümde bunu detaylı işliyoruz.

Kaldırılan API'ler ve iOS header değişikliği

Duyurunun "API removals" bölümü, tip sisteminden bağımsız olarak build'ini kırabilecek somut kaldırmaları listeliyor. Yükseltmeden önce bu satırları kod tabanında aratmanda fayda var:

Bunlara ek olarak useColorScheme() artık ColorSchemeName | null döndürüyor ve 'unspecified' değerini üretmiyor — bu dönüşü switch ile ele alan kodun null dalını eklemen gerekiyor.

iOS tarafında ise SwiftPM çalışmasının yan ürünü olan bir kırıcı değişiklik var: React Native header'larını namespace'siz "bare-form angle include" ile içe aktaran dosyalar artık bu biçimle çalışmıyor — duyuru bunu SwiftPM çalışmasının tek tüketici-tarafı değişikliği olarak veriyor ve çözümü headerı namespaceiyle içe aktarmak. Duyuru düzeltmeyi birebir şöyle gösteriyor:

1// Eski (namespace'siz — 0.87 ile artık geçerli değil)
2#import <RCTAppDelegate.h>
3 
4// Yeni
5#import <React/RCTAppDelegate.h>

Android tarafında da compileSdk ve buildTools 37'ye yükseltildi; kütüphaneler için minCompileSdk ise 34.

Strict TypeScript API: deep import'lardan kök export'lara

0.80 sürümünde React Native ekibi Strict TypeScript API'yi opt-in bir preview olarak tanıttı. 0.87 ile bu artık varsayılan davranış. Resmi dokümantasyon (reactnative.dev/docs/strict-typescript-api) değişikliği şöyle özetliyor: React Native'in genel TypeScript yüzeyi artık yalnızca react-native paketinin kök export'larıyla sınırlı; react-native/Libraries/... gibi internal path'lere yapılan deep import'lar artık type error veriyor.

Pratikte bu şu anlama geliyor: eğer kod tabanında şöyle bir satır varsa

1import RCTDeviceEventEmitter from "react-native/Libraries/EventEmitter/RCTDeviceEventEmitter";

0.87'ye geçtiğinde TypeScript derleyicisi bu satırda hata verecek, çünkü RCTDeviceEventEmitter artık kök export listesinde değil. Çözüm, kök paketten export edilen karşılığını bulmak veya resmi opt-out anahtarını geçici olarak açmak.

Burada sık yapılan bir hataya dikkat et: react-native-legacy-deep-imports kurulabilir bir npm paketi değil, tsconfig.json içindeki bir custom condition değeridir. Resmi duyuru birebir şöyle diyor: "To temporarily revert to the previous types, add the react-native-legacy-deep-imports custom condition to your tsconfig.json". Yapman gereken tek şey bu:

1{
2  "extends": "@react-native/typescript-config",
3  "compilerOptions": {
4    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
5  }
6}

Ama bunu kalıcı çözüm olarak görme: duyuru bu opt-out'un "geçici bir köprü" olduğunu, React Native 0.88 boyunca kullanılabilir kalacağını ve bir sonraki sürümde legacy tiplerin kaldırılmasının planlandığını belirtiyor. Ayrıca opt-out yalnızca kendi projendeki TypeScript analizini etkiliyor — uygulamalar ve kütüphaneler birbirinden bağımsız olarak taşınıyor.

Bu tür deep import'lar genellikle projenin eski katmanlarında birikir: bir bildirim modülü, eski bir native köprü sarmalayıcısı ya da yıllar önce "hızlı çözüm" olarak eklenmiş tek bir import satırı. Bunları tek tek taramak, kod tabanındaki gizli native bağımlılıkları da görünür kılar.

Kaynaktan üretilen tipler ne kazandırıyor, ne kırıyor

Değişikliğin ikinci ayağı daha az görünür ama daha köklü: React Native'in TypeScript tanımları artık elle senkronize edilen .d.ts dosyaları yerine doğrudan kaynak koddan üretiliyor. Bunun getirdiği somut fayda, native tarafta bir prop veya metot değiştiğinde tip tanımının otomatik güncellenmesi — daha önce tip dosyası uzun süre gerçek API'den geride kalabiliyordu.

Kırılan taraf ise şu: kaynaktan üretim, önceden "gizlice" doğru çalışan ama resmi olarak export edilmemiş tipleri de kapsam dışına alıyor. Eğer bir kütüphane ya da senin kodun bu tür bir tipi (örneğin bir native modülün internal prop tipini) import ediyorsa, üretim artık o tipi üretmiyor ve derleme kırılıyor.

React Native 0.84 desteği 0.87 ile birlikte düştü: duyuru "0.87 is now the latest stable version of React Native and 0.84.x moves to unsupported" diyor. Yani 0.84'te kalan ekipler için zorunlu bir geçiş baskısı oluşuyor ve deep import kullanan kod yollarının taranması gerekiyor.

Deep import'ları bulmak için basit bir tarama komutu kullanabilirsin:

1grep -rn "react-native/Libraries" src/ --include="*.ts" --include="*.tsx"

Tırnak kısıtı koymadığına dikkat et: from 'react-native/Libraries kalıbını aratırsan yalnızca tek tırnaklı import'ları bulursun ve çift tırnak kullanan dosyalar taramadan sessizce kaçar. Bu komut her eşleşmeyi dosya ve satır numarasıyla listeler; her satırı tek tek gözden geçirip kök export karşılığını bulman gerekiyor.

Elle tarama tek yol değil: resmi duyuru migration için hazır ESLint fixer'ları ve `/migrate-to-strict-api` skill'ini işaret ediyor; her kırıcı değişikliğin karşılığı ise strict API migration guide'ında tek tek listelenmiş durumda.

Node 22 + AGP 9 + Kotlin 2.0 toolchain yükseltmesi

0.87'nin ikinci büyük değişikliği build toolchain'inde. React Native 0.87 duyurusu minimum sürümleri şöyle belirliyor:

• Node.js: 22.13 veya üzeri şart. Paketin npm registry'deki engines alanı birebir ^22.13.0 || ^24.3.0 || >= 26.0.0; daha eski bir Node 22 patch sürümünde npm varsayılan olarak yalnızca EBADENGINE uyarısı basar, engine-strict açıksa install hata verir.
• Android Gradle Plugin (AGP): 9 veya üzeri.
• Kotlin: 2.0 veya üzeri — 0.87'nin paketlediği Kotlin sürümü 2.2.0.
• Android minCompileSdk: 34 (kütüphaneler compileSdk >= 34 hedeflemeli); compileSdk/buildTools ise 37'ye yükseltildi.

CI ortamında Node sürümünü pin etmek istiyorsan package.json içine React Native'in kendi aralığını birebir kopyalayıp CI'da --engine-strict bayrağıyla doğrulama yapmak, monorepo'larda farklı paketlerin farklı Node sürümleriyle build alınmasını önler:

1{
2  "engines": {
3    "node": "^22.13.0 || ^24.3.0 || >= 26.0.0"
4  }
5}

Android tarafında Gradle wrapper'ı ve Kotlin sürümünü birlikte güncellemen gerekiyor; minimum Kotlin 2.0 olduğu için 1.x'te kalan bir projede yalnızca AGP'yi yükseltmek yeterli değil. android/build.gradle dosyasında iki satırı birlikte güncelle:

1// android/build.gradle
2classpath("com.android.tools.build:gradle:9.0.0")
3classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:2.2.0")

Kotlin 2.0'ın getirdiği K2 compiler'ın kendi ekosistem etkileri var; bu konuyu ayrı ele almak istersen Kotlin 2.1: K2 Compiler + Context Parameters Yenilikler yazımıza bakabilirsin. Benzer şekilde React Native tarafında sıkı tip kontrolüne geçiş, TypeScript ekosisteminde yaşanan TypeScript 7 çıktısı tartışmasıyla aynı yöne işaret ediyor: derleyiciler ve tip sistemleri daha katı, daha hızlı ama geriye dönük uyumluluğu daha az önemsiyor.

AGP 9 tarafında duyurunun net bir eylem maddesi var ve çoğu yükseltme rehberi bunu atlıyor: bu sürümde AGP 9'un kendi içinde gelen Kotlin desteğinden ve yeni DSL API'sinden çıkmanız öneriliyor. Duyuru bu iki bayrağı android/gradle.properties dosyasına eklemeni söylüyor, Upgrade Helper diff'i de aynı satırları getiriyor:

1# AGP 9 ile gelen built-in Kotlin ve yeni DSL davranışından opt-out.
2# AGP 10.x'ten itibaren bu opt-out'lar kaldırılacak.
3android.builtInKotlin=false
4android.newDsl=false

AGP 9.0, Gradle build'lerinde birkaç API ve kırıcı değişiklik getiren majör bir sürüm; bu yüzden Kotlin ve AGP'yi ayrı ayrı değil birlikte planlaman gerekiyor.

Monorepo'da birden fazla paket varsa toolchain yükseltmesi tek başına da risk taşıyabilir. Expo kullanıyorsan burada bilmen gereken net bir gerçek var: duyuru, "For Expo projects, React Native 0.87 will be available as part of the expo@canary releases" diyor — yani 0.87'yi taşıyan stable bir Expo SDK sürümü yok. Expensify'ın kendi App deposundaki bir issue (github.com/Expensify/App/issues/101427) bunu doğruluyor: Expo SDK 58, React Native'i 0.86'dan doğrudan 0.88'e yükseltiyor ve 0.87'yi atlıyor. Bunun pratik anlamı şu: Expo ile yönetilen bir projede 0.87'yi denemek istiyorsan expo@canary kanalına geçmen gerekir; stable SDK üzerinde kalmak istiyorsan 0.88'i bekleyen SDK 58 takvimine bakman daha doğru olur.

Metro 0.87 ve cache sorunları

React Native 0.87 ile birlikte Metro bundler 0.84'ten 0.87'ye güncellendi. Büyük bir sürüm atlaması olduğu için mevcut Metro cache'i genellikle geçersiz kalıyor ve ilk build'de garip modül çözümleme hataları görebilirsin.

Yükseltme sonrası ilk build'de şu sırayı takip etmen sorun yaşama olasılığını azaltır:

1watchman watch-del-all
2rm -rf node_modules
3rm -rf /tmp/metro-*
4npm install
5npx react-native start --reset-cache

Eğer cache temizliğine rağmen çözülmeyen modül bulunamadı hataları alıyorsan, ikinci adım olarak Xcode'da "Clean Build Folder" (Android'de ./gradlew clean) çalıştırmayı dene; Metro'nun kendi cache'i temiz olsa bile native tarafın derleme çıktıları eski sürümden kalma referanslar taşıyabiliyor. CI runner'larında bu adımı atlama — yerel makinende çalışan bir build, CI'da farklı bir cache durumu yüzünden kırılabilir.

Burada dikkat etmen gereken ek bir nokta var: eğer 0.88'in release candidate sürümlerini takip ediyorsan (bu yazının yazıldığı 23 Eylül 2026 itibarıyla 0.88.0-rc.2 yayında), Metro'nun minimum sürümü orada 0.87.1'e çıkıyor. 0.88, release crew'ün kendi 0.88 kayıtlarında non-breaking bir sürüm olarak ele alınıyor; yani 0.87'nin zorunlu kıldığı strict API davranışını değiştirmiyor, üzerine küçük düzeltmeler (bazı TurboModule regresyonlarının revert edilmesi dahil) ekliyor. Şu an production'da 0.87'ye geçiyorsan bu seni bağlamaz, ama CI'da RC takip ediyorsan Metro pin'ini buna göre ayarla.

iOS'ta deneysel SwiftPM: denemeli mi

0.87 ile birlikte React Native, iOS tarafında Swift Package Manager (SwiftPM) desteğini deneysel/preview aşamasında tanıttı. Bu, CocoaPods'a alternatif bir bağımlılık yönetimi yolu.

Şu an için önerimiz net: production projede bu sürümde SwiftPM'e tam geçiş yapma. Bu bir tercih değil, duyurunun kendi uyarısı — bilinen kısıtlar listesinde komutların, bayrakların ve üretilen yerleşimin sonraki sürümlerde değişebileceği söyleniyor ve birebir "Do not use it in production yet" deniyor. CocoaPods varsayılan ve desteklenen yol olmaya devam ediyor; SwiftPM opt-in ve additive.

Denemek istersen komut mevcut .xcodeproj dosyanı değiştirmek yerine içine Swift package referansları enjekte ediyor; imzalama, capability ve build phase ayarların olduğu gibi kalıyor.

1cd ios
2# deintegrate projeden CocoaPods'u kaldırır
3npx react-native spm --deintegrate
4 
5# değişikliği birebir geri almak için
6npx react-native spm deinit

Bağımlılık tarafında en çok merak edilen soru şu: kullandığın kütüphane SwiftPM paketi olarak yayınlanmamışsa ne olacak? Duyuru buna bir çıkış yolu veriyor — bir topluluk kütüphanesinin Package.swift göndermesi gerekiyor, göndermiyorsa npx react-native spm scaffold komutuyla bunu kütüphanenin podspec'inden üretebiliyorsun. Ayrıca temiz bir clone sonrasında ve CI'da build almadan önce bir kez npx react-native spm çalıştırman gerekiyor; bu komut pod install'ın karşılığı.

Upgrade Helper ile adım adım

React Native ekibinin resmi yükseltme aracı, iki sürüm arasındaki tüm native dosya farklarını (Xcode projesi, android/ klasörü, Podfile vb.) bir diff olarak sunar. Mantık şu: React Native kendi native iskeletini her sürümde biraz değiştirdiği için package.json'daki versiyon numarasını değiştirmek yetmez, native proje dosyalarının da diff'lenerek elle senkronize edilmesi gerekir.

React Native ekibinin resmi "Upgrading" dokümantasyonu, sürüm atlarken native proje dosyalarının JS bağımlılıklarından bağımsız olarak diff'lenmesi gerektiğini vurguluyor — çünkü AppDelegate, MainActivity, build.gradle gibi dosyalar her sürümde küçük ama kritik değişiklikler alıyor ve bu değişiklikler npm install ile otomatik gelmiyor.

Pratik akış:

1. Mevcut sürümünü ve hedef sürümünü (0.87) not al.
2. Upgrade Helper diff aracında bu iki sürüm arasındaki native dosya farklarını incele.
3. android/ ve ios/ altındaki değişiklikleri kendi projenle karşılaştırarak elle uygula — özellikle build.gradle, Podfile ve AppDelegate dosyalarına dikkat et.
4. npm install ile JS bağımlılıklarını güncelle, ardından iOS için pod install çalıştır.
5. TypeScript derlemesini çalıştırıp deep import kaynaklı hataları temizle (bkz. yukarıdaki grep taraması).
6. Toolchain sürümlerini (Node 22.13+, AGP 9, Kotlin 2.0+) doğrula.

Bu adımların sırası önemli: önce native diff'i uygulamadan JS bağımlılıklarını güncellersen, build araçları uyumsuz sürüm kombinasyonuyla karşılaşıp anlaşılması zor hatalar verebilir.

Yükseltme sonrası regresyon testi

Strict TypeScript API değişikliği derleme zamanında yakalanıyor, yani tsc --noEmit temiz geçtiğinde deep import kaynaklı sorunların büyük kısmını görmüş olursun. Ama bu yeterli değil — runtime davranışını da doğrulaman gerekiyor, çünkü tip üretim mekanizmasındaki değişiklik bazı native modüllerin export şeklini de etkilemiş olabilir.

Önerilen regresyon kontrol listesi:

• Tip kontrolü: npx tsc --noEmit projede sıfır hata vermeli.
• Deep import taraması: yukarıdaki grep komutunu (tırnak kısıtı olmadan) tekrar çalıştır, sıfır eşleşme hedefle.
• Native modül smoke test: kamera, push notification, deep linking gibi native köprü kullanan özellikleri gerçek cihazda test et.
• Metro cache temizliği: CI runner'larında da cache'i sıfırlayarak en az bir kez temiz build al.
• Android/iOS build: her iki platformda da release build'in hatasız tamamlandığını doğrula.

CI pipeline'ında bu adımları ayrı job'lara bölmek, hangi kontrolün kırıldığını daha hızlı görmeni sağlar: önce typecheck job'ı (tsc --noEmit + deep import grep taraması), ardından paralel build-android ve build-ios, en sonda cihaz/simülatör üzerinde çalışan smoke test. Typecheck'i en başa koymak, native build'lerin dakikalar süren maliyetini üstlenmeden tip hatasını yakalamanı sağlar.

0.85/0.86'dan gelenler için kısa yol

0.85 veya 0.86'dan geliyorsan iyi haber şu: bu iki sürüm zaten Strict TypeScript API'nin opt-in preview'ını destekliyordu, yani eğer projende bu preview'ı daha önce açtıysan deep import migration'ının büyük kısmını çoktan yapmışsındır. Yapman gereken asıl iş toolchain tarafında: Node'u 22.13+'ya, AGP'yi 9'a, Kotlin'i 2.0+'a çekmek ve Metro cache'ini sıfırlamak.

Bu kısa yolun pratik faydası öngörülebilirlik: preview'ı açmış bir ekip hangi deep import'ların sorun çıkardığını zaten biliyor.

Eğer preview'ı hiç açmadıysan, 0.85→0.87 veya 0.86→0.87 atlaması senin için tek seferde hem toolchain hem tip sistemi değişikliğini getirir. Bu durumda migration'ı iki ayrı PR'a bölmen — önce toolchain yükseltmesi, sonra deep import temizliği — code review'ı kolaylaştırır ve hangi değişikliğin hangi regresyona yol açtığını ayırt etmeni sağlar.

Mimari tarafında atlanmaması gereken bir ön koşul var: React Native 0.82 duyurusu o sürümü "the first React Native that runs entirely on the New Architecture" diye tanıtıyor ve newArchEnabled=false ya da RCT_NEW_ARCH_ENABLED=0 denemelerinin yok sayılacağını söylüyor. Aynı duyuru Legacy Architecture'a izin veren son sürümleri de net veriyor: "React Native 0.81 or Expo SDK 54". Yani hâlâ Legacy Architecture'da olan bir proje doğrudan 0.87'ye geçemez; önce 0.81 (veya Expo SDK 54) üzerinde New Architecture'a taşınman ve orada çalıştığını doğrulaman gerekiyor — ancak ondan sonra 0.87 yolu açılır. Yukarıdaki kaldırma tablosunda useTurboModules feature flag'inin kaldırılmış olması da aynı gerçeğin 0.87'deki yansıması. New Architecture'ın kendisini merak ediyorsan React Native New Architecture 2026: Fabric, TurboModules ve Bridgeless Mode yazımızda mimari tarafı ayrıca işledik; bu yazı yalnızca sürüm/toolchain yükseltmesine odaklanıyor.

SSS

React Native 0.87'de hangi breaking change'ler var?

Strict TypeScript API varsayılan hale geldi ve deep import'lar artık type error veriyor, minimum toolchain Node.js 22.13+/AGP 9/Kotlin 2.0+'a yükseldi, Metro bundler 0.84'ten 0.87'ye güncellendi ve tip tanımları artık kaynak koddan otomatik üretiliyor. Bunlara ek olarak duyurunun "API removals" listesi InteractionManager, NativeMethods/NativeMethodsMixin, *Properties tip alias'ları, Modal animated prop'u ve StatusBar backgroundColor/translucent gibi kaldırmaları içeriyor; iOS tarafında ise namespace'siz header import'ları (#import <RCTAppDelegate.h>) artık derlenmiyor.

Legacy deep imports opt-out'unu açmak zorunda mıyım?

Hayır, zorunlu değil — ve önce şunu düzeltelim: bu bir npm paketi değil, tsconfig.json dosyandaki compilerOptions.customConditions dizisine eklediğin bir custom condition. Kurulacak bir şey yok, npm install da çalıştırmıyorsun. Eğer kod tabanın küçükse ve tüm deep import'ları tek seferde temizleyebiliyorsan bu anahtara hiç ihtiyaç duymayabilirsin. Büyük bir monorepo'da onlarca deep import varsa, condition'ı geçici olarak açıp migration'ı takım halinde parça parça ilerletmek daha güvenli bir yol.

RN 0.87 için minimum Node ve Gradle sürümü nedir?

Node.js 22.13 veya üzeri, Android Gradle Plugin (AGP) 9 ve Kotlin 2.0 veya üzeri gerekiyor; 0.87'nin paketlediği Kotlin sürümü 2.2.0. Kütüphaneler için minCompileSdk 34, uygulama tarafında compileSdk/buildTools 37. AGP 9'a geçerken android/gradle.properties dosyasına android.builtInKotlin=false ve android.newDsl=false bayraklarını eklemen öneriliyor.

React Native'de Swift Package Manager desteği kullanılabilir mi?

Evet ama deneysel aşamada. 0.87 ile iOS için SwiftPM desteği opt-in ve additive olarak tanıtıldı; CocoaPods varsayılan ve desteklenen yol olmaya devam ediyor. Duyuru bilinen kısıtlar listesinde birebir "Do not use it in production yet" diyor, dolayısıyla üretim projelerinde henüz kullanma. Denemek istersen npx react-native spm --deintegrate ile başlıyorsun, npx react-native spm deinit ile geri alıyorsun.

0.88'e mi yoksa 0.87'ye mi geçmeliyim?

Bu yazının yazıldığı 23 Eylül 2026 itibarıyla 0.88, release candidate (0.88.0-rc.2) aşamasında ve henüz stable değil. 0.88, release crew'ün 0.88 kayıtlarında non-breaking bir sürüm olarak ele alınıyor, yani 0.87'nin strict API zorunluluğunu değiştirmiyor. Production projede şu aşamada 0.87'ye geçmek güvenli bir seçim; 0.88 stable'a geçtiğinde küçük bir patch yükseltmesiyle takip edebilirsin.

Expo kullanıyorsam RN'i doğrudan 0.87'ye çekebilir miyim?

Stable bir Expo SDK üzerinden hayır. Duyuru bunu net söylüyor: "For Expo projects, React Native 0.87 will be available as part of the expo@canary releases." Yani 0.87'yi taşıyan bir stable SDK sürümü aramanın anlamı yok; RN 0.87'yi Expo ile denemek istiyorsan expo@canary kanalına geçmen gerekiyor. Stable tarafta ise Expensify/App#101427 issue'sunda kayıt altına alındığı gibi Expo SDK 58, React Native'i 0.86'dan doğrudan 0.88'e taşıyor ve 0.87'yi atlıyor — dolayısıyla Expo projesinde beklemek de tamamen geçerli bir strateji.

Sonuç

React Native 0.87 yükseltmesi iki bağımsız işi aynı anda çözmeni istiyor: toolchain'i (Node 22.13+, AGP 9, Kotlin 2.0+, Metro 0.87) güncellemek ve Strict TypeScript API'nin kırdığı deep import'ları temizlemek. Bu iki işi ayrı commit'lere bölmek, migration'ı hem daha izlenebilir hem de geri alınabilir hale getiriyor.

Adımların hiçbiri tek başına karmaşık değil — zorluk, sırayı doğru tutmakta ve her adımı bir öncekinin CI'da yeşil geçtiğinden emin olduktan sonra atmakta: toolchain'i güncelle, cache'i temizle, deep import'ları tara, tip kontrolünü geçir, sonra native build'leri doğrula.

Mimarinin kendisini (Fabric, TurboModules, Bridgeless Mode) merak ediyorsan React Native New Architecture 2026 yazımıza bakabilirsin; bu yazı yalnızca sürüm ve toolchain yükseltmesine odaklandı, mimari detaylara girmedi. Expo ile yönetilen bir proje işletiyorsan Expo SDK 52 EAS Build: Production Workflow yazımızdaki toolchain bölümünü bu makaledeki Node/AGP/Kotlin sürümleriyle çapraz kontrol etmeni öneririz — Expo'nun kendi SDK takvimi RN çekirdek sürümünden bağımsız ilerleyebiliyor.

React Native yerine Flutter'ı değerlendiriyorsan React Native vs Flutter 2024 Karşılaştırması genel resmi veriyor. Android tarafında ayrı bir breaking change dalgası yaşıyorsan Android 17 (API 37): Uygulamayı Kıracak 6 Değişiklik yazımız faydalı olabilir. TypeScript'in kendi derleyici tarafındaki sıkılaşma trendini TypeScript 7 Çıktısı yazımızda işledik.

Kaynaklar

• React Native 0.87 resmi duyuru — sürümün tüm breaking change'lerinin birincil kaynağı, 11 Ağustos 2026.
• Strict TypeScript API resmi dokümantasyonu — deep import kısıtlamasının ve kök export listesinin teknik açıklaması.
• React Native 0.80 duyurusu — Strict TypeScript API'nin opt-in preview olarak ilk tanıtıldığı sürüm, çapraz doğrulama için.
• React Native 0.82 duyurusu — New Architecture'ın tek mimari haline geldiği sürüm; Legacy Architecture'a izin veren son sürümlerin (0.81 / Expo SDK 54) kaynağı.
• react-native npm paket sayfası (0.87.0) — sürüm yayın zamanı ve paket meta verisi.
• React Native GitHub Releases (v0.87.0) — resmi release notu ve yayın tarihi doğrulaması.
• zyfolks.com — React Native 0.87 breaking changes analizi — bağımsız ikinci kaynak, Node 22.13+ ve CTO'ya risk haritası perspektifi.
• dopebase.com — RN 0.87 upgrade readiness check — pratik pre-upgrade checklist, toolchain doğrulaması.
• Expensify/App GitHub Issue #101427 — gerçek bir production ekibinin Expo SDK ve RN sürüm senkronizasyonu kararına örnek.