Odrzucenia metadanych App Store: naprawa 2.3.x, 2.3.7, 4.3 i 5.2.1
Właśnie dostałeś e-mail. Status zmienił się na Metadata Rejected, a notatka w Resolution Center powołuje się na numer wytycznej, który musiałeś sprawdzić. Dobra wiadomość jest taka, że odrzucenie metadanych to jedno z szybszych do naprawienia: nie przesyłasz ponownie builda, tylko edytujesz zapis wersji i wysyłasz ją ponownie.
Pierwsze, co warto sprawdzić, to numer wytycznej w wiadomości z Resolution Center, bo mówi on dokładnie, które pole poprawić. Ten artykuł omawia cztery, które najczęściej pojawiają się przy odrzuceniu opisu. Numery wytycznych z czasem się zmieniają, więc te tutaj odzwierciedlają aktualne App Store Review Guidelines.
Najpierw mechanika: co naprawdę oznacza "Metadata Rejected"
Status Metadata Rejected wskazuje na wpis w sklepie — nazwę aplikacji, podtytuł, słowa kluczowe, opis, zrzuty ekranu, podglądy, adresy URL — a nie na skompilowaną aplikację. Ponieważ oznaczenie dotyczy metadanych, nie potrzebujesz nowego builda. Edytujesz wskazane pole w App Store Connect, zachowujesz istniejący build przypisany do wersji i wysyłasz ponownie.
Warto jasno powiedzieć o dwóch zastrzeżeniach. Po pierwsze, ponowne wysłanie i tak wraca do kolejki weryfikacji, więc nie wymaga builda, ale nie omija weryfikacji — człowiek lub automat sprawdzi to ponownie. Po drugie, naprawienie jednego pola wskazanego przez Apple nie uodparnia reszty opisu. Weryfikatorzy mogą przy kolejnym podejściu oznaczyć inną wytyczną. Uporządkuj cały wpis, skoro już się nim zajmujesz, a nie tylko zdanie, które ci zacytowano.
Wytyczna 2.3.3 — zrzuty ekranu muszą pokazywać aplikację w użyciu
Co to wyzwala. Twoje zrzuty ekranu nie pokazują, jak aplikacja działa. Klasyczny przypadek to pierwszy slot będący ekranem powitalnym, ekranem logowania lub grafiką tytułową z hasłem reklamowym bez żadnego rzeczywistego interfejsu. Wyzwala się to też, gdy zrzut ekranu pokazuje funkcję, której aplikacja nie ma, albo odnosi się do urządzenia lub interfejsu z innej platformy.
Przed: slot pierwszy to twoje logo wyśrodkowane na gradiencie ze słowami "najmądrzejszy sposób na zaplanowanie tygodnia", bez żadnego interfejsu aplikacji nigdzie na nim.
Po: slot pierwszy to prawdziwy ekran z kluczowego procesu — widok tygodnia z rzeczywiście wypełnionymi wpisami — z krótkim podpisem nazywającym korzyść nad urządzeniem. Weryfikatorzy (i użytkownicy) widzą z miniatury, co robi aplikacja. Zachowaj podpisy marketingowe i ramki urządzeń, ale upewnij się, że interfejs pod spodem jest prawdziwy i aktualny.
To jest zmiana metadanych: podmień obrazy w zapisie wersji, wyślij ponownie, bez nowego builda.
Wytyczna 2.3.7 — słowa kluczowe muszą opisywać twoją aplikację, nie wyszukiwanie gier
Co to wyzwala. To wytyczna dotycząca nadużywania słów kluczowych. Wyzwala się, gdy metadane są wypchane terminami, które nie opisują twojej aplikacji: zastrzeżonymi znakami, których nie posiadasz, nazwami większych lub popularniejszych aplikacji, sformułowaniami cenowymi w niewłaściwym polu, nazwiskami celebrytów lub osób publicznych dodanymi dla zasięgu, albo ogólnymi frazami wciśniętymi po to, by łapać wyszukiwania. Pole słów kluczowych o limicie 100 znaków jest zwykłym winowajcą, ale podtytuł i nazwa też bywają oznaczane. Nazwy aplikacji są ograniczone do 30 znaków, a język cenowy lub promocyjny nie ma miejsca w nazwie, podtytule ani zrzutach ekranu.
Przed (pole słów kluczowych): lista zawierająca nazwy trzech większych aplikacji z twojej kategorii, nazwisko znanego twórcy i kilka niepowiązanych, popularnych słów, z których żadne nie opisuje funkcji, którą naprawdę wdrożyłeś.
Po: słowa kluczowe odpowiadające temu, czego użytkownik faktycznie szukałby, by znaleźć twoją funkcję — zadania, które wykonuje, problem, który rozwiązuje, rzeczowniki z twoich własnych ekranów. Każdy termin powinien wskazywać na coś, co aplikacja naprawdę robi.
Przed (podtytuł): linijka porównawcza pozycjonująca cię względem nazwanej konkurencyjnej aplikacji.
Po: podtytuł, który jasno przedstawia efekt, jaki daje twoja aplikacja, bez żadnej innej nazwy marki w środku. Podtytuł ma dawać kontekst dotyczący twojej aplikacji, a nie być miejscem na pożyczanie cudzego ruchu.
Wytyczna 4.3 — spam i niemal identyczne aplikacje
Co to wyzwala. 4.3 dotyczy podobieństwa. Wyzwala się, gdy wysyłasz kilka niemal identycznych aplikacji pod osobnymi bundle ID (osobny build na miasto, zespół czy klienta zamiast jednej aplikacji z tymi wariantami w środku), albo gdy zgłoszenie trudno odróżnić od czegoś już powszechnie dostępnego. To często problem koncepcji, ale to wpis w sklepie sprawia, że duplikacja staje się widoczna — identyczne opisy i zrzuty ekranu między twoimi własnymi aplikacjami to mocny sygnał.
Przed: pięć aplikacji na twoim koncie z tym samym układem, tą samą listą funkcji i treścią różniącą się tylko podmienioną nazwą miasta lub zespołu.
Po: jedna aplikacja, która niesie te warianty jako opcje lub zakupy w aplikacji, z wpisem opisującym faktycznie odrębną rzecz, którą robi. Jeśli naprawdę masz osobne produkty, spraw, by każdy wpis pokazywał, co jest w nim rzeczywiście inne — w zrzutach ekranu i opisie, a nie tylko przez zamianę jednej nazwy własnej.
4.3 może wymagać więcej niż poprawki metadanych, jeśli sama aplikacja jest w gruncie rzeczy powierzchowną przeróbką. Ale tam, gdzie problemem jest to, że twoje wpisy wyglądają jak swoje własne klony, zróżnicowanie treści i zrzutów ekranu jest poprawką metadanych.
Wytyczna 5.2.1 — cudza własność intelektualna w twoich metadanych
Co to wyzwala. Użycie chronionego materiału osób trzecich, do którego nie masz praw — znaków towarowych, dzieł chronionych prawem autorskim, nazw kopiujących inne — gdziekolwiek w bundle ID, nazwie deweloperskiej lub metadanych. Częstym wariantem jest niezgodność między aplikacją lub marką we wpisie a podmiotem, który ją faktycznie przesłał, przez co Apple pyta, kto jest właścicielem nazwy.
Przed: nazwa marki lub platformy, której nie posiadasz, umieszczona w tytule aplikacji, podtytule lub polu słów kluczowych, by przechwycić jej ruch wyszukiwania.
Po: własna nazwa produktu w tytule, podtytule i słowach kluczowych. Jeśli faktycznie integrujesz się z platformą osób trzecich i musisz to zaznaczyć, zamieść wzmiankę o zgodności tam, gdzie jest to dozwolone, czyli w opisie, a nie w nazwie ani podtytule. Jeśli zbudowałeś aplikację dla klienta, który jest właścicielem znaku, prześlij ją z konta podmiotu, który go posiada, albo poproś o dodanie do jego zespołu, tak by nazwa sprzedawcy zgadzała się z marką.
Część bez builda, jeszcze raz
We wszystkich czterech przypadkach, jeśli poprawka mieści się w zapisie wersji — tekst i obrazy — poprawiasz to w App Store Connect i wysyłasz ponownie ten sam build. Nie podbijasz numeru builda ani nie czekasz na przetwarzanie. To jest szybka ścieżka, którą kupuje ci odrzucenie metadanych. Cena jest taka, że wracasz przez weryfikację, więc warto sprawdzić cały wpis pod kątem tych czterech wytycznych przed wysłaniem ponownym, zamiast usuwać je jedno po drugim, odrzucenie po odrzuceniu.
Gdzie pomaga Mokbi (i gdzie nie pomaga)
Większość problemów z 2.3.7 zaczyna się na etapie pisania, kiedy pole słów kluczowych lub podtytuł zostają wypchane w pogoni za zasięgiem. AI Mokbi tworzy treść twojego wpisu — nazwę, podtytuł, słowa kluczowe, opis — na podstawie tego, co twoja aplikacja faktycznie robi, co odciąga cię od nawyków wypychania i pożyczania cudzej marki, które w pierwszej kolejności prowadzą do odrzucenia za słowa kluczowe. Następnie lokalizuje tę treść na 50 języków, więc nie piszesz ręcznie od nowa pola słów kluczowych dla każdego rynku, wprowadzając za każdym razem tę samą pułapkę.
Warto trzeźwo spojrzeć na ograniczenia. To obniża szansę na oznaczenie 2.3.x lub 5.2.1 związane z treścią; nie może obiecać zatwierdzenia i nie decyduje o tym, co znajduje się w twoim buildzie. Weryfikacja to decyzja Apple. Zgodna, trafnie opisująca aplikację treść usuwa łatwe, samodzielnie wywołane powody odrzucenia. Mokbi nie publikuje automatycznie w twoim wpisie — tworzy treść i zrzuty ekranu; ty je sprawdzasz i wysyłasz.