Compose Multiplatform (CMP) 1.7, JetBrains’in cross-platform native UI çözümü olarak 2025’te iOS stable desteği ile birlikte production-ready hale geldi. 2026 itibariyle, KMP ekosisteminin tamamlayıcı parçası olarak hem Android, iOS, desktop (Windows/macOS/Linux), hem de web (WASM tabanlı) tek bir Kotlin kod tabanından deploy edilebiliyor. JetBrains’in 2025 State of CMP raporuna göre, KMP kullanan kurumsal ekiplerin %38’i artık UI tarafında da CMP’ye yöneliyor; bu oran 2024’te sadece %14’tü. Konuyla ilişkili olarak Jetpack Compose Multiplatform 2026: Android ve iOS Rehber rehberimiz detaylı incelemeyi içerir.
CMP’nin temel cazibesi, “tek Compose kod tabanı, tüm platformlar” pattern’idir. Jetpack Compose ile yazılan kodun %85-95’i CMP’ye taşınabiliyor. Ancak production seviyesinde CMP kullanımı, platform-specific UI patterns’a saygı gösterme dengesi, performans optimizasyonu ve native interop konularında ciddi tasarım kararları gerektiriyor. Konuyla ilişkili olarak Swift on Server 2026: Vapor & Hummingbird Karar Rehberi rehberimiz detaylı incelemeyi içerir.

Compose Multiplatform 1.7 Production Mimarisi
CMP projesi, Gradle Kotlin Multiplatform yapısının üzerine ekleniyor. Tipik production setup’ı şöyle: composeApp modülü, ortak Compose UI; androidApp, Android Application wrapper; iosApp, iOS Application wrapper; desktopApp, JVM desktop wrapper; webApp, WASM web wrapper. composeApp kendi içinde commonMain (paylaşılan UI), platform-specific source set’lere bölünüyor.
2026’da production’da CMP ile en yaygın pattern, “single source UI + platform-aware components” yaklaşımıdır. UI logic’in %80’i commonMain’de yazılır; navigation, theming, layout. %20’lik kısım ise platform-aware tasarım kararlarına ayrılır: iOS’ta swipe-back gesture, Android’de Material 3 navigation rail, desktop’ta keyboard shortcuts. Bu pattern, native UI kalitesini koruyarak code reuse sağlar.
Cross-Platform Compose API ve Multiplatform Resources
CMP 1.7’nin getirdiği en önemli yenilik compose-multiplatform-resources kütüphanesi. Önceki sürümlerde Android, iOS ve desktop için ayrı resource yönetimi gerekirken, 2026’da tek bir Res object’i üzerinden tüm platformlarda image, font, string ve raw file’lara erişim sağlanıyor.
// composeApp/src/commonMain/composeResources/
// ├── drawable/
// ├── drawable-tr/ (Türkçe localized images)
// ├── values/strings.xml
// ├── values-tr/strings.xml
// └── font/
@Composable
fun WelcomeScreen() {
Image(
painter = painterResource(Res.drawable.welcome_hero),
contentDescription = stringResource(Res.string.welcome_title)
)
Text(
text = stringResource(Res.string.welcome_subtitle),
fontFamily = FontFamily(Font(Res.font.inter_regular))
)
}
Resource sistemi, build sırasında her platform için optimum format’a derlenir. Android için XML, iOS için Bundle, desktop için ClassLoader resource, web için fetch-able asset olarak. Localization, RTL desteği ve density-specific image’lar da otomatik olarak yönetilir.
Navigation: Decompose vs Voyager vs Jetpack Navigation
CMP’de navigation için üç ana yaklaşım var. Decompose, JetBrains tarafından önerilen, KMP-first ve component-based; lifecycle management dahil. Voyager, daha sade ve “annotation-free” yaklaşım; küçük-orta projeler için popüler. Jetpack Navigation Compose, 2026 itibariyle CMP’ye port edildi ama hala “experimental” durumda.
| Kriter | Decompose | Voyager | JP Navigation Compose |
|---|---|---|---|
| KMP Desteği | Birinci sınıf | Birinci sınıf | Experimental |
| Lifecycle Management | Dahili | Dahili | Compose-only |
| Deep Link Support | Native | Plugin | Var |
| Type-Safe Routes | Sealed classes | Generic params | kotlinx.serialization |
| Learning Curve | Yüksek | Düşük | Android dev’ler için kolay |
| Enterprise Adoption | %48 | %32 | %14 |
Decompose, kurumsal CMP projelerinin çoğunluğunda tercih ediliyor; çünkü lifecycle management’ı (Android’in Lifecycle’ı, iOS’un viewWillAppear/viewWillDisappear’ı) abstract eden tek araç. Voyager ise daha hızlı başlangıç sağlıyor ama büyük projelerde lifecycle eksikliği problem yaratabiliyor.
Platform-Specific UI Adaptation
Production’da en kritik tasarım kararı, “tek UI mi, platform-aware UI mi” sorusudur. CMP’nin gücü tek UI yazma yeteneğinde ama Apple kullanıcılarının iOS-native deneyim beklentisi bu yaklaşımı tehlikeli yapıyor. Çözüm, platform-aware composable’lar yazmak: aynı logical component, platform’a göre farklı görünür.
// commonMain
expect fun platformName(): String
@Composable
fun PlatformAwareSwitch(checked: Boolean, onCheckedChange: (Boolean) -> Unit) {
when (platformName()) {
"iOS" -> CupertinoSwitch(checked, onCheckedChange) // iOS-style toggle
else -> Switch(checked, onCheckedChange) // Material 3
}
}
@Composable
fun BackButton(onClick: () -> Unit) {
when (platformName()) {
"iOS" -> CupertinoBackButton(onClick) // "< Back" text + arrow
else -> IconButton(onClick) { Icon(Icons.Default.ArrowBack, "Back") }
}
}
Bu pattern, "Cupertino" tarzı component library oluşturmayı gerektirir; iOS-style switch, navigation bar, action sheet, alert dialog vs. Compose Cupertino projesi (open source) bu library'yi sağlıyor ve 2026'da production-ready durumda. Türkiye'de Yemeksepeti'nin CMP-based "tablet menu" uygulaması bu pattern'i kullanıyor.

iOS Tarafında Performance ve Skia Backend
CMP'nin iOS implementasyonu, Skia graphics library'si üzerine kurulu. Bu, Flutter'ın da kullandığı pattern; UIKit/SwiftUI'ı bypass edip kendi rendering engine'ini kullanmak. Avantajı: Android ve iOS arasında piksel-perfect tutarlılık. Dezavantajı: native iOS scrolling fizik kuralları ve gesture handling tam olarak replike edilemiyor.
2026 itibariyle CMP iOS performansı şu durumda: basit ekranlarda native SwiftUI'a yakın (60 FPS sabit). Karmaşık liste ekranlarında SwiftUI'nın %15-20 gerisinde; özellikle 1000+ item'lı LazyColumn'larda. Cold start, native iOS uygulamasından 300-500ms daha uzun, çünkü Kotlin/Native runtime initialize olması gerekiyor.
- UIKit Bridging: CMP içinde UIViewController kullanmak için UIKitView composable'ı kullanılır.
- Native gesture handling: iOS swipe-back gesture'ı için custom gesture detector yazılmalı.
- Memory pressure: CMP iOS uygulamaları, native SwiftUI'a göre %20-30 daha fazla memory tüketir.
- Hot reload: iOS tarafında Compose UI hot reload destekleniyor (1.7'de stable).
- Splash screen: Native iOS splash screen, CMP Compose UI başlamadan önce gösterilir.
Production'da iOS performans optimizasyonu için en kritik araç, Xcode Instruments + CMP profiling. CMP 1.7 ile gelen "Recomposition Inspector" iOS tarafında da çalışıyor ve hangi composable'ın gereksiz yere render olduğunu gösteriyor.
Desktop Deployment: JVM vs Native
CMP desktop tarafında iki seçenek sunuyor. JVM-based desktop, Compose UI'ı JVM üzerinde çalıştırır; uygulama bir .jar ya da packaged binary olarak deploy edilir. Native desktop (Kotlin/Native), JVM olmadan direkt native binary üretir; daha küçük binary, daha hızlı start ama daha kısıtlı.
2026'da production desktop CMP uygulamalarının çoğu JVM-based. Reason: JVM ekosisteminin tooling, debugging ve library zenginliği avantajı. Native desktop ise CLI tool'lar ve küçük utility uygulamaları için tercih ediliyor. JetBrains'in TeamCity ve YouTrack masaüstü clientları CMP JVM-based ile yapıldı.
Web Deployment: WASM ve JavaScript Backend
CMP'nin web desteği, 2025 sonunda WebAssembly (WASM) tabanlı olarak stabil sürüm aldı. Önceki JavaScript backend'ı deprecated; yeni projeler WASM kullanıyor. WASM backend'i çok daha performanslı ve bundle size optimization'da çok daha iyi.
| Özellik | WASM Backend | JS Backend (deprecated) | Native Mobile |
|---|---|---|---|
| Bundle Size | 2-4 MB initial | 5-8 MB | 15-25 MB |
| Cold Start | 800ms | 1.500ms | 1.200ms |
| Frame Rate | 60 FPS | 45-55 FPS | 60 FPS |
| SEO Friendly | SSR gerektirir | Aynı | N/A |
| Production Ready | Stable (1.7) | Deprecated | Stable |
CMP web'in en büyük dezavantajı SEO. WASM-based SPA'lar, server-side rendering olmadan arama motorları için ciddi sorun yaratır. Bu yüzden CMP web çoğunlukla "authenticated dashboard" ya da "internal tool" senaryolarında kullanılıyor; public-facing içerik siteleri için Next.js/Astro gibi web-native framework'ler tercih ediliyor.
State Management ve Reactive Architecture
CMP'de state management, KMP'nin standart Coroutines/Flow pattern'i üzerine inşa edilir. ViewModel benzeri component'ler için Decompose component lifecycle'ı, Voyager'ın Screen state holder'ı ya da raw Kotlin class'lar kullanılır. MVI (Model-View-Intent) pattern'i CMP topluluğunda en popüler yaklaşım.
JetBrains CMP ekip lideri Sebastian Aigner, 2025 KotlinConf'ta şu vurguyu yapmıştı: "Compose Multiplatform, 'iOS native UI alternatifi' olarak değil, 'cross-platform business UI çözümü' olarak konumlanıyor. Yani bankanızın çekirdek uygulaması için değil, ama dahili admin paneliniz, ekibinizin productivity tool'u, ya da B2B müşteri portal'ınız için ideal."
Theming ve Material 3 Expressive
CMP 1.7, Material 3 Expressive (2025'te Google tarafından duyuruldu) tam desteği getirdi. Bu, dynamic color, motion, ve adaptive layout sistemini cross-platform getiriyor. iOS tarafında "Material 3 vermek istemiyorum, iOS-native görünmeli" diyenler için Cupertino theme paketi mevcut.
- Material 3 Theme: Default seçenek; Android-native görünüm. iOS'ta da kullanılabilir ama "yabancı" hissi yaratabilir.
- Cupertino Theme: iOS-style. Compose Cupertino library üzerinden.
- Custom Theme: Brand-specific theme. Genelde tercih edilen, marka kimliği önemliyse.
- Dynamic Color (Material You): Android 12+ wallpaper-based color extraction. iOS'ta destek yok.
- Adaptive Theming: Light/dark mode + platform-aware. CMP'nin önerdiği pattern.
Native Interop: UIViewController, AppKit, JavaScript
CMP'nin gerçek gücü, platform-specific native code'a erişim. iOS'ta UIViewController/UIView'ları Compose içinde göstermek için UIKitView composable'ı; macOS'ta AppKit NSView'ları için MacAppKitView; web'de JavaScript interop için kotlinx.browser API'leri kullanılır.
Production'da en yaygın native interop senaryosu: harita gösterimi. Google Maps SDK ya da MapKit native bir UIView/UIViewController olduğu için CMP içinde UIKitView ile wrap edilir. Camera, biometric authentication, native sharing dialogs gibi sistem-seviye feature'lar da aynı pattern ile entegre edilir.

Testing: composeTest ve Cross-Platform UI Test
CMP testing, Jetpack Compose'un testing API'sini cross-platform yapılandırıyor. runComposeUiTest, hem Android hem iOS hem desktop'ta aynı test code'unu çalıştırabilir. Bu, "tek test yaz, tüm platformlarda doğrula" pattern'ini mümkün kılar.
| Test Türü | Source Set | Platformlar | Hız | Use Case |
|---|---|---|---|---|
| Compose UI Test | commonTest | Android, iOS, Desktop | Orta | Composable behavior |
| Screenshot Test | commonTest | Android, iOS, Desktop | Yavaş | Visual regression |
| Business Logic | commonTest (KMP) | JVM | Çok hızlı | State holders, repository |
| E2E | Platform-specific | Real device | Çok yavaş | Critical paths |
Pratikte production'da %75 test coverage'ı commonTest ile karşılanır; sadece platform-specific native interop kodu için ayrı testler yazılır. Bu pattern, geleneksel "Android + iOS ayrı test" yaklaşımına göre test yazma süresini %60 azaltır.
Sıkça Sorulan Sorular
CMP, Flutter'a göre ne zaman tercih edilmeli?
Mevcut Kotlin ekibiniz varsa CMP avantajlı; Dart öğrenmeye gerek yok. Native Android performansı kritikse CMP daha iyi; Flutter Engine layer overhead'i CMP'de yok. iOS native deneyim önemliyse Flutter ve CMP benzer; ikisi de tam native değil. Web desteği gerekiyorsa Flutter daha olgun (2026'da hala).
CMP iOS production-ready mi?
"Stable" kategorisinde ama "production-ready"'nin tanımı projeye göre değişir. B2B uygulamalar, internal tool'lar, dashboard'lar için tamamen hazır. Tüketici-yönlü, App Store top 100 hedefleyen uygulamalar için Apple Human Interface Guidelines uyumu konusunda native SwiftUI hala daha iyi.
CMP ile Jetpack Compose kod paylaşımı oranı ne?
Pure Compose UI code'unun %85-95'i CMP'ye taşınabilir. Android-specific API kullanan kod (Context, Resources, Intent vs.) commonMain'e taşınamaz; expect/actual pattern'i gerekir. Pratikte, yeni CMP projeleri başlangıçtan commonMain'i hedeflerken, mevcut Compose projeleri kademeli olarak %70-80 paylaşım oranına ulaşır.
CMP'de hot reload destekleniyor mu?
Evet, 1.7 ile tüm platformlarda. Android Studio ile Android için, IntelliJ ile desktop için, Xcode ile iOS için (Kotlin Multiplatform Mobile plugin gerekli) çalışıyor. Web tarafında WASM hot reload destekleniyor. Hot reload süresi 2-5 saniye arası.
CMP binary size mobile'da ne kadar artırır?
Android için 5-8 MB ek (Compose runtime dahil). iOS için 12-18 MB ek (Skia + Kotlin/Native runtime). Desktop için 30-50 MB (JVM + Compose). Web için 2-4 MB initial bundle. Mobile'da bu artışlar Trendyol/Hepsiburada ölçeğinde önemsiz, küçük uygulamalarda dikkat edilmeli.
Kurumsal CMP Dönüşümünde Tipik Sorunlar
CMP'ye geçen kurumsal ekiplerle çalışırken üç ana problem gözlemliyorum. Birincisi, iOS-native UX beklentisi mismatch'i. Compose ile yazılan iOS uygulaması, ne kadar polishlenirse polishlensin, SwiftUI ile yazılana göre subtle bir "farklı" hissi verir. Apple kullanıcılarının fark ettiği bu ayrıntılar uzun vadede uygulama puanı düşüşüne yol açabilir. Çözüm: ya bu farkı kabul edip B2B'ye odaklan, ya da Cupertino theme'i agresif şekilde uygula.
İkincisi, build pipeline karmaşıklığı. CMP projesi 4-5 farklı output (Android APK, iOS framework, desktop bundle, web WASM) üretir. CI/CD pipeline'ında her output için ayrı stage gerekir ve build süreleri uzar. Çözüm: paralel build matrix, remote cache (Gradle ve Kotlin/Native), ve "build only if changed" optimization.
Üçüncüsü, ekibin Compose öğrenme eğrisi. iOS ekibi Compose öğrenmek için 3-4 ay tam zamanlı pratik gerektiriyor. UIKit/SwiftUI deneyimi olan developer'lar, Compose'un imperative değil declarative paradigmasına alışana kadar verimsiz oluyor. Çözüm: 1-2 Compose champion yetiştirip ekibe mentor olarak ayırmak.
Bir fintech projesinde CMP geçişi danışmanlığında yaşadığımız ders şuydu: "Cross-platform native UI" iddiası abartılı bir vaat. Compose ile yazılan iOS uygulaması teknik olarak çalışıyor, ama "iOS-native hissi" sadece UI rendering değil; haptic feedback, scroll fiziği, gesture priority, transition timing gibi yüzlerce küçük detay. CMP bunların %85'ini yakalıyor, ama son %15'i yakalamak için SwiftUI gerekiyor. Karar verirken bu %15'in iş hedeflerinizde ne kadar önemli olduğunu net olarak belirleyin. — Ömer Önal
Sonuç
Compose Multiplatform 1.7, 2026'da cross-platform native UI alanında en güçlü Flutter alternatifi. Kotlin Multiplatform'un üzerine inşa edilmesi, mevcut Android ekipleri için doğal bir geçiş yolu sunuyor. Production'da başarı için üç temel kural geçerli: platform-aware UI patterns'ı uygula (özellikle iOS'ta Cupertino theme), build pipeline'ını paralel ve cache-aware tasarla, ve ekibin Compose öğrenme eğrisini ciddiye al. Bu üç kuralı uygulayan ekipler CMP'nin code reuse faydalarını eksiksiz alıyor.
CMP 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 geçiş planı çıkaralım.










Ömer ÖNAL
Mayıs 23, 2026Mobil uygulama projelerinde gözlemlediğim: cross-platform vs native kararı genelde ekibin yetkinliğine göre veriliyor ama doğru kriter ürünün UX-kritik özellikleri olmalı. Platform-spesifik API kullanım oranı %70 üzerinde ise native, altında ise cross-platform daha sürdürülebilir. Yorumlarınız?