Mobil uygulama yaptırma: süreç, maliyet ve yaygın hatalar

Mobil uygulama, mobil uyumlu bir web sitesinden çok daha pahalı ve bakımı süreklidir. Kullanıcı uygulamayı indirmek, güncellemek ve telefonunda yer ayırmak zorundadır. Bu eşiği aşmayı hak eden bir sebep olmalıdır.

Uygulama mantıklıdır: kullanıcı haftada birden fazla açacaksa, bildirim göndermek işin merkezindeyse, kamera, konum, çevrimdışı çalışma gibi cihaz özellikleri gerekiyorsa.

Uygulama gereksizdir: içerik ağırlıklı bir tanıtımsa, kullanıcı yılda birkaç kez girecekse, yapılan her şey web tarayıcısında da yapılabiliyorsa. Bu durumda mobil uyumlu bir site aynı işi çok daha ucuza görür.

Native geliştirme, iOS için Swift ve Android için Kotlin ile ayrı ayrı yazmak demektir. En yüksek performansı verir ama iki ayrı kod tabanı, iki ayrı bakım ve yaklaşık iki kat maliyet anlamına gelir.

Cross-platform yaklaşımda ise tek kod tabanından her iki platform çıkar. React Native ve Flutter bu alanın yaygın araçları. İşletme uygulamalarının büyük çoğunluğu için performans farkı kullanıcı tarafından hissedilmez.

Pratik kural: yoğun grafik, gerçek zamanlı görüntü işleme ya da çok karmaşık animasyon gerekmiyorsa cross-platform doğru seçimdir. Bütçenizin yarısını platform ikilemesine harcamak yerine ürünü iyileştirmeye ayırırsınız.

Uygulamanın görünen yüzü ekranlardır ama maliyetin önemli kısmı arkada yatar. Kullanıcı hesabı, veri saklama, bildirim altyapısı, ödeme, yönetim paneli ve raporlama — bunların hepsi ayrı geliştirme kalemleridir.

Sadece bilgi gösteren, veri yazmayan bir uygulama ile kullanıcıların hesap açtığı, içerik oluşturduğu ve ödeme yaptığı bir uygulama arasında kat kat fark vardır. Teklif alırken ekran sayısını değil, uygulamanın hangi verileri kimden alıp nereye yazacağını anlatın.

App Store ve Google Play'e yayınlamak teknik bir adımdan ibaret değildir; her iki mağazanın da inceleme süreci ve kuralları vardır.

• Apple Developer ve Google Play Console hesapları açılır (yıllık ücretlidir ve firma adına olmalıdır)
• Mağaza görselleri, ekran görüntüleri ve açıklama metinleri hazırlanır
• Gizlilik politikası ve veri kullanım beyanı zorunludur
• Uygulama yüklenir ve incelemeye gönderilir

Apple incelemesi genelde birkaç gün sürer ve reddedilme ihtimali gerçektir; eksik gizlilik beyanı, çalışmayan test hesabı ya da mağaza kurallarına aykırı bir akış en sık görülen ret sebepleridir. Bu süreci ajansın yürütmesi süreyi kısaltır.

• Geniş kapsamla başlamak. İlk sürüme her özelliği koymak, hem maliyeti hem riski büyütür. Kullanıcı geri bildirimi gelmeden yapılan geliştirmelerin önemli kısmı sonradan çöpe gider.
• Tasarımı atlamak. "Önce çalışsın, sonra güzelleştiririz" yaklaşımı, çalışan ama kullanılmayan bir uygulamayla sonuçlanır ve arayüz yeniden yazılır.
• Yönetim panelini sonraya bırakmak. Uygulamadaki içeriği güncellemek için her seferinde geliştiriciye ihtiyaç duymak, uzun vadede en pahalı kalemdir.
• Analitik kurmamak. Hangi ekranda kullanıcı kaybedildiğini bilmeden yapılan iyileştirmeler tahminden ibarettir.

İyi bir ilk sürüm, hedef kullanıcının tek bir işini baştan sona ve kusursuz çözer. Yemek siparişi uygulamasıysa: menüyü gör, sepete ekle, öde, siparişi takip et. Sadakat programı, kupon sistemi, arkadaş davet etme ikinci sürüme kalır.

Bu yaklaşımın avantajı hızlı yayına çıkmak ve gerçek kullanıcı verisiyle devam etmektir. İkinci sürümde ne geliştireceğinizi tahminle değil, ölçümle belirlersiniz.