Paylaşılan Katman: Yalnız İş Mantığı mı, UI de mi?
KMP'nin varsayılan kullanım şekli "shared module" — network çağrıları, veri modelleri, domain mantığı Kotlin'de tek yerde yazılır; UI Android'de Jetpack Compose/View, iOS'ta SwiftUI/UIKit ile native kalır. UI paylaşımı istersen Compose Multiplatform ayrı, opsiyonel bir katman olarak eklenir — zorunlu değil. React Native'de bu ayrım yok: varsayılan model UI + mantığın birlikte JavaScript/TypeScript'te yazılmasıdır, native ekranlar istisnadır. Bu yüzden "UI'ı native bırak" isteği doğrudan KMP'ye, "tek kod tabanından ekran üret" isteği doğrudan RN'e işaret eder — ikisi de aynı sorunu farklı katmanda çözüyor.
Mevcut Uygulamaya Kademeli Entegrasyon
Her iki taraf da resmi, adım adım rehbere sahip. KMP'nin "Integrate KMP into an existing application" tutorial'ı: shared module oluştur → Gradle bağımlılığı olarak Android projesine ekle → Xcode'da framework olarak iOS projesine bağla. React Native'in "Integration with Existing Apps" rehberi (Android tarafı): proje dizin yapısını kur → mevcut Android projesini alt klasöre taşı → Community Template'in package.json'ını al, npm install çalıştır → React Native'i Gradle yapılandırmasına ekle → ReactActivity ile entegre et → bundler'ı test et. RN'in adımı daha fazla (6 adım, proje yapısını yeniden düzenleme gerektiriyor); KMP'nin shared-module yaklaşımı mevcut proje yapısına daha az müdahale eder çünkü yalnızca bir Gradle modülü ekler.
Ekip Becerisi: Kotlin/Android mı, JS/Web mi?
Bu kriter çoğu zaman kararı tek başına verdiriyor. Android ekibi zaten Kotlin, Gradle ve Android Studio'ya hâkimse KMP shared module'ü öğrenmek küçük bir adım — syntax aynı, yeni olan yalnızca multiplatform hedefleri (expect/actual) ve iOS framework export'u. Web/JS ekibi mobile'a genişleyecekse React Native çok daha kısa yoldan üretken hale gelir — React bilgisi doğrudan transfer olur, yalnız native modül köprüleri (Kotlin/Swift tarafı) öğrenilmesi gerekir. İki tarafın da "diğer platformun native dilini hiç bilmeyen ekip" senaryosunda öğrenme eğrisi var: KMP'de iOS tarafı Swift/Xcode bilgisi gerektirir, RN'de native modül yazımı Kotlin/Swift bilgisi gerektirir — hiçbiri "native dil bilgisi sıfır" vaadi vermiyor.
UI'ın Native Hissi
KMP'de varsayılan UI native bileşenlerle (SwiftUI/UIKit, Jetpack Compose/View) yazıldığı için platform-spesifik davranış, animasyon ve erişilebilirlik otomatik gelir — çünkü UI zaten platformun kendi framework'üyle üretilir. React Native'in Yeni Mimarisi (Fabric/TurboModules), Meta'nın kendi production uygulamalarında 2024'ten beri kanıtlanmış durumda ve senkron layout ölçümü gibi native'e yakın davranışlar sağlıyor; Yeni Mimari'nin dört parçasından biri zaten "Removing the Bridge" — köprü 0.76'dan (Ekim 2024) beri yok. Yine de UI'ı bir JS runtime sürüyor: bileşenler JSI üzerinden native tarafa render ediliyor, yani ek bir runtime/JS thread katmanı var; KMP'de UI doğrudan platformun kendi framework'üyle çizilir. Pratik sonuç: karmaşık, platforma özgü gesture'lar veya sistem bileşenleriyle derin entegrasyon (ör. iOS'a özgü context menu davranışları) gerektiren ekranlarda KMP'nin native UI'ı ek soyutlama katmanı gerektirmez; RN'de bu tür ekranlar native modül köprüsü ister.
Build/CI Karmaşıklığı ve Kütüphane Erişimi
React Native 0.87 minimum toolchain'i net: Node.js 22, AGP 9, Kotlin 2.0+ — bu, "mevcut uygulamaya ekleme" senaryosunda projenin zaten bu sürümlerde olmasını şart koşuyor, aksi halde önce toolchain yükseltmesi gerekir. KMP tarafında ek bir JS/Node katmanı yok; CI zaten var olan Gradle/Xcode pipeline'ına bir modül daha ekler. Kütüphane erişiminde tablo tersine dönüyor: RN'in npm ekosistemi devasa (yüz binlerce paket) ve çoğu native modül köprüsü zaten yazılmış durumda geliyor; KMP'de expect/actual ile platforma özgü SDK'lara erişim için genellikle kendi köprünü yazman gerekiyor çünkü multiplatform-native kütüphane havuzu daha küçük ve genç.
Ekosistem Büyüklüğü ve İşe Alım Havuzu
GitHub yıldızı kaba ama somut bir ekosistem proxy'si: react/react-native 126.703 star, 25.283 fork ile JetBrains/kotlin'in 53.451 star, 6.421 fork'unun yaklaşık 2,4 katı büyüklükte — bu, Kotlin dilinin genel popülerliğini yansıtır, KMP'ye özel ayrı bir repo yıldız sayısı yayınlanmıyor. İşe alım tarafında elimizde kaynaklı bir iş ilanı sayımı yok: RN 2015'ten beri (react/react-native created_at) mainstream olduğu için havuzun daha geniş olmasını beklemek makul, ama bu bir beklenti — ölçüm değil; bu yüzden iki tarafın jobMarket puanını da nötr bantta tuttuk. Ancak Kotlin/Android becerisi zaten TR pazarında yaygın olduğundan, "KMP bilen Android geliştirici yetiştirmek" RN'den daha kısa bir öğrenme yatırımı olabilir — bu nüans ham yıldız sayısında görünmüyor.