Mobil uygulama maliyeti ve süreci

Mobil uygulama projelerinde maliyeti belirleyen şey ekran sayısı değildir. Aşağıda gerçekte neye para verildiğini ve en sık nerede aksadığını yazdık.

Önce şu soruya cevap verin: uygulama gerçekten gerekli mi?

Bazı işler için mobil uygulama doğru araç değildir. Kullanıcı yılda birkaç kez giriyorsa uygulama indirmez, indirse de siler.

Uygulamayı haklı çıkaran üç durum var:

• Sık kullanım. Kullanıcı haftada birkaç kez açıyorsa uygulama mantıklı olur.
• Cihaz özelliğine ihtiyaç. Kamera, konum, bildirim, çevrimdışı çalışma.
• Saha kullanımı. İnternetin zayıf olduğu ortamda çalışan ekipler.

Bunların hiçbiri yoksa mobil uyumlu bir web sitesi çoğu zaman hem daha ucuz hem daha etkilidir. Bu soruyu baştan sormak, altı ay sonra indirilmeyen bir uygulamayla kalmaktan iyidir.

Tek kod tabanı mı, iki ayrı uygulama mı?

Eskiden iOS ve Android ayrı ayrı yazılırdı; bu, iki ekip ve iki bütçe demekti. Bugün çoğu iş için tek kod tabanından iki platforma çıkmak mümkün ve maliyeti yaklaşık yarıya indiriyor.

Ayrı yazmanın hâlâ gerekli olduğu durumlar var: yoğun grafik işleme, platforma çok özel donanım erişimi, oyun. Tipik bir iş uygulaması bunlara girmiyor.

Maliyeti belirleyen asıl kalemler

Giriş ve hesap yönetimi. Kayıt, giriş, şifre sıfırlama, e-posta doğrulama, hesap silme. Basit görünür ama projede tahmin edilenden fazla yer tutar.

Çevrimdışı çalışma. Uygulama internetsiz de çalışacaksa veriyi cihazda tutup bağlantı gelince eşitleyen bir katman gerekiyor. Bu tek başına ciddi bir iştir ama saha ekipleri için genellikle zorunludur.

Abonelik ve satın alma. Mağaza içi satın alma, deneme süresi, iptal ve iade akışı. Sonradan eklemesi en zor parçalardan biridir. Ayrıca mağazalar bu satışlardan komisyon alıyor ve bu oran iş modelinizi etkiliyor.

Bildirimler. Altyapı, izin akışı ve hangi bildirimin ne zaman gideceğinin kurgusu. Yanlış kurgulanmış bildirim, uygulamanın silinme sebebi oluyor.

Yönetim paneli. Uygulamadaki içeriği kim güncelleyecek? Panel unutulursa her küçük değişiklik için geliştirici gerekiyor ve bu, uzun vadede en pahalı kalem oluyor.

Mağaza yayın süreci. Gizlilik formları, hesap silme akışı, ekran görüntüleri, açıklama metinleri, inceleme yanıtları. Genellikle hiç bütçelenmiyor ama gerçek bir iştir.

Görünmeyen maliyetler

Bunlar tekliflerde çoğu zaman yazmıyor ama ödeniyor.

• Geliştirici hesapları. Apple ve Google geliştirici hesapları yıllık ücretlidir.
• Sunucu ve veri tabanı. Uygulama tek başına çalışmıyor; arkasında bir servis oluyor.
• Bildirim ve e-posta servisleri. Kullanım arttıkça ücretlendirme başlıyor.
• Çökme takibi. Hangi cihazda ne zaman çöktüğünü görmeden düzeltmek mümkün olmuyor.

Mağaza incelemesinde en sık takılınan üç şey

Hesap silme akışının olmaması. Kullanıcı hesap açabiliyorsa uygulama içinden silebilmeli de. Apple bunu zorunlu tutuyor ve eksikse reddediyor.

Gizlilik bildiriminin eksik olması. Hangi verinin toplandığı ve ne için kullanıldığı mağaza formunda eksiksiz beyan edilmelidir.

Boş ya da demo içerik. İnceleme ekibi uygulamayı gerçekten kullanıyor. İçi boş bir uygulama "yeterli içerik yok" gerekçesiyle reddediliyor.

Bunların üçü de baştan planlanırsa sorun çıkarmıyor; sonda fark edilirse haftalar kaybettiriyor.

Süreç kabaca nasıl işliyor?

Kapsam belirleme. İlk sürümde neyin olmayacağına karar vermek. Mobilde en pahalı hata, her şeyi ilk sürüme sıkıştırmaktır.

Akış tasarımı. Tek elle kullanım, parmak erişimi, platform alışkanlıkları. iOS ve Android kullanıcıları farklı hareketlere alışkın; ikisini de kendi diline saygı göstererek tasarlamak gerekiyor.

Geliştirme. İki haftada bir test sürümü telefonunuza geliyor ve gerçek cihazda deniyorsunuz. Simülatörde iyi görünen çok şey gerçek cihazda farklı davranıyor.

Mağaza hazırlığı. Formlar, görseller, metinler. Ekran görüntüleri mağazada en çok bakılan şeydir ve satın alma kararını doğrudan etkiliyor.

Aşamalı yayın. Kullanıcıların bir kısmına açıp çökme raporlarını izlemek, sonra genişletmek. Her iki mağaza da bunu destekliyor ve kullanmamak için sebep yok.

Yayından sonrası

Mobilde yayın bir bitiş değildir. İşletim sistemi güncellemeleri, mağaza politikası değişiklikleri ve cihaz çeşitliliği sürekli küçük bakım gerektiriyor.

Apple ve Google her yıl yeni sürüm çıkarıyor ve uygulamanın o sürümlerle uyumlu kalması gerekiyor. Uzun süre güncellenmeyen uygulamalar mağazadan kaldırılabiliyor.

Pratik bir yaklaşım şu: ilk yılın bütçesine, geliştirme maliyetinin belirli bir oranını bakım payı olarak yazın. Bu pay ayrılmadığında uygulama genellikle bir yıl içinde çalışmaz hâle geliyor.

Zamanı neyin uzattığı

Projelerde en çok zamanı kod değil, bekleyen kararlar yakıyor. Tasarım onayı, içerik teslimi, mağaza hesabı açılışı ve ödeme sağlayıcı başvurusu tipik bekleme kalemleridir.

Bunları baştan başlatmak, geliştirmeyi hızlandırmaktan daha çok zaman kazandırıyor.

---

Kas Hafızam uygulamasını bu şekilde geliştirdik; vaka çalışmasında süreci ayrıntılı anlattık. Kendi projenizi konuşmak isterseniz mobil uygulama geliştirme sayfasına bakabilirsiniz.