“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.