Kotlin 2.4.0: Context Parameters ve Swift Paket Desteği

Kotlin 2.4.0, 3 Haziran 2026'da yayınlandı ve dilin son iki sürümde deneysel kalan iki özelliğini — context parameters ve explicit backing fields — Stable'a taşıdı. JVM tarafında Java 26 bytecode desteği geldi, Kotlin Multiplatform tarafında ise Gradle üzerinden doğrudan Swift Package bağımlılığı tanımlamak artık mümkün. Bu yazıda context parameters'ın deneysel halinden ne değiştiğini, gerçek kod desenlerini ve KMP projelerinde Swift paketi bağımlılığını Gradle'a nasıl bağlayacağını satır satır göreceksin.

💡 Pro Tip: Context parameters'a geçerken önce yalnız "gerçekten her çağrıda elle taşıdığın, nadiren değişen" bağımlılıkları (logger, UserService gibi) context parametreye taşı — sık değişen state'i context parametreye koymak kodu okunaksızlaştırır.

İçindekiler

• 2.1'den 2.4'e Kotlin özeti
• Context parameters stable: deneysel halinden farkları
• Gerçek kullanım desenleri (DI, logging, scope)
• Java 26 desteği ve toolchain
• KMP: Swift paketlerini bağımlılık olarak kullanmak
• Swift export'un bugünkü durumu
• UUID API ve explicit backing fields
• Yükseltme kontrol listesi (Gradle 9.5.0)
• SSS
• Kotlin 2.4.0'da neler yeni?
• Context parameters nedir, context receivers'tan farkı ne?
• Kotlin Multiplatform'da Swift paketi bağımlılık olarak nasıl eklenir?
• Kotlin 2.4 için hangi Gradle sürümü gerekli?
• Explicit context argument nedir, neden hâlâ deneysel?
• UUID API'si nasıl kullanılır?
• Explicit backing fields ne işe yarıyor?
• Swift export ile SwiftPM bağımlılığı arasındaki fark ne?
• Sonuç
• Kaynaklar

2.1'den 2.4'e Kotlin özeti

Kotlin 2.4.0, resmi duyuruya göre dil düzeyinde context parameters ve explicit backing fields'ı Stable yapan, JVM'de Java 26 desteği getiren, Native tarafında Swift paketi bağımlılığı ve Swift export'u Alpha'ya taşıyan bir dil sürümü. releases.html sayfasına göre sürümün yayın tarihi 3 Haziran 2026.

Kotlin 2.2.0 ve 2.3.0'da Experimental olarak tanıtılan context parameters, @all meta-target, annotation use-site default'ları ve explicit backing fields — bu dört özellik de 2.4.0 ile birlikte Stable durumuna geçti. Yani iki sürüm boyunca -Xcontext-parameters gibi opt-in bayraklarla denediğin bu özellikleri artık ek bayrak olmadan production kodunda kullanabilirsin.

Aynı sürümde standart kütüphanede kotlin.uuid.Uuid API'si de Stable oldu; bunu ayrı bir bölümde ele alacağız.

Bu yazıyı daha önce Kotlin 2.1: K2 Compiler ve Context Parameters yazımızı okuduysan, context parameters'ın deneysel halini zaten biliyorsun demektir — 2.4.0'daki asıl haber, o deneysel API'nin artık -X bayrağı gerektirmeden production kodunda kullanılabilir olması. Ne var ki 2.1 döneminde denediğin context receivers'tı: resmi dokümana göre context parameters o eski deneysel özelliğin yerini alıyor ve üyelere örtük receiver yerine parametre adıyla erişiyorsun. Kotlin 2.2.0'da gelen bu isimli söz dizimi 2.4.0'a kadar değişmedi; değişen, derleyicinin onu varsayılan kabul etmesi. Bir kütüphane yazıyorsan bu ayrım önemli: deneysel bir API'yi public API yüzeyine koymak (breaking change riski) ile Stable bir API'yi koymak arasında büyük fark var.

Context parameters stable: deneysel halinden farkları

Stable olan kısım, context parameter tanımı ve çağrı yerindeki örtük çözümleme. Stable OLMAYAN, yani hâlâ deneysel kalan kısım ise context argümanlarını çağrı yerinde açıkça geçirme (-Xexplicit-context-arguments bayrağı ile) ve context parametreli callable reference desteği.

Bu ayrımı net tutmak önemli: "context parameters stable oldu" demek, her context-ilişkili özelliğin stable olduğu anlamına gelmiyor. Kısıtlar da hâlâ geçerli:

• Constructor'lar context parameter tanımlayamaz.
• Context parametreli property'ler backing field, initializer veya delegation kullanamaz.

Bu kısıtlar özellikle DI framework'ü olmadan context parameters'ı "constructor injection yerine kullanma" fikrine kapıyı kapatıyor — context parameters şu an için yalnız fonksiyon ve computed property seviyesinde çalışıyor, sınıf oluşturma sürecine (constructor) dahil değil. Bu ayrımı gözden kaçırmak, deneyimli bir DI kullanıcısının context parameters'ı yanlış yerde arayıp "neden constructor'da çalışmıyor" diye takılmasına yol açabiliyor.

Aşağıdaki tablo deneysel dönemden (2.2/2.3) bugüne neyin değiştiğini özetliyor:

Gerçek kullanım desenleri (DI, logging, scope)

Context parameters'ın temel kullanım deseni, servis veya logger gibi paylaşılan bir bağımlılığı fonksiyon imzasına parametre olarak eklemeden, ama yine de tip-güvenli şekilde erişilebilir kılmak:

1interface UserService {
2    fun log(message: String)
3}
4 
5context(users: UserService)
6fun outputMessage(message: String) {
7    users.log(message)
8}

Bu fonksiyonu çağırırken users parametresini elle geçirmene gerek yok — çağrı yerinde context'te bir UserService örneği varsa derleyici onu otomatik bulur. Klasik yaklaşımla karşılaştırınca fark netleşiyor: normal bir parametre olarak tanımlasaydın (fun outputMessage(users: UserService, message: String)), çağıran her yerin users değerini elle taşıması gerekirdi — bu da özellikle çağrı zincirinin derin olduğu katmanlı mimarilerde (repository → use case → view model) her ara katmanın ilgisi olmayan bir parametreyi sırf bir alt katmana ulaştırmak için taşımasına yol açardı. Context parameter, bu "taşıma" yükünü derleyiciye devrediyor.

Adlandırmadan da erişebilirsin; anonim context parametre (_) veya contextOf<T>() ile:

1context(_: UserService)
2fun quickLog(message: String) {
3    contextOf<UserService>().log(message)
4}

Birden fazla eşleşen context değeri varsa derleyici ambiguity hatası verir. Bu durum özellikle overload'lar yalnız context parametre tipiyle ayrışıyorsa can sıkıcı olabilir — örneğin context parametresi EmailSender olan ve context parametresi SmsSender olan iki ayrı sendNotification() fonksiyonun varsa, çağrı yerinde ikisi de context'te bulunuyorsa derleyici hangisini kastettiğini bilemez. Bu durumda deneysel explicit context argument söz dizimiyle hangi context değerinin kullanılacağını açıkça belirtmen gerekir.

Pratikte context parameters'ı en çok fayda gördüğün yer, katmanlar arasında "her fonksiyona elle geçirmek istemediğin ama testte sahtesini koymak istediğin" servisler: logger, clock, feature-flag okuyucu gibi. Bu tip bağımlılıkları context parametre yapmak, imzayı kirletmeden fonksiyonun ihtiyacını açıkça belgelemenin bir yolu — fonksiyon imzasına bakan biri context(users: UserService) yazısını görünce bu fonksiyonun bir UserService'e ihtiyaç duyduğunu, ama bunun "asıl iş" parametresi olmadığını anlıyor.

Deneysel dönemde (2.2/2.3) aynı fonksiyonu yazmak için build script'ine -Xcontext-parameters derleyici bayrağını eklemen gerekiyordu:

1// build.gradle.kts — 2.2.0 / 2.3.0 döneminde gerekliydi
2tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile> {
3    compilerOptions {
4        freeCompilerArgs.add("-Xcontext-parameters")
5    }
6}

Kotlin 2.4.0'a yükselttikten sonra bu bloğu kaldırabilirsin — context parameter tanımı ve çağrı yerinde örtük çözümleme artık derleyicinin varsayılan davranışının bir parçası. Yükseltme sonrası CI'da bu bayrağı unutup bıraktıysan derleyici bir hata vermez, sadece gereksiz bir satır kalır; yine de temizlemek build script'ini güncel tutar.

Java 26 desteği ve toolchain

Kotlin 2.4.0 derleyicisi artık Java 26 bytecode üretebiliyor. Aynı sürümde Kotlin Metadata JVM kütüphanesi için annotation-in-metadata desteği varsayılan olarak açıldı; bu, annotation processor'ların ve diğer araçların reflection'a başvurmadan ve kaynak kodu değiştirmeden metadata seviyesinde annotation okuyup işleyebilmesini sağlıyor.

Toolchain tarafında Gradle 7.6.3 ile 9.5.0 arası sürümler tam destekleniyor; minimum AGP (Android Gradle Plugin) sürümü ise 8.5.2'ye yükseldi. Bu sürüm eşiklerini projeni yükseltmeden önce mutlaka kontrol et — aşağıdaki "Yükseltme kontrol listesi" bölümünde ayrıntılı tablo var.

Java 26 bytecode desteği, özellikle JVM hedefinde derleme yapan sunucu tarafı Kotlin projeleri (Ktor, Spring Boot ile Kotlin) için önemli: jvmTarget ayarını Java 26'ya çekebilmek, o sürümde gelen JVM seviyesindeki iyileştirmelerden (garbage collector, class loading) yararlanmak isteyen ekipler için ön koşul. Annotation-in-metadata desteğinin varsayılan açılması ise daha çok kütüphane ve framework yazarlarını ilgilendiriyor — KSP tabanlı bir annotation processor yazıyorsan, artık reflection'a başvurmadan ve kaynak kodu değiştirmeden doğrudan Kotlin metadata'sından annotation bilgisini okuyup işleyebilirsin.

Bu iki değişikliği (Java 26 bytecode + annotation-in-metadata) birbirinden ayrı düşünmek gerekiyor: biri hedef JVM sürümünü ilgilendiriyor (jvmTarget seçimin), diğeri derleme zamanında annotation okuma mekanizmasını. Bir Android projesi işletiyorsan Java 26 bytecode desteği seni doğrudan ilgilendirmeyebilir — Android runtime kendi bytecode hedefini kullanıyor — ama JVM'de (sunucu tarafı Kotlin, masaüstü Compose uygulaması) çalışan bir proje işletiyorsan bu ayrım yükseltme kararını doğrudan etkiliyor.

KMP: Swift paketlerini bağımlılık olarak kullanmak

Kotlin 2.4.0'ın Native tarafındaki en pratik yeniliği: Kotlin Multiplatform projeleri artık iOS app hedefi için Gradle üzerinden doğrudan Swift Package'leri bağımlılık olarak tanımlayabiliyor. swiftPMDependencies bloğuyla bir Swift paketini URL, versiyon ve kullanmak istediğin ürünlerle (products) birlikte deklare ediyorsun:

1kotlin {
2    swiftPMDependencies {
3        swiftPackage(
4            url = url("https://github.com/firebase/firebase-ios-sdk.git"),
5            version = from("12.11.0"),
6            products = listOf(
7                product("FirebaseAI"),
8                product("FirebaseAnalytics")
9            )
10        )
11    }
12}

Resmi dokümana göre SwiftPM import, Objective-C ve Swift kodundaki Objective-C'ye görünen API'leri Kotlin tarafına aktarıyor; saf Swift API'leri bu yolla gelmiyor. Aynı doküman özelliğin Alpha olduğunu, SwiftPM import kullanan bir KMP modülünün Swift paketi olarak export edilmesinin ise henüz desteklenmediğini belirtiyor. CocoaPods kullanan projeler için de resmi bir migrasyon rehberi yayınlandı — CocoaPods'tan SwiftPM tabanlı bağımlılık yönetimine geçmek isteyen ekipler için adım adım bir yol haritası sunuyor.

Bu özellik özellikle Firebase, analytics SDK'ları veya first-party olmayan native iOS kütüphaneleri KMP projesine dahil etmek isteyen ekipler için CocoaPods'a bağımlılığı azaltıyor.

Pratikte bu, bir KMP takımının iOS tarafındaki bağımlılık yönetimini artık iki ayrı araçla (CocoaPods + Gradle) değil, tek bir Gradle build dosyasıyla yürütebileceği anlamına geliyor. products listesine yalnız gerçekten ihtiyaç duyduğun ürünleri listelemek link edilen kodu sınırlı tutar — bir Swift paketinin tüm ürünlerini tek tek eklemek yerine, FirebaseAnalytics gibi gerçekten kullandığın modülü açıkça belirtmen yeterli.

Hâlâ CocoaPods kullanan bir projen varsa, resmi migrasyon rehberini uygulamadan önce takımınla birlikte hangi bağımlılıkların önce taşınacağına karar vermek, büyük bir KMP codebase'inde tek bir PR'da tüm bağımlılık yönetimini değiştirme riskini azaltır.

Modüler bir KMP projesi kuruyorsan, Swift paketi bağımlılıklarını hangi modülde tanımladığına da dikkat et — modüler mimari ve SPM ileri seviye kullanım yazılarımızdaki modül sınır prensipleri burada da geçerli: bir platforma özgü bağımlılığı paylaşılan commonMain modülüne değil, ilgili platform kaynak setine bağla.

Swift export'un bugünkü durumu

Kısa bir bağlam: Kotlin 2.4.0 ile Swift export resmi olarak Alpha durumuna geçti; suspend fonksiyonlar Swift'in async karşılığına, kotlinx.coroutines Flow'ları ise AsyncSequence'e export edilebiliyor. Bu, yukarıdaki Swift paketi bağımlılığı özelliğinin tam tersi yönde çalışan bir mekanizma: biri Kotlin kodunun Swift tarafından tüketilmesini (export), diğeri Swift paketlerinin Kotlin/Native tarafından bağımlılık olarak tüketilmesini (import) sağlıyor. İki farklı akışı karıştırmamak önemli — Swift export'un derinlemesine anlatımı ve KMP'deki Objective-C köprüsünün geleceği ayrı bir konu, bu yazının kapsamı dışında.

Alpha durumu pratikte şu anlama geliyor: API henüz kararlı değil, sürümler arası değişebilir ve production kritik akışlarda kullanmadan önce her yükseltmede davranış değişikliklerini kontrol etmen gerekiyor. Yukarıdaki SwiftPM import özelliği de dokümanında Alpha etiketli; yani ikisi de Alpha — biri import, diğeri export yönünde çalışıyor, ikisini de aynı ihtiyatla değerlendir.

UUID API ve explicit backing fields

kotlin.uuid.Uuid API'si 2.4.0'da Stable oldu; sürümü açıkça seçen Uuid.generateV4(), Uuid.generateV7() ve Uuid.generateV7NonMonotonicAt() fonksiyonları hâlâ Experimental. Rastgele V4 üreten Uuid.random() ise Stable, @OptIn istemiyor:

1import kotlin.uuid.Uuid
2import kotlin.uuid.ExperimentalUuidApi
3 
4fun createUser(): String {
5    val id = Uuid.random() // Stable: rastgele V4
6    return id.toString()
7}
8 
9@OptIn(ExperimentalUuidApi::class)
10fun createOrderedId(): Uuid {
11    return Uuid.generateV7() // V7 Experimental: @OptIn şart
12}

Explicit backing fields de bu sürümde Stable oldu — bir property'nin okuma (get()) tipiyle yazma (backing field) tipini birbirinden ayrı deklare etmeni sağlayan dil özelliği:

1class UserRepository {
2    val users: List<String>
3        field = mutableListOf()
4 
5    fun addUser(user: String) {
6        users.add(user) // sınıf içinde MutableList<String> smart-cast
7    }
8}

Bu sözdizimi, önceden ayrı bir private val + public val get() çifti gerektiren "read-only dışa açma" desenini tek property tanımına indiriyor. Eski desenle karşılaştırınca fark daha net görülüyor:

1// Eski desen: iki ayrı property + manuel senkronizasyon
2class UserRepositoryOld {
3    private val _users: MutableList<String> = mutableListOf()
4    val users: List<String>
5        get() = _users
6}

İki örnek de dışarıya List<String> tipinde read-only bir users sunuyor; fark, explicit backing fields'ta ayrı bir _users property'si ve get() yazmana gerek kalmaması. Okuma tipini (List<String>) sen deklare ediyorsun, derleyici backing field tipini (MutableList<String>) initializer'dan türetiyor — istersen field: MutableList<String> = mutableListOf() ile açıkça da yazabilirsin. Sınıf içinde users backing field tipine smart-cast edildiği için users.add(...) çalışıyor, dışarıdan yalnız okunabiliyor.

Yükseltme kontrol listesi (Gradle 9.5.0)

Kotlin sürüm yükseltmeleri genelde derleyici düzeyinde sorunsuz geçer, ama toolchain sürüm eşikleri (Gradle, AGP, minimum platform sürümleri) atlandığında CI'da beklenmedik build hataları çıkabiliyor. Projeni 2.4.0'a yükseltmeden önce kontrol etmen gereken sürüm eşikleri:

Ayrıca modül isimlendirmesinde bir davranış değişikliği var: platformlar arası varsayılan modül adı artık {group}:{project_name} formatında. JVM'de eski davranışa dönmek istersen build.gradle.kts içinde opt-out edebilirsin.

SSS

Kotlin 2.4.0'da neler yeni?

Kotlin 2.4.0, context parameters, explicit backing fields ve annotation use-site target özelliklerini Stable yapıyor; standart kütüphanede UUID API'sini stabilize ediyor; JVM'de Java 26 bytecode desteği ve Native'de Swift paketi bağımlılığı desteği getiriyor. Ayrıca Swift export Alpha durumuna yükseldi ve Gradle 9.5.0 uyumluluğu sağlandı. Bu maddelerin her biri bu yazıda ayrı bir bölümde, kod örnekleriyle birlikte ele alınıyor — özellikle context parameters ve Swift paketi bağımlılığı, günlük geliştirme akışını doğrudan etkileyen iki değişiklik.

Context parameters nedir, context receivers'tan farkı ne?

Context parameters, fonksiyon ve property'lerin çevresel bağlamda örtük olarak bulunan bağımlılıkları (context(users: UserService) fun ...) deklare etmesini sağlıyor — servis gibi paylaşılan, nadiren değişen değerleri elle taşımadan kullanmana yarıyor. Eski deneysel "context receivers" önerisinin yerini alan, isimli parametre söz dizimine sahip, tip bazlı çözümleme yapan bir yaklaşım; Kotlin 2.4.0 ile context argument geçirme ve callable reference desteği hariç Stable hale geldi.

Kotlin Multiplatform'da Swift paketi bağımlılık olarak nasıl eklenir?

Gradle build dosyasında kotlin { swiftPMDependencies { swiftPackage(url = ..., version = from("x.y.z"), products = listOf(product("ÜrünAdı"))) } } bloğuyla tanımlıyorsun. CocoaPods'tan geçiş yapan projeler için resmi bir migrasyon rehberi de mevcut.

Kotlin 2.4 için hangi Gradle sürümü gerekli?

Resmi duyuruya göre Gradle 7.6.3 ile 9.5.0 arası tam destekleniyor. Daha yeni Gradle sürümleri de genelde çalışır, ama deprecation uyarıları veya henüz test edilmemiş yeni Gradle özellikleriyle karşılaşabilirsin.

Explicit context argument nedir, neden hâlâ deneysel?

Explicit context argument, bir fonksiyonu çağırırken context parametresini örtük çözümlemeye bırakmak yerine açıkça belirtmeni sağlayan söz dizimi. Bu çağrı-yeri sözdizimi 2.4.0'da Experimental olarak tanıtıldı ve -Xexplicit-context-arguments bayrağıyla opt-in gerektiriyor; ayrıntısı özelliğin KEEP belgesinde izleniyor.

UUID API'si nasıl kullanılır?

kotlin.uuid.Uuid sınıfı ile Uuid.random() çağrısı Stable API üzerinden çalışıyor. V4 ve V7 formatlarını açıkça seçen üretim fonksiyonları ise @OptIn(ExperimentalUuidApi::class) gerektiren Experimental API'ler olarak kalmaya devam ediyor.

Explicit backing fields ne işe yarıyor?

Explicit backing fields, bir property'nin dışarıya sunduğu okuma tipiyle (get()) içeride tuttuğu yazma tipini (backing field) birbirinden ayırmanı sağlıyor — örneğin dışarıya read-only List<String> sunarken içeride MutableList<String> tutmak. 2.4.0 öncesinde bunu yapmak için ayrı bir private property + public getter çifti yazman gerekiyordu; artık field = ... söz dizimiyle tek property tanımında yapabiliyorsun.

Swift export ile SwiftPM bağımlılığı arasındaki fark ne?

İkisi ters yönde çalışan iki ayrı mekanizma. SwiftPM bağımlılığı (bu yazının ana konusu), bir Swift paketini Kotlin/Native tarafına bağımlılık olarak içe aktarmanı sağlıyor — swiftPMDependencies Gradle bloğuyla. Swift export ise tam tersi: Kotlin kodunu (suspend fonksiyonlar, Flow'lar) Swift tarafına dışa aktarmanı sağlıyor ve Kotlin 2.4.0 itibarıyla Alpha durumunda. Bir KMP projesinde ikisini aynı anda kullanman mümkün ama ikisinin de Alpha durumunda olduğunu unutma.

Sonuç

Kotlin 2.4.0, iki sürüm boyunca deneysel kalan context parameters'ı nihayet production'a taşıyan, Native tarafında ise Swift paketi bağımlılığı ile CocoaPods'a alternatif bir yol açan bir sürüm. Context parameters'a geçmeden önce K2 compiler ve context parameters'ın deneysel halini anlattığımız önceki yazıyı okuyup deneysel dönemle bu Stable dönem arasındaki farkı netleştirmeni öneririm.

KMP projende modüler bir yapı kuruyorsan modüler iOS mimarisi ve Swift Package Manager ile SPM ileri seviye modüler mimari yazılarımız Swift paketi bağımlılıklarını nereye bağlaman gerektiği konusunda yol gösterici. Production'da KMP kullanan ekiplerin gerçek deneyimlerini görmek istersen Kotlin Multiplatform 1.1 Stable production case study ve Compose Multiplatform Android + iOS production deployment yazılarına bakabilirsin. Kotlin ile paylaşımlı çekirdek mimarisi kararı veriyorsan Swift Android SDK mı KMP mi? karşılaştırmamız da karar sürecine katkı sağlar.

Kısacası: context parameters'a geçmek için acele etmene gerek yok — Stable olması, kütüphanelerin ve büyük codebase'lerin bu API'yi public yüzeyde kullanmaya başlayabileceği anlamına geliyor, ama mevcut kodunu hemen bu deseni kullanacak şekilde yeniden yazman gerekmiyor. Swift paketi bağımlılığı tarafında ise durum daha acil olabilir: CocoaPods bakımını azaltmak isteyen bir KMP takımıysan, bu özelliği Alpha etiketini akılda tutarak değerlendirmeye şimdiden başlayabilirsin.

Kaynaklar

• Kotlin 2.4.0 — What's New — context parameters/explicit backing fields Stable duyurusu, Java 26 desteği, Swift paketi bağımlılığı ve Swift export Alpha bilgisi, Gradle/AGP sürüm eşikleri
• Kotlin Releases — 2.4.0 sürüm tarihi doğrulaması (3 Haziran 2026)
• Context Parameters — Kotlin Docs — context parameter söz dizimi, kısıtlar ve kullanım desenleri
• Kotlin 2.4.0 Released — JetBrains Blog — resmi duyuru metni
• Import Swift Packages via SPM — Kotlin Docs — SwiftPM import: Alpha etiketi, Objective-C API sınırı ve export kısıtı