Kaynak dil ve mevcut ekip becerisi
Bu kriter en belirleyici olanı, çünkü diğer her şey buna bağlı şekilleniyor.
Skip'i seçtiğinde, tek satır Kotlin yazmadan gidebilirsin. Skip'in resmî tanımına göre amaç "native SwiftUI apps for iOS and Android" üretmek — SwiftUI view hiyerarşini ve Swift'in tip sistemini kullanmaya devam edersin. iOS tarafındaki proje, Skip olmayan bir iOS-only ekibin üreteceğiyle aynı Xcode projesi; Skip'in kendi dokümantasyonunun ifadesiyle Swift "ek çalışma zamanı, yorumlayıcı ve iOS'ta çöp toplayıcı olmadan" derleniyor, SwiftUI Apple platformlarında olduğu gibi çalışıyor.
Kotlin Multiplatform'da tersi işliyor: Kotlin öğreniyorsun, paylaşılan mantığı Kotlin'de yazıyorsun. Bu, Android tarafında daha "yerli" bir konum sağlıyor — Kotlin zaten Android'in birinci sınıf dili ve IntelliJ IDEA/Android Studio'da tam destek görüyor.
Pratik sonuç: ekibinde güçlü Swift bilgisi var ve Kotlin öğrenmeye isteğin yoksa Skip bir kısayol. Android tarafında da güçlü mühendislik olacaksa Kotlin'i er ya da geç öğrenmen gerekecek — bu durumda KMP daha uzun vadeli yatırım.
Android tarafında üretilen UI: gerçek Compose mu, taklit mi?
Bu, insanların en çok yanıldığı kriter — çünkü her iki taraf da "native Compose UI" iddiasında.
Skip, 4 Haziran 2026 tarihli blog yazısında bunu netleştiriyor: "There is no parallel widget hierarchy or custom renderer... The Compose tree is the Android UI." Yani senin SwiftUI view'ların, derleme zamanında gerçek Jetpack Compose çağrılarına dönüşüyor. Bu iddia, aynı hafta Google I/O 2026'da Android UI'ın "Compose First" konumlandırmasıyla da örtüşüyor.
Kotlin Multiplatform + Compose Multiplatform tarafında da Android'de gerçek Compose kullanılıyor — bu konuda ayrım yok. Fark iOS tarafında ortaya çıkıyor: Compose Multiplatform iOS'ta kendi render motorunu (Skia tabanlı) kullanıyor, yani sistem widget'ları değil çizilen bir arayüz söz konusu.
Pratik sonuç: Android'de "gerçek native görünüm" ekseninde ikisi de gerçek Compose üretiyor. Asıl fark iOS tarafında: Skip gerçek SwiftUI/UIKit kullanırken, Compose Multiplatform kendi çizim motoruna geçiyor.
Resmî destek ve uzun vadeli dayanıklılık
Bu kriterde iki taraf da 2026'da güçlü bir "resmiyet" kartı oynuyor, ama farklı ölçeklerde.
Swift Android SDK'nın resmiyeti taze: Swift 6.3, 24 Mart 2026'da bunu Static Linux/WebAssembly SDK'larıyla aynı statüde duyurdu. Ama Swift-on-Android 2026'da doğmadı — Swift.org'un Aralık 2025 tarihli yazısına göre resmî SDK öncesinde de Spark, flowkey, MediQuo gibi uygulamalar "millions of times" indirilen ölçekte production'daydı, homegrown interop katmanlarıyla.
Kotlin Multiplatform'un dayanıklılığı farklı bir kanıta dayanıyor: süre ve ölçek. Kotlin 13 Şubat 2012'de doğdu, Apache 2.0 lisanslı ve düzenli bir kadansla gelişiyor (güncel tooling sürümü 2.4.20, 7 Eylül 2026). JetBrains'in vaka çalışmaları sayfası Duolingo, Google, McDonald's, Netflix, Forbes, Philips gibi isimli referansları, kendi sözleriyle anlatılmış sonuçlarla listeliyor. Skip'in de resmî bir galerisi var — 24 uygulama, aralarında Polymarket, ServiceM8, MediQuo ve Naturitas — ama bu sayfalar ölçek/sonuç metriği yayımlamıyor.
Pratik sonuç: "resmî statü" ekseninde ikisi de güçlü; "kanıtlanmış üretim geçmişi" ekseninde KMP belirgin biçimde önde.
Lisans ve maliyet: eksen nötrleşti
Bu kriter 2026 öncesinde Skip'in aleyhine en büyük fark yaratan eksendi — artık öyle değil.
21 Ocak 2026'ya kadar Skip paralı bir abonelik ve lisans anahtarı gerektiriyordu. O gün bu tamamen değişti: Skip'in kendi duyurusuna göre "As of Skip 1.7, all licensing requirements have been removed. No license keys, no... trial or evaluation period." Skipstone motoru da aynı gün açık kaynak yapıldı, proje skip.tools'tan skip.dev'e taşındı. GitHub API'de doğrulanan lisans mpl-2.0.
Skip'in gerekçesi de dikkat çekici: "Even if the core team disappeared, the community could continue supporting the technology." — küçük bir şirkete bağımlılık riskini hedef alan bir konumlandırma.
Kotlin Multiplatform'da bu eksende değişim yok — Kotlin başından beri Apache 2.0 ile ücretsiz.
Pratik sonuç: 2026 öncesi "Skip paralı, KMP ücretsiz" diye düşünüyorsan artık geçerli değil — ikisi de tamamen ücretsiz. Asıl fark artık maliyette değil, olgunluk ve ölçekte.
Fuse mı, Lite mi? Skip'in içindeki karar
Skip'i değerlendirirken sık yapılan bir hata var: Skip'i tek bir teknoloji sanmak. Aslında iki ayrı çalışma modu var.
**Skip Fuse**, Swift 6.3'ün resmî Android SDK'sını kullanan native yol. Swift kodun doğrudan native makine koduna derleniyor, ek yorumlayıcı ya da çöp toplayıcı yok. Bu yol daha genç — resmiyeti Mart 2026'dan bu yana var — ve debugger/sourcekit-lsp entegrasyonu Swift.org'un Aralık 2025 yazısına göre "yüksek öncelikli ama eksik".
**Skip Lite** ise daha eski ve olgun: Swift kaynağını derleme zamanında Kotlin'e dönüştürüyor, mevcut Kotlin/Java kütüphaneleriyle interop sağlıyor. Dezavantajı: Skip'in dokümantasyonuna göre "bazı dil özellikleri (generic pattern'ler, operator overload'lar) Kotlin'e eşlenemez".
Bu iki mod proje içinde modül bazında karışık kullanılabilir. Kotlin Multiplatform'da böyle bir ayrım yok — paylaşılan kod her platformda aynı mekanizmayla derleniyor.
Pratik sonuç: Skip'i seçiyorsan "hangi modda?" sorusunu proje başında netleştirmelisin — Kotlin/Java erişimi önemliyse Lite, tam Swift desteği önemliyse Fuse.
Kademeli eklenebilirlik ve mevcut projeye entegrasyon
Sıfırdan yazmak zorunda kalmadan mevcut bir iOS uygulamasına Android desteği eklemek istiyorsan, bu kriter seni doğrudan ilgilendiriyor.
Skip'in dokümantasyonu bu senaryoyu doğrudan destekliyor: "Use Skip for bits of shared logic and UI, for your entire app, or anything in between." Önerilen yol: ortak iş mantığını ayrı bir Swift paketine çıkarıp "separate apps" modeliyle hem mevcut iOS projesine hem yeni Android projesine bağlamak. Kurulum akışı hafif: brew install skip → skip checkup → skip create.
Kotlin Multiplatform da bu modelle biliniyor — expect/actual mekanizmasıyla platforma özel kodu ayırıp geri kalanı paylaşmak, KMP'nin temel tasarım felsefesi. Bu model sektörde iyi belgelenmiş ve Duolingo gibi vakalarda uygulanmış.
Pratik sonuç: ikisi de "büyük patlama" gerektirmiyor. Skip'in avantajı Swift'te kalmana izin vermesi; KMP'nin avantajı bu modelin çok daha uzun süredir test edilmiş olması.
Ekosistem, kütüphaneler ve build gerçekleri
Son kriter grubu, günlük geliştirme deneyimini doğrudan belirliyor.
Skip'in entegrasyon modülleri Release Notes sayfasında görülebiliyor ve aktif: ana skip paketi 1.9.11, skipstone motoru 1.9.11, skip-sentry 0.1.2 (Eylül 2026) — sık, granüler sürümler. Ama build/debug süresi için resmî bir benchmark bulunamadı. Bilinen somut maliyet: Skip'in minimal "HelloSkip" örneğinin Android APK'sı yaklaşık 80 MB.
Skip'in kütüphane erişimi yalnız kendi modülleriyle sınırlı değil: Fuse modu için dokümantasyon aynen "Thousands of Swift packages already compile for Android" diyor ve Swift Package Index'in Android filtresine bağlanıyor — bu paketleri Skip modülüne çevirmeden doğrudan kullanabiliyorsun. Lite modunda ise transpile edilmiş üçüncü parti kütüphane sayısı gerçekten az.
Kotlin Multiplatform'un kütüphane ekosistemi klibs.io üzerinden kataloglanan çok daha geniş bir havuza dayanıyor — Kotlin'in JVM/Android kökeni sayesinde mevcut Java/Kotlin kütüphanelerine doğrudan erişim mümkün. IntelliJ IDEA ve Android Studio'da tam IDE desteği de günlük sürtünmeyi azaltıyor.
Skip tarafında bir başka tuzak: GitHub issue #635'e göre, USB debugging açık bir cihazda store-kurulu bir Skip uygulamasının üzerine dev build kurmak imza uyuşmazlığıyla başarısız oluyor.
Pratik sonuç: kütüphane erişimi ve IDE olgunluğunda KMP önde; Skip'in build tarafında bilinen somut maliyetleri var.