Mobil uygulama yaptırmaya karar veren herkes aynı yerde takılıyor: teklif isterken biri "Flutter ile yaparız, tek kodla iki platform" diyor, bir diğeri "native olmalı, performans farklı" diyor. İkisi de doğru cümleler ama ikisi de eksik.
Doğru soru "hangisi daha iyi" değil. Doğru soru şu: bu uygulama ne iş yapacak ve o iş hangi yaklaşımı gerektiriyor?
İkisi arasındaki fark, iş sahibi diliyle
Native, her platform için ayrı yazmak demek. Android tarafı Kotlin, iOS tarafı Swift ile yazılır. İki ayrı kod tabanı, iki ayrı geliştirme süreci.
Flutter, tek kod yazıp iki platforma birden çıkmak demek. Arayüz ve iş mantığı bir kez yazılır, her iki mağazaya da o koddan derlenir.
Üçüncü bir seçenek daha var ve tuzak burada: web sitesini uygulama gibi paketlemek. Ucuz görünür, hızlı görünür. Apple bunu genellikle reddediyor — mağaza kuralları, yalnızca siteyi çerçeve içinde gösteren uygulamaları "yeterli işlevi olmayan uygulama" sayıyor. Yani en ucuz yol, çoğu zaman hiç yayınlanamayan yoldur.
"Tek kod tabanı" gerçekten yarı fiyat mı?
Hayır, ve bu yanlış beklenti en çok hayal kırıklığı üreten yer.
Flutter'da paylaşılan şey arayüz ve iş mantığı. Paylaşılmayan şeyler:
- İki ayrı mağaza süreci. App Store ve Google Play'in kendi hesapları, kendi inceleme kuralları, kendi red gerekçeleri var. Bu iş Flutter ile de iki kere yapılır.
- İki platformda test. Aynı kod, farklı cihazlarda farklı davranır. Klavye, bildirim izni, geri tuşu, güvenli alan — hepsi ayrı kontrol ister.
- Platforma özel davranışlar. iOS kullanıcısı bazı şeyleri iOS gibi, Android kullanıcısı Android gibi bekler. Tek arayüzü ikisine birden oturtmak ayrı bir iştir.
- Cihaz özelliklerine erişim. Kamera, arka planda konum, Bluetooth gibi konularda çoğu zaman yine platforma özel kod yazılır.
Gerçekçi beklenti şu: Flutter iki ayrı native geliştirmeye göre ciddi tasarruf sağlar, ama yarı fiyat değil. Bütçeyi "ikiye böleriz" varsayımıyla kuran proje, mağaza aşamasında şaşırıyor.
Ne zaman native
Native'i şu durumlarda tercih ediyorum:
- Cihaz yoğun kullanılıyorsa. Sürekli konum takibi, harita üstünde canlı hareket, kamera ile yoğun işlem, arka planda çalışma.
- Platform deneyimi işin kendisiyse. Uygulamanın her platformda oranın alışkanlıklarına birebir uyması bekleniyorsa.
- Uzun ömürlü, büyüyecek bir ürünse. Yıllarca geliştirilecek bir ürün, platformun kendi araçlarıyla daha rahat büyür.
Kendi ürünüm Lojinak'ı bu yüzden native yazdım: Android tarafı Kotlin ve Jetpack Compose, iOS tarafı Swift ve SwiftUI. Uygulama nakliye talebi oluşturmayı, canlı teklif toplamayı ve anlaşılan aracı harita üzerinde takip etmeyi yapıyor; müşteri, nakliyeci ve şoför için üç ayrı akış var. Harita ve canlı takip yoğun olduğu için platformun kendi araçlarıyla çalışmak doğru karardı.
Ne zaman Flutter
Flutter şu durumlarda daha mantıklı:
- Uygulama ağırlıklı olarak form, liste ve panelse. Veri girişi, kayıt görüntüleme, onay akışı gibi işler tek kodla gayet iyi çalışıyor.
- Bütçe ve hız öncelikliyse. Tek ekip, tek kod, daha kısa süre.
- Aynı işi iki platformda birden yayına almak gerekiyorsa ve platform farkları işin özünde değilse.
Bir sinema zinciri için yaptığım personel uygulaması (vardiya takibi, görev atama, kasa girişi onayı) hem Flutter hem native iOS sürümü olarak yazıldı. Aynı işi iki yaklaşımla yazmak öğretici oldu: arayüz ve iş mantığı tarafında Flutter belirgin şekilde hızlı ilerletiyor, fark asıl mağaza süreçlerinde ve platforma özgü ayrıntılarda kapanıyor.
Fiyat: neden kimse net rakam veremiyor
Piyasadaki rehberlere baktığında 15.000 TL'den 3.000.000 TL'ye kadar uzanan rakamlar görürsün. Bu bant o kadar geniş ki pratikte işe yaramıyor. Sebebi şu: "mobil uygulama" tek bir ürün değil.
Fiyatı belirleyen asıl sorular şunlar:
| Soru | Fiyata etkisi |
|---|---|
| Kaç farklı kullanıcı rolü var? | Her rol ayrı ekranlar ve ayrı yetki demek |
| Arka uç (backend) var mı, yoksa sıfırdan mı kurulacak? | Veritabanı, API, kimlik doğrulama ayrı iş |
| Ödeme alınacak mı? | Mağaza kuralları ve komisyon devreye girer |
| Harita, kamera, bildirim gibi cihaz özellikleri var mı? | Her biri ek geliştirme ve test |
| Yönetim paneli gerekiyor mu? | Çoğu zaman uygulamanın kendisi kadar iş |
| Tek platform mu, iki platform mu? | İki mağaza iki süreç |
Teklif alırken bu altı sorunun cevabını yazılı olarak ver. Cevaplar net olmadan gelen fiyat tahmin, teklif değil.
Mağaza tarafındaki gizli maliyetler
Yazılım bitince iş bitmiyor. Sık atlanan kalemler:
- Geliştirici hesapları. Apple tarafı yıllık 99 dolar, Google tarafı tek seferlik 25 dolar. Bu hesaplar senin adına açılmalı; geliştiricinin hesabında kalan uygulama, ilişki bittiğinde senin olmaz.
- İnceleme süreci. Apple her sürümü inceliyor. Ret gelirse düzeltip yeniden gönderiyorsun; bu, takvimde gün demek.
- Uygulama içi satın alma. Uygulama içinde dijital abonelik satıyorsan mağazanın kendi ödeme sistemini kullanman gerekiyor ve mağaza komisyon alıyor. Harici ödeme entegrasyonu kullanmak ret sebebi olabiliyor.
- Zorunlu güncellemeler. Platformlar her yıl yeni sürüm çıkarıyor, uygulamanın belirli aralıklarla güncellenmesi gerekiyor. Bu bir bakım kalemidir.
- Gizlilik bildirimleri. Mağazalar hangi veriyi topladığını beyan etmeni istiyor; beyan ile uygulamanın davranışı uyuşmazsa ret geliyor.
Karar tablosu
| Durum | Öneri |
|---|---|
| Form, liste, panel ağırlıklı iç kullanım uygulaması | Flutter |
| Harita, canlı takip, arka planda konum | Native |
| Kısa sürede iki mağazada olmak, bütçe sınırlı | Flutter |
| Uzun ömürlü, sürekli büyüyecek ana ürün | Native |
| Sadece web sitesini uygulama yapmak | Hiçbiri — muhtemelen reddedilir |
Sormanız gereken sorular
- Bu uygulama hangi cihaz özelliklerini kullanacak?
- Arka uç var mı, yoksa o da kapsama mı dahil?
- Geliştirici hesapları kimin adına açılacak?
- Mağaza reddi gelirse düzeltme kapsam içinde mi?
- Yayın sonrası güncelleme ve bakım nasıl yürüyecek?
- Kaynak kod bana veriliyor mu?
Son soru özellikle önemli. Kaynak kodu olmayan bir uygulama, geliştiriciden bağımsız yaşayamaz.
Uygulamanın yanında web tarafı da olacaksa, kurumsal web sitesi maliyeti yazısı bandları anlatıyor. Uygulamada randevu da olacaksa randevu sistemi yazısındaki müsaitlik ve çakışma bölümleri aynen geçerli.