Pars Design
Blog

Web, SaaS ve Yazılım · Mobil Uygulama Tasarım ve Geliştirme

App Store reddi: en sık beş neden ve her birinin önlemi

Yayın günü gelen bir ret e-postası takvimi bozar. Beş ret nedenini, her birinin hangi kuraldan geldiğini ve yayından önce neyi kontrol ettiğimizi yazdık.

Güncellendi: 3 dk okuma
Uygulama incelemesinde reddedildi durumunu gösteren telefon ekranı
İçindekiler

Kısaca

  • Retlerin çoğu kural bilgisizliğinden değil, yayın öncesi kontrolün atlanmasından gelir.
  • Hesap silme akışı ve çalışan bir inceleme hesabı ilk kontrol edilecek iki maddedir.
  • Yazının sonunda yayından önce tek tek işaretlenebilecek altı maddelik bir liste var.

Uygulama yayına hazır, mağaza görselleri yüklenmiş, ekip duyuruyu bekliyor. Sonra App Store'dan "We noticed an issue with your app" başlıklı e-posta geliyor. Bir ret; düzeltme, yeni build ve yeni inceleme demek. Bazen ikinci bir ret de geliyor.

Aşağıdaki beş neden, Apple'ın inceleme kurallarında açıkça yazan ama yayın telaşında en kolay atlanan maddeler. Her birinin hangi kuraldan geldiğini, incelemecinin neye baktığını ve yayından önce ne yaptığımızı anlatıyoruz.

1. Hesap silme yok ya da bulunması zor #

Hesap açtıran her uygulama, hesabı uygulamanın içinden silme imkânı vermek zorunda (Guideline 5.1.1(v)). Ekipler silme işini çoğu zaman sunucu tarafında çözüyor, arayüzde ise ayarların en altına bir bağlantı koyuyor. İncelemeci akışı bulamazsa ret yazıyor.

Silme akışını ayarlar ekranının ilk seviyesine koyuyor, araya bir onay adımı ekliyor ve silme sonrasında kullanıcının gerçekten çıkış yaptığını test ediyoruz. İnceleme notuna akışın yolunu da yazıyoruz: Ayarlar, Hesap, Hesabı sil.

2. Giriş yapmadan denenemeyen uygulama #

İncelemeci uygulamayı sizin verdiğiniz test hesabıyla açıyor. Hesap çalışmıyorsa, SMS doğrulaması istiyorsa ya da kurumsal bir e-posta alanına bağlıysa uygulamayı göremeden reddediyor (2.1). Kurum içi uygulamalarda bu risk daha yüksek: kullanıcılar şirketin kimlik sistemiyle giriyor, dışarıdan hesap açmak mümkün olmuyor.

Yayından önce inceleme için ayrı bir test hesabı açıyor, doğrulama adımlarını bu hesap için kapatıyor, bilgileri App Store Connect'teki inceleme notuna yazıyor ve yayın tamamlanana kadar hesabı açık tutuyoruz. Kurumsal uygulamalarda mağaza yerine Apple Business Manager ile özel dağıtım gerekip gerekmediğine de bu aşamada karar veriyoruz.

3. Uygulama içi satın alma yerine dış ödeme #

Dijital bir içerik ya da özellik satıyorsanız ödemenin Apple'ın sistemi üzerinden geçmesi gerekiyor (3.1.1). Ekipler kuralı genellikle biliyor; ret, sınırın yanlış çizilmesinden geliyor. Fiziksel ürün ve hizmetlerde dış ödeme serbest, abonelik ve premium özelliklerde serbest değil.

Projenin başında satılan her şeyin listesini çıkarıyor, her kalemi fiziksel ya da dijital diye işaretliyoruz. Dijital olanlar için abonelik altyapısını baştan planlıyoruz; sonradan eklemek hem geliştirme hem inceleme tarafında daha zahmetli.

4. İzin isteğinin açıklaması yok #

Kamera, konum ve bildirim gibi her izin isteğinde sistem penceresi kullanıcıya bir açıklama cümlesi gösteriyor. Bu cümle boşsa ya da "uygulama bu izne ihtiyaç duyar" gibi bir şey yazıyorsa ret geliyor (5.1.1). Kullanılmayan bir iznin projede kalması da aynı sonuca yol açıyor: eski bir kütüphane kamera izni istiyorsa incelemeci nedenini soruyor.

İzin listesini tasarım aşamasında çıkarıyor, her izne kullanıcının anlayacağı tek bir cümle yazıyor ve izni gerçekten gerektiği anda istiyoruz. Uygulama açılışında toplu izin isteyen ekranlar kurmuyoruz.

5. Tamamlanmamış his: boş ekranlar ve kırık bağlantılar #

İncelemeci uygulamayı ilk kez açan bir kullanıcı gibi geziyor. Veri olmadığı için boş kalan liste, "yakında" yazan sekme ve yanıt vermeyen destek bağlantısı 2.1 ve 2.3 altında ret nedeni sayılıyor. Tasarım ve kod bitmiş olsa bile boş durumlar unutulabiliyor.

Her ekranın boş, yükleniyor ve hata hâlini tasarımda ayrı çiziyor, yayından önce sıfır veriyle bir tur atıyoruz. Destek ve gizlilik bağlantılarının test sunucusuna değil gerçek sayfalara gittiğini kontrol ediyoruz. Bu durumların tasarımdan koda nasıl kaybolduğunu Figma'dan çalışan ürüne geçiş yazısında ayrıca anlattık.

Gözden kaçan iki kural #

Gizlilik etiketi: App Store Connect'te işaretlediğiniz veri türleri ile SDK'ların gerçekte topladığı veri farklıysa ret geliyor. Analitik ve çökme raporu kütüphaneleri listede en kolay unutulanlar; SDK listesini etiketle karşılaştırmak kısa bir iş.

Ekran görüntüleri: mağaza görsellerinde uygulamada olmayan bir özellik ya da yalnızca pazarlama metni varsa incelemeci bunu da reddediyor (2.3.3). Görselleri gerçek ekranlardan alıyor, üstüne kısa açıklama ekliyoruz.

Yayından önceki liste #

Bu maddeleri yayından önce tek tek işaretliyoruz:

  • Hesap silme ayarların ilk seviyesinde ve çalışıyor.
  • İnceleme hesabı açık, doğrulama adımları kapalı, bilgiler notta.
  • Dijital satışlar uygulama içi satın alma ile.
  • Her izin isteğinde kullanıcı diliyle açıklama var; kullanılmayan izin yok.
  • Boş, yükleniyor ve hata durumları tasarlanmış; bağlantılar gerçek.
  • Gizlilik etiketi SDK listesiyle karşılaştırılmış; ekran görüntüleri gerçek ekranlardan.
Yayından önce işaretlenen altı maddelik kontrol listesi
Yayından önce tek tek işaretlenen altı madde.

Liste tamamlansa da ret gelebilir; Apple'ın yorumu incelemeciye göre değişebiliyor. Liste öngörülebilir retleri eler. Kalanlar için açık bir inceleme notu ve incelemecinin sorusuna hızlı bir yanıt gerekir.

Kaynaklar #

Bu konuda yardımcı olabiliriz

Uygulamanız mağazaya hazır mı?

Yayından önce bu listeyi uygulamanız için birlikte gözden geçirebilir, eksik durumları ve inceleme notunu yayın takvimine göre planlayabiliriz.

Devamında okuyun

Tüm yazılar

Yeni bir proje mi var?

Bir şeyler kuralım.

Tasarımda ve mühendislikte aynı masada oturan bir ortak arıyorsanız, konuşalım.