Geçen ay, Kadıköy’de bir kahve molasında Flutter 3.16 notlarını karıştırırken kendi kendime şunu söyledim: “Bu çerçeve artık sadece arayüz yapmıyor, ekosistemin yönünü de belirliyor.” İşin aslı şu ki, Flutter mülakatlarında hâlâ eski widget ezberini sayan çok kişi var; ama bugün seni öne çıkaran şey, yeni render motorunu, Dart 3’ün dil hamlelerini ve web tarafındaki yön değişimini gerçekten anlayıp anlamadığın.
Bu yazıyı hazırlarken özellikle iki şeyi düşündüm. Birincisi, geçen sene Şişli’de (söylemesi ayıp) yaptığım bir teknik görüşmede adayın Impeller’ı sadece “performans artışı” diye geçiştirmesi — açık konuşayım, o cevap pek tat vermedi. Tahmin eder misiniz? İkincisi ise 2024’te kendi yan projelerimde Material 3’e geçerken yaşadığım küçük sürprizler: seed tabanlı renk üretimi ilk bakışta oyuncak gibi duruyor, ama tasarım tutarlılığı açısından baya iş görüyor.
Hmm, bunu nasıl anlatsamdı…
Flutter mülakatında yeni sürümleri ezbere saymak yetmez; önemli olan, neden değiştiğini ve bunun gerçek uygulamada neyi etkilediğini anlatabilmek.
Flutter 3.x neden bu kadar önemli?
Şöyle bir şey var. Flutter 3.x serisini sıradan bir güncelleme gibi görmek biraz haksızlık olur — hem görsel katmanda hem de dil tarafında ciddi bir yön değişimi söz konusu. Eskiden “uygulama akıcı mı?” sorusu çoğu zaman cihazdan cihaza değişirdi. Şimdi ise motorun shader derleme yaklaşımı sayesinde, ilk açılışta yaşanan o sinir bozucu takılmalar çok daha kontrollü hale geldi.
Impeller’ın devreye girmesi tam da bu yüzden kritik. iOS tarafında Skia’nın yerini alması sadece teknik bir detay değil; geliştiricinin son kullanıcıya verdiği hissi doğrudan etkiliyor. Ben bunu ilk kez İstanbul’da bir fintech prototipinde test ettiğimde fark ettim — animasyonlar kağıt üstünde tamamen aynıydı ama uygulamanın “ilk temas” hissi bariz biçimde daha temizdi. Ciddi fark var.
Gel gelelim her şey güllük gülistanlık değil. Impeller henüz bazı senaryolarda Skia kadar oturmuş hissettirmiyor; özellikle eski cihazlarda ya da alışılmadık grafik akışlarında ufak pürüzler çıkabiliyor. Yani evet, iyi yolda. Ama hâlâ pişmeye devam ediyor.
Dart 3 ile gelen işleri değiştiren parçalar
Dart 3 tarafında en çok sorulan konuların başında records ve patterns geliyor. Bunları ben genelde mutfaktaki tepsi düzenine benzetiyorum: eskiden tek tek tabak taşıyordun, şimdi birkaç değeri birlikte düzgünce paketleyebiliyorsun. Bu kulağa basit geliyor, haklısın — ama kod okunabilirliği açısından gerçekten iş görüyor, küçümseme.
Sealed class ve exhaustive switch konusu da mülakatta sık sık yoklanan alanlardan biri oldu. Neden? Çünkü artık “hangi durumları unuttun?” sorusunun cevabı derleyici tarafından çok daha sert şekilde denetleniyor. Geçen mart ayında Levent’teki bir ürün ekibine danışmanlık verirken tam da bu noktada yakaladığımız hata yüzünden switch bloğuna eksik case düşmüştük; derleyici bize adeta el sallayıp “burada boşluk var” dedi. Utandık biraz ama öğrendik.
Records ve Patterns pratikte ne sağlıyor?
Kısaca söyleyeyim. Daha az gürültü, daha net niyet beyanı. Mesela API’den dönen iki-üç alanı küçük bir veri paketi olarak taşımak istiyorsan record mantığı baya kullanışlı oluyor. Pattern matching ise gelen veriyi elle parçalamak yerine doğrudan kalıbına göre ele almanı sağlıyor — nasıl desem, zihin yükü gerçekten azalıyor (eh, fena değil)
// Basit örnek
final user = (id: 7, name: 'Ece');
switch (user) {
case (id: final id, name: final name):
print('ID=$id, Name=$name');
}Sealed sınıflar ve eksiksiz switch kontrolü
Şöyle söyleyeyim, Bence sealed sınıflar Dart’ın olgunlaşma hikâyesinde sessiz ama sağlam bir adım oldu. Uygulama büyüdükçe hata ihtimali de büyüyor — özellikle ödeme akışı, oturum yönetimi veya bildirim durumları gibi dallanan yapılarda yanlış state’i kaçırmak istemezsin. Kaçırırsın da tabi, kaçırırsın. Ama en azından derleyici seni uyarsın.
Açıkçası, Küçük startup’larda insanlar bazen “bize gerek yok” diyor. Sonra üç ay sonra o sistem büyüyünce aynı ekip gecenin ikisinde bug avına çıkıyor. Hep böyle oluyor. Kurumsal tarafta ise sealed yapıların faydası daha erken görülüyor. Bakım maliyeti orada direkt para demek, soyut bir kavram değil. Daha fazla bilgi için Alibaba Qwen’i Nasıl Büyüttü, Parayı Nereden Arıyor? yazımıza bakabilirsiniz.
Impeller, WebAssembly ve Material You’nun gölgesi
Şimdi gelelim sahnenin biraz daha parlayan kısmına. Flutter Web için WebAssembly desteği hâlâ herkesin günlük kullanımına tam yerleşmiş değil —. Stratejik olarak çok önemli duruyor. Yıllardır süren “web performansı ne zaman düzelecek?” sorusuna gerçek bir cevap verebilecek araçlardan biri olabilir bu. Belki. Göreceğiz. Daha fazla bilgi için Railway İçin Internal Tool Güvenilir mi? 2026’da Cevap Bu yazımıza bakabilirsiniz.
Peki neden? Bu konuyla ilgili Rockstar Games gerçekten hacklendi mi? İşin aslı biraz daha karmaşık yazımıza da göz atmanızı tavsiye ederim.
Aynı şekilde Material You, yani Material 3 yaklaşımı da sadece tema rengini değiştirmekten ibaret değil. ColorScheme.fromSeed() ile başlayan iş akışı tasarımcıyla geliştirici arasındaki sürtüşmeyi ciddi ölçüde azaltıyor; marka rengi üzerinden türeyen paletler çok daha düzenli çıkıyor, keyfi kararlar azalıyor. Ben bunu Ankara’da küçük bir SaaS panelinde denediğimde net fark ettim — ekip üyeleri ayrı ayrı renk seçmek yerine seed tabanlı sistemi görünce işi hızlandırdı. Şaşırdım açıkçası.
| Özellik | Küçük ekipte etkisi | Büyük organizasyonda etkisi |
|---|---|---|
| Impeller | Daha akıcı ilk açılış hissi | Cihaz çeşitliliğinde daha tutarlı deneyim |
| Dart Records/Patterns | Daha kısa kod | Daha az bakım yükü |
| Sealed class + switch | Bazı durumlarda gereksiz gelebilir | Error kaçırmayı ciddi azaltır |
| M3 / fromSeed() | Tasarım kararını kolaylaştırır | Tasarım sistemi standardizasyonu sağlar |
| WASM destek çizgisi | Pilot proje için ilginçtir | Lojistik olarak dikkatli plan ister |
Mülakatın ikinci yarısı: hızlı ateş sorulara nasıl yaklaşılır?
Neyse uzatmayalım. Rapid-fire bölümünün amacı aslında bilgi ölçmekten çok refleks ölçmektir. Adayın kafasında temel prensiplerin oturup oturmadığını anlarlar — çünkü burada uzun uzun düşünmeye fırsat yoktur. Zaman baskısı altında ne kadar netsin, onu görürler (yanlış duymadınız)
- Soru kısa gelir. (bu kritik)
- Cevap net olmalı.
- Eğer emin değilsen dürüstçe sınırı söylemelisin.
- Tahmin yürütüp sallamak genelde kötü görünür.
- Mantığı anlatmak ezberden iyidir. (bence en önemlisi)
- Kod yolculuğunu sade tutmak avantaj sağlar.
- Konu widget ise yaşam döngüsünü bilmen gerekir.
- Konu performanssa raster ile UI thread ayrımını bilmen beklenir.
Sık düşülen rapid-fire başlıkları neler?
StatefulWidget içinde setState kullanmadan state yönetilebilir mi? Evet, bazı dış mekanizmalarla mümkün. Klasik akışta setState hâlâ temel araçtır. Bunu bilmeden geçmeyin derim.
Bir başka favori soru da Visibility ile Offstage farkıdır — biri görünürlüğe odaklanır, diğeri ağacı koruyup çizimi gizler. Ben bunu geçen kasımda İzmir’de yapılan mini meetup’ta canlı anlatırken gördüm; salondaki birkaç kişi önce aynı sanmıştı. Örnek çalışınca taşlar yerine oturdu. Güzel bir andı. Ayrıca build metodunun null dönmesi gibi tuzaklar var ki bunlar özellikle yeni başlayanların canını yakar — bunlara da hazırlıklı ol.
Kod kokusu aldığım yerler: mimari ipuçları ve pratik sınırlar
Eğer küçük bir startup’taysan her şeyi en modern şekilde kurmaya çalışma dürtüsü geliyor insana. Anlıyorum. Ama bazen doğru tercih en gösterişli çözüm değil, en sürdürülebilir çözümdür (şaşırtıcı ama gerçek). Mesela Navigator 1 ile başlayıp sonra ihtiyaç oldukça Navigator 2’ye geçmek birçok ekip için gayet makul olabilir — bunu söylemek ayıp değil. Kullanıcı Neden Gitmeden Önce Beklemez? Hızın Gizli Bedeli yazımızda da bu konuya değinmiştik.
Kurumsal projede ise tersi olur. Orada baştan yol haritası çıkarılır; çünkü geri dönüş maliyeti yüksektir. Sonradan “aslında şöyle yapmak daha iyiymiş” demek kurumsal ortamda sprint kayıplarına, bazen de müşteri kaybına dönüşüyor. Acı ama gerçek.
Peki hangi durumda ne tercih edilir?
| Konu | Küçük ekip | Büyük ekip |
|---|---|---|
| Navigasyon modeli | Basit ekranlar için Navigator on numara | Ayrıntılı deep-link senaryolarında Router mimarisi gerekebilir |
| Error handling | Zaman zaman global try/catch yeter | Tüm zincirin izlenebilir olması şart |
| Eklenti bağımlılıkları | Sorun çıktığında hızlıca yamalanabilir | Sürüm uyumu politikası gerekir |
Bellekli Yapay Zekâ Anlayışı Bazen Flutter State Mantığını Hatırlatıyor mu?
Sıkça Sorulan Sorular
Flutter ３.x öğrenmek için Dart ３ şart mı?
Evet diyebilirim… büyük ölçüde evet. Yeni sözdizimi özelliklerinin çoğu Dart 3 ile geliyor ve bunları anlamadan modern Flutter kodunu rahat okumak zorlaşıyor.
Error handling için en kritik nokta nedir？
Ana fikir tek yerde toplamak değildir; gözden kaçanı yakalamaktır.Global error handler kurup loglamayı disiplin haline getirmek genelde en doğru başlangıçtır.
{?} Impeller gerçekten herkeste hız kazandırır mı?
%100 aynı sonuç beklememek lazım.Çoğu senaryoda ilk kare hissini iyileştiriyor,ama uygulamanın yapısı kötüysa mucize yaratmaz.
Navigasyon tarafında hemen Router’a geçmeli miyim?
If your app is small,hayır.Ama deep link,nested flow veya web URL eşleme varsa Router mimarisini düşünmek mantıklı olur.
Kaynaklar Ve Ileri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
