Native mi, Flutter / React Native mi

Native mi, Flutter mı: hangisini seçmeli?

Uygulamanız cihazın derin özelliklerine yoğun biçimde dayanmıyorsa Flutter ya da React Native genellikle yeterlidir. Kamerayı, sensörleri ya da platforma özel özellikleri merkeze koyan uygulamalarda native daha doğru sonuç verir. Bu yazıda üç yolun farkını sade bir dille anlatıyoruz.

Biz dördünü de kullanıyoruz: Swift, Kotlin, Flutter ve React Native. Bu yüzden bir tarafı savunmak için değil, seçim yaparken sorduğumuz soruları paylaşmak için yazıyoruz.

Native uygulama ne demek?

Native uygulama, her platform için o platformun kendi diliyle ayrı yazılan uygulamadır. iOS için Swift, Android için Kotlin kullanılır. Sonuçta iki ayrı kod tabanı olur. Her yeni özellik iki kez yazılır ve iki kez test edilir.

Karşılığında platformun sunduğu her şeye ilk günden ve aracısız erişirsiniz. Apple ya da Google yeni bir özellik duyurduğunda onu kullanmak için başka bir aracın güncellenmesini beklemezsiniz.

Flutter ve React Native nasıl çalışır?

İkisi de tek kod tabanından hem iOS hem Android uygulaması çıkarır ama bunu farklı yollarla yapar. Bu yaklaşıma cross-platform geliştirme denir. Flutter, Google tarafından geliştirilir ve Dart dilini kullanır. Arayüzü kendi çizim motoruyla çizer. Bu yüzden uygulama iki platformda neredeyse aynı görünür.

React Native, Meta tarafından geliştirilir ve JavaScript ya da TypeScript kullanır. Arayüzde platformun kendi bileşenlerini kullanır. Bu yüzden düğmeler ve listeler her platformda o platformun alışılmış hâline daha yakın durur.

İki araç da gerektiğinde native kodla konuşabilir. Tek kod tabanında bile bazen küçük bir parçayı Swift ya da Kotlin ile yazmak gerekir. Bu normaldir ve iyi bir ekip bunu baştan öngörür.

Performans farkı gerçekten hissedilir mi?

Çoğu iş uygulamasında performans farkı kullanıcı tarafından hissedilmez. Liste göstermek, form doldurmak, sipariş vermek, bildirim almak gibi işlerde üç yol da akıcı çalışır. Yavaşlığın asıl sebebi genellikle teknoloji değil, kötü yazılmış kod ya da yavaş bir sunucudur.

Fark, ağır işlerde ortaya çıkar. Yoğun grafik, gerçek zamanlı görüntü işleme, artırılmış gerçeklik ya da düşük seviyede donanım kontrolü gereken uygulamalarda native daha rahat bir alan sunar.

Uygulama boyutu ve açılış süresi de konuşulan konulardır. Tek kod tabanıyla yapılan uygulamalar kendi çalışma altyapılarını da pakete koyduğu için genellikle biraz daha büyük olur. Çoğu kullanıcı bu farkı fark etmez. Ama uygulamanız düşük depolamalı cihazlarda yaygın kullanılacaksa bunu da hesaba katın.

Native ne zaman daha doğru seçimdir?

Native, uygulamanın kalbi cihazın kendisi olduğunda daha doğru seçimdir. Şu durumlarda native yönüne bakarız:

• Kamera, Bluetooth ya da sensörlerle yoğun ve düşük seviyede çalışılacaksa.
• Akıllı saat, ana ekran bileşeni gibi platforma özel parçalar merkezdeyse.
• Uygulama sadece bir platform için yapılacaksa.
• Platformun yeni özelliklerini çıktığı gün kullanmak iş için kritikse.
• Şirketin içinde zaten Swift ya da Kotlin bilen bir ekip varsa.

Flutter ya da React Native ne zaman yeterlidir?

Uygulama bir iş sürecini telefona taşıyorsa tek kod tabanı genellikle yeterlidir. E-ticaret, rezervasyon, sadakat programı, saha ekibi uygulaması, randevu ve içerik uygulamaları bu gruba girer. Bu uygulamaların çoğu bir API üzerinden sunucuyla konuşur ve ekranda veri gösterir.

Bu durumda tek kod tabanı iki şey kazandırır. İlki, iki platform daha az işle yayına çıkar. Mobil uygulama maliyeti yazısında anlattığımız gibi bu, bütçeye doğrudan yansır. İkincisi, bakım kolaylaşır. Bir hata bir kez düzeltilir, bir özellik bir kez eklenir.

Flutter mı, React Native mi?

İki araç arasındaki seçim çoğu zaman arayüz tercihi ve ekip yapısıyla ilgilidir. Markanıza özel, iki platformda birebir aynı görünen bir arayüz istiyorsanız Flutter rahat bir seçimdir. Uygulamanın her platformda o platformun alışılmış görünümüne yakın durmasını istiyorsanız React Native uygun olabilir.

Bir de bakım tarafı vardır. Uygulamayı yıllar içinde kim geliştirecek? İleride kendi ekibinizi kuracaksanız, piyasada hangi dili bilen geliştirici bulmanın sizin için kolay olacağını da düşünün.

Karar verirken hangi soruları soruyoruz?

Teknolojiyi ilk görüşmede değil, uygulamanın ne yapacağı netleşince seçiyoruz. Sorduğumuz sorular şunlar:

1. Uygulama cihazın hangi özelliklerini kullanacak?
2. Bir platform mu, iki platform mu?
3. Arayüz markaya özel mi, platform standartlarına yakın mı olacak?
4. İlk sürüm ne zaman yayında olmalı?
5. Uygulamayı ileride kim geliştirecek?

Cevaplara göre bir öneri yazar ve sebebini açıklarız. Seçim teklifte ve bitiş tanımında açıkça yer alır. Hangi yolu seçersek seçelim, kod deposu ve mağaza hesapları ilk günden sizin adınıza olur. Mağazaya gönderim adımlarını uygulamayı mağazaya yüklemek yazısında anlattık. Bu işi nasıl yaptığımızı mobil uygulama geliştirme sayfasında anlattık. İlk sürümü küçük tutmak istiyorsanız MVP kavramına da göz atın.

Örnek senaryolarda hangi yolu seçiyoruz?

Örnek senaryolarda seçimi belirleyen şey, uygulamanın ekranda veri mi gösterdiği yoksa cihazın donanımıyla mı çalıştığıdır. Aşağıdaki tablo sık karşılaştığımız uygulama türlerini ve genellikle önerdiğimiz yolu gösteriyor. Her proje kendi koşullarıyla değerlendirilir. Tablo bir başlangıç noktasıdır, kesin kural değildir.

Teknoloji seçiminde sık yapılan hatalar nelerdir?

En sık hata, teknolojiyi uygulamanın ihtiyacına göre değil, o dönem popüler olana göre seçmektir. Karşılaştığımız diğer hatalar şunlar:

• Tek platformu varsaymak: "Şimdilik sadece iPhone" denir, altı ay sonra Android istenir ve iş ikiye katlanır. İleride iki platform ihtimali varsa bunu baştan söyleyin.
• Eklentileri kontrol etmemek: Tek kod tabanında kullanılacak her cihaz özelliğinin güncel ve bakımı süren bir eklentisi olup olmadığı başta kontrol edilmelidir.
• Arka ucu unutmak: Tartışma telefon tarafında kalır. Oysa maliyetin ve riskin büyük kısmı çoğu zaman sunucu ve API tarafındadır.
• Kimin bakacağını düşünmemek: Uygulama yıllarca yaşar. Kodu kimin güncelleyeceği seçimin parçasıdır.
• Performansı yanlış yerde aramak: Yavaş açılan bir liste çoğu zaman teknolojiden değil, sunucudan ya da verimsiz sorgudan gelir.

Kotlin Multiplatform da bir seçenek mi?

Evet, Kotlin Multiplatform iş mantığını iOS ve Android arasında paylaşıp arayüzü her platformda native bırakmak isteyenler için bir seçenektir. Hesaplama, veri doğrulama ve sunucuyla konuşma gibi kısımlar bir kez yazılır. Ekranlar ise her platformun kendi araçlarıyla yapılır. Bu yol, native arayüzü isteyen ama aynı kuralı iki kez yazmaktan kaçınmak isteyen ekiplere uyar. Arayüz yine iki kez yazıldığı için tamamen tek kod tabanı kadar iş tasarrufu sağlamaz.

Seçim yıllık bakımı nasıl etkiler?

Seçim, her yıl gelen işletim sistemi güncellemelerinde ne kadar iş çıkacağını belirler. Native uygulamada iki kod tabanı ayrı ayrı uyarlanır. Tek kod tabanında önce çatının kendisi güncellenir, sonra kullanılan eklentiler kontrol edilir. Bakımı bırakılmış bir eklenti, güncellemeyi geciktiren en yaygın sebeptir. Bu yüzden eklenti seçerken sadece bugün çalışıp çalışmadığına değil, düzenli güncellenip güncellenmediğine de bakarız.

Bildirim altyapısı da bu listeye girer. Push bildirim servisleri Apple ve Google tarafında zaman zaman değişir ve uygulamanın bu değişikliğe uyarlanması gerekir. Hangi yolu seçerseniz seçin, bu işleri bakım ve destek kapsamında baştan planlamak sürprizleri önler. Tek kod tabanıyla nasıl çalıştığımızı Flutter ile uygulama geliştirme sayfasında anlattık. İlk sürümü küçük tutmak için MVP nasıl yapılır yazısına da bakabilirsiniz.