Swift ile Android: 6.3 Android SDK Gerçekten Çalışıyor mu?

Swift 6.3 ile birlikte Android için ilk resmi Swift SDK'sı geldi ve "swift ile android geliştirme" artık teorik bir soru olmaktan çıktı. Ama "resmi SDK var" ile "Android'de production-ready bir platform" aynı şey mi? Bu yazıda 24 Mart 2026'da yayınlanan Swift 6.3'ün Android desteğinin gerçekte ne verdiğini, kurulumdan mevcut bir Kotlin projesine Swift kodu gömmeye kadar adım adım göreceksin.

💡 Pro Tip: Swift SDK for Android'i denemeden önce Android NDK'nin LTS 27d ya da üstü bir sürümünü kurulu tuttuğundan emin ol — SDK, cross-compile başlıklarını ve araçlarını doğrudan bu NDK sürümüne bağımlı çalıştırıyor.

İçindekiler

• Resmi Android SDK ne getiriyor, ne getirmiyor
• SDK bir "Swift for Android app" değil
• Kurulum ve ilk derleme
• İlk derleme ve cihazda çalıştırma
• NDK'yi kurma ve SDK'ya tanıtma
• Swift-Java köprüsü ile mevcut Kotlin projesine bağlanmak
• İki köprü seçeneği: swift-java mı, JNI Core mu
• UI katmanı sınırı: paylaşımın nerede bittiği
• Gerçekçi kullanım alanı: paylaşımlı iş mantığı çekirdeği
• Kimler için mantıklı, kimler için değil
• CI hattına eklerken dikkat edilecekler
• KMP karşısındaki konumu
• SSS
• Swift ile Android uygulaması yazılabilir mi?
• Swift Android SDK resmi mi ve neyi destekliyor?
• Swift-Java interop mevcut Kotlin koduyla nasıl çalışır?
• Bu SDK ile Jetpack Compose ekranları Swift'te mi yazılır?
• Minimum Android sürümü ne?
• Şu an production'da kullanılabilir mi?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Resmi Android SDK ne getiriyor, ne getirmiyor

Swift'in resmi blogu bunu net bir cümleyle duyurdu: "Swift 6.3 includes the first official release of the Swift SDK for Android." Bu, Android Workgroup'un aylar süren çalışmasının ve yıllara dayanan taban-topluluk emeğinin (nightly preview'lardan resmi sürüme) sonucu. Swift 6.3'ün genel odağı da bu yöndeydi: daha esnek C interop, çapraz platform derleme araçlarında iyileştirmeler, gömülü ortamlarda Swift kullanımı için iyileştirmeler ve resmi bir Android SDK'sı.

Önemli bir ayrım var: Android desteği "Embedded Swift" kısıtlı modu değil; swift.org'un duyuru sayfasında "Platforms and Environments" başlığı altında ayrı bir "Android" alt bölümü olarak ele alınıyor. Yani bu, mikrodenetleyici sınıfı bir mod değil, tam teşekküllü bir cross-compilation hedefi.

Peki ne getirmiyor? SDK sana derleme ve JNI köprüsü veriyor, ama Android'in kendi UI framework'ünün (Jetpack Compose, View sistemi) yerini alan resmi bir Swift-taraflı arayüz katmanı vermiyor. Resmi kurulum rehberi de bunu örtük şekilde doğruluyor: Swift kodunun erişileceği Android uygulamasının "typically written in Java or Kotlin" olduğu ifade ediliyor — yani UI katmanının sahibi değişmiyor.

SDK bir "Swift for Android app" değil

Duyurunun kendi cümlesi şöyle: "With this SDK, you can start developing native Android programs in Swift." Buradaki "native Android programs" ifadesini doğru ölçekte okumak gerekiyor. Kurulum rehberi, Android uygulamalarının komut satırı çalıştırılabilirleri olarak dağıtılmadığını, .apk arşivine paketlendiğini ve Swift modüllerinin bu arşive paylaşımlı kütüphane olarak dahil edildiğini anlatıyor. Yani Swift ile native kod derlemek evet; uygulama kabuğunu ve UI katmanını Swift'te yazmak hayır — resmi kaynaklarda Swift-taraflı bir arayüz katmanı tarif edilmiyor. Pratikte verdiği şey, Swift kodunu Android'in native (JNI) katmanına derleyip mevcut bir Kotlin/Java uygulamasına gömme yolu. Bu ayrımı ilerleyen bölümlerde somut kodla göreceksin.

Kurulum ve ilk derleme

Android için çapraz derleme üç ayrı bileşen gerektiriyor: Swift Toolchain, Swift SDK for Android ve Android NDK. Resmi rehbere göre host toolchain'i macOS ve Linux'ta yönetmenin en kolay ve önerilen yolu swiftly komut satırı aracı.

1# 1) Host toolchain'i swiftly ile kur (macOS/Linux)
2swiftly install latest
3swiftly use latest
4 
5# 2) Android SDK bundle'ini indir ve kur (checksum ZORUNLU)
6swift sdk install https://download.swift.org/swift-6.3-release/android-sdk/swift-6.3-RELEASE/swift-6.3-RELEASE_android.artifactbundle.tar.gz \
7  --checksum 2f2942c4bcea7965a08665206212c66991dabe23725aeec7c4365fc91acad088
8 
9# 3) Kurulu SDK'lari dogrula -> ciktida: swift-6.3-RELEASE_android
10swift sdk list

Swift SDK for Android, Android NDK'nin LTS 27d ya da üstü bir sürümüne bağımlı — cross-compile için gereken başlık dosyalarını ve araçları bu NDK sürümü sağlıyor. Resmi rehbere göre en basit kurulum yolu, arşivi NDK Downloads sayfasından indirip açmak.

İlk derleme ve cihazda çalıştırma

Kurulum bittikten sonra swift build komutuna --swift-sdk ile hedef triple'ı vererek çapraz derleme yapıyorsun. Çıktı ikili dosya adb push ile cihaza veya emülatöre kopyalanıp adb shell üzerinden çalıştırılıyor — ikilinin yanında NDK'den gelen libc++_shared.so bağımlılığını da göndermen gerekiyor:

1swift build --swift-sdk aarch64-unknown-linux-android28 --static-swift-stdlib
2 
3adb push .build/aarch64-unknown-linux-android28/debug/hello /data/local/tmp
4adb push $ANDROID_NDK_HOME/toolchains/llvm/prebuilt/*/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so /data/local/tmp/
5adb shell /data/local/tmp/hello

swift sdk list çıktısında kurulu SDK'yı swift-6.3-RELEASE_android adıyla görürsün; derlemede hedefi triple ile belirtiyorsun. Minimum desteklenen Android sürümü API 28 (Android 9) — triple'lar da bunu yansıtıyor (aarch64-unknown-linux-android28, x86_64-unknown-linux-android28).

NDK'yi kurma ve SDK'ya tanıtma

Resmi rehber NDK'yi doğrudan Swift SDK'nın kurulum dizininde açmanı öneriyor: önce bundle dizinine geçiyorsun, arşivi indirip açıyorsun, ANDROID_NDK_HOME değişkenini ayarlıyorsun ve SDK ile gelen setup-android-sdk.sh script'ini çalıştırıyorsun. NDK'yi başka bir konuma zaten kurduysan tek yapman gereken ANDROID_NDK_HOME değişkenini o konuma ayarlayıp aynı script'i çalıştırmak. Script bittiğinde elinde Android için tam çalışan bir çapraz derleme araç zinciri oluyor.

1# macOS icin bundle dizini (Linux'ta: ~/.swiftpm/swift-sdks/...)
2cd ~/Library/org.swift.swiftpm/swift-sdks/swift-6.3-RELEASE_android.artifactbundle/swift-android/
3 
4curl -fSL -o ndk.zip https://dl.google.com/android/repository/android-ndk-r27d-$(uname -s).zip
5unzip -qo ndk.zip
6export ANDROID_NDK_HOME=$PWD/android-ndk-r27d
7./scripts/setup-android-sdk.sh

Swift-Java köprüsü ile mevcut Kotlin projesine bağlanmak

Android uygulamaları komut satırı çalıştırılabilirleri olarak değil, .apk paylaşımlı kütüphaneler halinde dağıtılıyor. Swift SDK'nın asıl pratik değeri burada ortaya çıkıyor: Swift modüllerini her mimari için paylaşımlı kütüphane olarak derleyip uygulama arşivine dahil edebilir, tipik olarak Java veya Kotlin ile yazılan Android tarafından swift-java aracılığıyla erişebilirsin — bu araç, Java Native Interface (JNI) detaylarını senin yerine hallediyor.

1package com.example.app
2 
3import android.os.Bundle
4import android.widget.TextView
5import androidx.appcompat.app.AppCompatActivity
6import com.example.swiftcore.SwiftCore
7 
8class MainActivity : AppCompatActivity() {
9    override fun onCreate(savedInstanceState: Bundle?) {
10        super.onCreate(savedInstanceState)
11        setContentView(R.layout.activity_main)
12        val textView = findViewById<TextView>(R.id.greeting)
13        // Swift tarafında hesaplanan iş mantığı sonucu
14        textView.text = SwiftCore.buildGreeting("Android")
15    }
16}

Yukarıdaki SwiftCore adı yer tutucudur: üretilen binding'in tam adı, paketi ve çağrı biçimi swift-java yapılandırmasına göre değişir, resmi rehber sabit bir sınıf adı ya da örnek çağrı vermiyor. Swift tarafında karşılığı ise sıradan bir public fonksiyon:

1// Swift tarafında: paylaşımlı kütüphaneye derlenen çekirdek
2public func buildGreeting(name: String) -> String {
3    "Merhaba, \(name)! Bu satır Swift'te çalıştı."
4}

İleri düzey kullanımlar için düşük seviyeli bir arayüz olarak Swift Java JNI Core de mevcut. Resmi "Android Examples" deposu, tam Android uygulamalarının bu SDK'yı nasıl kullandığını gösteren örnek projeler barındırıyor; bir Swift modülünü sıfırdan Kotlin projesine bağlamadan önce bu depoyu incelemek, kendi entegrasyonunda hangi dosya/hedef yapısını taklit edeceğini görmenin en hızlı yolu.

İki köprü seçeneği: swift-java mı, JNI Core mu

Resmi rehber bu iki katmanı tek cümleyle ayırıyor: swift-java JNI detaylarını senin yerine hallediyor; JNI Core için ise yalnızca "For advanced uses, Swift Java JNI Core is also available as a low-level interface." deniyor. Rehber, JNI Core'a hangi somut durumlarda geçmen gerektiğini tarif etmiyor. Dolayısıyla 6.3 penceresinde elindeki tek yazılı yön şu: varsayılan yol swift-java'nın ürettiği binding'ler, JNI Core ise dokümanın "advanced uses" diye işaretlediği düşük seviyeli seçenek.

UI katmanı sınırı: paylaşımın nerede bittiği

Burada net olmak lazım: Swift SDK for Android bir UI framework'ü sunmuyor. Resmi kurulum rehberi, Android uygulamasının tipik olarak Java veya Kotlin ile yazıldığını belirtiyor — yani ekranlar, navigasyon, Compose bileşenleri Kotlin/Java tarafında kalıyor. Swift'in rolü; bu Kotlin/Java katmanının JNI üzerinden çağırdığı bir native çalıştırılabilir/kütüphane katmanı olmak.

Bu, aşağıdaki tabloda özetlendiği gibi net bir sorumluluk ayrımı yaratıyor:

Gerçekçi kullanım alanı: paylaşımlı iş mantığı çekirdeği

Swift, 2015'te açık kaynak olmasından bu yana Darwin-odaklı bir dilden Linux, Windows ve çeşitli gömülü sistemleri destekleyen çapraz platform bir dile dönüştü. Android SDK, bu genişlemenin doğal bir devamı. Ama bu genişleme "Swift ile tam bir Android uygulaması yaz" anlamına gelmiyor — gerçekçi kullanım alanı, iOS ve Android arasında paylaşılan bir iş mantığı çekirdeği: doğrulama kuralları, hesaplama algoritmaları, veri dönüştürme, kriptografi gibi platformdan bağımsız kod.

Bu model, ekibinin zaten Swift ile yazdığı bir domain katmanını yeniden yazmadan Android'e taşımasına imkân veriyor — ama UI, platform entegrasyonu ve dağıtım hattı Kotlin/Java tarafında kalmaya devam ediyor.

Kimler için mantıklı, kimler için değil

Bu yaklaşım en çok, halihazırda büyük bir Swift kod tabanına sahip (iOS uygulaması, sunucu tarafı Swift servisi ya da paylaşımlı bir framework) ve bu mantığı sıfırdan Kotlin'de yeniden yazmak istemeyen ekipler için anlamlı. Buna karşılık, Swift kod tabanın yoksa veya ekip zaten Kotlin/Java'da rahatsa, sırf "cross-platform" olsun diye bu SDK'yı devreye sokmak ek bir araç zinciri (toolchain + NDK + JNI köprüsü) karmaşıklığı ekler ve elindeki tek dil avantajından vazgeçmene neden olur.

CI hattına eklerken dikkat edilecekler

Android hedefine çapraz derleme, host makinende zaten macOS/Linux + swiftly + Android SDK + NDK kurulumu gerektiriyor; CI ortamında bu üç bileşeni de sağlaman gerekir. Pratik bir yaklaşım, Swift çekirdeğini ayrı bir CI adımında derleyip ürettiği paylaşımlı kütüphaneyi Android build'inin girdisi olarak vermek — böylece Swift ve Gradle derlemeleri birbirinden bağımsız, sırayla veya paralel çalışabilir. Aşağıdaki cp adımının çalışması için paylaşımlı kütüphane ürününün Package.swift içinde .library(name: "SwiftCore", type: .dynamic, targets: ["SwiftCore"]) biçiminde tanımlanmış olması gerekiyor; tür belirtilmezse SwiftPM statik/dinamik seçimini kendisi yapar ve .so dosyası bu yolda oluşmaz:

1# CI: once Swift cekirdegini Android hedefine derle
2swift build --swift-sdk aarch64-unknown-linux-android28 \
3  -c release --static-swift-stdlib
4 
5# Uretilen paylasimli kutuphaneyi Android modulunun jniLibs dizinine kopyala
6cp .build/aarch64-unknown-linux-android28/release/libSwiftCore.so \
7  app/src/main/jniLibs/arm64-v8a/
8 
9# Ardindan normal Gradle build'i calistir
10./gradlew assembleRelease

Ben bu iki aşamayı ayrı CI adımları olarak tutmayı tercih ediyorum; hangi araç zincirinin hata verdiğini ayırt etmeyi kolaylaştırıyor, çünkü Swift derlemesi başarısız olduğunda Gradle adımına hiç geçilmiyor.

KMP karşısındaki konumu

Kotlin Multiplatform (KMP), JetBrains'in performans, UX veya kod kalitesinden ödün vermeden Android, iOS, Web, Masaüstü ve Sunucu hedeflerinde paylaşımlı kod yazmayı amaçlayan resmi çapraz-platform çözümü; Duolingo, Google, Booking.com, McDonald's, Philo, Workday gibi üretim vaka çalışmaları bulunuyor.

Swift'in Android hikâyesi, KMP'nin izlediği yoldan farklı kurgulanmış. KMP'de "Kotlin tarafından paylaşımlı kodu çağırma, isteğe bağlı Compose UI ile" modeli var. Swift SDK for Android'de ise yön tersine dönüyor: var olan bir Swift iş mantığı çekirdeğini JNI üzerinden mevcut bir Kotlin/Java uygulamasına gömüyorsun. Yani KMP "Kotlin merkezli, çoklu hedef" yaklaşımıyken, Swift SDK for Android şu an "Swift çekirdek, Kotlin/Java kabuk" seviyesinde konumlanıyor — resmi bir Swift-taraflı UI katmanı sunmadan.

Bu fark, hangi ekibin hangi aracı seçeceğini de büyük ölçüde belirliyor. Sıfırdan çok-platformlu bir uygulama kuran ve Kotlin'i ana dil olarak benimsemiş bir ekip için KMP, hem UI paylaşımı hem de olgun bir araç zinciri sunduğu için daha doğal bir başlangıç noktası. Buna karşılık, elinde zaten büyük ve test edilmiş bir Swift iş mantığı katmanı olan bir ekip — örneğin uzun süredir iOS için geliştirilen bir uygulamanın domain katmanı — için Swift SDK for Android, bu katmanı yeniden yazmadan Android'e taşımanın resmi ve doğrudan bir yolu. İki araç da birbirinin yerine geçmek yerine, farklı başlangıç noktalarından gelen ekiplere hizmet ediyor.

SSS

Swift ile Android uygulaması yazılabilir mi?

Doğrudan "Swift ile Android uygulaması yaz" anlamında değil. Swift SDK for Android, Swift kodunu paylaşımlı kütüphane olarak derleyip mevcut bir Kotlin/Java Android uygulamasına JNI üzerinden gömmeni sağlıyor; ekranlar ve navigasyon Kotlin/Java tarafında kalıyor.

Swift Android SDK resmi mi ve neyi destekliyor?

Evet, resmi. Swift 6.3 duyurusu bunu "the first official release of the Swift SDK for Android" ifadesiyle netleştirdi. SDK; cross-compile araçlarını, Android NDK LTS 27d ya da üstü bağımlılığını ve minimum API 28 hedefini destekliyor.

Swift-Java interop mevcut Kotlin koduyla nasıl çalışır?

swift-java kütüphanesi, Swift tarafında derlenen kodu Kotlin/Java'dan çağırmak için gereken JNI köprüsünü otomatik üretiyor. İleri düzey kontrol isteyen senaryolar için Swift Java JNI Core adında düşük seviyeli bir arayüz de mevcut. Pratikte akış şöyle işliyor: Swift tarafında herkese açık (public) bir fonksiyon veya tip tanımlarsın, swift-java bu arayüzü tarayıp karşılığında bir Kotlin/Java binding üretir, sen de bu binding'i normal bir sınıf çağrısıymış gibi Android kodundan kullanırsın — JNI'nin kendisiyle uğraşmana gerek kalmaz.

Bu SDK ile Jetpack Compose ekranları Swift'te mi yazılır?

Hayır. Resmi kaynaklarda Swift-taraflı bir UI framework'ü tarif edilmiyor; Android uygulaması tipik olarak Java veya Kotlin ile yazılmaya devam ediyor, Swift yalnızca çağrılabilen bir native katman sağlıyor.

Minimum Android sürümü ne?

Resmi platform desteği ve kurulum rehberindeki triple'lara göre minimum desteklenen sürüm API 28 (Android 9).

Şu an production'da kullanılabilir mi?

Teknik olarak evet, derleyip bir uygulamaya gömebilirsin — ama bu, Swift 6.3 ile gelen ilk resmi sürüm. Yeni bir toolchain'in ilk sürümünü kritik bir üretim akışına sokmadan önce, ekibinin küçük ve izole bir modülle (örneğin tek bir hesaplama fonksiyonu) başlayıp genişletmesi daha güvenli bir yol.

Güncelleme (Eylül 2026)

Bu makale 30 Mart 2026 penceresinden, Swift 6.3'ün taze duyurusuyla yazıldı. Aradan geçen altı ayda doğrulanan gelişmeler şunlar: Swift 6.3.3 yama sürümü Haziran 2026 sonunda çıktı (GitHub'daki swift-6.3.3-RELEASE etiketi 26 Haziran 2026 tarihli commit'i işaret ediyor); Swift 6.4 ise 15 Eylül 2026'da duyuruldu. Android tarafındaki en önemli değişiklik NDK bağımlılığında: Swift 6.4 duyurusu "This release of the Swift SDK for Android is built with the new LTS NDK 30" diyor ve bu NDK'nin Android availability attribute'larını hem Swift runtime kütüphanelerinde hem de varsayılan NDK'yi kullanan Swift paketlerinde sağladığını belirtiyor.

Yani gövdede anlatılan LTS 27d tabanı yerini LTS NDK 30'a bıraktı. Güncel rehber artık swift-6.4.0-RELEASE_android bundle adını ve aarch64-unknown-linux-android23 triple'ını gösteriyor; Mart'taki API 28 tabanı aşağı çekilmiş durumda. Swift 6.4 duyurusu ayrıca Swift/Java interop'un async ve callback desteğini genişlettiğini belirtiyor; swift-java projesi de 5 Eylül 2026'da 0.6.0 sürümüyle jextract aracına Java functional-interface desteği (Consumer/Predicate/BinaryOperator ailesi) ve isolated parametreli fonksiyon import desteği ekledi.

Sonuç

Swift 6.3'ün Android SDK'sı, "Swift ile tam bir Android uygulaması yaz" vaadi değil; mevcut bir Kotlin/Java uygulamasına JNI üzerinden gömülebilen, paylaşımlı bir iş mantığı çekirdeği için resmi bir yol. Daha geniş Swift ekosistemine bakmak istersen Swift 6.0'da nelerin değiştiğini inceleyebilir, sunucu tarafında Swift kullanmayı düşünüyorsan server-side Swift ekosistemine göz atabilirsin. Android'e taşıyacağın çekirdeği hazırlarken Swift structured concurrency rehberi eşzamanlılık tarafında, Swift Package plugin'leri yazısı ise derleme otomasyonu tarafında işine yarar. Çapraz platform karar sürecindeysen bu SDK'yı React Native ile Flutter karşılaştırmasıyla yan yana koyup ekibinin gerçek ihtiyacına göre değerlendir.

Kaynaklar

• Swift 6.3 Released — Swift.org Blog — Android SDK'nın ilk resmi duyurusu ve Swift 6.3'ün genel öne çıkanları.
• Getting Started with the Swift SDK for Android — Swift.org Documentation — kurulum, üç bileşenli araç zinciri ve swift-java köprüsü detayları.
• Swift 6.4 Released — Swift.org Blog — Eylül 2026 güncellemesi, LTS NDK 30 ve Swift/Java interop genişlemesi.
• swift-java Releases — GitHub — jextract ve JNI köprüsünün sürüm geçmişi.
• Swift Platform Support — Swift.org — minimum Android API seviyesi ve platform tier bilgisi.
• Kotlin Multiplatform — JetBrains — karşılaştırma bölümünde referans alınan resmi KMP sayfası.