iOS Geliştiricisi İçin Cross-Platform Seçimi: 2026 Kararı

iOS geliştiricisi cross platform seçimi 2026 sorusuyla karşı karşıyaysan aslında tek bir framework değil, bir karar çerçevesi arıyorsun demektir. Flutter 3.47, React Native 0.87, Compose Multiplatform 1.12.0, Skip ve Capacitor'ün hepsi Eylül 2026 itibarıyla aktif ve bakımlı; "en iyisi" diye tek bir cevap yok, doğru cevap ekip büyüklüğüne, bütçene ve SwiftUI bilgini ne kadar taşımak istediğine göre değişiyor. Bu yazı sana beş seçeneği tek tek anlatmak yerine, kararı beş soruya indirip hangi cevabın seni hangi seçeneğe götürdüğünü gösteriyor.

💡 Pro Tip: Framework seçimini "hangisi daha hızlı" diye sorarak değil, "3 yıl sonra bu kod tabanını kim sürdürecek" diye sorarak yap — çoğu yanlış seçim, ilk haftanın hızından değil üçüncü yılın bakım yükünden doğar.

İçindekiler

• Karar Aslında 5 Soruya İniyor
• Seçenek Haritası: Beş Yol, Beş Farklı Felsefe
• Flutter 3.47
• React Native 0.87 + Expo
• Compose Multiplatform (Kotlin Multiplatform)
• Skip: Swift'ten Android'e
• Capacitor: Web Bilgini Native Kabuğa Taşı
• Referans: .NET MAUI Nerede Duruyor?
• SwiftUI Bilgisinin Taşınabilirliği
• Ekip 1 Kişi mi, 5 Kişi mi? Ölçeğe Göre Karar
• İşe Alım ve Devir Maliyeti (Türkiye Pazarı)
• 3 Yıllık Bakım Maliyeti ve Sürüm-Yükseltme Vergisi
• Yanlış Seçimden Çıkış Maliyeti
• Karar Tablosu ve Hızlı Karar Kutusu
• SSS
• iOS geliştiricisi hangi cross-platform framework'ü seçmeli?
• SwiftUI bilen biri için en hızlı öğrenilen framework hangisi?
• Tek geliştiriciyle iki platform sürdürülebilir mi?
• Ekip büyüklüğü framework seçimini nasıl değiştirir?
• Hangi framework en az zorunlu migrasyon çıkarıyor?
• İşe alım havuzu hangi framework'te daha geniş?
• Sonuç
• Kaynaklar

Karar Aslında 5 Soruya İniyor

Cross-platform tartışması genelde "hangi framework daha performanslı" sorusuyla başlıyor, ama bu soru seni yanlış yöne götürür. Eylül 2026 itibarıyla Flutter, React Native, Compose Multiplatform, Skip ve Capacitor'ün hepsi üretim kalitesinde render performansı sunabiliyor; aradaki fark artık ham hızda değil, ekibinin bu kod tabanıyla nasıl bir ilişkisi olacağında. Kararını netleştirmek için kendine şu beş soruyu sor:

• Ekibim kaç kişi ve kim yazacak? Tek başına bir iOS geliştiricisiysen öncelik farklı, 5 kişilik karma bir ekipsen öncelik farklı.
• SwiftUI bilgimin ne kadarını taşımak istiyorum? Söz dizimi mi, yoksa framework'ün kendisi mi?
• Bu proje kaç yıl yaşayacak? 6 aylık bir MVP ile 3 yıllık bir ürün için doğru seçim aynı değil.
• İşe alım havuzum nerede geniş? Türkiye pazarında hangi teknolojide daha kolay geliştirici buluyorsun?
• Yanlış seçersem çıkış maliyetim ne olur? Bu framework'ten çıkmak ne kadar acı verir?

Aşağıdaki bölümler bu beş soruyu tek tek açıyor ve sonunda hepsini tek bir karar tablosunda birleştiriyor.

Seçenek Haritası: Beş Yol, Beş Farklı Felsefe

Karar tablosuna geçmeden önce beş seçeneğin Eylül 2026 itibarıyla nerede durduğunu netleştirelim. Her biri farklı bir varsayımla tasarlandı — bu farkı bilmeden hiçbir karar tablosu anlam ifade etmez.

Flutter 3.47

Flutter 3.47, flutter.dev'in resmi duyurusuna göre 12 Ağustos 2026'da yayınlandı. Bu sürümün başlığı "Modular by design" — material_ui ve cupertino_ui paketleri artık pub.dev'de standalone 1.0 sürümüne ulaştı, yani tasarım sistemleri çekirdek SDK'dan bağımsız olarak kendi haftalık takvimlerinde güncellenebiliyor. Impeller render motoru masaüstünde varsayılan hale geldi ve Flutter Widget Previews stabil kanala geçti. Flutter'ın felsefesi net: kendi widget ağacını, kendi render motorunu kullanarak platformdan bağımsız tek bir görsel dil sunmak.

React Native 0.87 + Expo

React Native 0.87, reactnative.dev'in resmi blogundaki duyuruya göre 11 Ağustos 2026'da yayınlandı. Bu sürümdeki en büyük değişiklik Strict TypeScript API'nin artık varsayılan olması — 0.80'de opt-in bir önizlemeydi, 0.87'de zorunlu varsayılan oldu (opt-out yalnızca 0.88'e kadar açık kalacak). Minimum toolchain de yükseltildi: Node.js 22, AGP 9, Kotlin 2.0+.

iOS tarafında dikkat çeken gelişme deneysel Swift Package Manager desteği — bu, CocoaPods bağımlılığını azaltma yönünde atılmış bir adım ve iOS geliştiricisi için özellikle anlamlı. Metro paketleyici 0.84'ten 0.87'ye güncellendi ve source map üretimi hızlandı. React Native'in felsefesi Flutter'ın tam tersi: kendi widget ağacı yerine platformun native bileşenlerini JavaScript/TypeScript köprüsüyle sürüyor.

Compose Multiplatform (Kotlin Multiplatform)

Compose Multiplatform 1.12.0, JetBrains'in resmi GitHub release kaydına göre Ağustos 2026'da yayınlandı. Öne çıkan özellik Compose Hot Reload için eklenen MCP server desteği — bu, çalışan bir Compose uygulamasıyla gerçek zamanlı etkileşim kurmasına imkân tanıyan bir AI-ajan entegrasyonu. Kırılma değişikliği de var: NativeCanvas ve NativePaint typealias'larının deprecation seviyesi ERROR'a yükseltildi, yani bu eski API'yi kullanan projeler artık derleme zamanında hata alıyor. Compose Multiplatform'un felsefesi Jetpack Compose'un state-hoisting modelini Android sınırlarının dışına, iOS ve masaüstüne taşımak.

Skip: Swift'ten Android'e

Skip, diğer dördünden farklı bir yönden geliyor: Swift kodunu Android'e taşıyor, tersi değil. skiptools/skip GitHub release listesine göre en güncel etiket 1.9.11, 19 Eylül 2026'da yayınlandı — proje haftalık kadansta aktif güncelleniyor, ama hâlâ 1.x sürüm hattında, yani major 1.0 sonrası olgunlaşma aşamasında. Flutter, React Native ve Compose Multiplatform'un ulaştığı üretim ölçeğiyle doğrudan kıyaslanabilir bir olgunluk seviyesinde değil. Skip'i "genel cross-platform seçeneği" olarak değil, "SwiftUI'de yazılmış bir iOS uygulamasını Android'e uzatmak isteyen ekipler için niş bir yol" olarak değerlendirmek daha dürüst bir çerçeve.

Capacitor: Web Bilgini Native Kabuğa Taşı

Capacitor'ün kararlı hattı npm registry'ye göre 8.5.2. Major 9 hattı henüz alpha aşamasında — 9.0.0-alpha.7, ionic-team/capacitor GitHub release kaydına göre 18 Eylül 2026'da yayınlandı. Yani Eylül 2026 itibarıyla üretim için güncel öneri Capacitor 8.5.x hattı. Capacitor, Flutter/RN/Compose Multiplatform'dan tamamen farklı bir varsayımla çalışıyor: mobil UI'yi native değil web teknolojileriyle (HTML/CSS/JS) yazıp bunu ince bir native kabuğun içine koyuyor. Bir iOS geliştiricisi için bu, en az "native hissi" veren ama zaten web ekibi olan şirketler için en düşük giriş maliyetli seçenek.

Referans: .NET MAUI Nerede Duruyor?

Karar tablosuna dahil etmediğimiz ama sık karşılaştırılan bir isim daha var: .NET MAUI. dotnet/maui GitHub release listesine göre güncel etiket 10.0.110 — bu bir GA (genel kullanıma açık) bakım sürümü, aday sürüm (RC) değil; MAUI 10 aylar önce stabil hale geldi ve şu an düzenli patch alıyor. Bu yazı MAUI'yi ana beşliye dahil etmiyor çünkü C#/.NET ekosistemi zaten farklı bir işe alım ve araç zinciri varsayımı taşıyor — ama bir .NET arka planı olan ekipler için göz ardı edilmemesi gereken kararlı bir seçenek.

SwiftUI Bilgisinin Taşınabilirliği

Bu, çoğu iOS geliştiricisinin atladığı ama kararı en çok etkileyen sorulardan biri: SwiftUI bilgim cross-platform'a geçince ne kadar korunur? swift.org'un "What's new in Swift: August 2026 Edition" yazısı (4 Eylül 2026 yayın) Swift dilinin ve araç zincirinin platform-ötesi genişlediğini gösteriyor: Swift on Windows bir yıllık olgunlaşma sürecinden geçiyor, Embedded Swift mikrodenetleyicilere (Raspberry Pi Pico gibi) kadar iniyor, ElementaryUI gibi topluluk projeleri Swift'i WebAssembly ve tarayıcı tarafına taşımaya çalışıyor. Ama bu genişleme Swift dilini taşıyor, SwiftUI framework'ünün kendisini değil.

Gerçekçi cevap şu: SwiftUI framework'ü hâlâ Apple platformlarına kilitli. Onu React Native, Flutter veya Compose Multiplatform projende doğrudan kullanamazsın. Taşınan şey söz dizimi alışkanlığın ve deklaratif düşünme biçimin — @State, tek yönlü veri akışı, bildirimsel view ağacı gibi kavramlar Jetpack Compose'da ve Compose Multiplatform'da neredeyse birebir karşılık buluyor, bu yüzden bir SwiftUI geliştiricisi Compose'u genelde birkaç hafta içinde rahat okur hale geliyor. React Native ve Flutter'da bu kavramsal köprü daha zayıf: React Native JSX + hook modeline, Flutter ise kendi widget ağacı ve StatefulWidget/StatelessWidget ayrımına dayanıyor — ikisi de öğrenilebilir ama SwiftUI'den gelen refleksler doğrudan işe yaramaz.

1# Elindeki projenin hangi sürümlerle çalıştığını doğrulamak için
2# framework seçmeden önce her zaman kaynağa bak, blog yazısına değil
3flutter --version
4npx react-native --version
5cat package.json | grep '"react-native"'

Ekip 1 Kişi mi, 5 Kişi mi? Ölçeğe Göre Karar

Ekip büyüklüğü, framework seçimini teknik özelliklerden çok daha fazla etkiliyor — çünkü her framework'ün "bakım vergisi" farklı büyüklükte ekiplere farklı ağırlıkta biniyor.

Tek başına çalışan bir iOS geliştiricisiysen önceliğin düşük churn (değişim hızı) olmalı: yeni bir major sürümün API'lerini yeniden öğrenmeye harcayacak vaktin sınırlı. Flutter'ın material_ui/cupertino_ui paketlerinin SDK'dan bağımsız hale gelmesi burada avantaj — çekirdek SDK'daki özgün tasarım kütüphaneleri Kasım 2026'daki Fall stable sürümünde resmen deprecate edilecek, yani zorunlu bir geçiş takvimine hemen girmiyorsun ama tarihi not et.

5 kişilik karma bir ekipte (iOS + Android + web geçmişi karışık) durum tersine dönüyor: React Native 0.87'nin getirdiği gibi büyük, ekosistem-genelinde kasıtlı breaking change'ler (Strict TypeScript API'nin zorunlu hale gelmesi) büyük bir ekipte paralel olarak absorbe edilebilir — birileri migration'ı üstlenirken diğerleri özellik geliştirmeye devam edebilir. Küçük ekipte aynı değişiklik haftalarca özellik geliştirmeyi durdurabilir.

İşe Alım ve Devir Maliyeti (Türkiye Pazarı)

Bu bölümde net bir uyarı yapmam gerekiyor: Türkiye pazarı için framework bazlı işe alım oranlarını ya da maaş verilerini gösteren doğrulanmış, güncel bir kaynak bu araştırmada bulunamadı — bu yüzden burada sayı iddia etmiyorum, bunun yerine kararını etkileyecek yapısal gerçekleri sıralıyorum.

• JavaScript/TypeScript havuzu geniş, React Native deneyimi eşit değil. Türkiye'de web geliştiricisi bulmak kolay ama "React Native + native modül debug edebilen" geliştirici bulmak ayrı bir beceri seti gerektiriyor; işe alırken bunu ayrı bir kriter olarak sor.
• Flutter/Dart tek amaçlı bir uzmanlık. Dart'ı başka hiçbir yerde kullanmayacaksın, yani işe aldığın kişi muhtemelen Flutter'a özel olarak yatırım yapmış biri olacak — bu hem artı (odaklanmış uzmanlık) hem eksi (dar havuz).
• Compose Multiplatform, Android/Kotlin ekibinin doğal uzantısı. Zaten Kotlin yazan bir Android ekibin varsa, Compose Multiplatform'a geçiş devir maliyeti açısından en düşük sürtünmeli yol — mevcut ekip yeni bir dil öğrenmiyor, yalnızca yeni bir hedef platform ekliyor.
• Skip ve Capacitor niş kalıyor. İkisi de küçük ama aktif topluluklara sahip; bu, işe alırken "bu teknolojiyi bilen kaç kişi var" sorusunu daha dikkatli sormanı gerektiriyor.

Devir (handoff) maliyeti açısından pratik soru şu: Sen bu projeden ayrılırsan, yerine gelen kişi kod tabanını ne kadar hızlı anlar? Native-hisli bir mimariye (Compose Multiplatform, kısmen Skip) aşina bir iOS/Android geliştiricisi genelde daha hızlı adapte olur; web-öncelikli bir mimariye (React Native, Capacitor) geçiş ise büyük ölçüde geliştiricinin JS/TS geçmişine bağlı.

3 Yıllık Bakım Maliyeti ve Sürüm-Yükseltme Vergisi

"Sürüm-yükseltme vergisi" derken kastettiğim şey şu: her framework, seni belirli aralıklarla zorunlu bir migrasyona sokuyor ve bu migrasyonun boyutu framework'e göre büyük farklılık gösteriyor. Üç örneği somut kaynaklarla karşılaştıralım:

• React Native 0.87 Strict TypeScript API'yi varsayılan yaptı — mevcut projelerin tip hatalarını düzeltmesi gerekiyor, opt-out yalnızca 0.88'e kadar açık kalacak, yani bu geçici bir erteleme, kalıcı bir kaçış yolu değil.
• Compose Multiplatform 1.12.0 NativeCanvas/NativePaint typealias'larının deprecation seviyesini ERROR'a çıkardı — bu API'leri kullanan projeler artık derlenmiyor, yükseltme opsiyonel değil zorunlu hale geldi.
• Capacitor, iOS 27/Xcode 27 için zorunlu UIScene geçişini npx cap migrate gibi tek bir komutla yönetilebilir hale getirdi; mevcut App Store'daki uygulamalar bu geçişten etkilenmiyor, ama yeni build'ler geçişi yapmak zorunda.

Üç örnek de gösteriyor ki hiçbir framework "sürüm yükseltmeden sonsuza kadar kaç" vaat etmiyor. Fark, yükseltmenin ne sıklıkla ve ne kadar acılı geldiğinde.

1// Compose Multiplatform 1.12.0'da NativeCanvas/NativePaint
2// typealias'larının deprecation seviyesi ERROR'a çıkarıldı.
3// Eski projelerde bu satır artık derlenmiyor:
4// val canvas: NativeCanvas = ...
5// Yerine platforma özgü Skia tabanlı API'ye geçmek zorunlu.

Yanlış Seçimden Çıkış Maliyeti

Bir framework'ü seçtikten 18 ay sonra yanlış olduğunu fark edersen ne olur? Bu soru, karar anında en az sorulan ama en pahalı sorulardan biri.

• Flutter'dan çıkış: Dart kod tabanını sıfırdan yeniden yazman gerekir — paylaşılabilecek iş mantığı (state yönetimi, veri katmanı) kavramsal olarak taşınabilir ama satır satır kod taşınmaz.
• React Native'den çıkış: TypeScript iş mantığının bir kısmı (API katmanı, validasyon, state yönetimi) web veya backend tarafında yeniden kullanılabilir olabilir, ama UI katmanı native'e geçerken tamamen yeniden yazılır.
• Compose Multiplatform'dan çıkış: Zaten Kotlin/Android tarafın varsa, iOS tarafını SwiftUI'ye geçirmek "sıfırdan başlamak" değil, "paylaşılan katmanı kaldırıp platforma özel katmanı genişletmek" gibi görünür — göreceli olarak daha kontrollü bir çıkış.
• Capacitor'dan çıkış: Web katmanını native'e taşımak en büyük yeniden yazımı gerektirir, çünkü UI hiç native değildi.
• Skip'ten çıkış: Zaten Swift/SwiftUI yazıyorsan iOS tarafı sabit kalır, yalnızca Android hedefini kaybedersin — çıkış maliyeti diğerlerine göre en düşük, çünkü ana kod tabanın zaten native Swift'ti.

Genel kural: paylaşılan kodun oranı ne kadar yüksekse, çıkış maliyeti o kadar yüksek. "Her şeyi tek kod tabanında yaz" vaadinin gizli faturası, o tek kod tabanından ayrılmak istediğinde ödenir.

Karar Tablosu ve Hızlı Karar Kutusu

Yukarıdaki beş soruyu tek tabloda birleştirelim. Sürüm ve tarih bilgileri Eylül 2026 itibarıyla birincil kaynaklardan doğrulanmıştır.

Sürüm tablosu "ne kullanmalıyım" sorusuna cevap vermiyor, yalnızca "şu an nerede duruyorlar" sorusuna cevap veriyor. Kararı somutlaştırmak için beş sorunun her birine 0-10 arası bir ağırlıklı puan verip basit bir karşılaştırma yapabilirsin. Aşağıdaki örnek, ağırlıkları ekip-büyüklüğü %30, teslim-hızı %25, SwiftUI-aşinalığı %20, bütçe %25 olacak şekilde ayarlayıp iki seçeneği kıyaslıyor — hesaplamayı kendi ekibinin puanlarıyla tekrar çalıştırmalısın:

1// Basit ağırlıklı karar skoru — kendi puanlarınla tekrar çalıştır
2const weights = { team: 0.3, timeline: 0.25, swiftuiFit: 0.2, budget: 0.25 };
3 
4const flutter = { team: 8, timeline: 7, swiftuiFit: 5, budget: 8 };
5const reactNative = { team: 7, timeline: 8, swiftuiFit: 4, budget: 7 };
6 
7function score(option) {
8  return (
9    option.team * weights.team +
10    option.timeline * weights.timeline +
11    option.swiftuiFit * weights.swiftuiFit +
12    option.budget * weights.budget
13  );
14}
15 
16console.log("Flutter:", score(flutter)); // 7.15
17console.log("React Native:", score(reactNative)); // 6.65

Bu örnekte Flutter puanı 0.3*8 + 0.25*7 + 0.2*5 + 0.25*8 = 7.15, React Native puanı 0.3*7 + 0.25*8 + 0.2*4 + 0.25*7 = 6.65 çıkıyor — ama bu sayılar örnek ekip profiline özel, senin ekibinle farklı çıkabilir. Önemli olan sonuç değil, yöntem: her kritere ağırlık ver, sonra kıyasla.

Hızlı karar kutusu:

• Tek başınasın, SwiftUI'ye çok bağlısın, kısa vadeli MVP: Compose Multiplatform'u dene — kavramsal köprü en kısa, ama iOS tarafında hâlâ öğrenme eğrisi var.
• Web/React geçmişin var, geniş bir işe alım havuzuna ihtiyacın var: React Native + Expo, özellikle Strict TypeScript API'nin getirdiği tip güvenliğiyle.
• Zaten Android/Kotlin ekibin var, iOS'u da aynı ekibe eklemek istiyorsun: Compose Multiplatform net favori.
• SwiftUI'de yazılmış bir iOS uygulamasını Android'e uzatmak istiyorsun, ana platformun iOS kalacak: Skip'i değerlendir, ama 1.x olgunluk seviyesini göz önünde bulundur.
• Zaten bir web/PWA'n var, mobil sadece o web deneyimini kabuğa koymak: Capacitor 8.5.x, ama "native hissi" bekleme.

SSS

iOS geliştiricisi hangi cross-platform framework'ü seçmeli?

Tek doğru cevap yok; seçim ekip büyüklüğüne, bütçeye ve UI hedefine göre değişir. SwiftUI'ye kavramsal olarak yakın bir deneyim isteyenler Compose Multiplatform'un gelişen mimarisini değerlendirebilir; geniş bir JS/TS ekosistemine erişmek isteyenler React Native 0.87'nin Strict TypeScript API'sini dikkate almalı; web+masaüstü+mobil tek kod tabanı önceliği olanlar Flutter 3.47'yi incelemeli. .NET geçmişi olan ekipler için MAUI 10 GA hattı da kararlı bir referans noktası.

SwiftUI bilen biri için en hızlı öğrenilen framework hangisi?

Kavramsal olarak en yakın köprü Compose Multiplatform'da: composable fonksiyonlar ve state-hoisting modeli, SwiftUI'nin @State ve bildirimsel view ağacına yakın düşünülüyor. Ama bu bir "aynı framework" değil, yalnızca daha kısa bir öğrenme eğrisi anlamına geliyor — framework'ün kendi API'lerini (Compose'un layout sistemi, Kotlin dilinin kendisi) yine de öğrenmen gerekiyor.

Tek geliştiriciyle iki platform sürdürülebilir mi?

Teknik olarak evet — tek kod tabanı sunan framework'ler platforma özel kod yazma ihtiyacını azaltır. Ama "sürdürülebilir" derken framework'ün breaking-change temposunu da hesaba katmalısın: React Native 0.87'nin ekosistem genelinde kasıtlı olarak getirdiği breaking change'ler veya Capacitor'ün iOS 27/Xcode 27 için zorunlu UIScene geçişi gibi migrasyonlar, tek kişilik bir ekipte özellik geliştirmeyi haftalarca durdurabilir. Düşük-churn bir seçenek (örneğin Flutter'ın SDK'dan bağımsızlaşan tasarım paketleri) tek geliştirici için daha az risk taşır.

Ekip büyüklüğü framework seçimini nasıl değiştirir?

Büyük ekipler büyük breaking-change dalgalarını paralel olarak absorbe edebilir — biri migrasyonu üstlenirken diğerleri özellik geliştirmeye devam eder. Küçük ekiplerde aynı migrasyon tüm ekibin haftalarca durmasına neden olabilir. Bu yüzden küçük ekipler düşük-churn seçenekleri, büyük ekipler ise ekosistem büyüklüğünü (işe alım kolaylığı) daha yüksek önceliklendirebilir.

Hangi framework en az zorunlu migrasyon çıkarıyor?

Bu sorunun sabit bir cevabı yok çünkü her framework'ün migrasyon takvimi kendi sürüm döngüsüne bağlı. Eylül 2026 itibarıyla gördüğümüz örnekler (React Native'in Strict TypeScript API zorunluluğu, Compose Multiplatform'un NativeCanvas/NativePaint deprecation'ı, Capacitor'ün UIScene geçişi) hepsinin düzenli olarak zorunlu migrasyon çıkardığını gösteriyor — "migrasyonsuz framework" beklentisiyle seçim yapma, bunun yerine migrasyonların ne sıklıkla geldiğini ve ne kadar iyi dokümante edildiğini karşılaştır.

İşe alım havuzu hangi framework'te daha geniş?

Bu araştırmada Türkiye pazarına özel, doğrulanmış bir işe alım verisi bulunamadı. Genel yapısal gözlem şu: JavaScript/TypeScript geçmişi olan geliştirici havuzu geniş ama React Native'e özgü native-modül deneyimi ayrı bir kriter; Dart/Flutter uzmanlığı dar ama odaklanmış bir havuz; Compose Multiplatform ise mevcut Kotlin/Android ekiplerinin doğal uzantısı olduğu için ayrı bir işe alım süreci gerektirmeyebilir.

Sonuç

Cross-platform kararı 2026'da hâlâ "hangisi en hızlı" sorusundan ibaret değil; ekip büyüklüğün, SwiftUI bilgini ne kadar taşımak istediğin, projenin yaşam süresi ve yanlış seçimden çıkış maliyetin bir araya gelince ortaya çıkan bir denklem. Bu yazıda beş soruyu, beş güncel seçeneği (Flutter 3.47, React Native 0.87, Compose Multiplatform 1.12.0, Skip 1.9.11, Capacitor 8.5.x) ve bir karar tablosunu bir araya getirdik — ama son karar hâlâ senin ekibine özgü.

Konuyu daha derinlemesine incelemek istersen, Flutter vs SwiftUI: 3 Yıl + 60K LOC Production Karşılaştırması yazısı uzun vadeli bir üretim deneyimini satır satır anlatıyor. Flutter tarafında son sürüm değişikliklerini merak ediyorsan Flutter 3.47: material_ui ve cupertino_ui Paketlerine Geçiş yazısına bakabilirsin. Compose Multiplatform'u üretimde nasıl kullanacağını merak ediyorsan Compose Multiplatform: Android + iOS Production Deployment 2026 ve Kotlin Multiplatform 1.1 Stable: Production Case Study 2026 yazılarını, React Native tarafında son mimariyi ve production build sürecini merak ediyorsan React Native New Architecture 2026: Fabric, TurboModules ve Bridgeless Mode ve Expo SDK 52 EAS Build: Production Workflow ve 2026 Deployment Rehberi yazılarını okuyabilirsin.

Kaynaklar

• Flutter 3.47 duyurusu — material_ui/cupertino_ui'nin standalone 1.0'a ulaşması, Impeller ve Widget Previews.
• React Native 0.87 duyurusu — Strict TypeScript API'nin varsayılan olması ve minimum toolchain değişiklikleri.
• Compose Multiplatform 1.12.0 duyurusu — Compose Hot Reload MCP server desteği.
• Compose Multiplatform 1.12.0 GitHub release notları — NativeCanvas/NativePaint deprecation seviyesinin ERROR'a çıkarılması.
• Capacitor 8.5 duyurusu — 31 Temmuz 2026 yayın, iOS 27/Xcode 27 için zorunlu UIScene geçişi ve npx cap migrate komutu.
• Skip GitHub release listesi — 1.9.11 sürüm etiketi, 19 Eylül 2026 yayın tarihi.
• .NET MAUI 10.0.110 GitHub release notları — GA bakım sürümü, Eylül 2026.
• Swift.org: What's new in Swift, August 2026 Edition — Swift dilinin ve araç zincirinin platform-ötesi genişlemesi.