Mobil Uygulama Yayın Süreci: Mağaza Reddine Yakalanmama Rehberi

Mağaza yayını, mobil projelerin en çok küçümsenen aşamasıdır: geliştirme biter, herkes rahatlar ve inceleme reddi takvimi iki hafta geriye atar. Yayınladığımız uygulamalardan damıtılmış kontrol listesi:

Ret sebeplerinin kısa listesi

• Eksik gizlilik beyanı: veri toplama beyanları (App Privacy / Data Safety) kodda gerçekte olanla birebir örtüşmeli; “analitik yok” deyip çökme raporlayıcısı gömmek klasik rettir.
• Giriş duvarı: incelemeci uygulamayı açamazsa reddeder. Test hesabı + inceleme notu her gönderimde standart.
• Bitmemiş his: boş durum ekranları, kırık bağlantılar, “yakında” düğmeleri. İlk sürüm dar olsun ama her ekranı dolu olsun.
• Ödeme kuralları: dijital içerik satışı mağaza içi ödemeye tabidir; harici ödeme yönlendirmeleri platform kurallarına göre tasarlanmalı.
• İzin gerekçeleri: kamera/konum izin metinleri gerçek kullanım amacını söylemeli; şablon metin ret sebebidir.

Sürüm stratejisi

1. İç dağıtım (TestFlight / Internal testing) — ekip + müşteri, her sprint sonu.
2. Kapalı beta — gerçek kullanıcı alt kümesi; çökme oranı ve ilk oturum hunisi izlenir.
3. Kademeli yayın — Play’de yüzdeli açılım, App Store’da aşamalı yayın; sorun ilk %10’da yakalanır.
4. Zorunlu güncelleme altyapısı — ilk sürümden itibaren: bir gün kritik bir hatayı herkesten geri çekmeniz gerekecek.

Takvim gerçeği

İnceleme süreleri değişkendir; kritik lansmanlarda gönderimi hedef tarihten en az bir hafta önce yapar, ret senaryosuna bir düzeltme turu bütçeleriz. “Cuma gönderelim, hafta sonu onaylanır” cümlesi, pazartesi krizinin tarifidir.

Mobil projelerde uçtan uca nasıl çalıştığımız: Mobil Uygulama hizmeti.