Son dönemde en çok duyduğum sorulardan biri şu:

“Ferhat, AI çıktı… artık yazılım daha ucuz değil mi?”

Kısa cevap: Bazı işlerde evet, ama kurumsal projelerde resim biraz daha farklı.
AI (kod asistanları, otomatik test, tasarım üretimi, dokümantasyon araçları) geliştirme süreçlerini hızlandırdı. Fakat iş “kurumsal mobil uygulama”ya geldiğinde, maliyetin asıl belirleyicileri hâlâ aynı: kapsam, mimari, entegrasyonlar, kalite ve sürdürülebilirlik.

Ben bu yazıda, sahada gerçek projelerde gördüğüm şekilde anlatacağım: AI mobil uygulama maliyetini nerede düşürür, nerede düşürmez? Ve “mobil uygulama fiyat hesaplama” yaparken nelere bakmak gerekir?

1) AI gerçekten neyi ucuzlattı?

AI’nın en net faydasını, tekrarlayan ve standart işlerde görüyorum:

• Basit ekranlar (listeleme, detay, form gibi)
• Standart kullanıcı akışları (login, profil, ayarlar)
• Boilerplate kodlar (temel altyapı)
• Dokümantasyon ve örnek kod hazırlığı
• Bazı test senaryolarının hızlı çıkarılması

Bu tip işlerde AI, geliştirme süresini kısaltabildiği için mobil uygulama fiyatları tarafında aşağı yönlü bir etki yaratabiliyor.

Ama…

2) Kurumsal projelerde neden “maliyet otomatik düşmüyor”?

Kurumsal bir mobil uygulamanın maliyeti genellikle “kod yazmak”tan ibaret değil. Hatta çoğu zaman en büyük maliyet kodun kendisi değil, şu parçalar:

• İş analizi (scope): Ne yapılacağı doğru tanımlanmazsa AI sadece yanlış işi hızlandırır.
• Mimari & ölçeklenebilirlik: Çok kullanıcı, rol-yetki, performans, raporlama.
• Offline çalışma & senkronizasyon: Saha ekipleri için kritik ve karmaşık bir konu.
• ERP/CRM entegrasyonları: Kurumsalda asıl zorluk burada başlar.
• Güvenlik & KVKK: Yetkilendirme, loglama, veri saklama politikaları.
• Kalite ve yayın süreçleri: Cihaz çeşitliliği, App Store süreçleri, stabilite.

Yani AI iyi bir hızlandırıcı ama kurumsalda maliyetin “kritik kalemleri” hâlâ uzmanlık ve süreç yönetimi istiyor.

3) Mobil uygulama maliyeti neye göre çıkar?

“Mobil uygulama maliyeti”ni hesaplarken ben genelde şu 7 başlığa bakıyorum:

1. Ekran sayısı ve akış karmaşıklığı
2. Rol-yetki yapısı (admin, saha, bayi, yönetici…)
3. Offline gereksinimi
4. Cihaz özellikleri (push, konum, foto/video, dosya yükleme)
5. Entegrasyonlar (ERP/CRM, ödeme, SMS/e-posta, kargo vb.)
6. Raporlama ve yönetim paneli
7. Bakım & SLA (kurumsalda asıl değer burada)

Bu yüzden “mobil uygulama fiyat hesaplama” dediğimiz şey tek bir kaleme bakarak yapılmıyor. “10 ekran var” demek tek başına yeterli olmuyor; o ekranların arkasındaki iş akışı, entegrasyon ve kalite beklentisi fiyatı asıl belirliyor.

4) AI ile birlikte bütçe nereye kaydı?

Benim gözlemim şu: AI sayesinde bazı proje tiplerinde toplam maliyet düşebiliyor; ama çoğu kurumsal projede olan şey şu:

• Geliştirme süresi kısalıyor (iyi)
• Ama analiz, test, entegrasyon ve bakım daha çok önem kazanıyor (zorunlu)

Yani şirketler “daha ucuz yazılım”dan çok daha hızlı ve daha güvenli teslimat kazanıyor. Bu da uzun vadede toplam sahip olma maliyetini (TCO) düşürüyor.

5) Kurumsal müşteri için en doğru soru: “Ucuzlar mı?” değil, “Sürdürülebilir mi?”

Kurumsal tarafta benim için kritik olan şey şu:

• Yarın bir ekip devraldığında bu sistem yürür mü?
• Yeni özellik geldiğinde sistem çatlar mı?
• Saha operasyonunda internet gidince çalışır mı?
• ERP değişince entegrasyon yönetilebilir mi?
• Bakım ve SLA düzgün mü?

Bunlar oturduğunda, zaten maliyet “doğru yerden” optimize edilmiş oluyor.

Sonuç: AI tek başına fiyat düşürmez, doğru süreç fiyatı düşürür

AI, iyi kullanılırsa geliştirmeyi hızlandırır. Ama kurumsal işlerde maliyetin ana belirleyicileri hâlâ: kapsam, mimari, entegrasyon, kalite ve bakım.

Eğer sen de “mobil uygulama geliştirme” projen için net bir yol haritası ve gerçekçi bir bütçe aralığı istiyorsan, en hızlı yöntem şu: 15 dakikalık kısa bir ihtiyaç analizi.

---

İletişim / Teklif

Projene göre mobil uygulama maliyeti ve zaman planını netleştirmek için buradan iletişime geçebilirsin:
👉 https://ferhatbalaban.com/#contact

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

Bu yazıda hangi teknolojiyi neden seçiyoruz , nasıl seçiyoruz, seçerken ne çileler çekiyoruz ve seçim sonuçlarına nasıl katlanıyoruz gibi bir paylaşımda bulunacağım.

Muhtemelen sen de yazılımcıysan, hayatının bir döneminde “Şimdi ben hangi teknoloji yığınını seçsem?” diye kara kara düşünmüşsündür. Hatta bazen kulaklarını ‘React mi, Flutter mı? Django mu FastAPI mi?’ gibi benzer sorularla doldurup, beklenmedik anlarda “Merhaba diyafram nefesi!” diye stres atmaya çalışıyorsundur. Hiç merak etme; bugün sana kendi maceramdan bahsedeceğim ve bu acı tatlı seçme sürecini biraz olsun şenlendireceğim. Sonuçta bir seçim yapmamız gerekiyor nedenleri ile de seçip arkasında duracağız.

Öncelikle projemiz ağırlıklı planladığım üzere web tabanlı çalışacak bir saas projesi ve belli parçaları python ile prototip olarak yapılmış durumda. Bu neden önemli? Prototip yaparken genelde python veya nodejs kullanıyorum, bunun da sebebi prototip geliştirmede çok hızlı olmaları ayrıca birçok kütüphane ile hızlıca testlerimi yapabiliyorum.

Bu durumda server tarafında çalışacak kodun bir kısmı elimde var ama ortada ne ui – arayüz var ne de veritabanı sistemi ,ui ile çalışacak api mevcut.

Önce biraz teknik bilgiler verelim:

1. Front-end Teknolojisi Seçimi
   • React: Web tarafında en popüler ve büyük topluluğa sahip kütüphanelerden biri. React ile birlikte React Router, Redux gibi ek kütüphanelerle ölçeklenebilir bir yapı kurabilirsin. Arayüzü daha hızlı geliştirmek için de Tailwind CSS, Material UI veya Chakra UI gibi bileşen kütüphanelerini kullanabiliriz.
   • Next.js (React tabanlı): React üzerine inşa edilen Next.js, sunucu taraflı render (SSR) ve sayfa bazlı yönlendirme gibi özelliklerle SEO ve performans açısından avantaj sağlayabilir. SaaS projelerinde statik + dinamik sayfaları kolayca yönetmek için de faydalı oluyor.
   • Flutter Web: Flutter esasen mobil uygulamalar geliştirmek için çok popüler. Web desteği de var ancak performans ve kullanıcı deneyimi açısından henüz React/Next.js kadar yaygın kullanıldığını söyleyemeyiz. Tamamen tek bir codebase ile hem mobil hem web isteyenlerin tercih ettiği bir yol. Projenin odak noktasında web varsa React/Next.js, eğer mobil uygulamaya da hızlıca geçmek istiyorsan Flutter değerlendirilebilir.
2. Arayüzün Modern ve İyi Görünmesi İçin
   • Tasarım Kütüphaneleri:
     • React ekosisteminde Material UI, Chakra UI, Ant Design, Tailwind CSS gibi seçenekler var. Bunlar hazır bileşen setleri, responsive tasarım, tema ve tipografi gibi konularda büyük kolaylık sağlar.
     • Kullanıcıya olabildiğince basit, temiz ve hızlı bir deneyim sunmayı hedeflemek lazım???
   • UX/UI Trendleri: Modern ve sade UI trendlerini takip edebilirsin bu aşamada. Özellikle minimal, boşlukları iyi kullananmak lazım. Büyük ve okunabilir tipografi, sezgisel navigasyonlu tasarımlar revaçta.
3. Back-end ve Veri Tabanı Seçimi
   • Eğer Python ile devam edeceksek:
     • Django: Kullanıcı yönetimi, admin panel, ORM (Object Relational Mapping) gibi pek çok özelliği hazır sunuyor. Hızlı prototipleme sağlıyor.
     • FastAPI: Daha hafif, asenkron yapısıyla yüksek performanslı bir REST API sunmak için iyi bir seçenek. Özellikle microservices mimarisine uygun.
   • Veritabanı olarak PostgreSQL, MySQL veya MongoDB tercih edebiliriz. JSON verileriyle yoğun çalışıyorsak, PostgreSQL’in JSON desteği de oldukça başarılı.
4. SaaS Mimarisindeki Önemli Noktalar
   • Kullanıcı Yönetimi & Yetkilendirme: Birçok SaaS projesinde kullanıcıların rollerini veya abonelik planlarını yönetmek için entegre bir sistem gerekiyor. Django veya FastAPI’de JWT tabanlı token yapıları ya da OAuth2 gibi standartları kullanarak güvenlik sağlayabiliriz.
   • Ödeme Altyapısı: Global bir proje olacağından Stripe, PayPal vb. ödeme altyapılarına entegre olup abonelik modelini yönetebiliriz.
   • İş Akışı (Workflow) Yönetimi: Projelerde aşama aşama ilerleme, onay mekanizmaları, durum güncellemeleri ve geçmiş kaydı tutmak için tasarlanmış bir yapı. Kullanıcıların hangi adımda olduğunu, hangi onayların beklediğini ve işin ne zaman tamamlandığını net takip edebilmelisin.
   • Arka Planda Çalışan İşlemler: Uzun süren işlemleri senkron veya asenkron şekilde yönetmek için Celery (Django/Flask/FastAPI ile uyumlu) ya da RQ (Redis Queue) gibi job queue çözümlerine bakabiliriz. Bu sayede ağır işlemleri asenkron şekilde yürütüp kullanıcıya daha hızlı tepki verebiliriz.
5. DevOps, Dağıtım ve Ölçeklenebilirlik
   • Docker: Projeyi Docker konteynerleri halinde paketlemek, hem yerel geliştirme ortamında tutarlılık hem de üretim ortamında kolay taşıma sağlar.
   • CI/CD: GitHub Actions, GitLab CI/CD veya Jenkins gibi araçlarla testleri, otomatik build ve deploy süreçlerini yönetmek büyük avantaj sağlar.
   • Bulut Altyapısı: AWS, Google Cloud veya Azure’da container orchestration (Kubernetes, ECS vs.) kullanarak projenin ölçeklenebilirliğini artırabiliriz.
6. Flutter vs React Karşılaştırması
   • Eğer ağırlıklı web üzerinde koşacak bir SaaS uygulaması yapıyorsan, React/Next.js ekosistemi bize daha hızlı ve yaygın bir çözüm sunar.
   • “Aynı uygulamayı mobilde de kullanmak istiyorum, tek kod tabanıyla ilerlemek istiyorum” dersen Flutter (ya da React Native) düşünürsün. Yine de Flutter Web henüz React/Next.js kadar olgun değil; bazı karmaşık web projelerinde daha fazla ince ayar yapmak gerekebilir.

Özetle

• Front-end: React + (Material UI / Tailwind / Chakra UI) veya Next.js üzerine modern bir tasarım kurmak, web uygulaması için daha “endüstri standardı” bir yaklaşım olur.
• Back-end: Python ile Django veya FastAPI, veritabanında PostgreSQL (JSON desteği) ya da MongoDB (döküman bazlı) kullanabiliriz.
• İş Akışı & Asenkron Görevler: Celery ya da RQ gibi araçlarla uzun süren işlemleri yönet.
• Abonelik/Üyelik & Ödeme: SaaS modelinde kullanıcı rol yönetimi, abonelik planları ve ödeme entegrasyonunu sağlam bir şekilde tasarla.
• DevOps: Docker + CI/CD + bulut sağlayıcı üzerinde ölçeklenebilir bir mimari kurmaya gayret et.

Bu şekilde hem teknolojik olarak güçlü hem de kullanıcı deneyimi açısından modern bir SaaS platformu geliştirebiliriz.

Ne seçiyorum?

Next.js + FastAPI + PostgreSQL, modern ve yüksek performanslı bir web uygulaması geliştirmek için oldukça popüler bir kombinasyon. Bu yüzden mobil uygulamarda daha iyi olan Flutter ı seçmiyoruz çünkü projemiz web tabanlı ve ileride gerekirse Yine FastAPI arkada olacak şekilde bazı react kodlarını ortak kullanıp React Native ile mobil uygulama yapabiliriz çok tercih etmesemde. Ama zaten bu işte mobil uygulama düşünmüyoruz çünkü arayüz çok mobil cihazlara sığacak gibi değil. Arayüzün mobil ağırlıklı olduğu bir proje olsaydı Flutter>FastApi>PostgreSql yapardık. Web de ise UI i Next.js yapmak daha mantıklı görünüyor.

1. Next.js (Front-end)
   • React tabanlıdır ve Sunucu Taraflı Render (SSR), statik site oluşturma (SSG), API Routes gibi özellikler sunar.
   • SEO dostudur, kullanıcıya hızlı bir deneyim sağlar.
   • Arayüz (UI) tarafını yönetmek ve dinamik sayfalar oluşturmak için oldukça esnek bir yapıdadır.
2. FastAPI (Back-end API)
   • Python ile yazılmış, asenkron (async/await) desteğiyle öne çıkan, hızlı ve hafif bir web framework’tür.
   • Temel hedefi: RESTful API’lar veya GraphQL endpoint’ler gibi servis tabanlı uygulamalar geliştirmek.
   • Performansı sayesinde gerçek zamanlı veya yüksek trafikli ortamlarda rahatlıkla kullanılabilir.
3. PostgreSQL (Veritabanı)
   • Güçlü, açık kaynaklı ve ilişkisel bir veritabanı yönetim sistemi.
   • JSON desteği, güçlü sorgulama mekanizmaları, yüksek güvenilirlik ve ölçeklenebilirlik sunar.
   • FastAPI ile birlikte SQLAlchemy, Tortoise ORM gibi kütüphaneler kullanılarak kolayca entegre edilebilir.

Basit mimari şöyle olacak yani

[Next.js (Front-end)] — (fetch/axios) –> [FastAPI (REST API)] — (ORM) –> [PostgreSQL]

1. Next.js uygulaması, kullanıcıya HTML/JS/CSS çıktısını sunar. Kullanıcı etkileşimleri (butona tıklama, form gönderme vb.) sonucunda FastAPI’ye istek gönderir.
2. FastAPI, gelen isteği işleyip gerekli veritabanı işlemlerini (ekleme, silme, güncelleme, sorgulama) yapar.
3. PostgreSQL, kalıcı veri depolama işlevini üstlenir. ORM (ör. SQLAlchemy) veya direkt PostgreSQL sorguları kullanarak kayıt oluşturulabilir, güncellenebilir, silinebilir.
4. Sonuçlar JSON (ya da ihtiyacına göre farklı format) olarak geri döndürülür; Next.js bu veriyi alarak ekranda günceller.

Off Zor İş:

Sonuçta seçtik, seçerken düşündük, araştırdık ve bir yol belirledik. Yarın biri neden bunu seçtin dediğinde işte kafama göre takıldım diyemezsin, her bilirkişi gibi sağlam temellere oturtman lazım , mantıklı bir cevap verebiliyor olman lazım

Mesela “Şundan dolayı seçtim” diyebilmen lazım?

1. Performans ve Esneklik: FastAPI asenkron yapısıyla hız, Next.js ise SEO dostu SSR ile kullanıcı deneyimini destekler.
2. Modüler Geliştirme: Front-end (Next.js) ve back-end (FastAPI) ayrı proje klasörlerinde veya depo (repository) olarak tutulabilir; birindeki değişiklik diğerini doğrudan etkilemez.
3. Ölçeklenebilirlik: Uygulama büyüdükçe mikroservis mimarisine kaymak, ek hizmetler eklemek veya ayrı ayrı container/hosting yapmak kolaylaşır.
4. Python Ekosistemi: Makine öğrenmesi, veri analizi veya background task gibi konularda Python kütüphanelerinden faydalanmak istediğinde, FastAPI sana kolay bir yol sunar.
5. Topluluk ve Dökümantasyon: Next.js ve FastAPI her ikisi de popüler, iyi dokümantasyona sahip ve aktif topluluk destekli araçlardır.

Sonuç:

Zaten her projede illaki bir “Acaba şunu mu kullansaydım?” diyen çıkar. Önemli olan, senin ihtiyaçlarını hangi kombinasyonun daha iyi çözdüğüdür. Ben de projenin ihtiyaçlarını göz önünde bulundurarak NextJs-FastApi-PostgreSQL üçlüsünü tercih ettim.

Hani Slogan Vardı ya, ‘Seç beğen, al!’
Tam da öyle yaptım: Seçtim, beğendim, aldım. Bakalım başımıza neler gelecek, çok yakında sonuçları da paylaşacağım, umuyorum güzel sonuçlanır 🙂

Flutter, Google tarafından geliştirilen, iOS, Android, Web ve Desktop için yüksek performanslı, tüketicinin beklentilerini karşılayan uygulamalar oluşturmayı hedefleyen bir mobil uygulama frameworkü olarak bilinir. Ancak Flutter’ın avantajları sadece bunlarla sınırlı değil. İşte Flutter’ı benzersiz kılan birkaç özellik:

1. Tek Kod Tabanı

Flutter, geliştiricilere iOS, Android, Web ve Desktop için uygulamaları tek bir kod tabanıyla yazma olanağı sunar. Bu, geliştirme sürecini hızlandırır ve işleri kolaylaştırır. Maliyetden tasarruf imkanı sağlar. 4 platforma da geliştirme yapacaksanız tek bir developer ile de işlerinizi yapmanız mümkün hale gelir.

Örnek bir “Merhaba Dünya” uygulaması:

import 'package:flutter/material.dart';
 void main() {
   runApp(MyApp());
 }
 class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Merhaba Dünya',
       home: Scaffold(
         appBar: AppBar(
           title: Text('Merhaba Dünya'),
         ),
         body: Center(
           child: Text('Merhaba Dünya!'),
         ),
       ),
     );
   }
 }

2. Hot Reload

Flutter’ın “hot reload” özelliği, geliştiricilerin yapılan değişiklikleri anında görmesini sağlar. Bu, hataların hızlıca bulunmasını ve düzeltilmesini sağlar ve geliştirme sürecini önemli ölçüde hızlandırır.

class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Hot Reload Örneği',
       home: MyHomePage(),
     );
   }
 }
 class MyHomePage extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return Scaffold(
       appBar: AppBar(
         title: Text("Hot Reload Örneği"),
       ),
       body: Center(
         child: Text("Değişiklikleri anında görün!"),
       ),
     );
   }
 }

Bu kodu çalıştırın ve "Değişiklikleri anında görün!" metnini değiştirin. Hot Reload özelliği sayesinde uygulamanın durumunu kaybetmeden değişikliği hemen görebilirsiniz.

3. Performans

Flutter, Dart dilinde yazılmıştır ve Dart, Just-In-Time ve Ahead-Of-Time derleme yeteneklerine sahiptir. Bu özellikler, uygulamanın başlangıç süresini hızlandırır ve performansını iyileştirir.

4. Zengin Widget Kütüphanesi

Flutter, kullanıcıların modern ve çekici bir arayüz oluşturmasını sağlayan bir dizi widget sunar. Bu widget’lar hızlı ve kolay bir şekilde uygulamaya entegre edilebilir.

class MyApp extends StatelessWidget {
   @override
   Widget build(BuildContext context) {
     return MaterialApp(
       title: 'Zengin Widgetler',
       home: Scaffold(
         appBar: AppBar(
           title: Text('Zengin Widgetler'),
         ),
         body: Center(
           child: RaisedButton(
             onPressed: () {},
             child: Text('Bir Buton Widgeti'),
           ),
         ),
       ),
     );
   }
 }

Bu kod parçası, basit bir buton widget’ini kullanarak kullanıcıya etkileşimli bir öğe sunar.

Flutter, bu gibi özellikleri sayesinde uygulama geliştirmede yeni bir çağ açmaktadır. Tek kod tabanı, hot reload, yüksek performans ve zengin widget kütüphanesi gibi özellikler, geliştiricilere daha hızlı ve daha etkili uygulamalar oluşturma imkanı sağlar. Üstelik bunu tüm platformlara export yapabilme özelliği ile birleştirerek bize zaman kazandırır. Sadece zaman değil ayrıca tek kod sayesinde ortak bir kalite yakalanmış olur. Tekrar eden kodlar azalır. Tabi ki tek kod ortamında kodunuz yine kaliteli olmak zorunda. Yazdığını flutter uygulamasını kötü yazarsanız sonuç tüm platformlarda kötü olacaktır. Bu yüzden işe başlamadan önce iyi araştırmak, örnekleri incelemek ve gerekirse eğitim almak önemlidir. Bir de şuna deyinmeden geçmemek lazım. Flutter bir client geliştirme aracı. Yani siz kapsamlı bir iş yapıyorsanız sağlam bir backend e de ihtiyaç duyacaksınız. Bunun için ayrı bir detaylı backend makalesi yazacağım.

Flutter’ın son gelişmelerini takip etmek ve tüm bu eşsiz özelliklerini keşfetmek için https://flutter.dev sitesini ziyaret edebilirsiniz. Nasıl kurulur, kullanılır ve son stabil sürümleri nelerdir https://docs.flutter.dev adresinde mevcut. Her stabil sürüm upgrade i ile çok daha iyi hale gelen flutter ı siz de öğrenebilir ve projelerinizde kullanabilirsiniz.

Herkese merhaba,

Uzun zamandır bir yazı paylaşmadığımı farkederek genel olarak bir paylaşım yapmak istedim.

Biliyorsunuz eskiden yaptığım paylaşımlarda ios da swift , android de ise java ve kotlin kullanarak native mobil uygulama geliştirme yaptığımızdan ve flutter a geçtiğimizden bahsetmiştim.

Bu serüven devam ediyor ve yeni yapılan uygulamaları flutter da yapıyoruz. Ancak eskiden gelen bazı uygulamalar hala native swift ve java,kotlin de devam ediyor. Büyük uygulamaları flutter a geçirmek kolay değil tabiki ancak sıfırdan yazılan uygulamalarda flutter ın kolaylıklarını çok aramaya başladık.

Son 3 senedir flutter ile uğraştığımızı düşünürsek oldukça deneyimimiz oldu bu konuda. İlk başlarda eski yönteme göre alışması zor olsada bir kere alıştığınızda artık herşey daha hızlı ve kolay oluyor. Hele birde hazırladığınız bir çatı var ise bu iş artık her projede daha kolay hala geliyor.

Flutter ve Getx kütühanesi de bu işi beraber daha da hızlandırıyor.

Sizler için flutter getx örneği hazırladım. Bu örnekde flutter ı çalıştırmayı ve biraz ön bilgisi olanların anlayabileceği sade bir yapı mevcut. İçerisinde bir başlangıç seti mevcut. Nasıl bir çatı kurmalıyız? Hangi kütüphaneleri kullanmalıyız hepsi mevcut.

https://github.com/balabanferhat/FlutterGetXWithNavigation

Ayrıca sayfamdaki diğer flutter örneklerini de inceleyebilirsiniz.

https://github.com/balabanferhat

Stackoverflow bilmeyenler için anlatmak gerekirse yazılımcıların çok kullandığı ve her türlü teknik soruyu sorduğu ve cevabını aldığı çok popüler bir web sitesi.

Bu sayede bizde sorulan sorular üzerinden kimin hangi konu ile daha çok ilgilendiğini görebilliyoruz.

Özellikle React-Native ile rekabet eden (kullanıcı sayısı olarak) Flutter, bu yarışta 2019 ortalarında öne geçmiş görünyor.

2020 yılında grafik bu şekilde.

2021 de ise fark oldukça açılmış. Buda flutter ın farkı daha da açacağını ve react in düşüşe geçeceğinin bir göstergesi bana göre.

Özellikle web tarafı Flutter da geliştikçe React tercih etmelerine gerek kalmayacak kimsenin. Daha önceki yazılarımda Flutter’ın dart dilinde tek bir kod yazarak hem android hem ios gerçek Native Mobil Uygulama yapabildiğinden bahsetmiştim. React malesef tam native değil arada bir javascript katmanı var ve buda biraz performans sorunu yada hatalara yol açabiliyor. Flutter ile hazırlanan küttüphanelerin modülleri tam native çevirisi yapıyor ve sonuç-çıktı gerçek bir native uygulama.

Ancak dikkat! Flutter’ı yanlış kullanırsanız sonuç React’dan kötü oluyor. State management çok önemli bir kavram Flutter da ve yanlış yapılırsa ciddi performans sorunları oluşuyor.

Ancak konumuz şimdi bu değil. Bu yazıda Fllutter’ın giderek yaygınlaştığını ve React’in giderek düşeceğini vurgulamak istedim.

Şimdi çok ilginç bir grafik daha paylaşacağım. Biliyorsunuz mobil uygulama geliştirken uzun yıllar android de java ve son olarak kotlin , ios da ise objective-c ile başlayan maceramız swift dili ile devam etti.

Java çok eski ve birçok yerde kulllanılan bir dil olduğundan onla kıyaslamak doğru olmaz flutter ı. Ancak son yıllarda android uygulama geliştirme dili olarak popüler olan Kotlin dilini karşılaştırma için kulllanabileceğimizi düşünüyorum.

Grafikte gördüğünüz gibi swift ve kotlin i sollamış durumda Flutter. Önümüzdeki zamanda Flutter ın 2017 de çıktığını düşünürsek bu yıllarda düşüşe geçen Swift de, 2021 den sonra düşecek olan Kotlin’de Flutter bu hızda giderse düşüş göstermeye devam edecek gibi görünüyor.

Yeni mobil uygulama geliştirecek arkadaşlara tavsiyem şu olacak. Trendi takip edin. Bu sayede güncel kalabilirsiniz. Bu tavsiyem hem yazılımcı arkadaşlara hem de mobil uygulama yaptırmak isteyenlere.

Sağlıkla ve sevgiyle kalın!