Mobil uygulama geliştirme: 14 haftalık gerçekçi takvim

iOS ve Android için tek kod tabanıyla geliştirilen orta kapsamlı bir mobil uygulama 8–14 haftada yayına alınır ve ₺140.000’den başlayan bir bütçe gerektirir. Takvimi en çok geciktiren kalem geliştirme değil; içerik, mağaza hesabı hazırlığı ve geri bildirim döngüsüdür.

Mobil proje planlarının çoğu geliştirme süresini doğru, çevresindeki işleri eksik tahmin ediyor. Aşağıda 14 haftalık bir projenin gerçek dağılımı var; kapsam küçüldükçe fazlar kısalır ama sıra değişmez.

Faz faz takvim

Keşif fazında netleşmesi gereken 5 karar

1. Uygulamanın tek bir ana işi ne? İlk sürüme yalnızca bunu ve destekleyen ekranları alın.
2. Kullanıcı girişi zorunlu mu? Zorunlu giriş, ilk açılıştaki terk oranını belirgin biçimde artırır.
3. Çevrimdışı çalışması gereken bir ekran var mı? Sonradan eklenmesi en pahalı özelliktir.
4. Hangi mevcut sisteme bağlanacak? Entegrasyon varsa API tarafının hazırlık süresi takvime ayrıca eklenmeli.
5. Yayın hangi hesaptan yapılacak? Kurumsal Apple Developer hesabı doğrulaması tek başına haftalar alabilir.

Beşinci madde en sık sürpriz üreten kalemdir. Apple’ın kurumsal hesap doğrulaması (D-U-N-S numarası dahil) ilk kez başvuran şirketlerde uzayabiliyor. Projenin ilk haftasında başlatın; geliştirme bitince başlatmayın.

Native mi, React Native mi?

İki platform için ayrı ayrı native geliştirme, tek kod tabanına göre tipik olarak %60–90 daha fazla süre ve bütçe gerektirir. Buna karşılık bazı durumlarda native gereklidir:

• Yoğun grafik veya oyun motoru gerektiren uygulamalar
• Donanıma derin erişim gerektiren işler (gelişmiş kamera işleme, BLE yoğun senaryolar)
• Platforma özgü, sürekli değişen sistem API’lerine bağımlı ürünler

Kurumsal uygulamaların, e-ticaret ve randevu uygulamalarının büyük çoğunluğu bu üç maddeye girmiyor. Bu yüzden projelerimizde varsayılan tercih React Native; native’e yalnızca yukarıdaki ihtiyaçlar varsa geçiyoruz.

Mağaza yayın süreci

Google Play tarafında inceleme genellikle hızlıdır; App Store tarafında ilk gönderimde red alma ihtimali yüksektir. En sık karşılaşılan red sebepleri şunlar:

• Hesap silme özelliğinin uygulama içinde bulunmaması (üyelik alan uygulamalar için zorunlu)
• Gizlilik politikası bağlantısının eksik ya da erişilemez olması
• Veri toplama beyanının uygulamanın gerçek davranışıyla örtüşmemesi
• İnceleme ekibi için test hesabı verilmemesi
• Uygulamanın web sitesinin birebir kopyası olması (özgün mobil değer sunmaması)

Bu beş maddeyi geliştirme sırasında kapatmak, yayın fazını 1–2 haftada bitirmenin en pratik yolu. Sonradan düzeltilmesi hâlinde her red turu ortalama 3–7 gün ekliyor.

Yayın sonrası: proje bitmiyor

Mobil uygulamada asıl maliyet yayından sonra başlar. iOS ve Android yılda birer büyük sürüm çıkarır; uyumluluk güncellemesi yapılmayan uygulamalar bir yıl içinde mağazadan düşebilir. Bakım planını baştan bütçeleyin.

• Yılda en az iki uyumluluk güncellemesi
• Çökme oranı takibi ve düzeltme döngüsü
• Kullanıcı yorumlarına yanıt — mağaza sıralamasını doğrudan etkiliyor
• Push bildirim stratejisi: sıklık arttıkça bildirim izni iptalleri hızla artıyor