Blog

Flutter vs Native: Tartışma artık bitsin :)

“Flutter mı native mi?” sorusunu son yıllarda çok sık duyuyorum. Açık konuşayım, bu cümle bana artık biraz eski geliyor. Çünkü Flutter’ı gerçekten kullanmış, production uygulama çıkarmış biri için bu tartışma çoktan başka bir yere evrildi.

Hâlâ “flutter mı seçelim native mi?” noktasında takılıyorsak, genelde konunun tamamına bakılmıyor demektir. 2025’e geldiğimizde bu tartışma teknik bir tartışma olmaktan çıktı. Daha çok karar verme biçimiyle, projeye nasıl yaklaşıldığıyla ilgili bir mesele hâline geldi.

Şunu baştan netleştirelim. Zaten Flutter native çalışır. Dart kodu AOT olarak derlenir. Android’de native binary çıkar, iOS’ta native binary çıkar. UI WebView üzerinden dönmez, JavaScript yoktur. Flutter kendi render engine’i ile ekranı doğrudan GPU’ya çizer. Yani Flutter web değildir, hybrid değildir, React Native hiç değildir. Bu kısım artık tartışmaya açık değil.

Peki o zaman neden hâlâ “Native daha performanslı” lafı dönüp duruyor?

Bence burada asıl karışan şey performansla kontrolün aynı kefeye konması. Oysa bunlar farklı şeyler. Ve kafa karışıklığı tam da buradan çıkıyor.

UI tarafında konuşalım. Animasyonlar, scroll’lar, ekran geçişleri… Düzgün yazılmış bir Flutter uygulamasıyla native bir uygulama arasında, kullanıcıya hissettiren bir performans farkı yok. Hatta bazı animasyon ağırlıklı ekranlarda Flutter daha tutarlı bile olabiliyor. Bunun sebebi tek bir render pipeline’a sahip olması. O yüzden bugün hala UI performansı üzerinden Flutter’ı eleştirmek bana çok anlamlı gelmiyor.

Asıl fark, işin platforma ne kadar yakın çalıştığı noktada başlıyor.

Native geliştirirken işletim sisteminin içindesin. Lifecycle senin elinde, background servisler senin kontrolünde, sensörler, Bluetooth, kamera gibi konularda doğrudan söz sahibisin. Flutter’da ise işler biraz daha katmanlı ilerliyor. Dart tarafındasın ve native tarafa geçerken platform channel kullanıyorsun. Bu kötü bir şey değil ama şu gerçeği de kabul etmek gerekiyor: Flutter native’e çok yakındır ama native kadar “içeride” değildir.

Bu fark her projede kendini göstermez. Hatta birçok projede hiç hissetmezsin bile. Ama bazı projelerde net şekilde ortaya çıkar. Özellikle yoğun background işlem yapan, sürekli sensör okuyan, OS lifecycle’ına çok hassas çalışan uygulamalarda Flutter tek başına yetmemeye başlar. O noktada genelde Flutter + native plugin yazma yoluna girilir. Bu yanlış bir yaklaşım değildir ama artık saf Flutter’da olmadığını kabul etmiş olursun.

Bu arada şunu da net söylemek istiyorum. Flutter projelerinde yaşanan performans problemlerinin büyük kısmı Flutter’dan kaynaklanmaz. Yanlış state yönetimi, gereksiz rebuild’ler, karmaşık widget ağaçları, kötü mimari… Bunlar varsa native yazsan da aynı problemleri yaşarsın. Flutter bu noktada sadece günah keçisi olur.

Benim gözlemim şu: Bu tartışma yıllardır bitmiyor çünkü genelde teknoloji seçimi, düzgün flutter yapısının kurulması proje başlamadan önce değil, sorunlar çıktıktan sonra sorgulanıyor. Proje yavaşlıyor, ekip zorlanıyor, bakım maliyeti artıyor… Sonra dönüp “Flutter mı hatalıydı?” deniyor. Oysa çoğu zaman sorun yanlış başlangıç kararlarında oluyor.

Kendi tecrübemden söyleyeyim. Flutter’ı kullandığım ve “iyi ki Flutter seçmişiz” dediğim bir sürü proje oldu. Hatta hiç pişman olmadım bu seçimden. Sadece ilk flutter a geçtiğimiz zamanlarda biz de bazı hatalar yaptık 🙂 Bunları çabuk farkedip düzelttik ve ustalaştık bu konuda.

Hızlı MVP çıkarmamız gereken, tek kod tabanıyla iOS ve Android’e aynı anda gitmek istediğimiz, UI ve iterasyon hızının kritik olduğu projelerde Flutter gerçekten çok güçlüydü. Bir projede, başladıktan sonra uzun bir süreden sonra ilk defa flutter kütüphanelerinin yetmediği bir yere denk geldim. Onda da kendi plugin imizi yazıp konuyu çözdük. Yani yine bir sorun yaşamadık.

Burada iş sadece teknik değil, ekip yapısıyla da ilgili. Küçük bir ekip, hızlı hareket etmesi gereken bir ürün ve sınırlı bütçe varsa Flutter ciddi avantaj sağlar. Ama büyük ekipler, uzun vadeli kurumsal projeler, çok sık geliştirici değişimi olan yapılar söz konusuysa, teknoloji seçiminin bakım maliyetine etkisi çok daha belirgin hâle gelir.

Yanlış teknoloji seçiminin faturası genelde hemen çıkmaz. İlk aylar her şey yolunda gider. Ama 6 ay sonra, “buraya dokunmayalım”, “şu kısmı bozmayalım”, “bunu değiştirmek riskli” gibi cümleler artmaya başlar. İşte o noktada mesele Flutter mı Native mi olmaktan çıkar; doğru karar verilip verilmediğine gelir.

O yüzden bana göre “Flutter mı Native mi daha hızlı?” sorusu artık yanlış soru. Asıl soru şu olmalı: Bu proje işletim sistemine ne kadar yakın olmak zorunda? Eğer cevap “çok yakın” ise native daha doğru bir tercih olur. Eğer cevap “çok da gerek yok” ise Flutter gayet güçlü bir çözümdür.

Toparlarsam, Flutter vs native sorusu yerine asıl soru işletim sistemine yakınlığı ve ne kadar çok os tabanlı iş yaptığıdır. Seçim bence buna göre yapılmalıdır. Çok derin bir şekilde os ile çalışıyor ve kütüphaneler performans sorunu çıkaracak bir durum var ise ben anca o zaman native seçerim. Yoksa bugün geldiğimiz noktada hem performans, hem maaliyet hem de kodun okunabilirliği açısından kesinlikle flutter ile devam etmeyi öneririm. Ancak tekrar çok önemli bir notu ekleyerek bitireyim. Düzgün bir flutter yapısı kurmzsanız olmaz. O zaman da flutter ı suçlamak yerine yapıya kuranların ne yaptığına odaklanmak gerekir. Yani herkes bugün flutter kolay ben yaparım diye ortaya çıkabiliyor ama ne kadar düzgün bir yapı kurduğu ve performansa dikkat edip etmediği çok tartışılır. Keşke native yapsaydık dediğiniz bir noktaya gelebilirsiniz dikkatli ve düzgün bir yapı kurulmaz ise.


Hybrid vs Native

Merhaba,

En çok karşımıza çıkan sorulardan biri, uygulama geliştirirken hybrid mi yoksa native mi geliştirmem lazım. Yada bunların birbirine göre avantaj ve dezavantajları neler.

Öncelikle hybrid ve native uygulama nedir onu anlatarak başlayalım.

Hybrid Uygulama Nedir?

Hybrid uygulamalar genelde web tabanlı yazılan ve javascript altyapısı ile çalışan html ve css den oluşan yapılardır. Aynı web sitesini geliştirir gibi geliştirken bir backend programlama dili kullanılmaz php yada dotnet gibi. Sadece normal mobil uygulamalarda olduğu gibi uygulama backend ile servisler aracılığı ile konuşur bu kısmı da javascript xhr (XMLHttpRequest ) ile sağlar. Bu durumda hybrid uygulama native gibi görünen ve çalışan uygulamalar oluşturabilir. Burada önyüz geliştirme html ve css çok önem teşkil eder. Şöyle ki arayüzde kullandığınız bootstrap ve responsive bir yapı olması gerekir ve kullanılan button , list yapıları native de kullanılanlara çok benzer hale getirilebilir.

Hybrid uygulamalar derlenirken genelde cordova altyapısı kullanılır. Bu konuda cordova web sitesinden daha detaylı bilgi alabilirsiniz. Özetle mantık şu şekilde:

1 – cordova app yaratırsınız
ör:

cordova create hello com.example.hello HelloWorld

2 – platform eklersiniz
ör:

cordova platform add ios
cordova platform add android

3 – html, css ve js den oluşan kodlarınızı app yarattığınızda oluşan www klasörü içine eklersiniz.
4 – istediğiniz platforma build alırsınız.
ör:

cordova build ios
cordova build android

Özetle bu şekilde tabi daha çok özelleştirme ve detay var burada daha fazla detaya girmeyeceğim. Konu cordova olmadığı için ancak sonuçta tek dilde yazılan ve programlama kodu olarak javascript kullanılılarak yazılan kodlar size istediğiniz platformda uygulama üretmenizi sağlar. Temel avantajlarından bir tanesi budur.

Native kod gerektiren yerlerde birçok kez test edilmiş ve özel olarak hazırlanmış cordova plugin leri işimizi çözer.

Ne zaman tercih etmemeniz gerektiği tecrübe oldukça daha çok ortaya çıkar. Ancak temel olarak şu söylenebilir. Eğer native koda çok girmeniz gerektiği durumlar varsa, performans olarak çok önem arzeden işler yapıyorsanız hybrid bir yapı tercih etmeyebilirsiniz. Çünkü hybrid yapı temelde web browser üstünde çalışır ve basit işlerde çok sıkıntı çıkarmasada karmaşık işlerde ve performans gerektiren işlerde işinizi zorlaştırma ve uygulamayı daha kötü noktaya götürme ve işten çıkılmaz hale gelmesine sebep olabilmektedir.

Benim görüşüm , basit akışı olan, listeleme , form uygulamaları gibi uygulamalarda hybrid yöntemi seçmek zaman ve maliyet tasarrufu sağlayabilir.

Diğer tüm durumlarda native kod yazmak daha efektif ve performanslı olacaktır.

Native Uygulama Nedir?

Native uygulama android için konuşursak java dilinde yazdığınız, ios için ise objective-c yada swift dili ile yazdığınız uygulamalardır. Şu anda android de Android Studio ile native uygulama geliştirebilir, ios içinde Xcode ile Swift yada Objective-C seçerek native uygulama geliştirebilirsiniz.

Her türlü uygulama geliştirme ve tüm kütüphanelere direk erişme şansınız vardır.

Bu tip uygulamalarda karşımıza çıkan en büyük sorun hem android hem ios da uzmanlaşmış kadronun olması gerekliliğidir.

Buda bize maliyet olarak dezavantaj sağlar.  Ancak performans ve esneklik açısından daha iyidir. Yani yapamayacağınız birşey yok diyebiliriz.

Özet ve Sonuç:

Hybrid uygulamalarda da plugin ler sayesinde birçok şeyi yapabilirsiniz. Ancak iş plugin i özelleştirme ye gelebilir. Bu plugin in yetersiz olduğu zamanlarda ortaya çıkar ki bu durumda yine android ve ios native programlama bilgisi gerektirecektir.

Bir app developer olarak düşündüğünüzde her iki yapıyı da biliyor olmak ve müşterinizi doğru yönlendirmek çok önemlidir. Eğer hızlı şekilde markete çıkmak isteniyor ve bütçe konusunda daha düşük bütçeler var ve native android ios developer sıkıntısı varsa bu durumda hybrid tercih edilebilir. Ancak süre, maliyet den ziyade performans ve esneklik önemli ve kadro var ise native tercih etmek herkesin içini daha çok rahatlatacaktır.

Bu arada hybrid in bir diğer avantajını da söylemeden bitirmemek lazım tabi, eğer web app isteniyorsa yani bu app in aynısı web de de çalışsın isteniyorsa zaten yapı web e uyumlu olduğu için browser platformu eklenerek yada hazırladığınız www klasörü altındaki kodlar zaten web server a yüklendiğinde çalışacaktır. Tabi cross domain ayarları yapmak , ssl li çalıştırmak, cordova.js yi içinden çıkarmak gerekebilir. Ancak bunlar aynı kodun web de çalışmasını engellemez sonuçta elinizde hem ios, hem android hem de web de çalışan bir yapı olacaktır.

Bu konuda sorularınız ve yorumlarınız olursa lütfen çekinmeyin, bu konuyu tartışmaktan ve hangisi daha iyi hangisi yada bu app e ve benim şartlarıma uygun irdelemekten her iki yapıyı da iyi tanıdığım için hoşuma gidiyor. Bu yazılımcı arkadaşlar arasında sürekli olacak ve tercihlerin belli zamanlarda ve teknolojinin gelişmesi ile ağırlığın her an değişebileceği ve diğer taraf kayabileceği bir konu.

Umarım biraz olsun özet bir bilgi verebilmiş ve faydalı olabilmişimdir.