2026'da dürüst cevap şu: web tarafınız React ise ve ekibinizi JavaScript havuzundan kuruyorsanız React Native; iki platformda piksel düzeyinde aynı arayüz ve öngörülebilir render istiyorsanız Flutter. "Flutter hızlı, React Native olgun" ayrımı bitti; ikisi de mimari yeniden yazımlarını tamamladı. Bugün farkı yaratan şey performans değil, size devrettikleri göç borcu ve "tek kod tabanı" vaadinin nerede bittiği. Aşağıdaki sürüm bilgileri 25 Eylül 2026'da resmî yayın notlarından alınmıştır.
React Native'de mimari geçiş bitti, bu yüzden risk artık "kütüphane riski"
React Native 0.82 (8 Ekim 2025) New Architecture'ı tek mimari yaptı. Android tarafında newArchEnabled=false, iOS tarafında RCT_NEW_ARCH_ENABLED=0 artık yok sayılıyor: uygulamanız bu ayarlar ne olursa olsun yeni mimaride çalışıyor. Resmî göç yolu da net: önce Legacy'yi destekleyen son sürüme (0.81 veya Expo SDK 54) çıkın, orada New Architecture'ı açın, sonra 0.82'ye geçin. Doğrudan atlamak istediğiniz adım tam olarak bu (bkz. React Native yayın blogu, 0.82).
Bunun pratik sonucu şu: eski mimariye yaslanan bir native modül kullanıyorsanız, kırılma noktanız 0.82 değil, o modülün bakımının durduğu gün. 0.82 Legacy API'lerini uyumluluk için hâlâ barındırıyor ama yayın notu bir sonraki sürümden itibaren Legacy kodunun paket boyutunu küçültmek adına kaldırılmaya başlanacağını söylüyor. Yani süre tanımlı bir erteleme.
Güncel kararlı sürüm 0.87. Sürüm sayfası 0.77 ve sonrası için doküman tutuyor; 0.76 ve altı arşive taşınmış durumda. Projeniz 0.76'nın altındaysa artık okuyacağınız bir belge bile kalmadı, bu tek başına bir yükseltme gerekçesi.
Yükseltmeyi ertelemenin bileşik faizi şöyle işliyor: Play Console yeni sürümü kabul etmiyor çünkü hedef API seviyesi yetmiyor; hedef API'yi yükseltmek React Native sürümünü çıkmayı gerektiriyor; sürümü çıkmak eski mimariye yaslanan native modüllerin karşılığını bulmayı gerektiriyor. Üç bağımsız iş, tek bir acil işe dönüşüyor.
Google Play'in 31 Ağustos 2026 tarihi her iki tarafı da bağlıyor
Framework tartışmasından bağımsız, takvimi belirleyen şey Google Play'in hedef API seviyesi kuralı. Resmî gereksinim sayfasına göre yeni uygulamalar ve güncellemeler 31 Ağustos 2026'dan itibaren Android 16 (API 36) veya üstünü hedeflemek zorunda; Wear OS ve Android Automotive için API 35, Android TV ve Android XR için API 34. Play Console üzerinden 1 Kasım 2026'ya kadar uzatma talep edilebiliyor.
Mevcut uygulamalar için ayrı bir kural var: API 34 ve altını hedefleyen uygulamalar yeni Android sürümlerindeki cihazlarda yeni kullanıcılara görünmüyor; yalnızca aynı veya daha eski Android sürümündeki cihazlarda listeleniyor. Bu, mağazadan kalkmak değil ama sessizce kurulum kaybetmek demek ve analitikte "organik düşüş" gibi görünüyor.
Karşılığı şu: 2026'da hangi framework'ü seçerseniz seçin, bakım bütçenizde yılda bir zorunlu hedef API yükseltmesi kalemi olmak zorunda. Bunu "sonra bakarız" diye planlamayan ekiplerin ikinci yıl faturası, ilk yıl geliştirme bütçesinin dörtte birine ulaşabiliyor.
Flutter'ın tek kod tabanı vaadi nerede duruyor
Güncel kararlı sürüm Flutter 3.47. Desteklenen platformlar sayfası minimumları net veriyor: Android API 24 ve üstü, iOS 15 ve üstü, macOS 12 (Monterey) ve üstü, Windows 10 ve üstü. Web tarafında Chrome, Firefox, Safari (15.6+) ve Edge destekleniyor; ancak WebAssembly derlemesi yalnızca Chrome ve Edge için listelenmiş durumda. Safari ve Firefox JavaScript hedefiyle çalışıyor.
Bu son cümle, "Flutter ile mobil + web tek kod tabanı" kararını verirken en çok gözden kaçan kısıt. Wasm'ın getirdiği performansı planlayıp Safari kullanıcı kitlesi büyük bir ürün çıkarırsanız, o kitlede beklediğiniz kazancı göremezsiniz.
Flutter'ın gerçek sınırı platform entegrasyonunda ortaya çıkıyor. Kamera, Bluetooth, NFC, banka SDK'ları, kurumsal MDM ajanları gibi her şey platform kanalı üzerinden geçiyor ve o katmanı yazan kişi hem Dart hem de Kotlin/Swift bilmek zorunda. Tek kod tabanı, arayüz katmanı için doğru; cihaz ve SDK katmanı için değil.
Türkiye'ye özgü üç kırılma noktası
Global karşılaştırmalarda geçmeyen ama buradaki projelerde her seferinde karşımıza çıkan üç kalem:
- Banka ve sanal POS SDK'ları. Türkiye'deki ödeme sağlayıcılarının çoğu native Android/iOS SDK dağıtıyor; resmî React Native veya Flutter paketi genelde yok. Her iki tarafta da köprü yazacaksınız. Kapsam çıkarırken bunu ayrı bir kalem olarak sayın, "ödeme ekranı" içinde saymayın.
- e-Devlet ve mobil imza akışları. Harici uygulamaya çıkıp geri dönen (deep link / custom scheme) akışlar, her iki framework'te de ayrı test yükü getiriyor; özellikle uygulama arka planda öldürülüp geri döndüğünde durum kaybı yaşanıyor.
- Cihaz profili. Türkiye'deki kurumsal saha ekiplerinde hâlâ Android 8-11 aralığında cihaz var. Flutter'ın minimumu API 24 olduğu için burada sorun yok; asıl sorun, eski cihazlarda ilk açılış süresinin ölçülmemesi. Testi orta segment gerçek cihazda yapın, geliştirici makinesindeki emülatörde değil.
Karar tablosu
| Durum | Seçim | Gerekçe |
|---|---|---|
| Mevcut web ürünü React/Next.js | React Native | İş mantığı, tip tanımları ve ekip paylaşılıyor; ikinci bir dil öğretmiyorsunuz |
| Marka arayüzü iki platformda birebir aynı olacak | Flutter | Kendi render motorunu taşıyor; platform bileşeni farkıyla uğraşmıyorsunuz |
| Yoğun native SDK (ödeme, IoT, sağlık cihazı) | İkisi de eşit | Köprüyü siz yazacaksınız; seçimi ekibin native yetkinliği belirlesin |
| Safari ağırlıklı web + mobil tek kod tabanı | Ayrı web, ayrı mobil | Flutter Wasm yalnız Chrome/Edge'de; beklenen kazanç gelmiyor |
| Ekipte hiç mobil deneyimi yok | Flutter | Tek dil, tek araç zinciri; RN'de Node + Gradle + CocoaPods üçlüsünü ayrı ayrı öğrenmek gerekiyor |
Efor ve maliyet bandı
Framework seçimi toplam eforu dramatik değiştirmiyor; ekran sayısı, entegrasyon sayısı ve backend olgunluğu değiştiriyor. Kaba bir referans için: iki platforma çıkan, 12-18 ekranlı, tek ödeme sağlayıcısı ve push bildirimi olan bir MVP tipik olarak 45-70 adam-gün bandında planlanıyor. ininia'nın fiyat modelinde adam-gün 300-400 USD aralığında; yani bu kapsam kabaca 13.500-28.000 USD'ye denk geliyor. Bu bağlayıcı bir teklif değil, kapsam konuşmasına başlamak için bir çerçeve.
Bandı yukarı iten kalemler öngörülebilir: native SDK köprüleri, arka planda çalışan işler (konum, senkronizasyon) ve mağaza yayın süreci. Kapsam dokümanında bunlar ayrı satır değilse, tahmin ekran sayısı üzerinden yapılmış demektir ve teslimde sapar.
Bugün yapılacak iki kontrol
Birincisi: package.json veya pubspec.yaml dosyanızı açın ve sürümünüzün hangi destek penceresinde olduğuna bakın. React Native 0.76 ve altındaysanız dokümantasyon arşivde; Flutter'da iki minör sürümden geride kaldıysanız paket ekosistemi sizi yakında zorlayacak.
İkincisi: Play Console'da hedef API seviyenizi kontrol edin. 36'nın altındaysa, 31 Ağustos 2026 tarihine ne kadar kaldığını takviminize yazın ve gereken framework yükseltmesini o tarihe geri sayarak planlayın.
Mobil tarafta kapsam ve ekip kurgusu için mobil uygulama geliştirme firması seçimi yazısına, mağaza yayını ve bulunabilirlik için ASO rehberine bakabilirsiniz. Hizmet kapsamımız mobil uygulama geliştirme sayfasında; kaba bir bant çıkarmak için proje fiyat hesaplama aracını kullanabilir, kapsamı konuşmak için iletişim sayfasından yazabilirsiniz.
Sürüm ve tarih bilgileri 25 Eylül 2026'da şu birincil kaynaklardan doğrulanmıştır: reactnative.dev/versions, React Native 0.82 yayın blogu, docs.flutter.dev sürüm notları ve desteklenen platformlar sayfası, Google Play hedef API seviyesi gereksinimleri. Adam-gün bandı ininia'nın fiyat modelinden türetilmiştir ve bağlayıcı teklif değildir.
