Kotlin 2.4 Swift Export: KMP'de Obj-C Köprüsü Bitiyor mu?

Kotlin Multiplatform'da iOS tarafı yıllardır aynı tek şikayeti taşıyor: Objective-C köprüsünden geçen API'ler Swift'e "yabancı" hissettiriyor. Alt çizgili parametre adları, KotlinInt kutulamaları, generic'lerin erimesi — hepsi Swift geliştiricisinin gördüğü ilk şey oluyor. Kotlin 2.4.0 ile gelen Swift export Alpha statüsü bu köprüyü ortadan kaldırmayı hedefliyor, ama "hedeflemek" ile "çözmek" arasında hâlâ mesafe var. Bu yazıda Swift export'un Kotlin 2.4.0 ile bugün gerçekten ne yaptığını, hangi sınırlamaların hâlâ yerinde durduğunu ve geçişte seni nelerin beklediğini kaynaklı şekilde anlatıyorum.

💡 Pro Tip: Swift export'u üretim projesine almadan önce kotlinlang.org/docs/native-swift-export.html sayfasındaki güncel sınırlama listesini oku — "direct integration" gerektirmesi, CocoaPods ile entegre edilmiş mevcut KMP kurulumlarının tamamını doğrudan kapsam dışı bırakıyor.

İçindekiler

• Neden Şimdi: Kotlin 2.4.0 ve Swift Export Alpha
• Obj-C Köprüsünün Somut Maliyeti
• Swift Export Bugün Ne Yapıyor, Ne Yapmıyor
• Ortak Modül API Tasarımında Nelere Dikkat Etmelisin
• CMS GC Varsayılanının iOS Akıcılığına Etkisi
• Swift Paket Bağımlılıkları Nasıl Bağlanıyor
• Geçişte Kırılacaklar ve Sürüm Kilidi
• Bugünkü Olgunluk: Dürüst Değerlendirme
• SSS
• Kotlin Swift export nedir, Obj-C köprüsünden farkı ne?
• Kotlin 2.4'te KMP iOS tarafında ne değişti?
• KMP'de Swift paketleri bağımlılık olarak kullanılabilir mi?
• Swift export production'a hazır mı?
• SKIE ile Swift export arasında hangisini seçmeliyim?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Neden Şimdi: Kotlin 2.4.0 ve Swift Export Alpha

Burada tarihleri netleştirmek önemli, çünkü kaynaklar arasında karışıklık kolay oluyor. kotlinlang.org/docs/releases.html release-history tablosuna göre Kotlin 2.4.0, 3 Haziran 2026'da yayımlandı; JetBrains'in resmi duyurusu (blog.jetbrains.com/kotlin/2026/06/kotlin-2-4-0-released/) bu sürümü şöyle özetliyor: "Kotlin/Native: Support for Swift packages as dependencies, updates on Swift export, and the CMS GC enabled by default." Yani Swift export'un Alpha'ya geçmesi, Swift paketlerinin bağımlılık olarak eklenmesi ve CMS GC'nin varsayılan olması — üçü de 2.4.0'a ait.

2.4.10 ise 14 Temmuz 2026'da yayımlandı, ama release notları bunu net biçimde tanımlıyor: "A bug fix release for Kotlin 2.4.0" — yeni özellik getirmiyor. Bu ayrımı bilerek yapıyorum çünkü Swift export'la ilgili bazı ikincil kaynaklar iki tarihi birbirine karıştırıyor.

kotlinlang.org/docs/whatsnew24.html sayfasının ilgili bölüm başlığında "Swift export goes Alpha with improved concurrency support" ifadesi geçiyor — Beta değil, Alpha. touchlab.co'nun analizi (touchlab.co/the-future-of-kmps-ios-interop) bu ilerlemeyi şöyle özetliyor: "Swift Export just hit alpha, with improved concurrency support." Aynı yazı önemli bir sınırlamaya da dikkat çekiyor: cross-language inheritance o dönemde desteklenmiyordu, open işaretli Kotlin sınıfları bile Swift tarafında final olarak görünüyordu. Bu sınırlama, aşağıda göreceğin gibi, Swift export'un bugünkü en belirleyici mimari kısıtı.

Neden bu ayrım (Alpha mı Beta mı, 2.4.0 mı 2.4.10 mu) bu kadar önemli? Çünkü Kotlin ekosisteminde "Swift export'la ilgili X geldi" cümlesi, hangi alt sürümde geldiğine bakılmadan paylaşıldığında, geçiş kararı veren bir ekip yanlış sürümü hedefleyip build'ini kıran bir bayrağı etkinleştirebilir. Sürüm notlarını okurken şunu refleks hâline getir: bir özelliğin adını gördüğünde önce onun hangi sürümde geldiğini releases.html tablosundan doğrula, sonra gradle.properties'ine dokun. Bir bug-fix sürümünü özellik sürümü sanmak, "bende çalışmıyor" ile geçen bir günün en sık nedeni.

Obj-C Köprüsünün Somut Maliyeti

Objective-C köprüsü uzun süredir KMP-iOS entegrasyonunun en çok şikayet edilen katmanı. Bunun nedeni teknik: Kotlin tipleri Obj-C header'larına dönüştürülürken bazı bilgiler kaybediyor ya da garip biçimde temsil ediliyor.

• İsimlendirme: Kotlin'in paket yapısı Obj-C'de düz, alt çizgili prefix'lere dönüşüyor; bu da IDE otokompleti okumasını zorlaştırıyor.
• Kutulama: Int, Boolean gibi primitive'ler bazı bağlamlarda KotlinInt, KotlinBoolean gibi kutulanmış Obj-C tiplerine dönüşüyor, Swift tarafında doğal hissettirmiyor.
• Generic'ler: Obj-C'nin generic desteği sınırlı olduğu için Kotlin generic'leri köprüden geçerken tip bilgisini büyük ölçüde kaybediyor.

Bu maddeler touchlab.co'nun karşılaştırmasında ve kotlinlang.org'un Swift export motivasyon metninde tekrar eden temalar. Bu üç kalemin ortak yanı şu: hiçbiri bir performans sorunu değil. Uygulaman Obj-C köprüsü yüzünden yavaşlamıyor; Swift tarafındaki API yüzeyi okunaksızlaşıyor.

Maliyet, her yeni iOS geliştiricisinin KotlinInt'in ne olduğunu sorduğu dakikalarda, her code review'da "bu alt çizgi neden burada" tartışmasında birikiyor. Swift export bu üç maddenin ikisini bugün zaten karşılıyor: doküman isimlendirme için "Kotlin packages are explicitly preserved during export" ve "Flattened package structure" maddelerini sayıyor, kutulama için "Swift export converts nullability information directly" diyerek KotlinInt sarmalayıcısını ortadan kaldırıyor. Çözülmemiş tek kalem generic'ler: "type-erased to their upper bounds". Üretime bugünkü engel bu üç madde değil, Alpha kısıtları: final-class-only export, yalnız direct integration ve IDE migration aracının yokluğu.

Swift Export Bugün Ne Yapıyor, Ne Yapmıyor

Swift export, Kotlin/Native derleyicisinin Kotlin kodundan doğrudan idiomatic Swift API'leri üretmesidir — Obj-C header köprüsünü tamamen devre dışı bırakır (kotlinlang.org/docs/native-swift-export.html). native-swift-export.html sayfasındaki güncel sınırlama listesi şöyle özetlenebilir:

Bu tablo kotlinlang.org/docs/whatsnew24.html ve kotlinlang.org/docs/native-swift-export.html sayfalarındaki maddelerin özetidir. Structured concurrency desteği (suspend→async, Flow→AsyncSequence) Alpha'nın en olgun tarafı; buna karşın "yalnızca final class" kısıtı, mevcut çoğu KMP projesinin open sınıflarla kurduğu paylaşılan mimarilerde doğrudan sürtünme yaratıyor.

1// commonMain — Swift export bu sınıfı export edebilir çünkü final
2class UserRepository(private val api: ApiClient) {
3    suspend fun fetchUser(id: String): User = api.getUser(id)
4}
5 
6// Ama bu sınıf Alpha'da export EDİLEMEZ (open + inheritance bekleniyor)
7open class BaseViewModel {
8    open fun onAppear() {}
9}

Swift tarafında üretilen kod, suspend fun'ı doğrudan async fonksiyona çeviriyor — bu, eski Obj-C köprüsünde callback-tabanlı imzalara dönüşen aynı fonksiyonla karşılaştırıldığında gerçek bir kazanım. Swift tarafında bu API'yi çağırmak, geleneksel Obj-C köprüsündeki kutulama katmanı olmadan doğrudan native async/await sözdizimiyle mümkün:

1// Swift export ile üretilen API'yi çağırmak
2let repository = UserRepository(api: ApiClient())
3let user = try await repository.fetchUser(id: "42")

Eski Obj-C köprüsünde aynı çağrı, KotlinInt gibi kutulanmış tipler ve tamamlanma-blok (completion handler) tabanlı bir imza gerektirirdi; burada Swift'in kendi concurrency modeliyle birebir örtüşüyor. Bu fark, özellikle Task {} blokları içinde zincirleme çağrılar yapan uygulamalarda okunabilirliği doğrudan etkiliyor — kod artık "Kotlin'den geldiği belli olan" değil, "Swift'te yazılmış gibi görünen" bir API yüzeyine sahip.

Ortak Modül API Tasarımında Nelere Dikkat Etmelisin

Swift export'un mevcut sınırlamalarından (final-class-only export, generic type erasure) doğrudan çıkarılabilecek pratik sonuçlar var; bunları "resmi kural" değil, dokümandaki sınırlama listesinden türeyen öneriler olarak okumalısın:

• Kalıtım yerine kompozisyon: commonMain'de export edilecek public API'leri open sınıflar yerine final sınıflar + interface kompozisyonuyla tasarlamak, Swift export ile uyumluluğu artırıyor.
• Generic'i API sınırından uzak tut: Generic parametreli public fonksiyonlar export edilse bile Swift tarafında tip bilgisi zayıflayabiliyor; generic'i internal katmanlarda tutup dış yüzeyi somut tiplerle sunmak daha güvenli.
• Suspend fonksiyonları tercih et: Callback tabanlı API'ler yerine suspend fun kullanmak, Swift export'un en olgun tarafı olan concurrency eşlemesinden doğrudan faydalanıyor.

1// Önerilen: final + suspend + somut dönüş tipi
2class ProfileService(private val client: ApiClient) {
3    suspend fun loadProfile(userId: String): Profile =
4        client.get("profile/$userId")
5}

CMS GC Varsayılanının iOS Akıcılığına Etkisi

Kotlin 2.4.0 ile Kotlin/Native'in bellek yöneticisinde CMS (Concurrent Mark & Sweep) GC varsayılan hale geldi (blog.jetbrains.com/kotlin/2026/06). Doküman geri dönüş yolunu da açıkça veriyor: "If you face problems, you can switch back to PMCS" — bunun için gradle.properties dosyana kotlin.native.binary.gc=pmcs binary option'ını yazman yeterli (kotlinlang.org/docs/whatsnew24.html). Buradaki ayrıntıya dikkat et: bu bir derleyici bayrağı değil, gradle.properties içinde tanımlanan bir binary option; Gradle komut satırına eklemeye çalışırsan beklediğin etkiyi görmezsin.

Pratik sonuç şu: varsayılanın değişmesi, bellek davranışını hiç ölçmeden geçtiğin bir sürümde uygulamanın GC profilini sessizce değiştirebilir. 2.4.0'a yükselirken iOS tarafında bellek kullanımını ve takılma şikayetlerini yeniden ölç; bir gerileme görürsen elinde net bir kıyas noktası olsun diye aynı ölçümü pmcs ile tekrarla. Doküman proje-spesifik bir rakam vermiyor ama etkisiz de demiyor: CMS için birebir "This significantly improves GC pause duration and app responsiveness" diyor — kendi projendeki fark yine de ölçmeden bilinebilecek bir şey değil.

1# gradle.properties — CMS yerine eski PMCS'ye dönmek istersen
2kotlin.native.binary.gc=pmcs

Swift Paket Bağımlılıkları Nasıl Bağlanıyor

Kotlin 2.4.0'dan itibaren gelen "Swift package import" özelliği, bir KMP modülünün Gradle yapılandırmasında doğrudan bir SwiftPM bağımlılığı tanımlamasına izin veriyor (kotlinlang.org/docs/whatsnew24.html, "Swift package import" bölümü). Ayrıntılı kurulum adımları kotlinlang.org/docs/multiplatform/multiplatform-spm-import.html sayfasında.

Bağımlılıklar, Apple hedeflerinin bildirildiği build.gradle.kts dosyasında swiftPMDependencies {} bloğuna yazılıyor:

1// build.gradle.kts
2plugins {
3    kotlin("multiplatform") version "2.4.0"
4}
5 
6kotlin {
7    iosArm64()
8    iosSimulatorArm64()
9 
10    swiftPMDependencies {
11        swiftPackage(
12            url = url("https://github.com/firebase/firebase-ios-sdk.git"),
13            version = from("12.11.0"),
14            products = listOf(
15                product("FirebaseAI"),
16                product("FirebaseAnalytics"),
17            ),
18        )
19    }
20}

Sözdiziminin üç parçasına dikkat et: url() paketin Git adresini, version çözümleme kuralını (from("12.11.0") gibi) ve products listesi Kotlin kodundan erişmek istediğin ürünleri belirtiyor. Bu liste hangi ürünlerin çözüleceğini belirler; Clang modül keşfi ise varsayılan olarak otomatiktir ("automatically discovers Clang modules"), kapatmak için discoverClangModulesImplicitly = false; transitif bir bağımlılığın sürümünü sabitlemek istersen onu da ayrı bir swiftPackage(...) çağrısıyla, boş products listesiyle ekleyebilirsin.

Bu özelliğin en somut pratik faydası, artık bir CocoaPods geçmişi olmadan SwiftPM ekosistemindeki paketlere (örneğin analytics ya da UI kütüphaneleri) doğrudan erişebilmen. Mevcut kurulumun CocoaPods üzerineyse yol kapalı değil: doküman bu senaryoyu ayrıca ele alıyor — "If your project relies on CocoaPods dependencies, you can migrate the current setup to use Swift packages" — ve KMP araçlarının bu geçişte projeyi otomatik yeniden yapılandırmaya yardım ettiğini söylüyor (kotlinlang.org/docs/whatsnew24.html). Bu, Swift export'un "direct integration" zorunluluğuyla da doğrudan bağlantılı: CocoaPods'tan çıkış, iki özelliğin önünü aynı anda açıyor.

Geçişte Kırılacaklar ve Sürüm Kilidi

Swift export'a geçiş kararsız/Alpha bir API üzerine kurulduğu için en riskli kısım burası. Dikkat etmen gereken üç kalem:

Bu üç kalem projede en çok gözden kaçan noktalar — özellikle minimum platform sürümü yükselmesi, mevcut kullanıcı tabanı eski cihazlarda ise doğrudan bir ürün kararı gerektiriyor.

Bu üç kalemin pratikte ne anlama geldiğini biraz daha açmak gerekir. Minimum sürüm yükselmesi, analytics panelinde eski işletim sistemi kullanan kullanıcı yüzdesine bakmadan geçiş kararı vermenin riskli olduğu anlamına geliyor — bu oran ürün ve pazar segmentine göre büyük farklılık gösterir, bu yüzden genel bir eşiğin peşine düşme, doğrudan kendi kullanıcı tabanının dağılımına bak. "Direct integration" zorunluluğu ise CocoaPods'tan XCFramework'e veya SwiftPM'e geçiş anlamına geliyor; bu geçişin kendisi ayrı bir mühendislik işi ve Swift export'tan bağımsız olarak planlanmalı. IDE migration aracının yokluğu ise en çok küçümsenen risk: büyük bir public API yüzeyini elle Swift export'a taşımak, hata payı yüksek ve zaman alan bir süreç — bu yüzden işe, yalnızca birkaç final sınıf ve suspend fonksiyon içeren küçük bir sandbox modülüyle başla.

Bugünkü Olgunluk: Dürüst Değerlendirme

Swift export'u SKIE (Touchlab'ın ürünü) ile karşılaştıran en derin teknik yazı touchlab.co'da yayımlandı (touchlab.co/the-future-of-kmps-ios-interop) ve derlenmiş Obj-C/Swift kod çıktısını yan yana gösteriyor. Aynı yazı Swift export için "does not yet support cross-language inheritance" diyor — yani kalıtım gerektiren bir mimaride SKIE bugün hâlâ daha geniş bir kapsam sunuyor. Bu tür karşılaştırmaların tarihli olduğunu unutma: Alpha bir özelliğin kapsamı her sürümde genişleyebilir, o yüzden kararını verirken karşılaştırmanın hangi Kotlin sürümüne bakarak yazıldığını kontrol et.

Diğer İngilizce kaynaklar iki kümede toplanıyor: sürüm özet makaleleri (Medium tarzı, yüzeysel liste formatı) ve pratik kurulum rehberleri (carrion.dev, 2.1.0 dönemine ait, 2.4.x güncellemesi yok). Kısacası: Swift export bugün gerçek ve ilerliyor, ama "üretime hazır" demek için henüz erken — Alpha etiketi boşuna değil. final-class-only kısıtı, IDE migration aracının yokluğu ve "direct integration" zorunluluğu, çoğu mevcut KMP projesi için bugün doğrudan bir geçiş engeli.

Bu olgunluk değerlendirmesini yaparken şunu da eklemek gerekir: JetBrains'in kendi dokümantasyonu Swift export'u hiçbir yerde "production-ready" olarak tanımlamıyor — statü açıkça Alpha. Bu, resmi bir taahhüt değil, aktif geliştirilen bir özellik demek; API yüzeyi sürümden sürüme değişebilir. Bir ekip olarak bunu benimsemenin maliyeti, her büyük Kotlin sürümünde sınırlama listesini yeniden kontrol etmek ve export edilen API'lerin kaynak kod diff'ini gözden geçirmek. Bu maliyeti göze almadan Swift export'u ana koda almak, önümüzdeki birkaç sürüm boyunca tekrarlayan bir bakım yükü yaratabilir.

SSS

Kotlin Swift export nedir, Obj-C köprüsünden farkı ne?

Swift export, Kotlin/Native derleyicisinin Kotlin kodundan doğrudan idiomatic Swift API'leri üretmesini sağlayan bir mekanizmadır; geleneksel Objective-C header köprüsünü (kutulanmış tipler, düz paket isimlendirmesi) devre dışı bırakır (kotlinlang.org/docs/native-swift-export.html). Obj-C köprüsünde generic'ler bilgi kaybederken, Swift export ile üretilen kod native Swift tiplerini kullanır — ama final-class-only sınırlaması gibi farklar Kotlin 2.4.0 itibarıyla hâlâ sürüyor.

Kotlin 2.4'te KMP iOS tarafında ne değişti?

Kotlin 2.4.0 (3 Haziran 2026) ile Swift export Alpha'ya geçti, geliştirilmiş concurrency desteği geldi, Swift paketlerini Gradle bağımlılığı olarak ekleme desteği açıldı ve Kotlin/Native GC'de CMS varsayılan oldu (blog.jetbrains.com/kotlin/2026/06). 2.4.10 (14 Temmuz 2026) ise yalnızca bir bug-fix sürümü; iOS interop tarafına yeni bir şey getirmiyor.

KMP'de Swift paketleri bağımlılık olarak kullanılabilir mi?

Evet — Kotlin 2.4.0'dan itibaren "Swift package import" özelliğiyle bir KMP modülü Gradle yapılandırmasında SwiftPM bağımlılığı tanımlayabiliyor (kotlinlang.org/docs/whatsnew24.html). Ayrıntılı rehber kotlinlang.org/docs/multiplatform/multiplatform-spm-import.html sayfasında.

Swift export production'a hazır mı?

Hayır, Kotlin 2.4.0 itibarıyla Alpha statüsünde. final-class-only kısıtı, generic type erasure ve IDE migration aracının yokluğu, çoğu mevcut proje için doğrudan geçişi zorlaştırıyor. Küçük bir sandbox modülde denemek daha güvenli bir başlangıç.

SKIE ile Swift export arasında hangisini seçmeliyim?

touchlab.co'nun karşılaştırması (yazıldığı tarih itibarıyla) SKIE'nin daha olgun ve inheritance dahil daha geniş bir kapsamı desteklediğini gösteriyor; Swift export ise resmi JetBrains çözümü olarak uzun vadede tercih edilecek yön. Bugün için ikisini de küçük ölçekte deneyip projenin ihtiyacına göre karar vermek makul.

Güncelleme (Eylül 2026)

Bu makale ilk yazıldığında (28 Temmuz 2026) yalnızca Kotlin 2.4.0'ın Alpha açılışı geçerliydi. 7 Eylül 2026'da yayımlanan Kotlin 2.4.20, yukarıda bahsettiğim final-class-only kısıtını doğrudan hedef alan üç ilerleme getirdi (kotlinlang.org/docs/whatsnew2420.html):

• Cross-language inheritance: Doküman birebir şöyle diyor: "Kotlin 2.4.20 introduces cross-language inheritance support in Swift export." Tipik kullanım da aynı sayfada tarif ediliyor: "A common use case for this feature is the reverse import pattern, where you define a contract in Kotlin and provide platform-specific implementations on the Swift side." touchlab.co'nun eleştirdiği "open sınıflar bile final" sınırlaması bu adımla kısmen ele alındı.
• Sealed class/interface export: Aynı sayfa şunu yazıyor: "Kotlin 2.4.20 adds support for sealed classes and interfaces to Swift export." Kotlin'de tanımlanan sealed hiyerarşiler Swift enum'larına eşleniyor; böylece Xcode'da tam otokompletle, tüketici switch ifadelerini default case yazmak zorunda kalmadan exhaustive yazabiliyorsun.
• Package.swift otomatik üretimi: SwiftPM paketlerine bağımlı bir XCFramework export ederken assembleSharedXCFramework Gradle görevi artık XCFramework'le birlikte dağıtılacak bir Package.swift dosyası üretiyor.

Kısacası: 2.4.0 Alpha'yı açtı, 2.4.20 onu somutlaştırdı. Eğer Temmuz'da bu konuyu değerlendirip erken bulduysan, Eylül 2026 itibarıyla tekrar bakmaya değer — özellikle cross-language inheritance ilerlemesi, en büyük mimari engellerden birini kısmen kaldırıyor.

Sonuç

Kotlin 2.4.0 ile Swift export Alpha statüsüne geçti ve Obj-C köprüsünün en çok şikayet edilen üç sorunundan ikisini — isimlendirme ve primitive kutulaması — çözdü; geriye generic type erasure kalıyor. Üretime asıl engel Alpha kısıtları: final-class-only export, yalnız direct integration ve IDE migration aracının yokluğu. Mimarini yeniden gözden geçirmeden önce, minimum platform sürümü yükselmesi gibi sessiz kırıcı değişiklikleri kontrol listesine ekle ve küçük bir sandbox modülde deneyerek karar ver; sürüm notlarını ön-sürümlerden itibaren takip et, çünkü Alpha bir API'nin kapsamı her sürümde değişebiliyor.

Konuyu derinleştirmek için şu yazılara bakabilirsin: Kotlin Multiplatform 1.1 Stable Production Case Study paylaşılan mimarinin üretimde nasıl davrandığını gösteriyor; Kotlin 2.1: K2 Compiler ve Context Parameters bu sürüm ailesinin bir önceki adımını anlatıyor; Compose Multiplatform: Android + iOS Production Deployment UI katmanındaki paralel hikayeyi tamamlıyor; Flutter vs SwiftUI: 3 Yıl + 60K LOC Production Karşılaştırması çapraz platform kararını daha geniş bir çerçeveden ele alıyor; Swift 6.0 Tam Rehber ise Swift tarafındaki concurrency temelini pekiştiriyor.

Kaynaklar

• Kotlin Releases — resmi sürüm tablosu — 2.4.0 (3 Haziran 2026) ve 2.4.10/2.4.20 tarihlerinin birincil kaynağı.
• What's New in Kotlin 2.4.0 — Swift export Alpha, swiftPMDependencies sözdizimi, CMS GC varsayılanı ve kotlin.native.binary.gc=pmcs geri dönüşü.
• What's New in Kotlin 2.4.20 — cross-language inheritance, sealed class/interface export ve Package.swift üretiminin birincil kaynağı.
• Kotlin Swift Export Dokümantasyonu — güncel sınırlama listesi (final-class-only, generic erasure, direct integration zorunluluğu).
• Kotlin 2.4.0 Released — JetBrains Blog — resmi duyuru, üç özelliğin 2.4.0'a bağlandığı kaynak.
• The Future of KMP's iOS Interop — Touchlab — Swift export'un SKIE ile teknik karşılaştırması, Obj-C köprüsünün somut sorunları.
• Swift Export Kurulum Rehberi — carrion.dev — gradle.properties flag'i ve embedSwiftExportForXcode adımının pratik anlatımı.
• Multiplatform SwiftPM Import Rehberi — Swift paket bağımlılığı kurulumunun ayrıntılı adımları.