Native Modül Ekleme: Config Plugin vs Elle Native Yapılandırma
Expo'da native koda dokunma ihtiyacı iki yoldan çözülür: native kod içeren npm paketleri Expo Autolinking ile otomatik bağlanır; ek native yapılandırma (Info.plist izinleri, Android manifest girdileri, Gradle ayarları) gerektiren paketler için bir config plugin yazılır ya da paketin kendi plugin'i kullanılır. Resmi tanım net: bir config plugin, prebuild sürecinde oluşturulan native projeyi varsayılan app config props'larının ötesinde otomatik yapılandırmana izin verir — yani her prebuild çalıştığında aynı native proje yeniden üretilir.
Bare React Native'de de native paketler autolinking ile bağlanır: resmi dokümantasyondaki akış npm install <paket> + npx pod-install + uygulamayı yeniden derlemekten ibarettir, elle Podfile ya da Gradle girdisi yazmazsın. Elle kalan şey yapılandırmadır: Info.plist izin anahtarları, AndroidManifest girdileri, Gradle ayarları. Bunlar native klasörlerin içinde yaşadığı için her RN sürüm yükseltmesinde elle korunmaları gerekir. Kısacası fark bağlamada değil, yapılandırmanın nerede durduğunda: Expo'da "bir kere config plugin yaz, her prebuild'de uygulanır"; bare RN'de "her native yapılandırmayı projede tut ve yükseltmelerde koru".
CNG/Prebuild: Native Klasörleri Sıfırdan Üretmek
Continuous Native Generation (CNG), Expo'nun native klasörleri "kaynak" değil "derlenmiş çıktı" olarak ele almasıdır. npx expo prebuild --clean çalıştırdığında android ve ios klasörleri app config'ine (app.json/app.config.js) ve yüklü config plugin'lere göre sıfırdan üretilir. Resmi dokümantasyon bunun pratik sonucunu şöyle özetliyor: RN sürüm yükseltme süreci artık yalnızca npm bağımlılıklarını ve app config'i güncelleyip prebuild --clean'i yeniden çalıştırmaktan ibaret. Native klasörler git'e commit'lenmeyebilir (.gitignore), CI her build'de onları yeniden üretir.
Bare React Native'de android/ios klasörleri projenin kalıcı, elle bakımı yapılan bir parçasıdır. React Native'in web tabanlı "Upgrade Helper" aracının var olma sebebi tam olarak bu: her minör sürüm arasındaki native dosya farklarını (Podfile, build.gradle, AppDelegate) elle uygulaman gerekir. Bu, daha fazla şeffaflık sağlar (native projede tam olarak ne olduğunu her zaman görürsün) ama sürüm yükseltmelerini CNG'ye göre belirgin şekilde daha emek yoğun hale getirir — özellikle RN'nin kendisi her birkaç ayda bir minör sürüm çıkardığı için (0.85 Nisan, 0.86 Haziran, 0.87 Ağustos 2026).
EAS Build/Update Maliyeti ve Ücretsiz Katman
EAS'ın Free planı ayda 15 Android + 15 iOS build (toplam 30), 1.000 MAU'ya kadar OTA update gönderimi ve 100 GiB edge bandwidth içeriyor — düşük öncelikli build kuyruğuyla. Küçük-orta ölçekli, haftada birkaç kez build alan bir proje için bu genelde yeterli. Ekip büyüdüğünde veya sık CI tetiklendiğinde iki basamak var: Starter ($19/ay + $45 build kredisi, yüksek öncelikli kuyruk, 3.000 MAU) ve Production ($199/ay + $225 build kredisi, 2 eşzamanlı build, 50.000 MAU, SSO, öncelikli destek). Aşım ücretleri $0,10/GiB bandwidth ve $0,05/GiB depolama şeklinde.
Önemli nüans: EAS Build ve EAS Update, Expo'ya özgü değil — resmi dokümantasyon EAS Workflows'u "React Native ve Expo uygulamaları için" bir CI/CD servisi olarak tanımlıyor. Yani bare RN projesi de EAS'ı kullanabilir. Ancak CNG olmadığı için native proje durumunu (build credentials, native yapılandırma) EAS'a manuel senkronize etmen gerekir; Expo projelerinde bu senkronizasyon app config üzerinden otomatik akar. Bare RN'de EAS kullanmayıp kendi CI'ını (Fastlane, Bitrise, GitHub Actions + Xcode/Gradle script'leri) sıfırdan kurmak da yaygın bir tercih — bunun maliyeti zaman ve bakım yüküdür, doğrudan bir abonelik ücreti değildir.
OTA Güncelleme ve Expo Go Login Değişikliği
EAS Update, bir build'i iki katmana ayırır: binary'ye gömülen native katman ve her ikisi arasında "değiştirilebilir" olan update katmanı — küçük bug fix'ler ve JS değişiklikleri kanal (channel) ve deployment mekanizmasıyla native sürüm yükseltmesi beklemeden kullanıcıya ulaşır. expo-updates kütüphanesi bare RN projesine de manuel entegre edilebilir (Expo modülleri bare RN'de de kullanılabilir), ama varsayılan/otomatik değildir — geliştirici kendi OTA çözümünü kurar.
3 Eylül 2026'dan itibaren Expo Go'nun iOS sürümünde önemli bir değişiklik geldi: proje çalıştırmak için hem terminaldeki Expo CLI'da hem Expo Go uygulamasında login zorunlu hale geldi. Bu ayrım kritik — resmi changelog açıkça development build'lerin bu gereksinimden muaf olduğunu ve şu an yalnızca iOS'taki en güncel Expo Go sürümünü etkilediğini belirtiyor. Yani EAS Build ile üretilmiş bir development veya production build'in çalışması login şartına bağlı değil; yalnızca hızlı prototipleme aracı olan Expo Go'da, sadece iOS'ta bu sürtünme var. Bare RN projelerinde böyle bir "hızlı önizleme uygulaması" katmanı hiç yok, dolayısıyla bu tartışma ona dokunmuyor.
New Architecture ve RN 0.87 Strict TypeScript Uyum Hızı
React Native 0.87 (11 Ağustos 2026), Strict TypeScript API'yi varsayılan JavaScript API'si yaptı ve minimum toolchain gereksinimlerini Node.js 22, Android Gradle Plugin 9 ve Kotlin 2.0+'a yükseltti; ayrıca deneysel Swift Package Manager desteği eklendi. New Architecture ise 0.68'de deneysel opt-in olarak başlamıştı; RN 0.76 (23 Ekim 2024) ile varsayılan hale getirildi ve aynı duyuruda production kullanımına hazır ilan edildi — yani 0.87'de her iki kurulum modeli de onu varsayılan alıyor.
Burada önemli bir ayrım var: Expo SDK'ları belirli bir RN çekirdek sürümüne kilitli çıkar, yani SDK 57 (30 Haziran 2026) RN 0.87'yi değil RN 0.86'yı taşıyor. Bu, Expo projelerinin RN 0.87'nin Strict TS varsayılanını henüz almadığı, bir sonraki SDK sürümünü beklemesi gerektiği anlamına geliyor — resmi bir taahhüt tarihi yok. Expo projeleri bu tür yükseltmeleri SDK güncellemesiyle "paket halinde" alırken, bare RN projeleri her minör RN sürümünü (0.85→0.86→0.87) bağımsız ve anında yükseltebilir. Deep import kullanan üçüncü parti paketler Strict TS'e geçişte tip hatası verecek — bare RN'de bunu hemen, Expo'da SDK yükseltmesiyle birlikte deneyimlersin.
CI/CD: EAS Workflows vs Kendi Pipeline'ın
EAS Workflows; Android/iOS binary build, OTA update yayınlama, mağazalara gönderim, E2E test çalıştırma ve EAS Hosting'e web deploy gibi tekrarlanan işleri otomatikleştiren bir CI/CD servisi. Yönetilen bulut ortamlarında çalışır, GitHub olaylarından (push, PR) veya cron zamanlamalarından tetiklenebilir. Resmi dokümantasyon bunun hem React Native hem Expo projeleri için kullanılabildiğini belirtiyor — yani bare RN projesi de EAS Workflows'a bağlanabilir.
Fark, "hazır paket" job'ların tasarımında ortaya çıkıyor: Expo/CNG projelerinde EAS, app config'i okuyarak native build sürecini uçtan uca yönetebilir. Bare RN projesinde native proje durumu (imzalama sertifikaları, provisioning profile, Gradle yapılandırması) EAS'a elle senkronize edilmeli — CNG'nin otomatik ürettiği bilgiyi burada sen sağlarsın. Alternatif olarak bare RN ekipleri sıklıkla Fastlane + Bitrise veya GitHub Actions + kendi Xcode/Gradle script'leriyle sıfırdan bir pipeline kurar; bu, EAS'ın sunduğu "pre-packaged" kolaylığı kaybettirir ama pipeline üzerinde tam kontrol ve kurumsal on-prem gereksinimlerine (ör. self-hosted runner zorunluluğu) uyum sağlar.
Vendor Lock-in ve Kurulumdan İlk Build'e Geçen Süre
"Eject" kavramını resmi doküman kullanımdan kalkmış sayıyor; tüm Expo projeleri artık Continuous Native Generation kullanıyor ve bu işin yerini expo prebuild aldı. Bu değişimin pratik anlamı: native klasörlere elle dokunmadığın sürece, prebuild her zaman aynı native projeyi yeniden üretebilir — yani "managed'dan çıkış" artık tek yönlü bir kapı değil, tekrarlanabilir bir işlem. Config plugin kaldırırsan native klasörler onsuz yeniden üretilir. Tersi yönde de esneklik var: expo-modules-core sayesinde Expo modülleri bare RN projelerine de sonradan eklenebiliyor — yani "bare'den Expo tooling'ine" geçiş de tek yönlü bir kapı değil.
Kurulum eşiği farkı somut: Expo projesi için tek sistem gereksinimi Node.js LTS — npx create-expo-app sonrası Expo Go veya Snack üzerinden native SDK kurulu olmadan anında test edebilirsin. Bare RN'de resmi dokümantasyon seni "environment-setup" bölümüne yönlendiriyor: Xcode + CocoaPods, Android Studio + SDK + Gradle kurulumu ilk build'in ön koşuludur. Bu fark yalnız ilk günü değil, takıma yeni katılan bir geliştiricinin ve CI ortamı kuran kişinin her seferinde ödediği kurulum maliyetini de belirler.