Uygulama bitti, test edildi, mağazaya gönderildi. Birkaç gün sonra gelen cevap: reddedildi. Şimdi hem takvim kayıyor hem de düzeltmenin maliyeti, baştan doğru yapmanın maliyetinden yüksek.
Ret gerekçelerinin çoğu sürpriz değil. Aşağıdakiler en sık karşılaşılanlar ve neredeyse hepsi, kod yazılmadan önce alınan kararlarla ilgili.
1. Web sitesini uygulama sanmak
En sık ve en pahalı hata. Var olan siteyi bir çerçeve içine koyup mağazaya göndermek ucuz ve hızlı görünüyor. Apple bunu "yeterli işlevi olmayan uygulama" sayıyor ve reddediyor.
Mantığı şu: kullanıcı zaten tarayıcıdan o siteye girebiliyorsa, o uygulamanın mağazada bulunması için bir sebep yok. Uygulamanın tarayıcının yapamadığı bir şey yapması bekleniyor — bildirim, çevrimdışı çalışma, cihaz özellikleri, uygulamaya özel akış.
Bu kararın maliyeti şu: "sitemi uygulama yapalım" diye başlayan proje, reddedildikten sonra "gerçek uygulama yazalım"a dönüyor ve ilk harcanan para çöpe gidiyor. Doğrusu, baştan sitenin arka ucuna bağlanan gerçek bir uygulama yazmak.
2. Dijital satışta kendi ödeme sistemini kullanmak
Uygulama içinde dijital bir şey satıyorsan — abonelik, kredi, premium özellik, ders paketi — mağazanın kendi satın alma sistemini kullanman gerekiyor. Kendi ödeme altyapını koymak yaygın bir ret sebebi.
Bunun iki sonucu var ve ikisi de baştan bilinmeli:
- Komisyon. Mağaza satıştan pay alıyor. İş modelini kurarken bu payı hesaba katmadıysan, fiyatlandırman yanlış demektir.
- Teknik kurulum. Uygulama içi satın alma ayrı bir entegrasyon; abonelik yenileme, iade, sunucu tarafında doğrulama gibi parçaları var.
Fiziksel ürün ya da uygulama dışında tüketilen hizmet satıyorsan bu kural geçerli değil; orada kendi ödeme sistemini kullanabilirsin. Ayrım "dijital ve uygulama içinde tüketiliyor mu" sorusunda.
3. İnceleme ekibinin uygulamayı kullanamaması
Girişi olan bir uygulama gönderiyorsan, inceleme ekibine çalışan bir demo hesap vermen gerekiyor. Vermezsen ya da hesap çalışmıyorsa, ekip uygulamanın içini göremiyor ve reddediyor.
Aynı başlık altına girenler: eksik özellik, çalışmayan buton, "yakında" yazan ekranlar, test verisi görünen sayfalar. Mağaza yarım uygulamayı kabul etmiyor.
4. Gizlilik beyanı ile davranışın uyuşmaması
Her iki mağaza da hangi veriyi topladığını beyan etmeni istiyor: Apple'da gizlilik etiketleri, Google Play'de veri güvenliği formu. Beyan ettiğin ile uygulamanın gerçekte yaptığı uyuşmuyorsa ret geliyor.
En sık takılınan yer analiz ve çökme raporu araçları. Uygulamaya bir analiz aracı eklediysen, o araç veri topluyor demektir; formda bunu belirtmek zorundasın.
Ayrıca hesap oluşturulabilen uygulamalarda hesap silme imkânının uygulama içinde sunulması isteniyor. "Bize e-posta atın, silelim" yeterli değil.
5. İzin istemek ama gerekçesini yazmamak
Konum, kamera, mikrofon, rehber gibi izinler isteniyorsa, iznin neden gerektiğini anlatan metinlerin doldurulmuş olması gerekiyor. Boş bırakılan ya da "uygulamanın çalışması için gerekli" gibi anlamsız yazılan gerekçeler ret sebebi.
Buna bağlı bir başka madde: kullanmadığın izni isteme. Uygulama konumu kullanmıyorsa konum izni istemesi hem ret sebebi hem kullanıcı kaybı.
6. Hesap ve yayıncı sorunları
Daha uygulamaya bakılmadan çıkan sorunlar:
- Geliştirici hesabı yanlış kişide. Hesap senin adına olmalı. Geliştiricinin hesabında yayınlanan uygulama, ilişki bittiğinde onun hesabında kalır.
- Marka ve içerik hakları. Kullandığın isim, logo ya da görseller sana ait değilse ret gelir.
- Yaş sınırı ve içerik derecelendirmesi yanlış seçilmişse düzeltme istenir.
Yayına göndermeden önce kontrol listesi
- Uygulama tarayıcının yapamadığı bir şey yapıyor mu?
- Dijital satış varsa mağazanın satın alma sistemi kullanılıyor mu?
- Çalışan demo hesap hazır mı?
- Tüm ekranlar tamam mı, "yakında" yazan yer kaldı mı?
- Gizlilik formu uygulamanın gerçek davranışıyla uyuşuyor mu?
- Hesap silme uygulama içinde var mı?
- İstenen her izin için gerekçe metni yazıldı mı?
- Geliştirici hesapları senin adına mı?
- Gizlilik politikası adresi çalışıyor mu?
Ret geldiğinde ne yapılır
Panik yapmadan önce şunu bil: ret, sürecin normal bir parçası. Gelen mesajda hangi maddeye takıldığın yazılı oluyor ve çoğu zaman ekran görüntüsü de ekleniyor.
İki yol var: düzeltip yeniden göndermek ya da kararın yanlış olduğunu düşünüyorsan itiraz etmek. İtiraz gerçekten yanlış anlaşılma varsa işe yarar; kural açıkça ihlal ediliyorsa zaman kaybıdır.
Takvim planlarken ilk gönderimin geçmeyebileceğini varsay. Lansman tarihini inceleme süresine yapışık vermek, herkesi zora sokuyor.
Uygulama yaptırmadan önce hangi yaklaşımın seçileceği Flutter mı native mi yazısında; bütçe tarafı kurumsal web sitesi maliyeti yazısında.