Flutter mu React Native mi: Neden Yeni Projelerde Flutter Seçiyoruz

Ekiplerin çoğu bu soruyu özellik listesi karşılaştırarak tartışıyor. Biz on yılı aşkın süredir mobil uygulama teslim ediyoruz ve tercihimiz net: yeni projelerde Flutter.

Bu yazı nedenini anlatıyor, React Native'i küçümsemeden. İkisi de olgun araçlar ve React Native ile de üretime çıkmış projelerimiz var. Ama aynı işi iki araçla da yapabildiğinizde, tercihi ayrıntılar belirliyor.

Önce yaygın bir yanlışı düzeltelim

React Native web görünümü içinde çalışmıyor. Bunu karıştıranlar çok, ama WebView kullanan araçlar Cordova ve Ionic. React Native gerçek native bileşenler kullanıyor.

Ayrıca eskiden eleştirilen köprü (bridge) katmanı da artık yok. 0.76 sürümünden itibaren varsayılan olan yeni mimaride JavaScript ile native arasındaki serileştirme yerini doğrudan çağrıya bıraktı. Yani "React Native yavaş" iddiası güncel değil.

Tercihimizi bu eski eleştirilere dayandırmıyoruz. Gerçek sebepler başka.

1. Kendi render motoru, birebir aynı arayüz

Flutter ekranı kendi çiziyor. Impeller motoru her pikseli kendisi üretiyor, işletim sisteminin hazır bileşenlerini kullanmıyor.

Bunun pratik karşılığı şu: tasarımcının verdiği ekran, iPhone'da da eski bir Android cihazda da aynı görünüyor. Cihaz üreticisinin kendi arayüz katmanı, işletim sistemi sürümü ya da yazı tipi ölçeği ayarı tasarımı bozmuyor.

Native bileşen kullanan çözümlerde bu böyle değil. Aynı kod iki platformda farklı görünüyor ve farkı kapatmak için platforma özel düzeltmeler yazılıyor. Kurumsal müşteride marka tutarlılığı önemliyse bu iş birikiyor.

Sportez'de bunun karşılığını gördük: tek tasarım sistemi, iki mağaza, platforma özel düzeltme neredeyse yok.

2. Method channel: bekleyecek paket yok

En çok fark yaratan nokta bu.

Mobil projelerde er geç şuna ihtiyacınız oluyor: cihazın özel bir yeteneğine erişmek. Özel bir Bluetooth cihazı, kurumun kendi kimlik doğrulama SDK'sı, sektöre özel bir donanım.

Flutter'da method channel ile native tarafı kendiniz yazıyorsunuz. Kotlin ya da Swift ile gereken parçayı yazıp Dart tarafına açıyorsunuz. Aradaki sözleşme sizin.

Alternatif yaklaşımda önce topluluk paketi aranıyor. Paket varsa iyi. Yoksa ya yazılacak ya da bakımsız bir paket çatallanacak. Paket varsa bile sorusu bitmiyor: son güncelleme ne zaman, yeni işletim sistemi sürümünde çalışıyor mu, bakımcısı aktif mi.

Bu, tek projede küçük bir fark. On projede birikince ciddi bir risk farkı oluyor.

3. Sığ bağımlılık zinciri

Flutter'da çoğu şey çerçevenin içinde geliyor: gezinme, durum yönetimi seçenekleri, animasyon, form doğrulama, tema sistemi.

JavaScript ekosisteminde bunların her biri ayrı bir pakete düşüyor ve her paket kendi bağımlılıklarını getiriyor. Orta ölçekli bir uygulamada yüzlerce dolaylı bağımlılık oluşabiliyor.

Her bağımlılık bir bakım yükü: güvenlik uyarısı, sürüm çakışması, terk edilmiş paket. Üç yıl yaşayacak bir uygulamada bu yükü taşımak zorundasınız.

Bu, uygulamayı teslim ettikten sonra müşterinin kendi ekibinin sürdürebilmesi açısından da önemli.

4. Sürüm yükseltmeleri daha az kırıyor

Flutter sürüm yükseltmelerinde geçiş genellikle daha sakin geçiyor çünkü çekirdek yetenekler tek elden geliyor. Bağımlılık sayısı az olduğu için "bir paket güncellendi, diğerleri kırıldı" zinciri daha nadir yaşanıyor.

Sekiz haftada teslim edilen bir projede bu fark görünmez. Ama üçüncü yılın bakım faturasında görünür.

React Native'i ne zaman öneririz

Dürüst olmak gerekirse net durumlar var.

Ekibiniz zaten React biliyorsa. Bu en güçlü gerekçe. Altı kişilik bir React ekibine Dart öğretmek yerine bildikleri aracı kullanmak daha hızlı sonuç verir.

Mevcut bir native uygulamayı parça parça yenilemek istiyorsanız. React Native'in mevcut bir native kabuğun içine ekran gömme desteği daha oturmuş durumda.

Mağaza onayı beklemeden güncelleme göndermeniz gerekiyorsa. JavaScript paketini uzaktan güncelleyebilme yeteneği Flutter'da doğrudan karşılığı olmayan bir avantaj.

Web ekibiyle zihinsel model paylaşımı önemliyse. Aynı bileşen mantığını iki tarafta da kullanmak bazı ekiplerde gerçek kazanç sağlıyor.

İkisini de atlamanız gereken durum

Uygulamanız temelde gerçek zamanlı bir oyun, video düzenleme aracı ya da ağır artırılmış gerçeklik içeriyorsa native geliştirme yapın. Her iki çapraz platform aracı da bu iş için yanlış araç.

Bunun dışında kalan iş uygulamalarında, yani formlar, listeler, harita, bildirim ve senkronizasyon içeren çoğunlukta, ikisi de yeterli.

Özetle

Soru "hangisi daha iyi" değil. İkisi de çalışıyor.

Biz yeni projelerde Flutter'ı seçiyoruz çünkü arayüz tutarlılığını garanti ediyor, native yeteneğe erişmek için üçüncü tarafı beklemiyoruz ve teslim ettiğimiz kod tabanının bakım yükü daha hafif oluyor.

Ekibiniz React biliyorsa ya da mevcut bir native uygulamayı kademeli yeniliyorsanız, React Native doğru karar olabilir. Kararda belirleyici olan çerçevenin kendisi değil, sizin bağlamınız.

Yaklaşan bir mobil proje için bu kararı konuşmak isterseniz, ekibinizin mevcut becerilerini ve uygulamanın hangi cihaz yeteneklerine ihtiyacı olduğunu getirin. Karar genellikle bu iki bilgiden çıkıyor.