Skip ile SwiftUI'dan Android'e: Pratik Kurulum Rehberi

Skip'i SwiftUI projene entegre etmek için Xcode ve Homebrew dışında hiçbir ek araca ihtiyacın yok — Skip 21 Ocak 2026'dan beri tamamen ücretsiz ve açık kaynak, kurulum tek bir brew install skip komutuyla başlıyor. Bu rehberde Skip'in transpile mi yoksa native derleme mi yaptığını, Lite ile Fuse modu arasındaki pratik farkı ve ilk SwiftUI ekranını Android'de gerçekten çalıştırmayı adım adım göreceksin.

💡 Pro Tip: Kuruluma başlamadan önce skip checkup komutunu çalıştır — Skip, Xcode ve Android SDK sürümlerini tek seferde doğrulayıp örnek bir hello-skip derlemesi yapar; eksik bir bağımlılık varsa saatler kaybetmeden en başta öğrenirsin.

İçindekiler

• Skip Mimarisi: Transpile mı, Runtime mı
• Lite vs Fuse: Hangi Modu Seçmelisin
• Kurulum: Xcode, Android SDK ve skip checkup
• İlk Ekranı İki Platformda Çalıştırmak
• SwiftUI'ın Compose'a Çevrilmeyen Kısımları
• Platform-Özel Kod Yazma
• "Compose First" Kararının Pratik Anlamı
• Gerçek Proje Sınırları
• Ne Zaman KMP'yi Tercih Etmelisin
• SSS
• Skip ile SwiftUI kodu Android'de nasıl çalışır?
• Skip Lite ile Skip Fuse arasındaki fark nedir?
• Skip ücretsiz mi?
• Skip ile üretilen Android uygulaması native mi?
• Skip'i Fuse ile başlayıp sonra Lite'a (ya da tersine) geçirebilir miyim?
• Sonuç
• Kaynaklar

Skip Mimarisi: Transpile mı, Runtime mı

Skip tek bir motor değil, iki farklı çalışma biçimi sunan bir araç seti. Hangi modu seçtiğine göre kodun Android'de ya gerçek Swift olarak derlenir ya da Kotlin'e çevrilir — ve bu ayrım proje mimarini baştan belirler.

Fuse modu, Swift 6.3 ile resmi hale gelen Swift SDK for Android'i katman olarak kullanır: Swift kodun Android'de gerçekten native derlenir, tam Swift dil desteği ve deterministik bellek yönetimiyle çalışır, Apple'ın Foundation kütüphanesine erişir. Skip burada rakip bir runtime değil, resmi SDK'nın üzerine kurulu bir proje araç zinciridir.

Lite modu ise farklı bir strateji izler: Swift kaynak kodunu derleme zamanında Kotlin'e transpile eder. Sonuç gerçek bir Kotlin projesidir, dolayısıyla mevcut Kotlin/Java kütüphaneleriyle doğrudan interop kurabilirsin — ama Swift dilinin her özelliği transpiler tarafından desteklenmez (bir sonraki bölümde bu sınırları göreceksin).

Mod, Swift modülü düzeyinde belirlenir; skip create yalnızca projenin varsayılan modunu seçer. Aynı Skip projesinde bazı modülleri Fuse, bazılarını Lite ile derlemek mümkündür.

Bu iki modlu yaklaşım, Skip'i tek-motorlu diğer cross-platform çözümlerden ayıran temel özellik. Bir ekip iş mantığı ağırlıklı bir modülde Kotlin ekosistemine derin erişim istiyorsa o modülü Lite'ta tutup, performans-kritik ya da Apple framework'lerine yoğun bağımlı bir modülü Fuse'da derleyebilir. Bu esneklik bir bedelle gelir: iki farklı derleme yolu, iki farklı hata ayıklama deneyimi ve iki farklı araç zinciri anlamına gelir — bir sonraki bölümde bu iki modu daha somut kriterlerle karşılaştıracağız.

Lite vs Fuse: Hangi Modu Seçmelisin

İkisi arasındaki seçim, projenin Kotlin/Java ekosistemine ne kadar bağımlı olacağıyla doğrudan ilgili. Aşağıdaki tablo iki modu pratik kriterlere göre karşılaştırıyor:

Kısacası: mevcut bir Android/Kotlin projesine Swift modülü eklemek istiyorsan Lite; sıfırdan başlayıp Swift'i tek dil olarak tutmak istiyorsan Fuse daha az sürpriz çıkarır.

Bu kararı verirken ekibinin mevcut yetkinliğini de hesaba kat. Lite modunda üretilen Kotlin üzerinden tam stack trace alır, Android Studio'nun yerleşik Kotlin/Java hata ayıklama araçlarını doğrudan kullanabilirsin — bu, Kotlin'e de aşina bir ekipte belirgin bir avantaj, saf SwiftUI ekiplerinde ise ilk haftalarda öğrenme eğrisi yaratabilir. Fuse modunda ise Android'de native kodu ayıklamak, resmi dokümanın dezavantajlar listesinde de belirttiği gibi üretilen Kotlin'i ayıklamaktan daha zordur; buna ek olarak Kotlin/Java tarafındaki bir kütüphaneyi kullanmak istediğinde SkipBridge köprüsünün ek bir soyutlama katmanı eklediğini göz önünde bulundurmalısın.

Kurulum: Xcode, Android SDK ve skip checkup

Skip'in resmi kurulum dokümanına göre gereken araçlar: Xcode, Android Studio ve Homebrew. Kurulum sırası şöyle:

1# 1) Skip'i Homebrew ile kur (Android SDK ve gradle bağımlılıklarıyla birlikte)
2brew install skip
3 
4# 2) Ortamı doğrula — Xcode, Android SDK sürümlerini kontrol eder
5# ve örnek bir hello-skip projesini derler
6skip checkup
7 
8# 3) Yeni proje oluştur — App ya da Library, Fuse ya da Lite seçimiyle
9skip create

skip create çalıştırıldığında sana proje tipini (App/Library) ve modu (Fuse/Lite) soran interaktif bir sihirbaz açılır. Kurulum dokümanındaki örnek çıktıda spesifik bir Skip sürüm numarası görebilirsin — bu yalnızca komutun nasıl davrandığını gösteren bir örnektir, kendi kurulumunda skip checkup çıktısında hangi sürümün geldiğine bak; Skip sık patch yayınlıyor (Eylül 2026'da haftada birkaç sürüm çıktığı görüldü), bu yazı hazırlandığı sırada (24 Eylül 2026) GitHub'daki en güncel etiket 1.9.11'di.

İlk Ekranı İki Platformda Çalıştırmak

skip create ile oluşturduğun App projesi, tek bir SwiftUI kaynak dosyasından hem iOS hem Android hedefini üretecek şekilde kurulur. Xcode tarafında normal bir SwiftUI önizlemesi görürsün; Android tarafında ise proje bir Gradle modülü olarak Android Studio'da açılır ve emülatörde ya da fiziksel cihazda çalışır.

1// ContentView.swift — tek kaynak, iki platform
2import SwiftUI
3 
4struct ContentView: View {
5    @State private var count = 0
6 
7    var body: some View {
8        VStack(spacing: 16) {
9            Text("Skip ile merhaba")
10                .font(.title)
11            Text("Sayaç: \(count)")
12            Button("Artır") {
13                count += 1
14            }
15        }
16        .padding()
17    }
18}

Her iki modda da Android tarafındaki arayüz gerçek bir Jetpack Compose ağacıdır — paralel bir widget seti değil, doğrudan Compose bileşenleri çalışır. Fark UI katmanında değil, iş mantığının derlenme biçimindedir: Fuse modunda bu kod Android'de native Swift olarak derlenir ve SkipFuseUI ince bir köprü katmanı olarak render'ı SkipUI'a devreder; SkipUI de SwiftUI görünümlerini Jetpack Compose composable'ları olarak uygular. Lite modunda ise transpiler Swift'i idiomatik Kotlin'e çevirir. Bu ayrım bir sonraki bölümde ele alacağımız "Compose First" kararının temelini oluşturuyor.

Pratikte akış şöyle işler: Xcode'da normal şekilde Cmd+R ile derleyip iOS simülatöründe önizlersin — burada Skip'in araya girdiğini fark etmezsin bile, çünkü Fuse ya da Lite fark etmeksizin iOS tarafı zaten doğrudan Apple'ın SwiftUI'ı ile çalışır. Android tarafı için ise skip create sırasında oluşturulan Gradle modülünü Android Studio'da açman, ardından normal bir Gradle senkronizasyonu ve "Run" adımıyla emülatörde ya da fiziksel cihazda başlatman yeterli. İlk derleme (özellikle Fuse modunda Swift SDK for Android'in araç zincirini ilk kez indirdiği an) diğer derlemelere göre belirgin şekilde daha uzun sürer; sonraki build'ler artımlı olduğu için hızlanır. Resmi dokümanın belirttiği gibi, native Swift'i Android araç zinciriyle derleyip dağıtmak transpile ederek derlemekten daha yavaştır; bir modülü Lite'tan Fuse'a (ya da tersine) geçirdiğinde o modülün derleme süresi profilinin değiştiğini hesaba kat — bu yüzden mod kararını proje büyümeden, mümkünse ilk hafta içinde netleştirmek pratikte zaman kazandırıyor.

SwiftUI'ın Compose'a Çevrilmeyen Kısımları

Skip Lite'ın Swift → Kotlin transpiler'ı SwiftUI ve Swift dilinin geniş bir alt kümesini destekler, ama sınırsız değildir. Resmi dokümana göre 24 Eylül 2026 itibarıyla desteklenmeyen ya da sınırlı desteklenen alanlar şunlar:

• Fonksiyon içi tip tanımları: bir fonksiyonun gövdesinde struct veya class tanımlamak transpile edilemiyor.
• Arity 6 ve üzeri tuple'lar: altı veya daha fazla elemanlı tuple'lar transpiler tarafından desteklenmiyor.
• Bazı generic + protocol constructor kombinasyonları: generic bir tipin protocol tabanlı initializer'larıyla birleştiği belirli örüntüler sınırlı destekleniyor.

Bu sınırlardan biriyle karşılaşırsan iki seçeneğin var: ilgili kodu daha basit bir örüntüyle yeniden yaz, ya da o modülü Fuse moduna taşı (Fuse native Swift derlediği için transpiler sınırlarına tabi değil).

Örneğin arity 6+ bir tuple döndüren bir fonksiyonun Lite modunda transpile edilmesini beklemek yerine, aynı veriyi taşıyan küçük bir struct tanımlamak hem daha okunabilir hem de transpiler-uyumlu bir çözüm:

1// Transpile edilemeyen örüntü: 6+ elemanlı tuple
2// func kullaniciOzet() -> (String, Int, Bool, String, Int, Bool) { ... }
3 
4// Yerine: isimlendirilmiş alanlarla struct
5struct KullaniciOzet {
6    let ad: String
7    let yas: Int
8    let aktif: Bool
9    let sehir: String
10    let puan: Int
11    let dogrulanmis: Bool
12}
13 
14func kullaniciOzet() -> KullaniciOzet {
15    KullaniciOzet(ad: "Ada", yas: 29, aktif: true, sehir: "İzmir", puan: 87, dogrulanmis: true)
16}

Bu değişim yalnızca transpiler uyumluluğu için değil, genel olarak daha okunabilir bir API tasarımı için de tercih edilir — tuple yerine isimlendirilmiş alan kullanmak, kodu okuyan başka bir geliştirici için de daha az belirsizlik bırakır.

Platform-Özel Kod Yazma

Bazı durumlarda iki platform için farklı davranış yazman gerekir — bir Android izni istemek, ya da bir Kotlin kütüphanesini doğrudan çağırmak gibi. Skip bunun için iki farklı derleme direktifi sunar ve ikisinin anlamı birbirinden net şekilde ayrılır:

1// #if os(Android): platform kontrolüdür.
2// Fuse modunda bu blok native Swift olarak kalır,
3// Lite modunda transpile edilir — ama her iki modda da çalışır.
4#if os(Android)
5print("Android'de çalışıyoruz")
6#endif
7 
8// #if SKIP: her zaman Kotlin'e transpile edilir.
9// Kotlin/Java API'lerine doğrudan erişmek istediğinde kullanılır.
10#if SKIP
11// Buraya yalnızca Kotlin/Java tarafına özel çağrılar gelir
12#endif

Pratik fark şu: #if os(Android) bir platform ayrımı sorusudur — "bu kod Android'de mi çalışıyor?" #if SKIP ise bir derleme hedefi sorusudur — "bu kod Kotlin'e mi çevriliyor?" Kotlin/Java API'sine erişmen gereken kod her zaman #if SKIP bloğunda olmalı, çünkü #if SKIP bloğu moddan bağımsız olarak her zaman Kotlin'e transpile edilir; Fuse modunda #if os(Android) bloğu native Swift olarak kalır ve oradan Kotlin/Java API çağıramazsın.

"Compose First" Kararının Pratik Anlamı

2026 Google I/O'da Android ekibi önemli bir yön değişikliği duyurdu: tüm yeni UI geliştirmesi artık Jetpack Compose ile yapılacak, klasik View toolkit'i ise "bakım modu"na alındı. Bu karar Skip'in mimarisini doğrudan doğruladı, çünkü Skip kuruluşundan beri Compose-first bir yaklaşım izliyor: Lite modunda transpiler SwiftUI'ı idiomatik Compose'a çevirir, Fuse modunda ise native Swift doğrudan Compose'a köprülenir — her iki durumda da Android UI'ı paralel bir widget hiyerarşisi değil, gerçek bir Compose ağacıdır. iOS tarafında da benzer bir prensip geçerli — Skip'in kendi runtime'ı SwiftUI'ı taklit etmiyor, doğrudan Apple'ın SwiftUI framework'ünü kullanıyor. Bu yüzden Apple yeni bir görsel dil (ör. iOS 26 ile gelen Liquid Glass) tanıttığında, Skip uygulamaları bunu otomatik olarak miras alıyor — ayrı bir güncelleme beklemene gerek kalmıyor.

Bu kararın pratik sonucu, Android tarafında bileşen seviyesinde beklenmedik davranış farkları görme riskinin azalmasıdır. Skip'ten önce çoğu "tek kod tabanı" aracı, iki platformun UI sistemini kendi soyutlama katmanının arkasına gizler; bu da platform güncellemesi geldiğinde soyutlama katmanının güncellenmesini beklemen anlamına gelir. Skip'in Compose-first ve SwiftUI-first duruşu bu bekleme süresini modda tutuyor: her iki modda da Android tarafındaki çıktı standart bir Compose ağacı olduğu için, Jetpack Compose'un kendi güncellemelerini (yeni bileşen, yeni modifier) olağan bir Android geliştiricisi gibi doğrudan kullanabilirsin — Skip'in bunları ayrıca "desteklemesini" beklemene gerek kalmaz.

Gerçek Proje Sınırları

Skip'i değerlendirirken onu diğer cross-platform araçlarıyla aynı kategoriye koymamak önemli. Flutter, Compose Multiplatform'un iOS hedefi ve React Native gibi araçlar "pixel-painted widget" (kendi çizim motoruyla platformun görünümünü taklit etme) ya da eski nesil köprü mimarisi kullanır; platformun tasarım dili değiştiğinde bu araçların yeni görünümü yakalaması ayrı bir mühendislik işidir. Skip ise Android'de gerçek Compose, iOS'ta gerçek SwiftUI çalıştırdığı için bu senkronizasyon maliyetini büyük ölçüde ortadan kaldırıyor. Bunun bedeli de var: transpiler sınırları (yukarıdaki bölümde gördüğün gibi), Fuse modunda Swift standart kütüphanesinin, Foundation'ın ve Swift uluslararasılaştırma kütüphanelerinin paketlenmesinden gelen yaklaşık 60 MB'lık ek Android paket boyutu ve hâlâ olgunlaşmakta olan Swift SDK for Android'e bağımlılık. Swift Android SDK'nın gerçek üretim durumunu ve hangi senaryolarda hâlâ eksik kaldığını Swift ile Android: 6.3 Android SDK Gerçekten Çalışıyor mu? yazısında bulabilirsin.

Bu sınırın somut bir örneği Flutter tarafında görülebilir: iOS 26 ile gelen "Liquid Glass" tasarım diline Cupertino widget setinde destek isteyen GitHub issue'su (flutter/flutter #170310) Haziran 2025'te açıldı ve 24 Eylül 2026 itibarıyla hâlâ açık — çünkü Flutter'ın kendi çizim motoru, Apple'ın yeni tasarım dilini "taklit etmek" için ayrı bir mühendislik çalışması gerektiriyor. Skip'in Fuse modunda aynı senaryo söz konusu değil: SwiftUI doğrudan Apple'ın kendi framework'ü olduğu için yeni tasarım dili otomatik olarak gelir, ayrı bir widget güncellemesi beklemene gerek kalmaz. Bunun karşılığında ödediğin bedel ise Swift SDK for Android'in Swift 6.3 ile henüz resmi hale gelmiş, dolayısıyla Flutter'ın yıllara dayanan Android desteği kadar olgunlaşmamış bir araç zincirine bağımlı olmak.

Ne Zaman KMP'yi Tercih Etmelisin

Skip her projeye uygun değil. UI katmanını da tek kaynaktan yönetmek, SwiftUI'ı öğrenmiş bir ekiple hem iOS hem Android'i aynı anda geliştirmek istiyorsan Skip mantıklı bir seçim. Ama şu senaryolarda Kotlin Multiplatform (KMP) daha az sürtünmeli bir yol sunar:

• Ekibinde zaten güçlü bir Android/Kotlin çekirdek var ve yalnızca iş mantığını (network, veritabanı, use-case) paylaşmak istiyorsun — UI'ları platforma özgü native kalsın istiyorsan.
• Mevcut bir Android uygulaman var ve iOS'a yeni giriyorsun; KMP'nin "sadece paylaşımlı çekirdek" modeli daha az yeniden yazım gerektirir.
• Ekibinizde SwiftUI deneyimi sınırlı ama Kotlin deneyimi derinse.

Karar vermeden önce iki aracın paylaşım kapsamını yan yana koymak faydalı:

Skip ve KMP'yi paylaşımlı çekirdek kararı açısından karşılaştıran derinlemesine analiz için Swift Android SDK mı KMP mi? Paylaşımlı Çekirdek Kararı yazısına, Kotlin'in Swift tarafına köprü kurma girişimi için ise Kotlin 2.4 Swift Export: KMP'de Obj-C Köprüsü Bitiyor mu? yazısına bakabilirsin. İki aracı doğrudan yan yana koyan kısa karşılaştırma için Skip vs Kotlin Multiplatform (2026) sayfası daha hızlı bir özet sunuyor.

SSS

Skip ile SwiftUI kodu Android'de nasıl çalışır?

İki farklı yoldan biriyle: Fuse modunda Swift kodun Swift SDK for Android üzerinden native derlenir ve Android'de gerçek Swift olarak çalışır; SkipFuseUI ince bir köprü katmanı olarak render'ı SkipUI'a devreder, SkipUI de SwiftUI görünümlerini Jetpack Compose composable'ları olarak uygular. Lite modunda ise Swift kaynak kodu derleme zamanında Kotlin'e transpile edilir. Her iki modda da Android'de çalışan arayüz gerçek bir Jetpack Compose ağacıdır — paralel bir widget seti değil. Her iki durumda da senin yazdığın tek kaynak SwiftUI kodu; hangi motorun devrede olduğunu belirleyen şey proje ya da modül oluştururken seçtiğin mod.

Skip Lite ile Skip Fuse arasındaki fark nedir?

Lite, Swift'i Kotlin'e çevirerek mevcut Kotlin/Java kütüphaneleriyle maksimum interop sağlar ama transpiler'ın desteklemediği ya da sınırlı desteklediği bazı Swift örüntülerinde (fonksiyon içi tip tanımı, arity 6+ tuple, bazı generic+protocol constructor kombinasyonları) kısıtlıdır. Fuse ise Swift SDK for Android'i kullanarak native derleme yapar, Swift dilinin tamamını destekler ve deterministik bellek yönetimi sağlar, ama Kotlin/Java tarafına erişim için SkipBridge'in otomatik köprüsüne ve #if SKIP bloklarına (ya da AnyDynamicObject'e) ihtiyaç duyar.

Skip ücretsiz mi?

Evet. Skip, 21 Ocak 2026'da yayınlanan 1.7 sürümüyle birlikte lisans anahtarı gereksinimini kaldırdı; "skipstone" motoru dahil araç seti tamamen ücretsiz ve açık kaynak hale geldi, geliştirme sponsorluklarla finanse ediliyor.

Skip ile üretilen Android uygulaması native mi?

Fuse modunda evet — Swift kodun Swift SDK for Android ile native derlenir. Lite modunda uygulama gerçek bir Kotlin/Compose projesine dönüştüğü için Android'in kendi çalışma zamanında native bir Kotlin uygulaması gibi çalışır; aradaki fark hangi dilde yazıldığıdır, ikisi de platformun kendi runtime'ında (JVM/ART) çalışan gerçek bir Android uygulaması üretir. Bu, Skip'i WebView tabanlı ya da tamamen kendi çizim motorunu kullanan araçlardan ayıran temel özellik: çıktı, arayüzünü platformun kendi Compose ağacıyla çizen gerçek bir Android uygulamasıdır.

Skip'i Fuse ile başlayıp sonra Lite'a (ya da tersine) geçirebilir miyim?

Mod seçimi modül bazında yapıldığı için evet, ama bunu ücretsiz bir işlem gibi düşünme. Bir modülü bir moddan diğerine taşımak, o modülün derleme süresi profilinin değişmesi (resmi dokümanın belirttiği gibi native Swift'i Android araç zinciriyle derlemek transpile ederek derlemekten daha yavaştır) ve modülün kullandığı Kotlin/Java ya da Apple framework API'lerinin karşı tarafta nasıl karşılandığını yeniden gözden geçirmen anlamına gelir. Bu yüzden mod kararını, "Lite vs Fuse: Hangi Modu Seçmelisin" bölümündeki kriterlere göre proje başında netleştirmek, ileride modül taşıma maliyetinden kaçınmanın en pratik yolu.

Sonuç

Skip'i denemek için beklediğin büyük engel muhtemelen zaten ortadan kalktı: kurulum tek bir brew install skip komutu, lisans maliyeti sıfır. Gerçek karar noktası mod seçimi — Kotlin/Java ekosistemine derin entegrasyon istiyorsan Lite, Swift'i tek dil olarak tutmak istiyorsan Fuse. Skip'in Android SDK for Swift üzerindeki gerçek olgunluk durumunu Swift ile Android: 6.3 Android SDK Gerçekten Çalışıyor mu? yazısından, paylaşımlı çekirdek kararını Swift Android SDK mı KMP mi? yazısından takip edebilirsin. Kotlin tarafındaki üretim deneyimi için Kotlin Multiplatform 1.1 Stable: Production Case Study 2026 ve Compose Multiplatform: Android + iOS Production Deployment 2026 yazılarına, Android'e geçiş yapan bir iOS geliştiricisinin bakış açısı için iOS Geliştiricinin Android'e Geçişi: Yol Haritası yazısına göz atabilirsin.

Kaynaklar

• Skip Releases (GitHub Atom feed) — sürüm geçmişi ve yayın tarihleri, 1.9.11'in 19 Eylül 2026'da yayınlandığını doğrular.
• Skip: Getting Started — resmi kurulum adımları (Homebrew, skip checkup, skip create).
• Skip: Modes (Lite ve Fuse) — iki modun mimari farkları, Fuse'un ~60 MB'lık paket boyutu ve derleme süresi bedeli.
• Skip: Swift Language Support — Lite transpiler'ının desteklemediği Swift örüntüleri.
• Skip: Platform Customization — #if os(Android) ve #if SKIP direktiflerinin kullanımı.
• Skip: Bridging Reference — tam nitelikli Kotlin/Java tiplerinin AnyDynamicObject'e çevrilmesi.
• Skip: SkipFuseUI — SkipFuseUI'ın render'ı SkipUI'a devreden ince köprü katmanı rolü.
• Skip is Free (skip.dev blog) — lisans anahtarının kaldırılması ve açık kaynak duyurusu.
• Skip: Compose First (skip.dev blog) — Google I/O 2026 Compose-first kararı ve Skip'in buna uyumu.
• Swift 6.3 Released (swift.org) — Swift SDK for Android'in resmi ilk sürümü.
• Skip: Swift 6.3 Android Support (skip.dev blog) — Skip'in resmi Android SDK ile ilişkisi.
• Support for iOS 26 "Liquid Glass" Design in Cupertino Widgets (GitHub Issue #170310) — Flutter'ın platform tasarım dili değişikliklerine yetişme maliyetine somut örnek.