React Native mi, Flutter mı, native mi? Mobil uygulamada hangisi seçilmeli
Mobil uygulama isteyen hemen herkes aynı soruyla geliyor: "Hangi teknolojiyle yapacaksın, native mi olacak?" Soru makul, ama çoğu zaman yanlış yerden soruluyor. Teknoloji seçimi uygulamanın ne yapacağından, kimin bakımını yapacağından ve bütçenin ne kadar süreye yayılacağından çıkar. Hangisinin "daha iyi" olduğundan değil.
Portföyümdeki beş mobil uygulamanın hepsi React Native ve Expo ile yazıldı: antrenman ve beslenme takibi için bir fitness takip uygulaması, bir toplu taşıma uygulaması, bir mobil bankacılık uygulaması, bir yemek sipariş uygulaması ve Kelime Avı (kelime bulmaca oyunu). Bu yazıda bu tercihin nedenini ve hangi durumda başka bir yolun daha doğru olacağını anlatıyorum.
Üç seçeneğin 2026'daki hâli
React Native ve Expo
React Native uzun süre "köprü" (bridge) mimarisiyle anıldı: JavaScript ile native taraf birbirine mesaj yollayarak konuşuyordu ve performans eleştirilerinin çoğu buradan geliyordu. Bu artık geçmişte kaldı. React Native 0.82 ile eski mimari tamamen kaldırıldı; bu sürümden itibaren her uygulama yeni mimaride (Fabric render sistemi, TurboModules, köprüsüz çalışma) çalışıyor ve bunu kapatmanın yolu yok. Eski mimariyi destekleyen son sürümler 0.81 ve Expo SDK 54'tü. Ardından 0.84 ile Hermes V1 varsayılan JavaScript motoru oldu.
Pratikte bunun anlamı şu: 2023'te okuduğunuz "React Native yavaş, köprü darboğaz yapıyor" yazılarının çoğu bugünkü sürümü anlatmıyor. Portföydeki projeler React Native 0.86 ve Expo SDK 57 üzerinde.
Expo da artık "başlangıç için oyuncak" değil. Dosya tabanlı yönlendirme (Expo Router), bulutta derleme, uygulama mağazasına gönderim ve native modül yazma imkânı aynı çatının altında. Native bir paket gerektiğinde Expo'dan çıkmak zorunda kalmıyorsunuz.
Flutter
Flutter kendi çizim motoruyla çalışır; platformun düğmelerini kullanmaz, her pikseli kendisi boyar. Bu yüzden iki platformda birebir aynı görünüm elde etmek kolaydır. Google'ın 2026 yol haritasına göre Android'de Impeller motoruna geçiş tamamlanıyor ve Android 10 ve üstünde eski Skia arka ucu kaldırılıyor. Web tarafında WebAssembly'nin varsayılan olması planlanıyor. Dil Dart; öğrenmesi zor değil ama ekipte Dart bilen birini bulmak, TypeScript bilen birini bulmaktan daha zor.
Native (Swift ve Kotlin)
iOS için Swift ve SwiftUI, Android için Kotlin ve Jetpack Compose. Platformun her yeni özelliğine ilk gün erişirsiniz, performans tavanı en yüksektir, hata ayıklama araçları en olgunudur. Bedeli: iki ayrı kod tabanı, iki ayrı test süreci, çoğu zaman iki ayrı geliştirici. Arada bir seçenek de var: Kotlin Multiplatform ile iş mantığını paylaşıp arayüzü ayrı yazmak ya da Compose Multiplatform ile arayüzü de paylaşmak. Compose Multiplatform'un iOS desteği Mayıs 2025'te 1.8.0 sürümüyle kararlı ilan edildi.
Karşılaştırma tablosu
| Ölçüt | React Native + Expo | Flutter | Native (Swift/Kotlin) |
|---|---|---|---|
| Kod paylaşımı | iOS, Android ve web tek kod | iOS, Android, web, masaüstü tek kod | Yok (KMP ile kısmen) |
| Dil | TypeScript | Dart | Swift + Kotlin |
| Arayüz | Platformun native bileşenleri | Kendi çizim motoru | Platformun kendisi |
| Web ile paylaşım | Güçlü (aynı dil, aynı ekip) | Var, ama web'de ağır | Yok |
| Yeni platform özelliği | Paket ya da native modül gerekir | Paket ya da platform kanalı gerekir | İlk gün |
| Ekip bulmak | Kolay | Orta | Her platform için ayrı |
| Uygun olduğu yer | İçerik, form, liste, e-ticaret, iş uygulamaları | Özel ve yoğun animasyonlu arayüzler | Donanıma yakın, platforma özel işler |
Kendi projelerimde neden React Native seçtim
Beş uygulamanın ortak noktası, hepsinin ekranlarının büyük kısmının liste, form, kart ve grafikten oluşması. Bu tür arayüzde React Native'in performansı fazlasıyla yetiyor. Ağır görünen yerler bile beklenenden rahat çalıştı:
- Toplu taşıma uygulamasında harita tamamen react-native-svg ile çiziliyor, harici bir harita servisi yok. 7 hat, 36 durak ve saniyede bir konumu güncellenen 31 araç aynı SVG üzerinde hareket ediyor; sürükleme ve yakınlaştırma da cabası.
- Kelime Avı'nda harf çarkı PanResponder ve SVG ile yazıldı; parmakla sürükleyerek harf birleştiriyorsunuz, geri sürükleyince son harf bırakılıyor.
- Fitness takip uygulamasında kalori halkası, kilo grafiği ve haftalık sütunlar hazır bir grafik kütüphanesi yerine react-native-svg ile yazdığım bileşenler.
İkinci sebep test. Beş uygulamanın beşi de web'de çalışıyor, bu yüzden uçtan uca testleri Playwright ile web çıktısı üzerinde koşturulabiliyor. Fitness takip uygulamasında onboarding'den koça kadar giden akış 40 kontrol ve 12 ekran görüntüsüyle, mobil bankacılık uygulamasında 41 kontrol ve 21 ekran görüntüsüyle doğrulanıyor. Hesaplama mantığını (kalori hedefi, 1RM, transfer ücreti, IBAN doğrulaması) saf fonksiyonlara ayırıp Vitest ile ayrıca test ediyorum. Native'de aynı güvenceyi iki ayrı test altyapısıyla kurmanız gerekirdi.
Üçüncü sebep paylaşım. Yemek sipariş uygulaması, mobil bankacılık uygulamasındaki tasarım belirteci mimarisini sıcak bir paletle yeniden kullanıyor. Aynı TypeScript bilgisi Next.js ile yazdığım web projelerine de taşınıyor. Tek kişi çalışan biri için bu ciddi bir kazanç.
Ne zaman başka bir şey seçerim
React Native her işe uymaz. Aşağıdaki durumlardan birindeyseniz seçimi baştan tartışmak gerekir:
- Uygulamanın özü platforma özel bir özellikse. Ana ekran widget'ları, saat uygulaması, CarPlay ya da Android Auto, arka planda uzun süre çalışan Bluetooth bağlantısı, artırılmış gerçeklik. Bunların hepsi React Native'den de yapılabilir ama her biri native kod yazmayı gerektirir. Uygulamanın yarısı native olacaksa, tamamını native yazmak daha temiz olabilir.
- Arayüz tamamen markaya özel ve yoğun animasyonluysa. Her ekranda özel çizim, parçacık efekti, sürekli hareket eden grafikler varsa Flutter'ın kendi çizim motoru avantaj sağlar. Standart bileşenlerden uzaklaştıkça React Native'in "native bileşen kullanıyorum" üstünlüğü de anlamını yitirir.
- Oyun yapıyorsanız. Kelime Avı gibi bulmaca türü bir oyun React Native'de gayet iyi çalışır. Fizik, sürekli çizim ve efekt isteyen bir oyunda ise oyun motoru kullanırım. Shadow Lock adlı oyunumu bu yüzden GameMaker ile yazdım.
- Şirketin zaten iOS ve Android ekibi varsa. Eldeki Swift ve Kotlin bilgisini çöpe atıp herkesi TypeScript'e geçirmek, çapraz platformun kazandırdığından fazlasını kaybettirebilir.
- Uygulama çok uzun ömürlü ve çok büyük olacaksa. Bir bankanın ana uygulaması gibi yıllarca onlarca kişinin üzerinde çalışacağı bir üründe native'in bakım maliyeti kendini amorti eder. Mobil bankacılık uygulamam konsept bir çalışma; gerçek bir bankanın ana uygulaması için kararı yeniden verirdim.
Karar vermeden önce cevaplamanız gereken sorular
Teknoloji tartışmasına girmeden önce şu listeyi doldurmanızı öneririm. Cevapların çoğu seçimi zaten kendisi yapıyor:
- Web sürümü de olacak mı? Olacaksa React Native'in web desteği ya da aynı dilde bir Next.js sitesi büyük avantaj.
- Uygulamanın kaç ekranı kamera, Bluetooth, sensör veya arka plan görevi gibi platform özelliklerine bağlı?
- Uygulama yayına çıktıktan sonra bakımı kim yapacak? Bu kişi hangi dili biliyor?
- İlk sürüm için süre ve bütçe ne kadar? İki ayrı native uygulama, kabaca iki katı geliştirme ve test demek.
- Tasarım platform kurallarına mı uyacak, yoksa her iki platformda birebir aynı mı görünecek?
- Uygulama güncellemeleri ne sıklıkla çıkacak? Sık değişen bir üründe tek kod tabanı hız kazandırır.
Karşılaşılan projelerin çoğunda cevaplar React Native ve Expo'yu gösteriyor: liste ve form ağırlıklı ekranlar, web ile paylaşılan iş mantığı, tek geliştiricinin sürdürebileceği bir kod tabanı. Cevaplar donanıma ya da ağır grafiğe işaret ediyorsa native veya Flutter'a geçmekten çekinmem. Bir mobil uygulama fikriniz varsa ve hangi yolun size uyduğunu konuşmak isterseniz bana yazabilirsiniz.