Flutter ve React Native (RN) dünyasından gelen bir geliştirici olarak, muhtemelen “Write Once, Run Anywhere” (Bir kere yaz, her yerde çalıştır) felsefesine alışkınsın. İster Flutter’ın kendi render motoruyla her pikseli çizmesi olsun, ister React Native’in JS köprüsü üzerinden native bileşenleri yönetmesi olsun; amaç genellikle tek bir kod tabanıyla tüm UI ve lojiği paylaşmaktır.
Kotlin Multiplatform (KMP) ise masaya farklı bir felsefe ile oturuyor: “Logic Shared, UI Flexible” (Mantık Paylaşımlı, Arayüz Esnek). Ancak son zamanlarda Compose Multiplatform ile Flutter’a doğrudan rakip olabilecek bir yapıya da evrildi.
İşte bir Flutter/RN geliştiricisi gözüyle KMP’nin anatomisi:
1. Mimari: Köprüler ve Motorlar Yok (Neredeyse)
Bu kısmı anlamak için mevcut bilginle kıyaslayalım:
- React Native: JavaScript kodu bir “Bridge” (Köprü) üzerinden Native (Host) platformla konuşur. JSON mesajlaşması vardır. Performans darboğazı genellikle bu köprüdür.
- Flutter: Kendi Skia (veya Impeller) motorunu getirir. Platformun UI kütüphanelerini kullanmaz, kendi çizer. Native tarafla konuşmak için
PlatformChannelkullanır (yine bir nevi mesajlaşma). - Kotlin Multiplatform: Burada bir “Sanal Makine” veya “Köprü” zorunluluğu yoktur (UI hariç).
KMP Nasıl Çalışır?
KMP, yazdığın Kotlin kodunu hedef platformun anadilinde derler.
- Android için: JVM Bytecode’una derlenir (Zaten native Android geliştirme ile aynı).
- iOS için: LLVM kullanılarak doğrudan Apple framework’ü (Binary) olarak derlenir. Yani iOS tarafı senin kodunu bir
Objective-C/Swiftframework’ü gibi görür.
Özetle: React Native’deki gibi bir JS Bridge beklemezsin veya Flutter’daki gibi uygulamanın şişmesine neden olan gömülü bir motor taşımazsın (Logic paylaşımında). Kod, native olarak çalışır.
2. Neler Yapabilir? (Kapsam)
KMP’yi iki ana başlıkta incelemelisin. Eskiden sadece ilki vardı, şimdi ikincisi de var.
A. İş Mantığı (Business Logic) Paylaşımı (KMP’nin Doğuşu)
KMP’nin asıl çıkış noktası şudur: “UI platforma özel kalsın (SwiftUI & Jetpack Compose), ama altındaki her şeyi paylaşalım.”
Paylaşabildiğin katmanlar:
- Networking: API çağrıları (Ktor vb.).
- Veritabanı: Lokal caching (SQLDelight, Room).
- View Model / Presenter: State yönetimi.
- Algoritmalar & Utility: Doğrulama kuralları, tarih formatlama, veri işleme.
Bu senaryoda; iOS geliştiricisi Xcode açar, SwiftUI yazar ve senin yazdığın Kotlin fonksiyonunu import SharedModule diyerek çağırır.
B. UI Paylaşımı (Compose Multiplatform)
Google ve JetBrains, “Flutter geliştiricileri tek kodla UI yapmayı seviyor” diyerek Compose Multiplatform‘u geliştirdi.
- Bu, Flutter’a çok benzer. Skia kütüphanesini kullanarak UI çizer.
- Android’de zaten native Jetpack Compose çalışır.
- iOS’te ise Skia motoru üzerinden çizim yapar (Flutter mantığı).
3. React Native ve Flutter’a Göre Artıları (+)
- Native Performans ve İnterop (Birlikte Çalışabilirlik): React Native’de native bir modül yazmak bazen tam bir kabustur. Flutter’da ise Dart ile Native arasına MethodChannel koymak gerekir. KMP’de ise Kotlin dosyasının içine expect/actual mekanizmasıyla doğrudan platforma özgü kod yazabilirsin. Swift kodunu Kotlin’den çağırmak (veya tam tersi) çok daha az maliyetlidir.
- Incremental Adoption (Aşamalı Geçiş): Bu, KMP’nin en büyük kozudur. Mevcut devasa bir Native uygulamanız varsa, Flutter veya RN’e geçmek için uygulamayı baştan yazmanız gerekir. KMP’de ise “Sadece şu yeni feature’ın veri katmanını ortak yazalım” diyebilirsin. Mevcut projeyi bozmadan entegre olabilir.
- Tek Dil, Güçlü Tip Güvenliği: React Native’deki TypeScript harika olsa da, runtime hataları (JS tarafında) olasıdır. Kotlin, Java ekosisteminin gücünü ve Swift’in modernliğini birleştiren çok güçlü, statik tipli bir dildir.
- Platformun Doğallığını Korumak: Eğer sadece Logic paylaşırsan (Compose kullanmazsan), iOS uygulaman %100 Apple hissi verir. Kullanıcı, uygulamanın cross-platform olduğunu asla anlamaz çünkü UI tamamen native SwiftUI’dır. Flutter’da bazen o “tekinsiz vadi” (uncanny valley) hissi oluşabilir (iOS scroll fiziğinin tam tutmaması vb.), KMP Native UI’da bu yoktur.
4. React Native ve Flutter’a Göre Eksileri (-)
- Kurulum ve Build Karmaşası (Gradle): Bir Flutter geliştiricisi olarak pubspec.yaml’ın sadeliğine, bir RN geliştiricisi olarak npm’in kolaylığına alışkınsın. KMP dünyasında Gradle ile boğuşacaksın. iOS build ayarlarını Gradle üzerinden yönetmek bazen saç baş yoldurabilir.
- Ekosistem ve Kütüphaneler: Flutter (pub.dev) ve RN (npm) derya denizdir. Her şey için bir paket vardır. KMP ekosistemi hızla büyüyor (Ktor, Koin, SQLDelight, Voyager) ama hala “her şeyin hazır bir kütüphanesi” yok. Bazen platforma özel kod yazmak zorunda kalırsın.
- iOS Tarafındaki Debugging: Kotlin kodu iOS’te çalışırken bir hata aldığında, Xcode içindeki debug deneyimi (özellikle stack trace’ler) native Swift kadar temiz olmayabilir (gerçi geliştiriliyor).
- “Hot Reload” Eksikliği: Compose Multiplatform kullanıyorsan bir önizleme ve hızlı yenileme var ama Flutter’ın efsanevi Hot Reload hızı ve stabilitesi henüz tam yakalanmış değil. Logic tarafında değişiklik yaptığında yeniden derleme süreleri can sıkabilir.
5. Hangi Durumda Hangisini Seçmeli?
Aşağıdaki tablo karar vermene yardımcı olabilir:
| Senaryo | Tavsiye | Neden? |
| MVP / Erken Aşama Startup | Flutter / RN | Hız her şeydir. UI ve Logic’i tek seferde yazıp çıkmak en mantıklısıdır. |
| Mevcut Büyük Native Uygulama | KMP | Uygulamayı çöpe atamazsın. Yeni modülleri KMP ile yazıp native ekibin yükünü azaltırsın. |
| Yüksek Donanım Erişimi | KMP | Bluetooth, Sensörler, AR/VR gibi native API’lere çok yoğun erişim gerekiyorsa KMP’nin “bridge-less” yapısı avantajdır. |
| Mükemmel iOS UI Hassasiyeti | KMP (Logic Only) | Eğer tasarım ekibi “iOS’te bu buton tam Apple standardında olsun” diyorsa, Logic’i paylaş, UI’ı SwiftUI ile yaz. |
| Web Geliştirici Arkaplanı | React Native | JS/TS bilgin varsa RN en hızlı adaptasyonu sağlar. |
6. Örnek Bir Kod Yapısı (Zihinsel Model)
Bir RN/Flutter geliştiricisi olarak şu yapı tanıdık gelecektir:
Klasör Yapısı:
androidApp/(Sadece Android native giriş noktası)iosApp/(Xcode projesi, sadece iOS giriş noktası)shared/(Büyü burada gerçekleşir)commonMain/-> Herkesin kullandığı kod (ViewModel, Data, Models).androidMain/-> Android’e özel implementasyonlar (örn: Bluetooth sürücüsü).iosMain/-> iOS’e özel implementasyonlar.
Basit Bir Fonksiyon:
Flutter’da if (Platform.isIOS) dediğin yerler için KMP şunu yapar:
1 2 3 4 5 6 7 8 9 | // commonMain (Interface gibi düşün) expect fun getPlatformName(): String // androidMain actual fun getPlatformName(): String = "Android ${android.os.Build.VERSION.SDK_INT}" // iosMain import platform.UIKit.UIDevice actual fun getPlatformName(): String = UIDevice.currentDevice.systemName() + " " + UIDevice.currentDevice.systemVersion |
Derleme anında doğru kod parçası ilgili binary’nin içine gömülür. Runtime kontrolü (if/else) yoktur, doğrudan o kod çalışır.
Sonuç: KMP Bir Tehdit mi, Fırsat mı?
Flutter ve React Native geliştiricisi olarak KMP senin için bir tehdit değil, kariyerinde bir üst seviyedir.
Özellikle “Super App” boyutundaki şirketler (Netflix, Uber, vb.) UI paylaşımından ziyade, karmaşık iş mantığını (Business Logic) paylaşmaya odaklanırlar. KMP, Flutter ve RN’in “her şeyi ben çizerim/yönetirim” yaklaşımının aksine, native dünyaya saygı duyan ve onunla bütünleşen bir “System Design” çözümüdür.
Bir sonraki makalede sıfırdan bir KMP projesi nasıl oluşturulur konusunu anlatacağım. En kısa sürede Part2 kısmını sizlere ulaştıracağım.
