Отклонение метаданных App Store: исправляем 2.3.x, 2.3.7, 4.3 и 5.2.1
Ты только что получил письмо. Статус сменился на Metadata Rejected, а в заметке Resolution Center указан номер гайдлайна, который пришлось искать. Хорошая новость в том, что отклонение метаданных — одно из самых быстрых для исправления: тебе не нужно заново загружать сборку, ты редактируешь запись версии и отправляешь заново.
Первым делом стоит проверить номер гайдлайна в сообщении Resolution Center — он точно скажет, какое поле нужно исправить. Этот пост охватывает четыре наиболее вероятных случая отклонения листинга. Номера гайдлайнов со временем меняются, так что здесь приведены актуальные App Store Review Guidelines.
Сначала механика: что на самом деле значит «Metadata Rejected»
Статус Metadata Rejected указывает на твой листинг в сторе — название приложения, подзаголовок, ключевые слова, описание, скриншоты, превью, ссылки — а не на скомпилированное приложение. Поскольку флаг стоит на метаданных, новая сборка не нужна. Ты редактируешь указанное поле в App Store Connect, оставляешь текущую сборку прикреплённой к версии и отправляешь заново.
Стоит прямо сказать о двух оговорках. Во-первых, повторная отправка всё равно возвращает тебя в очередь ревью — процесс не требует новой сборки, но не освобождает от проверки: человек или автоматика снова всё посмотрят. Во-вторых, исправление одного поля, на которое указал Apple, не защищает остальную часть листинга. На следующем проходе ревьюеры могут отметить другой гайдлайн. Приведи в порядок весь листинг, пока занимаешься этим, а не только процитированную фразу.
Гайдлайн 2.3.3 — скриншоты должны показывать приложение в работе
Что вызывает. Твои скриншоты не показывают, как приложение выполняет свою функцию. Классический случай — первый слот занимает заставка, экран входа или заглавная картинка со слоганом без реального интерфейса. Это также срабатывает, если скриншот показывает функцию, которой в приложении нет, или ссылается на устройство или интерфейс другой платформы.
До: в первом слоте — логотип по центру градиента со словами «самый умный способ планировать неделю», и нигде не видно интерфейса приложения.
После: в первом слоте — реальный экран из основного сценария использования: недельный вид с заполненными записями, с короткой подписью над устройством, называющей выгоду. Ревьюеры (и пользователи) видят по миниатюре, что делает приложение. Оставь маркетинговые подписи и рамки устройства, но убедись, что интерфейс под ними настоящий и актуальный.
Это правка метаданных: замени изображения в записи версии, отправь заново — без новой сборки.
Гайдлайн 2.3.7 — ключевые слова должны описывать твоё приложение, а не поиск игр
Что вызывает. Это гайдлайн о злоупотреблении ключевыми словами. Срабатывает, когда метаданные забиты терминами, не описывающими твоё приложение: чужими товарными знаками, названиями более крупных или популярных приложений, ценовой лексикой не в том поле, именами знаменитостей или публичных персон ради охвата, или общими фразами, вставленными для попадания в поиск. Обычно виновато поле ключевых слов на 100 символов, но подзаголовок и название тоже нередко попадают под отметку. Название приложения ограничено 30 символами, а цена или рекламная лексика не должны появляться в названии, подзаголовке или скриншотах.
До (поле ключевых слов): список, включающий названия трёх более крупных приложений в твоей категории, имя известного автора и пару не связанных трендовых слов — ни одно из них не описывает функцию, которую ты реализовал.
После: ключевые слова, соответствующие тому, что пользователь реально ищет для нахождения твоей функции — задачи, которые она решает, проблему, которую она снимает, существительные с твоих собственных экранов. Каждый термин должен указывать на то, что приложение действительно делает.
До (подзаголовок): строка сравнения, позиционирующая тебя против конкретного конкурирующего приложения.
После: подзаголовок, простыми словами описывающий результат, который даёт твоё приложение, без чужого названия бренда. Подзаголовок нужен для контекста о твоём приложении, а не для заимствования чужого трафика.
Гайдлайн 4.3 — спам и почти-дубликаты приложений
Что вызывает. 4.3 касается однотипности. Срабатывает, когда ты выпускаешь несколько почти идентичных приложений под разными bundle ID (отдельная сборка на город, команду, клиента вместо одного приложения с этими вариациями внутри), или когда отправку трудно отличить от чего-то уже широко доступного. Часто это проблема самой концепции, но именно листинг делает дублирование заметным — одинаковые описания и скриншоты у твоих же приложений — сильный сигнал.
До: пять приложений в твоём аккаунте с одинаковым макетом, одинаковым списком функций и текстом, отличающимся только заменой названия города или команды.
После: одно приложение, реализующее эти вариации как внутренние опции или покупки, с листингом, который описывает, чем оно на самом деле отличается от остальных. Если у тебя действительно разные продукты, сделай так, чтобы каждый листинг показывал реальное отличие в скриншотах и описании, а не просто замену собственного имени.
4.3 может потребовать больше, чем правку метаданных, если базовое приложение действительно является тонким рескином. Но там, где проблема в том, что листинги читаются как клоны друг друга, разграничение текста и скриншотов — это правка метаданных.
Гайдлайн 5.2.1 — чужая интеллектуальная собственность в твоих метаданных
Что вызывает. Использование защищённых материалов третьих лиц, на которые у тебя нет прав, — товарных знаков, произведений с авторским правом, имитирующих названий — где угодно в bundle, имени разработчика или метаданных. Частый вариант — несоответствие между приложением или брендом в листинге и организацией, которая реально его отправила, из-за чего Apple спрашивает, кому принадлежит название.
До: название бренда или платформы, тебе не принадлежащее, стоит в названии приложения, подзаголовке или поле ключевых слов, чтобы поймать её поисковый трафик.
После: собственное название твоего продукта в названии, подзаголовке и ключевых словах. Если ты действительно интегрируешься со сторонней платформой и тебе нужно об этом сказать, оставь фактическое упоминание совместимости в описании, где это разрешено, и убери из названия и подзаголовка. Если ты сделал приложение для клиента, владеющего товарным знаком, отправляй его из аккаунта организации-владельца или попроси добавить тебя в их команду, чтобы имя продавца и бренд совпадали.
Часть без новой сборки, ещё раз
Во всех четырёх случаях, если исправление находится в записи версии — текст и изображения, — ты правишь его в App Store Connect и отправляешь заново ту же сборку. Не нужно увеличивать номер сборки или ждать обработки. Это и есть быстрая полоса, которую даёт отклонение метаданных. Плата за неё в том, что ты снова проходишь ревью, так что стоит прочитать весь листинг на предмет этих четырёх пунктов перед повторной отправкой, а не устранять их по одному отклонению за раз.
Где помогает Mokbi (и где нет)
Большинство проблем с 2.3.7 начинается на этапе написания текста, когда поле ключевых слов или подзаголовок забивают ради охвата. ИИ Mokbi составляет текст твоего листинга — название, подзаголовок, ключевые слова, описание — на основе того, что твоё приложение реально делает, что уводит от привычек с забиванием текста и заимствованием чужих брендов, которые в первую очередь и вызывают отклонение по ключевым словам. Затем он локализует этот текст на 50 языков, так что тебе не нужно вручную писать новое поле ключевых слов для каждого рынка и заново создавать ту же ловушку в каждом из них.
Важно трезво оценивать границы. Это снижает вероятность отметки по 2.3.x или 5.2.1 из-за формулировок; это не может гарантировать одобрение и не решает, что находится внутри твоей сборки. Ревью — решение Apple. Соответствующий, точный по сути текст убирает лёгкие, самими же созданные причины для отклонения. Mokbi не публикует автоматически твой листинг — он создаёт текст и скриншоты, а ты их проверяешь и отправляешь.