Mobil uygulama konuşmalarının neredeyse tamamı aynı yerde tıkanıyor: "iOS için ayrı, Android için ayrı mı yaptıracağız?" Sorunun arkasında teknik bir merak değil, bütçe kaygısı var. Çünkü klasik yaklaşımda iki ayrı ekip, iki ayrı kod tabanı, iki ayrı test süreci ve uzun vadede iki ayrı bakım faturası anlamına geliyor bu.
Biz bu soruya birkaç yıldır aynı cevabı veriyoruz: çoğu iş için tek kod tabanı yeterli, hatta daha doğru. Ama bunu bir moda olduğu için değil, kendi ürünlerimizi de aynı yöntemle geliştirdiğimiz için söylüyoruz. Aracı savunmakla aracı tanımak arasında fark var; ikincisi ancak o araçla canlıya çıkıp bir süre bakımını yaptıktan sonra oluşuyor.
Bu yazıda Flutter'ı neden tercih ettiğimizi, nerede işe yaradığını, hangi maliyetleri gerçekten düşürdüğünü ve nerede "burası Flutter'lık değil" dediğimizi anlatacağım. Teknik bir övgü metni değil; teklif masasında müşteriye anlattığımız şeyin yazıya dökülmüş hali.
Tek kod tabanı tam olarak ne demek?
Flutter, Google'ın geliştirdiği bir arayüz çatısı. Yazdığınız kod derlenip iOS'ta da, Android'de de, web tarayıcısında da çalışabiliyor. Yani ekranları, iş mantığını, veri akışını bir kere yazıyorsunuz; platforma özgü kısımlar için küçük ayrımlar yapıyorsunuz.
Pratikte bu şu anlama geliyor: uygulamanızda "sipariş oluştur" ekranında bir değişiklik yapılacaksa, bu değişiklik tek yerde yapılır ve her iki mağazadaki sürüme de aynı anda gider. İki ayrı kod tabanında ise aynı değişikliğin iki kez yazılması, iki kez test edilmesi ve çoğu zaman iki farklı şekilde hata üretmesi gerekir.
Burada "her şey ortak" da demiyoruz. Bildirim izinleri, dosya seçici, kamera erişimi gibi konularda platformların kendi kuralları var ve o kısımlar ayrı ele alınıyor. Ama bir iş uygulamasında kodun büyük bölümü ekranlar, formlar, listeler, doğrulamalar ve veri iletişimidir. İşte o büyük bölüm ortaklaşıyor.
Asıl tasarruf ilk teslimatta değil
Burada sık yapılan bir hata var: tek kod tabanını sadece "yarı fiyatına uygulama" gibi görmek. İlk teslimatta elbette ciddi bir fark oluyor ama asıl kazanç ikinci yılda ortaya çıkıyor.
Bir uygulama canlıya çıktıktan sonra ölmez; yaşar. İşletim sistemi sürümleri değişir, mağaza kuralları güncellenir, yeni özellik istekleri gelir. İki ayrı kod tabanı bu bakım yükünü iki katına çıkarır. Tek kod tabanında ise bakım, tek bir hattan yürür. Uzun vadeli maliyeti düşüren şey budur.
İki kod tabanının görünmeyen maliyeti
Fatura kalemi olarak görünmeyen ama herkesin canını sıkan bir maliyet daha var: tutarsızlık. İki ekip aynı ekranı yazdığında, kullanıcı iki platformda birbirine benzemeyen iki uygulamayla karşılaşır. Bir tarafta hata mesajı çıkar, diğer tarafta sessiz kalır. Bir tarafta alan zorunludur, diğer tarafta değildir.
Bu tür farklar destek yükü üretir. Müşteri hizmetleri "hangi telefondasınız?" diye sormaya başlar. Tek kod tabanında bu sorunun büyük kısmı kendiliğinden ortadan kalkıyor, çünkü davranışı tanımlayan tek bir kaynak var.
Neden React Native değil de Flutter?
Bu sorunun tek doğru cevabı yok, ikisi de saygın araçlar. Bizim tercihimizin birkaç somut gerekçesi var.
- Arayüz tutarlılığı: Flutter kendi çizim motorunu kullanıyor. Yani bir düğme, iOS'ta da Android'de de aynı görünüyor. Tasarımı onaylanan ekranın iki platformda farklı davranması gibi bir sürprizle çok az karşılaşıyoruz.
- Performans: Native koda derleniyor. Liste kaydırma, animasyon, geçiş gibi kullanıcının doğrudan hissettiği yerlerde akıcılık sorunumuz olmuyor.
- Tasarımcı-geliştirici mesafesi: Grafik tasarım tarafını da aynı çatı altında yürüttüğümüz için, tasarımdan koda geçişte kayıp yaşanmaması bizim açımızdan önemli. Flutter'ın bileşen yapısı buna uygun.
- Tek dil: Ekibin tamamının aynı dilde çalışması, iş devri ve destek açısından sandığınızdan daha büyük bir avantaj.
- Öngörülebilir güncelleme: Arayüz motoru uygulamayla birlikte geldiği için, telefon işletim sistemi güncellendiğinde ekranların bozulma riski daha düşük.
Bunlar genel geçer avantajlar. Somut karşılığını ise kendi ürünlerimizde gördük. Projelerimiz arasında yer alan Amatör Arena spor platformunu ve Omerta oyununu geliştirirken kullandığımız yöntemler, müşteri projelerinde tahmin yürütmek yerine deneyimle konuşmamızı sağlıyor. Kendi ürününüzü kendi araçlarınızla geliştirmenin en büyük faydası da bu: aracın nerede tıkandığını müşteri projesinde değil, kendi projenizde öğreniyorsunuz.
Web tarafı: her zaman doğru cevap değil
Flutter web'e de derleniyor. Ama burada dürüst olmak gerekiyor: "tek kod tabanından web sitesi de çıkar" cümlesi her senaryo için doğru değil.
Flutter web'in iyi olduğu yer
Giriş yapılan, kullanıcıya özel ekranlar gösteren, veri girişi yapılan uygulamalar. Yani bir yönetim paneli, bir bayi portalı, bir rezervasyon ekranı, bir saha ekibi uygulamasının masaüstü sürümü. Buralarda arama motoru görünürlüğü zaten önemli değil, kullanıcı zaten giriş yapıyor. Mobil uygulamayla aynı kodu paylaşmak burada net kazanç.
Flutter web'in doğru seçim olmadığı yer
Kurumsal tanıtım siteleri, blog, e-ticaret vitrini, hizmet sayfaları. Yani Google'dan organik trafik alması beklenen her şey. Flutter web çıktısı, klasik HTML yapısına göre arama motorları açısından dezavantajlı. Sayfa açılış süresi ve ilk yüklenen dosya boyutu da tanıtım sitesi için ideal değil.
Bu yüzden karma bir yol izliyoruz: kurumsal site ve içerik tarafını web teknolojileriyle, uygulama tarafını Flutter ile kuruyoruz. İkisi aynı tasarım dilini, aynı veriyi ve aynı yönetim panelini paylaşıyor. Müşteri tek bir bütün görüyor, arkada ise her iş kendi doğru aracıyla yapılmış oluyor.
Nerede tek kod tabanından vazgeçiyoruz?
Bir aracın savunucusu olmak, onu her yere zorlamak demek değil. Şu durumlarda müşteriye açıkça "native yapalım" diyoruz:
- Donanımı çok yoğun kullanan işler: sürekli arka planda çalışan konum takibi, yoğun kamera işleme, özel Bluetooth cihaz entegrasyonları.
- Platforma çok özel deneyimler: saat uygulamaları, gelişmiş widget'lar, sistem seviyesinde entegrasyon isteyen senaryolar.
- Ağır grafik ve 3B gerektiren oyunlar. Basit oyun mantıkları Flutter'la gayet yürür ama sınır var, o sınırı biliyoruz.
- Kurumun halihazırda native bir uygulaması ve onu geliştiren iç ekibi varsa. O durumda sıfırdan taşımak yerine mevcut yapıyı iyileştirmek daha akıllıca oluyor.
Bu netliği baştan kurmak, projenin ortasında "bu özellik olmuyor" demekten çok daha iyidir. Teklif aşamasında hangi özelliğin hangi yöntemle yapılacağını yazılı olarak konuşuyoruz.
Bildirim, ödeme, entegrasyon: işin görünmeyen yarısı
Uygulama projelerinde konuşmalar genelde ekranlar üzerinden yürür, oysa süreyi belirleyen kısım çoğu zaman ekranlar değil. Bildirim altyapısı, oturum yönetimi, ödeme akışı, mevcut ERP veya muhasebe sistemiyle konuşma... Bunların her biri kendi başına bir kalem.
Tek kod tabanı bu tarafta da işi kolaylaştırıyor, çünkü entegrasyonun iş mantığı bir kez yazılıyor. Ama kolaylaştırmak yok saymak demek değil. "Mevcut sistemimizden veri çeksin" cümlesinin arkasında, karşı tarafın bir servis sunup sunmadığı sorusu var. Cevap hayırsa, o servisin de yazılması gerekir ve bu ayrı bir iştir. Kapsamı çıkarırken en çok bu noktada durup soru soruyoruz.
Süreç nasıl işliyor?
1. Kapsam çıkarma
Önce ekran listesi çıkarıyoruz. "Bir uygulama istiyorum" cümlesi teklif için yeterli değil; kaç ekran, hangi kullanıcı tipleri, hangi veri kaynakları, ödeme var mı, bildirim var mı? Bu liste netleşmeden fiyat vermiyoruz. Verirsek de o fiyat sonradan değişir ki bizim en sevmediğimiz şey bu.
2. Tasarım ve akış onayı
Kod yazılmadan önce ekranlar tasarlanıyor ve onaylanıyor. Bu aşamada yapılan değişiklik bedava, koddan sonra yapılan değişiklik pahalı. Müşteriye bunu her zaman açıkça söylüyoruz.
3. Geliştirme ve ara teslimler
Uygulamayı sonunda "tadaa" diye göstermiyoruz. Belirli aralıklarla test sürümü paylaşıyoruz, müşteri kendi telefonunda deniyor. Yanlış anlaşılmalar üç ay sonra değil, ilk iki haftada ortaya çıkıyor.
4. Mağaza yayını
App Store ve Google Play süreçleri kendi başına bir iş. Hesap açılışı, gizlilik politikası, uygulama içi satın alma kuralları, ekran görüntüsü standartları... Bunları müşteriye bırakmıyoruz, biz yürütüyoruz.
5. Teslim ve panel eğitimi
Teslimde mutlaka panel eğitimi yapıyoruz. İçerik girişi, bildirim gönderimi, kullanıcı yönetimi gibi işleri müşterinin kendi ekibi yapabilsin diye. Her küçük değişiklik için ajansa bağımlı kalınmasını doğru bulmuyoruz.
Fiyatlandırma tarafında nasıl duruyoruz?
Yazılım projelerinde en yaygın şikâyet, başlangıçta konuşulan rakamla sonunda ödenen rakamın tutmaması. Bunun sebebi çoğu zaman kötü niyet değil, kapsamın baştan yeterince net konuşulmamış olması.
Biz kapsamı netleştirip sabit fiyat veriyoruz. Kapsam büyürse ek iş olarak ayrıca konuşulur, ama onaylanan kapsam içinde sonradan sürpriz kalem çıkmaz. Web paketlerimizde barındırma, alan adı ve güncellemeler zaten dahil; uygulama projelerinde de aynı şeffaflık mantığını koruyoruz. Rakamlara ve nelerin dahil olduğuna paketler sayfasından bakabilirsiniz.
Manisa ve Ege için birkaç not
Bölgemizde sanayi, tarım, lojistik ve üretim ağırlıklı bir yapı var. Bu işletmelerin çoğunun ihtiyacı vitrin uygulaması değil; saha ekibinin kullanacağı iş uygulaması. Sevkiyat takibi, sipariş girişi, bakım formu, depo sayımı, bayi ekranı gibi.
Bu tip işlerde tek kod tabanı gerçekten çok işe yarıyor. Çünkü saha ekibinin elinde Android, yöneticinin elinde iPhone, ofiste ise tarayıcı var. Üçüne birden aynı yerden çıkabilmek, hem maliyeti hem de "hangi cihazda ne var" karmaşasını ortadan kaldırıyor.
Bir de şu var: saha uygulamalarının çoğu depoda, tarlada, yolda kullanılıyor. Yani internetin zayıf olduğu yerlerde. Bu yüzden çevrimdışı çalışma ve sonradan eşitleme meselesini baştan konuşuyoruz. Ekranları güzel yapmak kolay; bağlantı koptuğunda veri kaybetmeyen bir akış kurmak asıl iş.
Yakınlık da ayrı bir mesele. Ekranları yerinde göstermek, saha ekibiyle aynı odada test etmek uzaktan yapılan toplantılarla kıyaslanamaz. Manisa merkezli çalışıyoruz ve İzmir'den Denizli'ye, Aydın'dan Balıkesir'e Ege genelinde yerinde destek verebiliyoruz.
Sık aldığımız üç soru
"Uygulama native kadar hızlı olur mu?" Bir iş uygulaması, e-ticaret uygulaması veya içerik uygulaması için evet. Kullanıcı farkı hissetmiyor. Fark, donanımı sınırda kullanan senaryolarda ortaya çıkıyor ve zaten oralarda native öneriyoruz.
"Sonradan native'e geçmek gerekirse ne olur?" Sunucu tarafı ve veri yapısı ortak kaldığı için sıfırdan başlanmıyor. Yeniden yazılan kısım arayüz oluyor. Bu yüzden projeleri baştan katmanlı kuruyoruz.
"Tek kod tabanı test süresini de yarıya indirir mi?" Hayır, orada abartmamak lazım. Kod ortak olsa da iki platformda ayrı ayrı test etmek gerekiyor. Tasarruf geliştirme ve bakım tarafında; test tarafında kazanç daha ölçülü.
Özetle
Flutter sihirli değnek değil. Her işi çözmez, her yere uymaz. Ama doğru senaryoda kullanıldığında hem ilk maliyeti hem de uzun vadeli bakım yükünü ciddi biçimde azaltır, üstelik kullanıcı deneyiminden ödün vermeden.
Önemli olan, aracı işe göre seçmek. Tanıtım sitesini web teknolojileriyle, uygulamayı Flutter ile, donanım ağırlıklı özel işleri native ile yapmak. Bu ayrımı baştan doğru kuran proje, ilerleyen aylarda kimseyi zorlamaz.
Aklınızda bir uygulama fikri varsa, önce kapsamı birlikte çıkaralım. Ekran listesi netleştiğinde hem sürenin hem de bütçenin ne olacağı konuşulabilir hale gelir. Mesajlarınıza aynı iş günü içinde dönüyoruz; iletişim sayfasından yazmanız yeterli.