Uygulama Mağazası Reddini Önleyen Yayın Öncesi Kontrol Listesi

Bir uygulama mağazası incelemesinden dönen "reddedildi" bildirimi, çoğu ekibin sandığından çok daha az sıklıkla koddan kaynaklanır. Sahada en sık görülen sebepler eksik bir gerekçe metni, ulaşılamayan bir gizlilik politikası bağlantısı veya incelemecinin uygulamaya giriş yapamamasıdır. Kötü haber şu ki her ret, sürümü tipik olarak birkaç gün geciktirir. İyi haber ise bu sebeplerin neredeyse tamamı yayın öncesi on beş dakikalık bir kontrolle önlenebilir.

1. İzinler ve gerekçeleri

Konum, kamera, mikrofon, kişiler ve bildirim izinlerinin her biri için iki soru sorulur: gerçekten gerekli mi ve kullanıcıya neden gerektiği anlatılıyor mu? Uygulamanın kullanmadığı bir izni istemek doğrudan ret sebebidir; kullandığı ama gerekçesi yazılmamış bir izin de öyle.

Pratik kural: her izni, kullanıcının o özelliği ilk kez kullanmaya çalıştığı anda isteyin. Uygulama açılışında peş peşe beş izin penceresi göstermek hem ret riskini artırır hem de izin verme oranını düşürür. Arka planda konum gibi hassas izinlerde ise gerekçenin somut olması beklenir; "daha iyi hizmet için" gibi genel ifadeler yetersiz bulunur.

2. Gizlilik metni ve veri beyanı

Gizlilik politikası bağlantısının çalışması, metnin uygulamanın gerçekte topladığı veriyle tutarlı olması ve mağaza panelindeki veri beyanı formuyla çelişmemesi gerekir. En sık yakalanan tutarsızlık şudur: analitik veya çökme raporlama kütüphanesi cihaz tanımlayıcısı topluyordur, ancak beyanda "veri toplanmıyor" işaretlenmiştir. Üçüncü parti kütüphanelerin ne topladığı, entegrasyondan önce kontrol edilmelidir; bu, bağımlılıkları güvenle kullanmak yazımızda ele aldığımız denetim alışkanlığının mobil tarafındaki karşılığıdır.

3. Hesap silme yolu

Uygulama içinde hesap açılabiliyorsa, hesabın uygulama içinden silinebilmesi de beklenir. "Bize e-posta gönderin" çözümü artık kabul edilmiyor. Silme akışının yalnızca var olması değil, kolay bulunabilir olması da isteniyor; ayarların üçüncü alt menüsüne gizlenmiş bir bağlantı geri dönüş sebebi olabiliyor.

4. İncelemeci erişimi

Giriş gerektiren her uygulamada incelemeciye çalışan bir test hesabı verilmelidir. Burada üç detay atlanıyor: hesabın inceleme süresince aktif kalması, çok adımlı doğrulama varsa bunun nasıl aşılacağının açıklanması ve hesabın gerçek veriye sahip olması. Boş bir hesapla açılan uygulama "işlevsiz" görünebilir ve içerik yetersizliğinden reddedilebilir.

Ayrıca uygulamanın incelendiği ağdan erişilebilir olması gerekir. Yalnızca kurumsal ağdan çalışan bir arka uç, incelemecide bağlantı hatası üretir.

5. Mağaza sayfası tutarlılığı

Ekran görüntüleri ve açıklama, uygulamanın gerçek hâlini yansıtmalıdır. Henüz yayımlanmamış bir özelliğin tanıtımda görünmesi, yanıltıcı bulunur. Aynı şekilde açıklamada rakip marka adı geçirmek veya "en iyi", "bir numara" gibi kanıtlanamayan iddialar kullanmak da düzeltme talebi getirir.

6. Çökme ve temel işlevsellik

İncelemede en hızlı ret sebebi, uygulamanın açılışta veya ilk akışta çökmesidir. Yayın öncesi minimum kontrol: en eski desteklenen işletim sistemi sürümünde, küçük ekranlı bir cihazda ve internet bağlantısı yokken uygulamayı açmak. Çevrimdışı davranış, en çok atlanan durumdur; bu konuda offline-first tasarım yazımız yalnızca ret riskini değil, gerçek kullanıcı deneyimini de doğrudan iyileştirir.

Cihaz kaynaklarını agresif kullanan uygulamalar da eleştiri alır. Arka planda sürekli konum veya ağ isteği yapan bir uygulama hem pil tüketimi nedeniyle kullanıcı şikâyeti toplar hem de mağaza tarafında incelemeye takılabilir; pil tüketimini artıran hatalar yazımızdaki kalıplar bu açıdan da yararlıdır.

7. Sürüm notları ve sürümleme

"Hata düzeltmeleri ve iyileştirmeler" her sürümde tekrarlandığında kullanıcı için bilgi taşımaz. Somut sürüm notu yazmak, güncelleme oranını artıran en ucuz yöntemdir. Sürüm numarasının artırılmayı unutulması ise yükleme aşamasında hata verir — basit ama sık yaşanan bir zaman kaybıdır.

Reddedildiyse ne yapmalı?

Ret bildirimi genellikle ilgili kural maddesine atıf yapar. İzlenecek sıra şudur: maddeyi okuyun, tartışmak yerine somut değişikliği yapın ve yeniden gönderirken ne değiştiğini kısa ve net yazın. Kararın yanlış olduğunu düşünüyorsanız itiraz yolu vardır; ancak itiraz ancak elinizde somut bir kanıt (ekran görüntüsü, akış açıklaması) varsa işe yarar. Uygulama yayın kurallarının güncel hâli için Android geliştirici dokümantasyonu düzenli takip edilmelidir; kurallar sessizce güncellenir.

Sonuç

Uygulama mağazası reddi, çoğu ekipte teknik bir başarısızlık değil, süreç eksikliğidir: izin gerekçesi yazılmamıştır, gizlilik beyanı gerçek durumla çelişir, incelemeciye çalışan bir hesap verilmemiştir. Bu maddeleri bir kontrol listesine dönüştürüp her sürümde beş dakikada gözden geçirmek, ortalama bir ekipte yılda birkaç haftalık gecikmeyi ortadan kaldırır. Bir sonraki sürümü göndermeden önce şu üçünü doğrulayın: test hesabı çalışıyor mu, gizlilik bağlantısı açılıyor mu, uygulama uçak modunda açılıyor mu?