Aşama 1 — Kapsam ve ekran listesi
Uygulamanın ne yapacağını cümlelerle değil, ekranlarla tanımlamak gerekiyor. “Kullanıcı üye olsun, ilan versin, mesajlaşsın” cümlesi kulağa üç işmiş gibi geliyor; ekran listesine döküldüğünde on beş ekran çıkıyor: kayıt, giriş, şifre sıfırlama, profil, profil düzenleme, ilan oluşturma, fotoğraf yükleme, ilan önizleme, ilan listesi, ilan detayı, mesaj listesi, mesaj ekranı, bildirim ayarları, arama, filtre.
Bu liste hem fiyatın hem takvimin temeli. Aynı aşamada cevaplanması gereken diğer soru sunucu tarafı: uygulama verileri kendi cihazında mı tutacak, yoksa üyelik, veritabanı ve bildirim gibi bir arka uç mu gerekiyor? Arka uç ihtiyacı, projenin büyüklüğünü belirleyen tek kalem olabiliyor.
Burada verilmesi gereken en zor karar, ilk sürüme neyin girmeyeceği. Her fikir haklıdır ama hepsi ilk sürüme girerse uygulama hiç yayınlanmaz. Pratik yöntem: uygulamanın var olma sebebini tek cümleyle yazın, o cümleye hizmet etmeyen her şeyi ikinci sürüme bırakın.
Aşama 2 — Native mi, cross-platform mu?
Bu kararın maliyete etkisi büyük. Native geliştirme, Android ve iOS için ayrı ayrı uygulama yazmak demek: iki kod tabanı, iki bakım hattı ve her yeni özellikte iki kat iş. Cross-platform ise tek kod tabanından her iki platforma birden çıkmak.
Uygulamaların büyük çoğunluğunda cross-platform doğru tercih: süre kısalıyor, maliyet düşüyor ve güncellemeler tek yerden yapılabiliyor. Kullanıcı açısından fark, çoğu uygulamada hissedilir düzeyde değil.
Native’in hâlâ doğru olduğu yerler var ve bunları baştan bilmekte fayda var: yoğun grafik işleyen oyunlar, cihazın alt seviye donanımına derinlemesine giren uygulamalar (gelişmiş kamera işleme, özel Bluetooth cihazlarıyla düşük seviye haberleşme) ve milisaniye hassasiyeti gerektiren işler. Projeniz bu tanıma girmiyorsa cross-platform’a itiraz etmek için pratik bir sebep kalmıyor.
Aşama 3 — Arayüz tasarımı
Tasarım aşamasının çıktısı bir resim değil, tıklanabilir bir prototip olmalı. Yani ekranlar arasında gerçekten gezinebildiğiniz, akışı telefonunuzda deneyebildiğiniz bir sürüm.
Sebebi basit: bir akışın sorunlu olduğu, resme bakarak değil deneyerek anlaşılıyor. “Buradan geri dönünce sepet boşalıyor” gibi bir sorun prototipte on saniyede fark ediliyor, kod yazıldıktan sonra ise günler alıyor.
Bu yüzden geliştirmeye, akış onaylanmadan başlanmamalı. Onay öncesi yapılan değişiklik ücretsizdir; onay sonrası yapılan değişiklik bir maliyet kalemidir.
Aşama 4 — Geliştirme
Geliştirmede takip edilmesi gereken tek kural şu: sonunda tek seferde teslim edilen proje, kötü giden projedir. İki haftada bir yüklenebilir bir test sürümü almalısınız ve bunu kendi telefonunuzda çalıştırabilmelisiniz.
Bunun sebebi denetim değil, maliyet. Yanlış anlaşılmış bir gereksinim iki hafta sonra fark edildiğinde iki haftalık iş yeniden yapılır; üç ay sonra fark edildiğinde proje yeniden kurulur.
Bu aşamada arka uç ve uygulama genellikle paralel ilerliyor. Push bildirim altyapısı, çevrimdışı çalışma, kullanım analitiği ve hata takibi de burada kuruluyor — özellikle hata takibi, yayın sonrası kullanıcıların yaşadığı çökmeleri görmenin tek yolu ve sonradan eklemek zor.
Aşama 5 — Test
Test, geliştiricinin kendi telefonunda denemesi değil. Üç ayrı boyut var: farklı ekran boyutları (küçük telefondan tablete), farklı işletim sistemi sürümleri (eski Android sürümleri hâlâ yaygın) ve gerçek kullanım koşulları (zayıf bağlantı, düşük pil, izin reddetme).
Uygulamanın izin isteme davranışı özellikle test edilmeli: kullanıcı konum iznini reddettiğinde uygulama çökmemeli, ne yapacağını bilmeli. Mağaza incelemelerinde en sık takılınan noktalardan biri de bu.
Aşama 6 — Mağaza yayını
Bu aşama çoğu kişinin beklediğinden daha uzun sürüyor ve büyük kısmı sizin kontrolünüzde değil. Gerekenler:
- Geliştirici hesapları. Google Play tek seferlik, App Store yıllık ücretli. Hesaplar uygulamanın sahibi olarak sizin adınıza açılmalı — geliştiricinin hesabında duran uygulama, ilerde ciddi bir sorun.
- Mağaza görselleri ve metinler. Simge, ekran görüntüleri, kısa ve uzun açıklama. Bunlar aynı zamanda mağaza içi aramada bulunmanızı sağlayan alanlar.
- Gizlilik politikası ve veri formu. İki mağaza da uygulamanın hangi veriyi topladığını beyan etmenizi istiyor. Beyan ile uygulamanın gerçek davranışı uyuşmuyorsa uygulama reddediliyor.
- İnceleme süreci. Birkaç gün ile birkaç hafta arasında değişebiliyor. Red gelirse gerekçeye göre düzeltip yeniden gönderiliyor; ilk yayında red almak sıra dışı değil.
Maliyeti ne belirliyor?
Fiyat sorusunun cevabı dört kalemde toplanıyor:
- Ekran sayısı. En doğrudan etken.
- Sunucu tarafı ihtiyacı. Üyelik, veritabanı ve bildirim gerekiyorsa proje belirgin şekilde büyüyor.
- Entegrasyonlar. Ödeme, harita, kimlik doğrulama, üçüncü taraf servisler.
- Mağaza yayınının kapsama dahil olup olmadığı.
Bir de sık atlanan kalem var: yayın sonrası. Uygulama yayınlandığında iş bitmiyor. İşletim sistemleri yılda bir büyük sürüm çıkarıyor ve uygulamanın bunlara uyumlu tutulması gerekiyor; mağazalar da zaman zaman yeni beyan ve kural zorunlulukları getiriyor. Bakımı planlamayan projeler bir–iki yıl içinde mağazadan düşüyor.
Ne kadar sürer?
Orta ölçekli bir uygulama için 6–12 hafta gerçekçi bir aralık. Buna mağaza inceleme süresi dahil değil, çünkü o süre mağazaların kontrolünde. Süreyi en çok uzatan iki şey: ilk sürüm kapsamının şişmesi ve içerik/veri hazırlığının gecikmesi.