Android tarafında paylaşımlı bir çekirdek kurmak istiyorsun ve önünde iki gerçekçi yol var: Kotlin Multiplatform (KMP) ile iş mantığını Kotlin'de yazıp hem iOS hem Android'e derlemek, ya da Swift'i merkeze alıp Swift Android SDK üzerinden Android'e taşımak. İkisi de aynı felsefeyi (paylaşımlı çekirdek + native UI) vaat ediyor ama olgunluk seviyeleri, araç zincirleri ve interop kaliteleri birbirinden çok farklı. Bu yazı iki seçenek arasında teknik-mimari bir karar rehberi; işe alım, maliyet tablosu ya da beş-yol karşılaştırması değil.
💡 Pro Tip: Karar vermeden önce "hangi taraf zaten olgun" sorusunu sor — KMP'de paylaşımlı Kotlin çekirdeği + native Swift/Compose UI yılı geçmiş bir desen, Swift Android SDK ise henüz 1.0 sürümüne ulaşmamış, API kararlılığı garanti edilmeyen bir interop katmanı üstüne kuruluyor.
İçindekiler
- Karar Bağlamı: Paylaşımlı Çekirdek Neyi Çözer
- Olgunluk: Araç Zinciri, Dokümantasyon, Topluluk
- Kotlin Release Kadansı
- Interop Kalitesi: Swift Export mü Swift-Java mı
- Derleme Süresi ve Binary Boyutu Beklentileri
- Debug Edilebilirlik Farkı
- UI Katmanı ve Ekip Yapısının Etkisi
- Ekip Yapısının Kararına Etkisi
- Dört Ekip Senaryosu İçin Net Seçim
- Karar Matrisi
- SSS
- Swift Android SDK mı KMP mi seçilmeli?
- Paylaşımlı çekirdek için hangisi daha olgun?
- Ekip Swift biliyorsa KMP'ye gerek var mı?
- Swift export ne zaman Beta'ya geçer?
- Swift-Java kütüphaneleri Maven Central'da mı?
- Güncelleme (Eylül 2026)
- Sonuç
- Kaynaklar
Karar Bağlamı: Paylaşımlı Çekirdek Neyi Çözer
Paylaşımlı çekirdek kararı genelde iş mantığı, ağ katmanı, veri modeli ve doğrulama kurallarının iki platformda iki kez yazılmasını önlemek için alınır. UI katmanı native kalır (SwiftUI + Jetpack Compose), yalnızca "platform bağımsız" katman paylaşılır. Sorulması gereken asıl soru şu: paylaşılan çekirdek hangi dilde yazılacak ve o dilin derleyicisi diğer platforma ne kadar sürtünmesiz geçiş yapıyor?
KMP'de cevap net: Kotlin/Native, LLVM tabanlı derleyiciyle Kotlin kodunu doğrudan iOS'a native binary olarak derliyor, yıllardır üretimde. Swift Android SDK'da cevap tersine dönüyor: Swift kodun Android'e taşınıyor ama Android'in kendi ekosistemi (Jetpack, Kotlin kütüphaneleri, Gradle) Kotlin/Java üzerine kurulu — yani Swift tarafı "misafir" konumunda. Bu asimetri kararın merkezinde duruyor: KMP'de paylaşılan kod hangi platforma giderse gitsin kendi evinde, Swift Android SDK'da paylaşılan kod Android'de yabancı bir çalışma zamanına entegre olmak zorunda.
İki taraf da "paylaşımlı çekirdek + native UI" felsefesini benimsiyor; farkları çekirdeğin hangi platformda "yerli", hangisinde "konuk" olduğunda. Ekibinin çoğunluğu Swift biliyorsa Swift Android SDK cazip görünür, ama bu yazının ilerleyen bölümlerinde göreceğin gibi olgunluk farkı bu tercihi büyük ölçüde geçersiz kılıyor.
Olgunluk: Araç Zinciri, Dokümantasyon, Topluluk
Kotlin Multiplatform, JetBrains'in resmi release takviminde: dil sürümleri altı ayda bir, araç-zinciri (tooling) sürümleri dil sürümünden üç ay sonra çıkıyor (kotlinlang.org/docs/releases.html). Kotlin 2.4.0, 3 Haziran 2026'da yayınlandı ve bu tarih aynı sayfadaki release listesinde duruyor.
Swift tarafında Android desteği çok daha genç: ilk resmi Swift SDK for Android, Swift 6.3 ile 24 Mart 2026'da geldi (swift.org/blog/swift-6.3-released). Yani KMP'nin native-iOS derleyicisi yıllardır olgunlaşırken, Swift'in native-Android derleyicisi 2026'nın yalnızca ilk çeyreğinde doğdu. Bu, iki teknolojinin "kaç yıllık deneyim" farkını değil, "hangi yönün önceliklendirildiği" farkını gösteriyor — JetBrains yıllardır Kotlin'i iOS'a taşımaya odaklandı, Swift tarafında ise Android Workgroup, nightly preview'lardan ilk resmi Swift SDK for Android sürümüne 24 Mart 2026'da geçti.
Swift'in platform desteği sayfası da bu tabloyu doğruluyor: Android, minimum dağıtım sürümü tablosunda "9 (API 28)" ile listeleniyor, ama "deployment-only" bölümündeki debugger/REPL tablosunda macOS, iOS, watchOS, tvOS, Ubuntu ailesi ve Windows var — Android bu tabloda ayrı bir satır olarak görünmüyor (swift.org/platform-support). Yani Android desteği var ama henüz birinci sınıf "deployment-only" platform listesiyle aynı seviyede işlenmiyor.
Dokümantasyon ve topluluk tarafında da fark açık: KMP'nin resmi kotlinlang.org dokümantasyonu, örnek proje şablonları (Kotlin Multiplatform Wizard) ve IDE entegrasyonu (IntelliJ IDEA, Android Studio) yıllardır olgun.
Swift Android SDK tarafında resmi örnekler swift-java deposunun Samples/ dizininde toplanıyor, ama deponun kendi README'si projeyi "under active development" diye tanımlıyor ve 1.0 sürümüne kadar API kararlılığı garantisi vermediğini açıkça yazıyor (github.com/swiftlang/swift-java). Bu, "çalışmıyor" anlamına gelmiyor — anlamına geldiği şey, ekibinin ilk entegrasyon sürecinde henüz sabitlenmemiş bir API yüzeyinin üstüne kuracağı.
Kotlin Release Kadansı
Kotlin'in kendi releases sayfası kadansı şöyle tanımlıyor: dil sürümleri (x.x.0) altı ayda bir, tooling sürümleri (x.x.20) dil sürümünden yaklaşık üç ay sonra çıkıyor. Bu makalenin yayın tarihinde (26 Haziran 2026) en güncel sürüm, 3 Haziran 2026'da çıkan Kotlin 2.4.0 — Swift export'un Alpha'ya geçtiği sürüm. Bu kadans, KMP'nin arkasında öngörülebilir ve düzenli bir release ritmi olduğunu gösteriyor; Swift Android SDK tarafında henüz bu netlikte bir takvim yayınlanmadı.
Interop Kalitesi: Swift Export mü Swift-Java mı
Her iki tarafın da kendi interop mekanizması var ama statüleri birbirinden farklı: bu makalenin yayın tarihinde (26 Haziran 2026) Swift export resmi olarak Alpha, Swift-Java ise 1.0 öncesi, API kararlılığının garanti edilmediği aktif geliştirme aşamasında. KMP tarafında Kotlin, Swift export adında bir özellik geliştiriyor: Kotlin/Native derleyicisinin ürettiği kodu doğrudan Swift'ten çağrılabilir hale getiriyor. Kotlin 2.4.0 sürüm notları bunu birebir şöyle tanımlıyor: "Swift export goes Alpha with improved concurrency support."
Bilinen kısıtları da dokümantasyonda açıkça duruyor: List, Set veya Map'ten türeyen tipler export sırasında yok sayılıyor (KT-80416) ve bu tiplerden türeyenler Swift tarafında örneklenemiyor (KT-80417). Ayrıca Swift export şu an yalnızca iOS framework'ünü Xcode projesine "direct integration" ile bağlayan projelerde çalışıyor; bu da istisnai bir mod değil, IntelliJ IDEA'daki Kotlin Multiplatform eklentisiyle ya da web wizard ile oluşturulan KMP projelerinin standart yapılandırması. Kotlin'in kendi native-swift-export dokümantasyonu statüyü "Alpha" olarak listeliyor (kotlinlang.org/docs/native-swift-export.html).
Swift Android SDK tarafında interop yükü Swift-Java ve Swift-Java JNI Core kütüphaneleri üzerinden yürüyor. Bu kütüphaneler Swift 6.3 ile birlikte geldi ama swift-java'nın dayandığı destek kütüphaneleri 26 Haziran 2026 itibarıyla Maven Central'da yayınlanmış değildi — yani bir Android projesinde kullanmak için bu kütüphaneleri kendin yerelde yayınlaman (self-publish) gerekiyordu. Bu, KMP'nin Gradle üzerinden tek satırla bağımlılık eklediği deneyimin tam tersi: Swift Android SDK'da interop katmanının kendisi henüz "paketlenmiş bir bağımlılık" değil, üzerinde çalışman gereken bir altyapı parçası.
kotlin
1// KMP: paylaşılan çekirdek, tek Gradle bağımlılığıyla iki platforma da dağıtılır2// ktorVersion gradle.properties'te pinlenir; açık aralık kullanılmaz3val ktorVersion: String by project4 5kotlin {6 androidTarget()7 iosArm64()8 sourceSets {9 commonMain.dependencies {10 implementation("io.ktor:ktor-client-core:$ktorVersion")11 }12 }13}Derleme Süresi ve Binary Boyutu Beklentileri
Bu eksende iki teknolojiyi doğrudan karşılaştıran, metodolojisi açıklanmış resmi bir benchmark yok — ne JetBrains ne Apple tarafında yayınlanmış bir "KMP vs Swift Android SDK derleme süresi" raporu bulunmuyor. Bu yüzden burada somut bir sayı vermek yerine mimari farkın ne anlama geldiğini açıklamak daha dürüst: KMP'de Kotlin/Native derleyicisi LLVM üzerinden tek bir native binary üretiyor ve bu binary doğrudan iOS uygulamasına linklenir; ek bir çalışma zamanı köprüsü yok. Swift Android SDK'da ise Swift kodu Android'in JVM tabanlı çalışma zamanıyla Swift-Java/JNI katmanından konuşuyor — bu, ek bir serileştirme/köprüleme adımı demek.
Pratik sonucu şu: KMP'nin derleme hattı yıllardır optimize edildi ve CI'da öngörülebilir; Swift Android SDK'nın derleme hattı henüz 1.0 öncesi bir interop katmanının üstünde, dolayısıyla CI süresi ve binary boyutu konusunda ekibinin kendi projesinde ölçüm yapması gerekiyor — üçüncü taraf bir referans sayı bu aşamada güvenilir değil.
bash
1# KMP: iOS için paylaşılan framework derlemesi (öngörülebilir, yıllardır optimize)2./gradlew :shared:assembleSharedXCFrameworkDebug Edilebilirlik Farkı
Derleme süresinin ötesinde, günlük geliştirme deneyimini asıl belirleyen şey debug edilebilirlik. KMP'de Kotlin/Native binary'si Xcode'un LLDB'siyle doğrudan debug edilebiliyor çünkü çıktı native bir binary; breakpoint koyabilir, step-into yapabilirsin. Swift Android SDK tarafında Swift kodu Android'de Swift-Java/JNI köprüsü üzerinden çalıştığı için, hatanın Swift tarafında mı yoksa köprüleme katmanında mı oluştuğunu ayırt etmek ek bir adım gerektiriyor.
Bu fark, günlük geliştirmede en çok "neden burada patlıyor" sorusuna harcanan zamanda hissediliyor. KMP'de commonMain içindeki Kotlin kodu her iki platformda da aynı çalışma zamanı davranışını (aynı exception tipleri, aynı coroutine iptal semantiği) gösteriyor — debug ederken zihinsel modelin değişmiyor. Swift Android SDK'da ise Swift'in kendi hata modeli (throws/Result) ile Android tarafının JVM exception modeli arasında bir köprüleme katmanı var; bu katman henüz 1.0 öncesi olduğu için hata mesajlarının okunabilirliği ve stack trace'in ne kadar net kaldığı henüz kotlinlang.org seviyesinde belgelenmiş değil.
Bu belirsizlik, üretim-kritik bir çekirdek için "riskin nerede biriktiğini önceden bilemiyorsun" anlamına geliyor — ve bu, olgunluk farkının derleme süresinden çok daha somut bir yansıması.
Boyut | KMP | Swift Android SDK |
|---|---|---|
Derleme çıktısı | Tek native binary (LLVM) | Swift binary + JNI köprü katmanı |
Debug araçları | Xcode/LLDB doğrudan | Köprü katmanında sınır belirsiz |
Hata modeli | Kotlin Result/Exception, iki platformda ortak | Swift throws + JVM exception, iki ayrı model |
CI öngörülebilirliği | Yıllardır optimize | 1.0 öncesi katman, ölçüm ekibe kalıyor |
UI Katmanı ve Ekip Yapısının Etkisi
Her iki seçenekte de standart öneri aynı: iş mantığını paylaş, UI'ı native bırak. KMP'de bu SwiftUI + Jetpack Compose ile pürüzsüz çalışıyor çünkü paylaşılan Kotlin modülü her iki tarafa da "yerel bir kütüphane" gibi görünüyor. Swift Android SDK'da UI kararı biraz daha karmaşık: Swift tarafında SwiftUI kalabilirsin, ama Android'de UI'ı yine Jetpack Compose'da yazman gerekiyor çünkü Swift'in Android'de native bir UI framework'ü yok — yalnızca iş mantığı katmanı Swift'te kalıyor, arayüz katmanı yine Kotlin/Compose'a devrediliyor.
Bu da şu soruyu doğuruyor: ekibin zaten Kotlin/Compose yazıyorsa, Swift Android SDK'nın kazandırdığı şey yalnızca "iş mantığını Swift'te tutabilmek" oluyor — UI tarafında hâlâ Kotlin bilmen gerekiyor. KMP'de ise paylaşılan katman zaten Kotlin, UI tarafında da Kotlin/Compose kullanmak doğal bir uzantı.
kotlin
1// KMP: paylaşılan ViewModel, hem SwiftUI hem Compose'dan tüketilir2class ProductListViewModel(private val repository: ProductRepository) {3 private val _state = MutableStateFlow(ProductListState())4 val state: StateFlow<ProductListState> = _state.asStateFlow()5 6 suspend fun loadProducts() {7 _state.update { it.copy(isLoading = true) }8 val products = repository.fetchProducts()9 _state.update { it.copy(isLoading = false, products = products) }10 }11}Ekip Yapısının Kararına Etkisi
Bu yazı işe alım piyasası ya da maliyet karşılaştırması yapmıyor — o konu ayrı bir yazının kapsamı. Burada önemli olan tek şey: mevcut ekibinin hangi dilde derinliği var ve o derinlik hangi teknolojiyle daha az sürtünmeyle buluşuyor. iOS ağırlıklı bir ekip, Swift Android SDK'yı "zaten bildiğim dili Android'e taşıyorum" diye cazip bulabilir, ama bir önceki bölümde gördüğün gibi Android UI'ı yine Compose/Kotlin'de kalıyor — yani ekip yine de bir miktar Kotlin bilgisine ihtiyaç duyuyor.
Tersine, Android ağırlıklı veya full-stack Kotlin kullanan bir ekip için KMP doğal bir uzantı: zaten yazdıkları dil, iOS'a da native olarak taşınıyor. Karar burada "hangi dili biliyoruz" sorusundan çok "paylaşılan çekirdeğin native olduğu platform hangisi, konuk olduğu platform hangisi" sorusuna dönüyor — ve bu sorunun cevabı bugün açıkça KMP lehine.
Dört Ekip Senaryosu İçin Net Seçim
- Android-ağırlıklı ekip, iOS'u genişletiyor: KMP. Paylaşılan çekirdek zaten native platformunda, iOS tarafı yeni.
- iOS-ağırlıklı ekip, Android'i genişletiyor: Yine KMP öneriliyor — Swift Android SDK'nın interop katmanının 1.0 öncesi olgunluğu, üretim kritik bir çekirdek için risk taşıyor; ekip Kotlin öğrenip paylaşılan katmanı Kotlin'de tutmalı.
- Yeni takım, sıfırdan başlıyor: KMP. Kararlılık garantisi verilmiş bir katman üzerine kurmak, ilk üründe risk almamak anlamına geliyor.
- Deneysel/yan proje, riski göze alabiliyorsun: Swift Android SDK denenebilir — Swift export Alpha'da hızlı ilerliyor ama üretim-kritik bir çekirdek için henüz erken.
Dört senaryonun üçünde net cevap KMP çünkü olgunluk farkı, dil aşinalığından daha ağır basıyor. Dördüncü senaryoda bile "dene ama üretime henüz koyma" uyarısı geçerli.
Karar Matrisi
Kriter | KMP | Swift Android SDK |
|---|---|---|
Native olduğu platform | iOS (yıllardır) | — (Android'de konuk) |
Interop statüsü (26 Haz 2026) | Swift export: Alpha | Swift-Java: 1.0 öncesi, API kararlılığı yok |
Araç zinciri olgunluğu | IDE + wizard + resmi doküman yıllardır olgun | Örnekler swift-java deposunda toplanıyor |
UI katmanı | SwiftUI + Compose (ikisi de native) | SwiftUI (iOS) + yine Compose (Android) |
Üretime hazır mı | Evet (yaygın kullanım) | Hayır (1.0 öncesi bağımlılıklar) |
ALTIN İPUCU
Bu yazının en değerli bilgisi
Bu ipucu, yazının en önemli çıkarımını içeriyor.
Easter Egg
Gizli bir bilgi buldun!
Bu bölümde gizli bir bilgi var. Keşfetmek ister misin?
Okuyucu Ödülü
Bu karara başlamadan önce kendi ekibinde kontrol etmen gereken beş madde var — hepsini işaretlemeden Gradle dosyasına dokunma. Bu liste, yazıdaki olgunluk ve interop bulgularının senin projenin için pratik bir ön-kontrol listesine dönüştürülmüş hali.
SSS
Swift Android SDK mı KMP mi seçilmeli?
Üretim-kritik bir paylaşımlı çekirdek için KMP öneriliyor çünkü Kotlin/Native'in iOS derleyicisi yıllardır olgun ve Swift export interop katmanı 26 Haziran 2026 itibarıyla hâlâ Alpha statüsünde.
Paylaşımlı çekirdek için hangisi daha olgun?
KMP daha olgun. Kotlin/Native'in iOS derleyicisi yıllardır üretimde kullanılıyor; Swift'in resmi Android SDK'sı ise ilk kez Swift 6.3 ile 24 Mart 2026'da geldi, yani KMP'ye göre çok daha genç bir teknoloji.
Ekip Swift biliyorsa KMP'ye gerek var mı?
Evet, çünkü Android'de UI katmanı yine Jetpack Compose'da kalıyor — Swift Android SDK yalnızca iş mantığı katmanını Swift'te tutmana izin veriyor, arayüz tarafında hâlâ bir miktar Kotlin bilgisi gerekiyor. Ekip zaten bir miktar Kotlin öğrenecekse, paylaşılan çekirdeği doğrudan Kotlin'de tutmak daha az sürtünme yaratıyor.
Swift export ne zaman Beta'ya geçer?
26 Haziran 2026 itibarıyla Kotlin'in kendi dokümantasyonu statüyü "Alpha" olarak listeliyor ve resmi bir Beta tarihi taahhüdü yok. Elinde olan tek şey, Kotlin'in öngörülebilir release kadansı: dil sürümleri altı ayda bir, tooling sürümleri dil sürümünden yaklaşık üç ay sonra.
Swift-Java kütüphaneleri Maven Central'da mı?
26 Haziran 2026 itibarıyla değildi; daha doğrusu swift-java'nın dayandığı destek kütüphaneleri Maven Central'da yayınlanmış değildi ve projeye dahil etmek için bunları kendin yerelde yayınlaman gerekiyordu — bu durum KMP'nin tek satır Gradle bağımlılığıyla kıyaslandığında ek bir operasyonel yük.
Güncelleme (Eylül 2026)
Bu yazının gövdesi 26 Haziran 2026 itibarıyla geçerli sürüm bilgilerine dayanıyor. 26 Haziran–23 Eylül 2026 arasında karar dengesini değiştirecek bir gelişme olmadı, ama Kotlin tarafında somut ilerleme var:
Kotlin 2.4.20, 7 Eylül 2026'da yayınlandı ve Swift export'a üç yeni özellik ekledi (kotlinlang.org/docs/whatsnew2420.html): sealed class/interface hiyerarşileri artık Swift enum'larına eşleniyor ve Xcode'da exhaustive switch + autocompletion destekliyor; "cross-language inheritance" resmî hale geldi — Kotlin'de kontrat tanımlayıp Swift tarafında platforma özgü implementasyon yazmayı mümkün kılıyor; assembleSharedXCFramework artık SwiftPM bağımlılıkları için otomatik Package.swift üretiyor.
Buna rağmen Swift export, 23 Eylül 2026 itibarıyla kotlinlang.org'un kendi dokümantasyonunda hâlâ resmi olarak "Alpha" statüsünde (native-swift-export.html) — yani bu yazının "Swift export'u production-kritik yola henüz koyma" uyarısı geçerliliğini koruyor. Swift tarafında da somut bir tooling ilerlemesi var: Swift 6.4 (15 Eylül 2026) sürüm notları Android'e ayrı bir başlık açıyor ve Android için Swift SDK'nın artık yeni LTS NDK 30 ile derlendiğini, bunun hem Swift runtime kütüphanelerinde hem de varsayılan NDK'yı kullanan Swift paketlerinde Android availability attribute'ları sağladığını yazıyor; ayrıca Swift Build artık SwiftPM'de Android'i destekliyor ve post-install script ihtiyacını ortadan kaldırıyor (swift.org/blog/swift-6.4-released). Bu tam olarak bu yazının tartıştığı tooling-olgunluk ekseninde bir kalem. Kotlin 2.5.0-Beta1 (23 Eylül 2026, EAP) ise Swift export'a yönelik yeni bir madde içermiyor. Sonuç: makaledeki karar değişmiyor — çünkü interop katmanlarının statüsü iki tarafta da aynı kaldı — ama Swift tarafı da yerinde saymıyor.
Sonuç
Swift Android SDK ile KMP arasındaki karar, dil aşinalığından çok olgunluk farkına dayanıyor: KMP'nin native olduğu platform (iOS) yıllardır üretimde, Swift Android SDK'nın Android desteği ise 2026'nın ilk çeyreğinde doğdu ve interop katmanı hâlâ 1.0 öncesi. Dört ekip senaryosunun üçünde net cevap KMP; dördüncüsünde bile "dene ama üretime henüz koyma" uyarısı geçerli.
Kararını netleştirmeden önce mimari tercihlerini daha geniş bağlamda görmek istersen Flutter vs SwiftUI production karşılaştırmasına veya Compose Multiplatform'un Android+iOS üretim deneyimine göz atabilirsin. KMP'yi üretimde nasıl kullandığımızı somut bir vaka üzerinden görmek için KMP 1.1 üretim vaka çalışmasını okuyabilirsin. UI katmanında SwiftUI mı UIKit mi sorusuyla da boğuşuyorsan 2026 karar rehberimiz ve Swift tarafında concurrency temelini sağlamlaştırmak için Swift 6 strict concurrency derin rehberi faydalı olacaktır.
Kaynaklar
- Kotlin Releases Overview — Kotlin'in dil ve tooling sürüm takvimi ile 2.4 release line tarihleri.
- Kotlin 2.4.20 sürüm notları — sealed class/interface Swift export desteği, cross-language inheritance ve otomatik Package.swift üretimi.
- Swift Export interop dokümantasyonu — Swift export'un Alpha statüsünü ve List/Set/Map sınırlarını doğrudan tanımlayan resmi Kotlin dokümanı.
- Swift 6.3 Released — Android için ilk resmi Swift SDK'nın duyurusu, 24 Mart 2026.
- Swift 6.4 Released — 15 Eylül 2026 sürüm notları; Android başlığı altında LTS NDK 30 ve SwiftPM'de Swift Build desteği.
- swift-java — Swift-Java interop deposunun proje statüsü,
Samples/dizini ve destek kütüphanelerinin Maven Central durumu. - Swift Platform Support — Android'in minimum dağıtım sürümü ve deployment-only platform tablosundaki konumu.
