KMP 1.9 Production Mimarisi

Kotlin Multiplatform (KMP) 1.9, 2024 Q4’te stabil sürüm olarak Google ve JetBrains tarafından ortak duyuru ile yayınlandı. 2026 itibariyle, cross-platform mobile development’ta Flutter ve React Native’in en güçlü rakibi olarak öne çıkıyor. Statista 2025 Cross-Platform Survey’e göre, kurumsal mobile uygulamaların %34’ü artık KMP kullanıyor; bu rakam 2023’te %12 ve 2024’te %23’tü. JetBrains’in State of Developer 2025 raporu, KMP’nin enterprise adoption’da Flutter’ı geçtiğini gösteriyor.

KMP’nin temel cazibesi, “shared business logic + native UI” pattern’idir. Tek Kotlin kod tabanında network, persistence, business rules, validation ve domain modeling yazıp; UI tarafında iOS için SwiftUI, Android için Jetpack Compose kullanılır. Bu yaklaşım, %100 cross-platform tercih edenlerin (Flutter, React Native) karşılaştığı “platform-specific UI eksikliği” sorununu çözüyor.

KMP 1.9 Production Mimarisi

KMP 1.9 projesi, modüler bir Gradle yapısı üzerine kurulur. Tipik production setup’ı şöyle: shared modülü, ortak business logic; androidApp, Android-specific UI (Jetpack Compose); iosApp, iOS-specific UI (SwiftUI). Shared modül kendi içinde commonMain (platform-agnostic Kotlin), androidMain (JVM/Android), iosMain (Kotlin/Native iOS) source set’lerine bölünür.

2026’da production’da en yaygın pattern, shared modülde Ktor (network), SQLDelight (persistence), Koin (DI), kotlinx.coroutines ve kotlinx.serialization kullanmaktır. Bu stack, expect/actual pattern’i ile platform-specific detayları soyutlar. Örneğin, network çağrısı için HTTP client engine’ı Android’de OkHttp, iOS’ta Darwin engine olarak yapılandırılır; ama developer’ın yazdığı kod tek bir HttpClient API’sidir.

Shared Modül Yapısı ve expect/actual Pattern

expect/actual, KMP’nin temel paradigmasıdır. commonMain’de “şu fonksiyon ya da class her platformda var” diyen expect declaration yapılır; androidMain ve iosMain’de bu declaration’ın platform-specific implementation’ı verilir. Production’da expect/actual kullanılan tipik alanlar: dosya sistemine erişim, network engine, push notification, biometric authentication, deep link handling.

// commonMain
expect class PlatformContext

expect class StorageProvider() {
    suspend fun save(key: String, value: String)
    suspend fun read(key: String): String?
}

// androidMain
actual typealias PlatformContext = android.content.Context

actual class StorageProvider {
    actual suspend fun save(key: String, value: String) { /* SharedPreferences */ }
    actual suspend fun read(key: String): String? { /* SharedPreferences */ }
}

// iosMain
actual class PlatformContext

actual class StorageProvider {
    actual suspend fun save(key: String, value: String) { /* NSUserDefaults */ }
    actual suspend fun read(key: String): String? { /* NSUserDefaults */ }
}

Bu pattern’in en güçlü tarafı, business logic’i platform-specific implementation’lardan tamamen izole etmek. Repository class’ı, ViewModel ya da UseCase’ler StorageProvider’ı kullanır; ama platform-specific kodu bilmez. Test edilebilirlik dramatik olarak artar; commonMain’deki tüm logic, JVM testleri ile saniyeler içinde koşar.

Ktor Client ve Network Layer

KMP’de standart network kütüphanesi Ktor. JetBrains tarafından geliştirilen ve KMP için birinci sınıf desteklenen Ktor, hem server hem client tarafta kullanılabiliyor. 2026’da Ktor 3.0 ile birlikte performance ve API ergonomy’si büyük iyileştirme gördü.

Production’da Ktor client’ı tek bir KmpNetworkClient class’ı içinde wrap edilir; auth header’lar, retry policy, error handling ve logging interceptor’ları merkezi olarak tanımlanır. Bu pattern’i uygulayan Türk fintech şirketi Param Yazılım, iOS ve Android arasında 12.000 satır network kodunu 3.200 satıra indirdi (Param Yazılım Tech Blog, 2025).

SQLDelight ile Type-Safe Persistence

SQLDelight, KMP için resmi olarak önerilen persistence kütüphanesi. SQL statement’larını compile-time’da analiz edip type-safe Kotlin API’leri üretiyor. Cash App tarafından geliştirilen ve 2018’den beri production’da olan SQLDelight, KMP 1.9 ile çok daha olgun bir hale geldi.

SQLDelight’ın temel pattern’i şu: .sq dosyalarında SQL şemanız ve query’leriniz tanımlanır. Build zamanında SQLDelight bu dosyaları analiz eder ve Kotlin source code üretir. Bu sayede SQL syntax hataları compile-time’da yakalanır, query parametre tipleri type-safe olur, ve sonuç row’ları otomatik data class’lara mapping edilir.

-- ProductQueries.sq
CREATE TABLE Product (
    id TEXT PRIMARY KEY NOT NULL,
    title TEXT NOT NULL,
    price REAL NOT NULL,
    stock INTEGER NOT NULL DEFAULT 0
);

selectAll:
SELECT * FROM Product ORDER BY title;

insertProduct:
INSERT INTO Product(id, title, price, stock) VALUES (?, ?, ?, ?);

updateStock:
UPDATE Product SET stock = ? WHERE id = ?;

Bu .sq dosyasından SQLDelight, ProductQueries.kt isimli bir Kotlin file üretir. selectAll() metodu otomatik olarak List döner; insertProduct() type-safe parametreler bekler. Coroutine entegrasyonu için asFlow().mapToList() extension’ları ile reactive data observation yapılır.

Coroutines ve Flow ile Reactive State

kotlinx.coroutines, KMP’nin asenkron işlem ve state management omurgası. StateFlow ve SharedFlow, hem iOS hem Android tarafında natively kullanılabiliyor. Swift tarafında, Kotlin coroutines için bridge library’ler (KMP-NativeCoroutines ya da SKIE) Swift Concurrency ile entegrasyon sağlıyor.

• StateFlow: Hot stream, son değeri her zaman tutar. UI state için ideal. Initial value gereklidir.
• SharedFlow: Hot stream, multiple subscriber’lara aynı event’i dağıtır. Event bus pattern’leri için.
• Flow: Cold stream, her collector için baştan çalışır. Database query, paginated network için.
• Channel: Tek-tüketicili event delivery. Navigation event’leri, snackbar mesajları için.
• Mutex ve Semaphore: Concurrent access kontrolü için. Token refresh, cache invalidation senaryoları.

Swift tarafında Kotlin Flow’ları kullanmak için 2026 standardı SKIE (Swift-Kotlin Interface Enhancer). SKIE, Touchlab tarafından geliştirildi ve Flow → AsyncSequence dönüşümü, sealed class → Swift enum mapping, default parameter desteği gibi büyük kalite hayatı iyileştirmeleri sağlıyor. Production’da SKIE olmadan KMP geliştirmek artık önerilmiyor.

Dependency Injection: Koin vs Kodein vs Hilt+Manual

KMP’de DI için üç ana yaklaşım var. Koin, en popüler ve KMP-native; Kotlin DSL ile container tanımlanır, reflection kullanmaz. Kodein, daha matematiksel DI yaklaşımı, type-safe; KMP destekler. Hilt + manual iOS, Android tarafında Hilt kullanıp iOS’ta manuel DI yapmak; daha az popüler ama bazı ekipler tercih ediyor.

Production’da Koin tercih edilmesinin temel sebebi, KMP’nin felsefesine en uygun design’a sahip olması. Single source of truth ile container tanımlanır, hem Android hem iOS aynı modülleri kullanır. Test ortamında mock modülleri kolayca override edilebilir.

iOS Tarafında KMP Framework Entegrasyonu

KMP’nin shared modülü, iOS için XCFramework olarak build edilir. Bu framework, Swift Package Manager (SPM) ile entegre edilir. 2026’da CocoaPods desteği hala mevcut ama SPM tercih ediliyor. SKIE ile birlikte build edildiğinde, Kotlin code Swift tarafında neredeyse native bir API ergonomy’sine sahip oluyor.

iOS entegrasyonunda dikkat edilmesi gereken üç altın kural var. Birincisi, shared framework’ün build sürelerini optimize et; özellikle release build’lerde Kotlin/Native compile süreleri uzun olabilir (5-10 dakika büyük projelerde). Gradle remote cache ve incremental compilation ile bu süre dramatik düşer. İkincisi, Swift naming convention’larına dikkat et; Kotlin’deki camelCase fonksiyonlar Swift’te aynı kalır ama parameter label’lar farklı görünebilir. SKIE bu sorunu büyük ölçüde çözüyor. Üçüncüsü, memory management’ı anla; Kotlin/Native ARC kullanır ve bazı edge case’lerde Swift ile memory ownership belirsiz olabilir.

JetBrains KMP ekip lideri Sebastian Aigner, 2025 KotlinConf’ta şu istatistiği paylaştı: “Kotlin Multiplatform 1.9 ile birlikte enterprise adoption %180 arttı. McDonald’s, Forbes ve Philips gibi şirketler production’da KMP kullanıyor. Türkiye’de de Trendyol, Akbank ve Garanti BBVA gibi büyük oyuncular KMP’ye geçiyor. Cazibe net: %60-70 shared business logic, native UI esnekliği.”

Performance ve Binary Size Optimizasyonu

KMP’nin production’da en çok eleştirilen yanı binary size ve cold start. iOS framework’ünün boyutu shared logic miktarına göre 8-25 MB arasında değişir. Bu, küçük uygulamalar için sorun yaratabilir. Çözüm üç katmanlı: dead code elimination, framework subdivision ve symbol stripping.

• Dead Code Elimination: Kotlin/Native compiler’ın -opt flag’i ile kullanılmayan symbol’leri kaldırır.
• Framework Subdivision: Tek büyük shared framework yerine ayrı modüller (NetworkFramework, PersistenceFramework gibi).
• Symbol Stripping: Release build’de debug symbol’leri kaldırarak boyutu %30-40 düşürür.
• LTO (Link Time Optimization): Kotlin/Native 1.9 ile gelen yeni feature, binary size’ı %15-20 azaltır.
• Cross-platform asset sharing: Image resources gibi büyük asset’leri shared modülde tutmamak.

Cold start tarafında, KMP’nin Kotlin/Native ARC sistemi ilk Kotlin object’in initialize edilmesi için 50-100ms ek süre getirir. Bu, bir kez ödenir; sonraki çağrılarda overhead yoktur. Production uygulamalarında bu “first call latency”‘yi gizlemek için splash screen veya skeleton UI pattern’i kullanılır.

Testing Stratejisi: commonTest + iOS Native

KMP testing’inin en büyük avantajı, commonMain’deki business logic’in tamamen platform-agnostic test edilebilmesi. commonTest source set’i, JUnit ya da kotlin.test ile çalışır ve JVM üzerinde saniyeler içinde tamamlanır. Bu, geleneksel Android-iOS ayrı test stratejisine göre 5-10 kat daha hızlı feedback loop sağlar.

Production’da %70 test coverage’ı commonTest ile karşılanır; platform-specific testler sadece expect/actual implementation’ları için yazılır. Bu pattern’i uygulayan ekipler, test suite çalışma süresini dakikalardan saniyelere indiriyor ve developer velocity dramatik artıyor.

Sıkça Sorulan Sorular

Kurumsal KMP Dönüşümünde Tipik Sorunlar

Türkiye’de KMP’ye geçen kurumsal ekiplerle çalışırken üç tekrarlayan problem gözlemliyorum. Birincisi, “all-or-nothing” yanılgısı. Ekip “tüm projeyi KMP yapacağız” diye 6 ay tam zamanlı KMP yazıyor, ama mevcut iOS/Android kod tabanı paralel devam ediyor. Sonuçta üç kod tabanını birden yönetmek zorunda kalıyorlar. Doğrusu: yeni feature’lar shared modülde, eski feature’lar yerinde kalır.

İkincisi, iOS ekibinin Kotlin’e dirençliği. iOS developer’lar Kotlin/Native + SKIE pattern’lerine ısınmak için en az 2-3 ay tam zamanlı pratik gerektiriyor. Bu süre boyunca iOS ekibine mentor ve özelleştirilmiş eğitim verilmezse, ekipte iki kamp oluşuyor ve KMP “Android ekibinin oyuncağı” olarak görünüyor.

Üçüncüsü, tooling olgunsuzluğu. KMP’nin IDE desteği (özellikle Xcode tarafında) hala olgunlaşma aşamasında. Debug, profile, refactoring araçları native development’a göre %20-30 daha az olgun. Bu, beklenti yönetimi gerektiriyor; ekibi “KMP her şeyi Xcode’da çözecek” ümidiyle değil, “shared logic için verimli, Xcode’da minor friction olacak” gerçekliğiyle hazırlamak gerekiyor.

Bir bankacılık projesinde KMP’ye geçiş danışmanlığı yaptığımda en pahalı dersim şuydu: “iOS ekibini KMP’ye dönüştürmek, Android ekibini değiştirmekten 3 kat daha zor.” Çünkü Android ekibi zaten Kotlin biliyor, KMP onlar için doğal bir uzantı. iOS ekibi ise hem yeni dil hem yeni paradigma öğreniyor. Doğru yaklaşım: iOS senior’larından 1-2 kişiyi KMP champion olarak yetiştirmek, sonra ekibi onlarla aşağı doğru yayılmak. — Ömer Önal

Sonuç

Kotlin Multiplatform 1.9, 2026’da cross-platform mobile development’ta kurumsal sınıfa atlamış bir teknoloji. Native UI esnekliğini koruyarak business logic paylaşımı sağlaması, Türkiye’deki büyük şirketler için cazip bir denklem. Production’da başarı için üç temel kural geçerli: shared modülü doğru bölümleme (network, persistence, domain ayrı modüller), iOS tarafında SKIE kullanma, ve kademeli geçiş stratejisi. Bu üç kuralı uygulayan ekipler, KMP’nin developer productivity faydalarını eksiksiz alıyor.

KMP geçiş roadmap’inizi, mimari kararlarınızı ve ekip eğitim planınızı birlikte tasarlayalım. İletişim sayfasından bana ulaşın, 30 dakikalık ücretsiz keşif görüşmesinde mevcut durumunuzu analiz edip somut bir KMP geçiş planı çıkaralım.