App Store metadata reddi: 2.3.x, 2.3.7, 4.3 ve 5.2.1 nasıl çözülür
E-postayı az önce aldın. Durum Metadata Rejected oldu ve Resolution Center notunda bakman gereken bir kılavuz numarası var. İyi haber şu: metadata reddi daha hızlı çözülenlerden biri — yeni bir build yüklemiyorsun, sürüm kaydını düzenleyip yeniden gönderiyorsun.
İlk kontrol edeceğin şey Resolution Center mesajındaki kılavuz numarası, çünkü bu sana hangi alanı düzeltmen gerektiğini tam olarak söyler. Bu yazı, listeleme reddinde görme ihtimalinin en yüksek olduğu dört maddeyi kapsıyor. Kılavuz numaraları zamanla yeniden numaralandırılıyor, bu yüzden buradakiler güncel App Store Review Guidelines'ı yansıtıyor.
Önce mekanik: "Metadata Rejected" gerçekte ne demek
Metadata Rejected durumu mağaza listelemene işaret eder — uygulama adı, alt başlık, anahtar kelimeler, açıklama, ekran görüntüleri, önizlemeler, URL'ler — derlenmiş uygulamana değil. İşaret metadata üzerinde olduğu için yeni bir binary'e ihtiyacın yok. Belirtilen alanı App Store Connect'te düzenler, mevcut build'i sürüme bağlı tutar ve yeniden gönderirsin.
Açıkça belirtilmesi gereken iki uyarı var. Birincisi, yeniden gönderim seni yine inceleme kuyruğuna sokar; yani build gerektirmez ama incelemeden muaf da değildir — bir insan ya da otomatik geçiş buna tekrar bakar. İkincisi, Apple'ın belirttiği tek alanı düzeltmek listenenin geri kalanını bağışık kılmaz. İncelemeciler bir sonraki geçişte başka bir kılavuzu işaretleyebilir. Sadece sana geri okunan cümleyi değil, o listelemenin tamamını gözden geçir.
Kılavuz 2.3.3 — ekran görüntüleri uygulamayı kullanımda göstermeli
Neyi tetikler. Ekran görüntülerin uygulamanın işini yaptığını göstermiyor. Klasik örnek, ilk slotun açılış ekranı, giriş sayfası ya da bir slogan içeren ve gerçek arayüz içermeyen başlık görseli olmasıdır. Ayrıca bir ekran görüntüsü uygulamanın sahip olmadığı bir özelliği gösteriyorsa veya başka bir platformdan cihaz ya da arayüze referans veriyorsa da tetiklenir.
Önce: ilk slot, gradyan üzerinde ortalanmış logon ve "haftanı planlamanın en akıllı yolu" yazısıyla, üzerinde hiçbir uygulama arayüzü yok.
Sonra: ilk slot temel bir akıştan gerçek bir ekran — gerçek girişlerle doldurulmuş bir hafta görünümü — ve cihazın üzerinde faydayı belirten kısa bir başlık. İncelemeciler (ve kullanıcılar) küçük resimden uygulamanın ne yaptığını görebiliyor. Pazarlama başlıklarını ve cihaz çerçevelerini koru, ama altındaki uygulama arayüzünün gerçek ve güncel olduğundan emin ol.
Bu bir metadata değişikliği: sürüm kaydındaki görselleri değiştir, yeniden gönder, yeni build gerekmez.
Kılavuz 2.3.7 — anahtar kelimeler uygulamanı tanımlamalı, oyun aramasını değil
Neyi tetikler. Bu, anahtar kelime kötüye kullanımı kılavuzudur. Metadatan uygulamanı tanımlamayan terimlerle doldurulduğunda tetiklenir: sahip olmadığın ticari markalar, daha büyük veya popüler uygulamaların adları, yanlış alandaki fiyat dili, erişim için eklenmiş ünlü veya kamuoyu figürü isimleri ya da aramaları yakalamak için tıkıştırılmış genel ifadeler. Genelde suçlu 100 karakterlik anahtar kelime alanıdır, ama alt başlık ve ad da işaretlenir. Uygulama adları 30 karakterle sınırlıdır ve fiyat veya promosyon dili adda, alt başlıkta ya da ekran görüntülerinde yer almamalıdır.
Önce (anahtar kelime alanı): kategorindeki üç daha büyük uygulamanın adını, tanınmış bir içerik üreticisinin adını ve gönderdiğin herhangi bir özelliği tanımlamayan birkaç alakasız trend kelimeyi içeren bir liste.
Sonra: bir kullanıcının işlevini bulmak için gerçekten arayacağı şeylerle eşleşen anahtar kelimeler — yaptığı görevler, çözdüğü sorun, kendi ekranlarındaki isimler. Her terim uygulamanın gerçekten yaptığı bir şeye işaret etmeli.
Önce (alt başlık): kendini adı geçen bir rakip uygulamayla karşılaştıran bir satır.
Sonra: uygulamanın sağladığı sonucu düz bir dille anlatan, içinde başka hiçbir markanın adı geçmeyen bir alt başlık. Alt başlık uygulaman hakkında bağlam vermek içindir, başkasının trafiğini ödünç almak için değil.
Kılavuz 4.3 — spam ve neredeyse birebir aynı uygulamalar
Neyi tetikler. 4.3 aynılıkla ilgilidir. Ayrı bundle ID'ler altında neredeyse birebir aynı birden fazla uygulama gönderdiğinde tetiklenir (her şehir, her ekip, her müşteri için ayrı bir build — bu varyasyonları içinde barındıran tek bir uygulama yerine) ya da bir gönderim zaten yaygın olarak mevcut bir şeyden ayırt edilemez olduğunda. Genelde bir konsept sorunudur, ama kopyalamayı görünür kılan şey listelemedir — kendi uygulamaların arasında birebir aynı açıklamalar ve ekran görüntüleri güçlü bir işarettir.
Önce: hesabında aynı düzene, aynı özellik listesine sahip ve sadece bir şehir ya da ekip adını değiştirerek farklılaşan metne sahip beş uygulama.
Sonra: bu varyasyonları uygulama içi seçenek veya satın alma olarak taşıyan, gerçekten farklı olan şeyi anlatan bir listelemeye sahip tek bir uygulama. Gerçekten ayrı ürünlerin varsa, her listelemenin ekran görüntülerinde ve açıklamada gerçekte neyin farklı olduğunu göstermesini sağla, sadece bir özel isim üzerinde bul-değiştir yapma.
Altta yatan uygulama gerçekten ince bir yeniden deri kaplamaysa 4.3, bir metadata düzenlemesinden fazlasını gerektirebilir. Ama sorun listelemelerinin birbirinin kopyası gibi okunması ise, metni ve ekran görüntülerini farklılaştırmak bir metadata düzeltmesidir.
Kılavuz 5.2.1 — metadatanda başkasının fikri mülkiyeti
Neyi tetikler. Haklarına sahip olmadığın korunan üçüncü taraf materyalini — ticari markalar, telif hakkıyla korunan eserler, taklit isimler — bundle'ında, geliştirici adında veya metadatanda herhangi bir yerde kullanmak. Yaygın bir varyant, listelemedeki uygulama veya marka ile onu gerçekten gönderen taraf arasındaki uyumsuzluktur; bu da Apple'ın adın kime ait olduğunu sormasına yol açar.
Önce: arama trafiğini yakalamak için uygulama başlığında, alt başlıkta veya anahtar kelime alanında oturan, sahip olmadığın bir marka veya platform adı.
Sonra: başlıkta, alt başlıkta ve anahtar kelimelerde kendi ürün adın. Gerçekten üçüncü taraf bir platformla entegre oluyorsan ve bunu belirtmen gerekiyorsa, herhangi bir gerçek uyumluluk notunu izin verilen açıklama alanında tut, ad ve alt başlığın dışında. Uygulamayı markaya sahip bir müşteri için geliştirdiysen, satıcı adı ve markanın uyuşması için onu markaya sahip olan tarafın hesabından gönder ya da onların ekibine eklen.
Build gerektirmeyen kısım, tekrar
Dört madde için de düzeltme sürüm kaydında yaşıyorsa — metin ve görseller — bunu App Store Connect'te düzeltir ve aynı binary'yi yeniden gönderirsin. Build numarasını artırmana ya da işlem sürecini beklemene gerek yok. Metadata reddinin sana kazandırdığı hızlı şerit budur. Karşılığında yine incelemeden geçersin, bu yüzden reddetmeleri tek tek çözmek yerine yeniden göndermeden önce tüm listelemeni bu dört madde açısından gözden geçirmek daha mantıklıdır.
Mokbi nerede yardımcı olur (ve nerede olmaz)
2.3.7 sorunlarının çoğu, bir anahtar kelime alanı veya alt başlık erişim için doldurulduğunda yazım aşamasında başlar. Mokbi'nin yapay zekası — ad, alt başlık, anahtar kelimeler, açıklama — listeleme metnini uygulamanın gerçekte ne yaptığından yola çıkarak yazar, bu da seni doldurma ve ödünç marka alışkanlıklarından uzak tutar; bunlar zaten anahtar kelime reddine yol açan şeylerdir. Ardından bu metni 50 dile yerelleştirir, böylece her pazar için elle yeni bir anahtar kelime alanı yazıp aynı tuzağı her birinde tekrar yaratmazsın.
Sınırı net görelim. Bu, metinde 2.3.x veya 5.2.1 işaretlenme olasılığını düşürür; onay garantisi veremez ve build'inin içinde ne olduğuna karar vermez. İnceleme Apple'ın kararıdır. Uyumlu ve uygulamayı doğru yansıtan metnin yaptığı şey, reddedilmenin kolay ve kendinden kaynaklanan sebeplerini ortadan kaldırmaktır. Mokbi listelemene otomatik yayınlama yapmaz — metni ve ekran görüntülerini üretir; sen gözden geçirir ve gönderirsin.