Guideline 5.1.1 Reddi: Veri Toplama ve İzin Metinleri Nasıl Düzeltilir?

Panik yapmanıza gerek yok; App Store veri toplama reddi, kod yapınızı baştan kurmanızı nadiren gerektirir. Çoğu zaman sorun birkaç metin, bir kayıt ekranı ya da bir SDK ayarıdır. Bu nedenle sırayla ilerlemek, aceleyle yeni derleme göndermekten daha hızlı sonuç verir. Aşağıdaki adımları sırayla uygulayın:

1. App Store Connect içindeki ret mesajını baştan sona okuyun ve atıf yapılan alt maddeyi not edin.
2. Mesajda adı geçen ekranı, izni ya da veri alanını kendi cihazınızda yeniden üretin.
3. Sorunun metin mi, akış mı, yoksa SDK kaynaklı mı olduğunu belirleyin.
4. Düzeltmeyi yapın ve yeni derlemeyi gerçek bir cihazda temiz kurulumla test edin.
5. Ret mesajına kısa, madde madde bir yanıt yazın; ardından yeni derlemeyi gönderin.

Bu yazıda yalnız 5.1.1 maddesine odaklanıyoruz. Genel ret nedenlerinin geniş haritası için uygulamaların en sık reddedilme nedenleri yazımıza bakabilirsiniz.

Ret mesajındaki 5.1.1 atfını nasıl okumalısınız?

Apple ret mesajında hangi kurala dayandığını madde numarasıyla belirtir. 5.1 bölümü gizliliği, 5.1.1 ise veri toplama ve saklamayı kapsar. Ancak 5.1.1 tek bir kural değil, onlarca ayrıntılı alt maddeden oluşan bir başlıktır. Yani mesajın geri kalanını okumadan düzeltmeye başlamak, yanlış ekranı değiştirmenize yol açar.

Mesajda genellikle üç ipucu bulursunuz: sorunlu ekranın ya da özelliğin tarifi, Apple'ın beklediği davranış ve bazen bir ekran görüntüsü. Örneğin inceleme ekibi kamera izni isteyen pencerenin ekran görüntüsünü ekler ve metnin amacı açıklamadığını yazar. Böyle bir durumda sorun neredeyse her zaman Info.plist dosyasındaki amaç metnidir.

Öte yandan mesaj "kullanıcıdan gerekmediği halde kişisel bilgi istiyorsunuz" anlamına geliyorsa sorun bir form alanında ya da kayıt akışındadır. Mesajın birebir ifadesi değişebilir; bu yüzden ifadeye değil, işaret ettiği ekrana odaklanın. Mesajı ekip içinde paylaşırken ekran görüntüsünü de saklayın, çünkü sonradan yanıt yazarken bu kanıta ihtiyacınız olur.

Guideline 5.1.1 hangi alt maddelerden oluşur?

Apple'ın resmi App Review Guidelines metninde 5.1.1, (i) ile (x) arasında on alt madde içerir. Ret mesajlarının büyük bölümü bunların dördüne ya da beşine dayanır. Aşağıdaki tablo, en sık karşılaştığımız alt maddeleri ve tipik düzeltmeyi özetliyor:

Kısacası, App Store veri toplama reddi mesajını bu tablodaki satırlardan birine eşleyebiliyorsanız düzeltmenin yönü de büyük ölçüde belli olur.

Bu reddi kendi başınıza ne zaman çözemeyebilirsiniz?

Amaç metni düzeltmesi çoğu ekip için birkaç saatlik iştir. Ancak bazı durumlar daha derin değişiklik ister: kayıt akışının tamamen yeniden tasarlanması, misafir modunun veri katmanına eklenmesi ya da hangi SDK'nın hangi korumalı kaynağa eriştiğinin çıkarılması gibi. Bu işler hem ürün kararı hem kod değişikliği gerektirir.

Eğer uygulamayı sizin için başka bir ekip geliştirdiyse ve kaynak koduna ya da derleme sürecine hâkim değilseniz, ret döngüsü uzayabilir. Böyle durumlarda mobil uygulama geliştirme tarafında deneyimli bir ekibin akışı incelemesi, aynı maddeden ikinci kez ret almanızı önleyebilir. Yine de önce aşağıdaki bölümlerdeki kontrolleri kendiniz denemenizi öneririz; çünkü sorunların önemli bir kısmı metin düzeyindedir.

Apple da resmi metninde aynı ihlal için tekrar tekrar reddedilen uygulamaların incelemesinin daha uzun sürdüğünü belirtiyor. Dolayısıyla ilk düzeltmeyi eksiksiz yapmak, zaman açısından en ucuz yoldur.

İzin amaç metni (purpose string) nedir?

Amaç metni (purpose string ya da usage description), uygulamanız kamera, konum, mikrofon, fotoğraflar gibi korumalı bir kaynağa erişmek istediğinde sistemin gösterdiği izin penceresindeki açıklamadır. Bu metni Info.plist dosyasında ilgili anahtarın değeri olarak tanımlarsınız; örneğin kamera için NSCameraUsageDescription anahtarını kullanırsınız.

Apple'ın amaç metinleri rehberi, işletim sisteminin bu kaynaklara erişimi kullanıcı izin verene kadar engellediğini ve amaç metninin kullanıcının bilinçli karar vermesini sağladığını açıklar. Yani bu metin teknik bir zorunluluktan öte, kullanıcıyla kurduğunuz ilk güven cümlesidir.

5.1.1 (ii) maddesi bu konuda açıktır: amaç metniniz verinin kullanımını açık ve eksiksiz anlatmalıdır. İnceleme ekibi her izin penceresini tek tek açar ve metnin gerçekten neyi, neden istediğini söyleyip söylemediğine bakar. Bu nedenle "Konuma erişmek istiyoruz" gibi kaynağın adını tekrarlayan bir cümle, ret için yeterli bir gerekçedir.

Amaç metni neden App Store veri toplama reddi getirir?

Apple'ın rehberi yetersiz metinlerin üç ortak özelliğini sayar. İlki, kaynağın adını kullanımını açıklamadan tekrar etmektir. İkincisi, verinin kime gittiğini gizleyen belirsiz fayda cümleleri ya da edilgen yapılardır. Üçüncüsü ise pazarlama dili ya da özelliklerin uzun bir listesidir.

• Kaynağı tekrar eden metin: "Kamerayı kullanmak için."
• Belirsiz fayda: "Verileriniz size daha iyi bir deneyim sunmak için kullanılacak."
• Pazarlama dili: "Harika özelliklerimizin keyfini çıkarın!"
• Uygulamanın gerçekte kullanmadığı bir amaç: metin fotoğraf taramasından bahsediyor ama kamera başka bir yerde açılıyor.

Son madde özellikle önemli, çünkü inceleme ekibi metni gerçek davranışla karşılaştırır. Örneğin metniniz "profil fotoğrafı çekmek için" diyorsa ama kamera ilk açılışta kendiliğinden izin istiyorsa, metin ile bağlam uyuşmaz. Ayrıca aynı metni birden fazla kaynak için kopyalamak da sorun yaratır; Apple her korumalı kaynak için ayrı amaç metni yazmanızı ister.

İyi bir amaç metnini nasıl yazarsınız?

Apple'ın rehberine göre iyi bir amaç metni tek, kısa ve tam bir cümledir; etken çatıyı, cümle düzeninde büyük harfi kullanır ve noktayla biter. Ayrıca verinin hangi özelliği ya da sonucu mümkün kıldığını söyler ve somut bir örnek verir. Kısacası, okur metni okuduğunda "bu izni verirsem ne olur?" sorusunun cevabını almalıdır.

Somut bir formül işinize yarar: kim, hangi veriyi, hangi özellik için kullanıyor? Aşağıdaki örnekler bu formülü gösteriyor:

• Konum: "Uygulama, en yakın şubeyi haritada göstermek ve yol tarifi vermek için konumunuzu kullanır."
• Kamera: "Uygulama, fatura üzerindeki QR kodu okuyup ödeme ekranını doldurmak için kamerayı kullanır."
• Mikrofon: "Uygulama, sesli not kaydedip notunuza eklemek için mikrofonu kullanır."
• Kişiler: "Uygulama, davet göndermek istediğiniz kişiyi rehberinizden seçebilmeniz için kişilerinize erişir."

Bu örnekler, Apple'ın rehberindeki "rotayı belirlemek ve adım adım yol tarifi vermek" örneğiyle aynı mantıkta kuruludur. Metni yazdıktan sonra kendinize şunu sorun: bu cümleyi okuyan biri, verinin uygulama dışına çıkıp çıkmadığını anlayabiliyor mu? Eğer veri reklam ya da analiz amacıyla paylaşılıyorsa, bunu da açıkça söylemeniz gerekir.

Çok dilli uygulamada amaç metinlerini nasıl yerelleştirirsiniz?

Uygulamanız birden fazla dili destekliyorsa, Apple'ın rehberi her dil için ayrı amaç metni sağlamanızı açıkça ister. Yani yalnız İngilizce bir Info.plist değeri bırakıp Türkçe arayüzde İngilizce izin penceresi göstermek, hem kötü bir deneyim hem de ret riski demektir.

Pratikte her dil için ayrı bir InfoPlist.strings (ya da projenizin kullandığı yerelleştirme dosyası) tutarsınız ve her anahtarın çevirisini burada tanımlarsınız. Ardından cihazın dilini sırayla değiştirip her izin penceresini açarak doğru metnin göründüğünü test edersiniz. Apple da rehberinde uygulamayı her yerelleştirmeye ayarlayıp izin isteğinde doğru metnin çıktığını test etmenizi öneriyor.

Çeviri yaparken metni kelime kelime aktarmak yerine aynı somutluğu korumaya dikkat edin. Örneğin İngilizce metin "en yakın şubeyi göstermek için" diyorsa, Almanca ya da Türkçe karşılığı da aynı özelliği adıyla anmalıdır. Ayrıca makine çevirisinden gelen bozuk cümleler, inceleme ekibinin gözünde "açık ve eksiksiz" ölçütünü karşılamayabilir.

Üçüncü taraf SDK'lar 5.1.1 reddine nasıl yol açar?

Pek çok ekip, kendi kodunda hiç kullanmadığı bir izin yüzünden ret aldığında şaşırır. Oysa Apple'ın rehberi açıktır: uygulamanızdaki her şeyden, SDK'lar, kütüphaneler ve üçüncü taraf kodlar dahil, siz sorumlusunuz. Bir analiz, reklam ya da harita SDK'sı, siz farkına varmadan korumalı bir API'ye referans verebilir.

Apple bu durumda iki yol tarif eder. Uygulamanızın o kaynağa erişmek için geçerli bir nedeni varsa, Info.plist içinde kendi kullanım senaryonuzu anlatan bir amaç metni tanımlarsınız. Böyle bir neden yoksa, o API'lere yapılan referansları derlemeden çıkarırsınız. Dolayısıyla "SDK istiyor, biz kullanmıyoruz" demek, inceleme ekibi için geçerli bir yanıt değildir.

1. Projedeki tüm bağımlılıkları listeleyin.
2. Her birinin belgesinde hangi korumalı kaynaklara erişebildiğini kontrol edin.
3. Kullanmadığınız modülleri kapatın ya da kaldırın.
4. Kalan erişimler için kendi özelliğinizi anlatan amaç metni yazın.

Ayrıca SDK'ların topladığı veriyi App Store gizlilik bilgilerinde de doğru göstermeniz gerekir; bu konuyu App Store gizlilik etiketleri yazımızda ayrıntılı anlattık.

Zorunlu olmayan kişisel veri istemek neden ret sebebidir?

5.1.1 (v) maddesi, uygulamanın işlemek için kullanıcıdan kişisel bilgi istemesini, bu bilgi temel işlevle doğrudan ilgili olmadıkça ya da yasa gerektirmedikçe yasaklar. Örneğin bir hesap makinesi uygulamasının ilk ekranda doğum tarihi ve telefon numarası istemesi bu maddeyle çelişir.

(x) maddesi ise ad ve e-posta gibi temel iletişim bilgilerine izin verir; ancak üç şartla. İstek kullanıcı için isteğe bağlı olmalı, özellikleri bu bilgiye bağlamamalı ve çocuklardan veri toplama sınırları dahil diğer tüm kurallara uyulmalıdır. Yani bülten kaydı için e-posta alanı koyabilirsiniz, ama "e-posta vermeden devam edemezsiniz" diyemezsiniz.

Formlarınızı gözden geçirirken her alan için şu soruyu sorun: bu alan olmadan özellik çalışır mı? Cevap evetse, alanı isteğe bağlı yapın ya da tamamen kaldırın. Örneğin teslimat yapan bir uygulamada adres zorunludur, ama aynı uygulamada meslek ya da cinsiyet alanı zorunlu olmamalıdır. Türkiye'deki kullanıcılar için aydınlatma ve rıza yükümlülükleri ayrıca geçerlidir; bunu mobil uygulamada KVKK uyumu yazımızda ele aldık. Bu yazı hukuki danışmanlık değildir.

Hesap gerektirmeyen özellik için kayıt zorunluluğunu nasıl kaldırırsınız?

5.1.1 (v) maddesinin ilk cümlesi şunu söyler: uygulamanız önemli hesap tabanlı özellikler içermiyorsa, insanların giriş yapmadan kullanmasına izin verin. Bu, özellikle katalog, menü, içerik ya da bilgi sunan uygulamalarda sık görülen bir ret nedenidir.

Örnek senaryo olarak bir restoran uygulamasını düşünün: menüyü görmek, şube saatlerini incelemek ve fiyatlara bakmak hesap gerektirmez. Sipariş vermek, sipariş geçmişini görmek ya da puan biriktirmek ise hesap gerektirebilir. Bu durumda doğru akış, kullanıcıyı misafir olarak içeri almak ve yalnız hesap gerektiren işleme geldiğinde giriş istemektir.

1. Uygulamadaki tüm ekranları "hesapsız çalışabilir" ve "hesap şart" diye ikiye ayırın.
2. Açılıştaki zorunlu giriş ekranını kaldırın ya da atlanabilir yapın.
3. Hesap gerektiren işlemlerde, o anda giriş ya da kayıt penceresi açın.
4. Misafir kullanıcının verisini yerel olarak saklayın ve kayıt olunca aktarın.

Ayrıca uygulamanız hesap oluşturmayı destekliyorsa, aynı madde uygulama içinden hesap silmeyi de zorunlu tutar. Bu ayrı ama sık birlikte görülen gereksinimi Apple'ın zorunlu hesap silme kuralı yazımızda anlattık.

Sosyal ağ ile giriş konusunda 5.1.1 ne diyor?

5.1.1 (v) maddesi sosyal ağlarla ilgili ayrı bir kural da içerir. Uygulamanızın temel işlevi belirli bir sosyal ağla ilgili değilse, girişsiz ya da başka bir yolla erişim sağlamanız gerekir. Apple, temel profil bilgisini çekmeyi, sosyal ağda paylaşmayı ya da arkadaş davet etmeyi temel işlev saymaz.

Bunun yanında madde iki teknik şart koyar. Birincisi, uygulama içinde sosyal ağ kimlik bilgilerini geri alma ve uygulama ile sosyal ağ arasındaki veri erişimini kapatma mekanizması bulunmalıdır. İkincisi, uygulama sosyal ağ kimlik bilgilerini ya da belirteçlerini (token) cihaz dışında saklayamaz ve bunları yalnız uygulama kullanımdayken doğrudan bağlantı için kullanabilir.

Dolayısıyla "yalnız sosyal ağla giriş" sunan bir uygulama, temel işlevi o ağa bağlı değilse risk taşır. Çözüm genellikle misafir modu ya da e-posta ile giriş gibi alternatif bir yol eklemek ve ayarlar ekranına bağlantıyı kesme seçeneği koymaktır. Böylece hem 5.1.1 maddesine uyar hem de sosyal hesabı olmayan kullanıcıları kaybetmezsiniz.

Tam erişim yerine sistem seçicisini mi kullanmalısınız?

5.1.1 (iii) veri minimizasyonu maddesi, uygulamanın yalnız temel işlevle ilgili veriye erişim istemesini ve yalnız ilgili görev için gereken veriyi toplamasını ister. Madde ayrıca mümkün olduğunda Fotoğraflar ya da Kişiler gibi korumalı kaynaklara tam erişim istemek yerine süreç dışı seçiciyi (out-of-process picker) ya da paylaşım sayfasını kullanmanızı önerir.

Pratikte bu şu anlama gelir: kullanıcı profil fotoğrafı yükleyecekse, tüm fotoğraf arşivine erişim izni istemenize gerek yoktur. Sistemin fotoğraf seçicisi kullanıcının seçtiği görseli uygulamanıza verir; uygulamanız arşivin geri kalanını görmez. Böylece hem izin penceresi göstermezsiniz hem de inceleme ekibinin "neden tüm galeriye erişiyorsunuz?" sorusunu ortadan kaldırırsınız.

Aynı mantık kişiler için de geçerlidir. Bir kişiye davet göndermek için tüm rehberi okumak yerine, kullanıcının tek bir kişiyi seçmesini sağlayan sistem arayüzü genellikle yeterlidir. Kısacası, izin sayısını azaltmak 5.1.1 açısından en sağlam düzeltmedir, çünkü olmayan izin için amaç metni tartışması da olmaz.

İzni reddeden kullanıcıya hangi alternatifi sunmalısınız?

5.1.1 (iv) maddesi, uygulamaların kullanıcının izin ayarlarına saygı göstermesini ve insanları gereksiz veri erişimine onay vermeye yönlendirmeye, kandırmaya ya da zorlamaya çalışmamasını ister. Apple bu maddede iki örnek verir: fotoğraf paylaşan bir uygulama, fotoğraf yüklemeden önce mikrofon erişimini şart koşmamalıdır. Konum paylaşmayı reddeden kullanıcıya ise adresi elle girme seçeneği sunulmalıdır.

Bu madde, "izin vermezseniz uygulama kapanır" türünden akışları doğrudan hedef alır. Örneğin konum izni reddedildiğinde boş bir ekran ve "ayarlardan izin verin" uyarısından başka hiçbir şey göstermemek risklidir. Bunun yerine şehir ya da posta kodu ile arama, haritada elle nokta seçme gibi alternatifler eklersiniz.

• Konum izni yok: elle adres ya da şehir girişi.
• Kamera izni yok: galeriden seçim ya da kodu elle yazma.
• Bildirim izni yok: uygulama içi bildirim kutusu.
• Kişiler izni yok: telefon numarasını elle girme.

Ayrıca izin istemeden önce gösterdiğiniz açıklama ekranı, kullanıcıyı onaya zorlayan bir dil taşımamalıdır. Reklam takibi için gereken izin akışı ayrı bir çerçeveye tabidir; bunu Uygulama Takip Şeffaflığı (ATT) yazımızda anlattık.

Gizlilik politikası bağlantısı neleri kapsamalı?

5.1.1 (i) maddesine göre tüm uygulamalar, gizlilik politikası bağlantısını hem App Store Connect'teki ilgili meta veri alanına hem de uygulama içinde kolay erişilebilir bir yere koymalıdır. Politika ise üç konuyu açık ve net biçimde anlatmalıdır.

• Uygulamanın hangi veriyi topladığı, nasıl topladığı ve bu verinin tüm kullanım amaçları.
• Veriyi paylaştığınız analiz araçları, reklam ağları ve SDK'lar gibi üçüncü tarafların aynı ya da eşdeğer korumayı sağlayacağının teyidi.
• Veri saklama ve silme politikası ile kullanıcının rızasını nasıl geri alacağı ya da verisinin silinmesini nasıl talep edeceği.

Sık gördüğümüz hata, web sitesi için hazırlanan genel bir politikayı uygulamaya bağlamaktır. Böyle bir metin, uygulamanın kamerayı ya da konumu neden kullandığını hiç anmayabilir. Bu nedenle politikayı uygulamanın gerçek veri akışına göre güncelleyin ve amaç metinleriniz, gizlilik etiketleriniz ve politikanız arasında çelişki bırakmayın. Üç belgenin birbirini doğrulaması, inceleme ekibinin işini de kolaylaştırır.

Rıza geri alma ve ücretli özellik kuralı ne diyor?

5.1.1 (ii) maddesi, kullanıcı ya da kullanım verisi toplayan uygulamaların, veri toplama anında anonim sayılsa bile kullanıcı rızası almasını ister. Aynı madde iki önemli şart daha koyar: ücretli işlevsellik bu veriye erişim izni vermeye bağlanamaz ve uygulama kullanıcıya rızasını geri çekmesi için kolay erişilebilir ve açık bir yol sunmalıdır.

Örneğin premium aboneliği yalnız konum ya da kişiler iznini veren kullanıcılara açan bir uygulama, bu maddeyi doğrudan ihlal eder. Aynı şekilde analiz verisi toplamaya rıza veren kullanıcının bu rızayı geri almak için destek e-postası yazmak zorunda kalması da sorun yaratır. Ayarlar ekranında açık bir anahtar, bu şartı karşılamanın en basit yoludur.

Madde ayrıca AB Genel Veri Koruma Tüzüğü (GDPR) gibi bir düzenlemeye dayanarak rıza olmadan meşru menfaat gerekçesiyle veri toplayan uygulamaların o yasanın tüm şartlarına uyması gerektiğini belirtir. Bu noktada hukuki değerlendirme gerekir; bu yazı hukuki danışmanlık değildir, bir hukukçuya danışmanızı öneririz.

Resolution Center yanıtını nasıl yazarsınız?

Geliştiricilerin hâlâ Resolution Center (Çözüm Merkezi) dediği alan, bugün App Store Connect içindeki App Review mesajlaşma ekranıdır. Apple'ın App Review mesajlarına yanıt verme belgesine göre uygulamanızı seçer, sayfanın üstündeki açık sorun bağlantısına tıklar, ilgili gönderimin yanındaki Resolve seçeneğiyle mesajı açar ve Reply to App Review ile yanıt yazarsınız. Yanıta ekran görüntüsü ve destekleyici belge ekleyebilirsiniz.

Apple'ın kendi yönergesi yanıtın nasıl olması gerektiğini de söyler: sorduğunuz şeyde spesifik olun, ilgili özelliği, kuralı ya da adımı açıkça belirtin. Uygulamanın yanlış anlaşıldığını düşünüyorsanız, kavramı ve amaçlanan işlevi anlatan ek bilgi verin. Bu nedenle iyi bir 5.1.1 yanıtı uzun bir savunma değil, kısa bir değişiklik raporudur.

1. Atıf yapılan alt maddeyi adıyla anın.
2. Her sorun için ne değiştirdiğinizi tek cümleyle yazın.
3. Yeni amaç metinlerini ya da form değişikliğini birebir aktarın.
4. Değişikliği gösteren ekran görüntüsünü ekleyin.
5. Test için gerekiyorsa hesap bilgilerini App Review Information bölümünde güncelleyin.

Ayrıca Apple, bu yanıt alanını ret kararına itiraz etmek için kullanmamanızı belirtir; itiraz için ayrı bir form vardır.

Yanıt mı, yeni derleme mi, itiraz mı seçmelisiniz?

5.1.1 reddinde üç yolunuz var ve doğru seçim, sorunun gerçekten var olup olmadığına bağlıdır. Sorun gerçekse, yani amaç metni belirsizse ya da kayıt zorunluysa, düzeltip yeni derleme göndermek ve kısa bir yanıtla neyi değiştirdiğinizi açıklamak en hızlı yoldur.

Öte yandan inceleme ekibi bir özelliği yanlış anladıysa, örneğin konum verisinin yalnız cihazda kaldığını görmediyse, önce App Store Connect üzerinden açıklama yazarsınız. Apple'ın App Review Board itiraz rehberi de itiraz etmeden önce ret mesajına yanıt verip açıklama yapmanızı ister. Açıklama yeterli olmazsa itiraz formuna geçersiniz.

İtirazda Apple, ilgili kuralı anmanızı ve uygulamanızın onu nasıl karşıladığını madde madde açıklamanızı bekler. Ayrıca reddedilen uygulama başına yalnız bir itiraz gönderirsiniz; ret birden fazla kurala dayanıyorsa hepsini tek itirazda ele alırsınız. Sorunu zaten düzeltip yeniden gönderdiyseniz itiraz etmezsiniz. Rehber, eksiksiz bir itirazın kararın değişeceğini garanti etmediğini de açıkça belirtir. Biz de hiçbir yolun kesin onay getirdiğini söylemiyoruz; yalnız doğru yolu seçmek süreci kısaltır.

Hangi hatalar App Store veri toplama reddini tekrar getirir?

İkinci bir App Store veri toplama reddi, çoğu zaman düzeltmenin yarım kalmasından doğar. Sahada en sık karşılaştığımız hatalar şunlar:

• Yalnız mesajda adı geçen izni düzeltip diğer belirsiz amaç metinlerini aynı bırakmak.
• Ana dilde metni düzeltip diğer dillerin yerelleştirme dosyalarını unutmak.
• Açılıştaki giriş ekranına "atla" düğmesi ekleyip sonraki ilk ekranda yine giriş istemek.
• Kullanılmayan bir SDK modülünü kodda bırakmak.
• Gizlilik politikasını güncelleyip uygulama içi bağlantıyı eklememek.

Bu yüzden düzeltmeyi yalnız mesajda geçen ekranla sınırlamayın; tüm uygulamayı aynı gözle tarayın. İnceleme ekibi bir sonraki gönderimde başka bir ekranda aynı sorunu bulursa, yeni bir 5.1.1 reddi alırsınız. Ayrıca derlemeyi göndermeden önce uygulamayı silip temiz kurulumla test edin; çünkü daha önce verdiğiniz izinler, izin pencerelerini görmenizi engeller.

Eksik ya da yarım çalışan özellik yüzünden gelen retler farklı bir maddeye dayanır; bunu Guideline 2.1 uygulama tamamlanmamış reddi yazımızda ele aldık.

Google Play tarafında benzer bir veri sorunu ne anlama gelir?

Uygulamanızı iki mağazada birden yayınlıyorsanız, Apple'daki 5.1.1 düzeltmesini Android sürümüne de yansıtmanız mantıklıdır. Google Play'in kendi politika çerçevesi ve süreçleri vardır; dolayısıyla Apple'daki madde numarası orada geçmez, ama gereksiz izin ve şeffaf olmayan veri toplama orada da sorun yaratabilir.

Play tarafında politika ihlali yüzünden kaldırılan bir uygulamada izlemeniz gereken yolu Google Play uygulama kaldırıldı itiraz yazımızda anlattık. Yeni geliştirici hesaplarındaki kapalı test şartını ise Google Play kapalı test şartı yazımızda bulabilirsiniz. Hesap düzeyinde bir kapatma yaşıyorsanız Google Play geliştirici hesabı kapatıldı yazımız daha uygun.

Burada önemli bir uyarı yapalım: herhangi bir mağazada reddi ya da kapatmayı atlatmak için aynı uygulamayı yeni bir hesapla yeniden yüklemek ya da ilişkili hesaplar kullanmak sorunu çözmez. Aksine bu yol, politika ihlalini ağırlaştırabilir ve hesap düzeyinde yaptırıma yol açabilir. Doğru yol her zaman sorunu düzeltip resmi kanaldan yeniden göndermektir.

App Store veri toplama reddi düzeltmesinde ne zaman destek almalısınız?

Amaç metni ve form alanı düzeltmeleri çoğunlukla kendi ekibinizin çözebileceği işlerdir. Ancak ret iki ya da üç kez tekrarlandıysa, mesaj kayıt akışının tamamını hedef alıyorsa ya da hangi SDK'nın hangi izni tetiklediğini bulamıyorsanız, dışarıdan bir göz zaman kazandırır. Kaynak koduna erişiminiz yoksa ya da önceki geliştiriciyle bağlantınız koptuysa da aynı durum geçerlidir.

Talha Aslan ve ekibi olarak bu tür işlerde önce ret mesajını ve uygulamanın izin haritasını çıkarır, ardından gereken kod ve metin değişikliklerini tek seferde planlarız. Yine de hiçbir ekibin Apple onayını garanti edemeyeceğini açıkça söyleyelim; karar her zaman App Review ekibindedir. Uygulamanızın veri akışını baştan doğru kurmak ya da mevcut uygulamayı yeniden ele almak istiyorsanız mobil uygulama yaptırma sürecimizi inceleyebilirsiniz.

Guideline 5.1.1 açısından en kalıcı çözüm, izin ve veri kararlarını tasarım aşamasında vermektir. Böylece her yeni özellikte aynı soruyu sormuş olursunuz: bu veri gerçekten gerekli mi?

Göndermeden önce hangi son kontrolleri yapmalısınız?

Yeni derlemeyi göndermeden önce aşağıdaki listeyi tek tek işaretleyin. Bu liste, Guideline 5.1.1 alt maddelerinin tamamını kapsayacak biçimde düzenledik:

• Her korumalı kaynak için ayrı, somut ve tek cümlelik amaç metni var.
• Amaç metinleri tüm desteklenen dillerde hazır ve cihazda test ettiniz.
• Kullanmadığınız SDK modüllerini ve API referanslarını kaldırdınız.
• Hesap gerektirmeyen içerik misafir olarak açılabiliyor.
• Ad ve e-posta gibi alanlar isteğe bağlı ve özellikler bunlara bağlı değil.
• İzin reddedildiğinde kullanıcı bir alternatif görüyor.
• Gizlilik politikası güncel ve uygulama içinden erişilebilir.
• Rızayı geri alma seçeneği ayarlar ekranında açıkça duruyor.

Liste tamamlandıktan sonra uygulamayı silip yeniden kurun ve tüm izin pencerelerini sırayla açın. Ardından ret mesajına kısa yanıtınızı yazın ve yeni derlemeyi gönderin. Bu sırayı izlemek, aynı maddeden ikinci kez ret alma ihtimalini belirgin biçimde azaltır.