Первый отказ Apple получают почти все. Письмо приходит сухое, со ссылкой на пункт правил, и без объяснений, что именно не так. Ниже — причины, с которыми мы сталкивались чаще всего, и что помогало пройти проверку.
Ревьюер не смог войти в приложение
Самая частая причина. В заявке нужно указать рабочие логин и пароль, и они должны работать в момент проверки — а не в момент, когда вы их вписывали.
Отдельная ловушка: демонстрационные данные, которые может испортить сам ревьюер. У нас был случай, когда проверяющий нажал в приложении кнопку сброса и снёс демонстрационный матч, после чего экран стал пустым — и мы получили отказ три раза подряд, пока не защитили демо-данные на сервере от изменения. Если в приложении есть кнопка, способная обнулить содержимое, демо-аккаунт должен от неё не зависеть.
Если для входа нужен код из SMS или мессенджера, заведите номер с фиксированным кодом и опишите его в заметках для проверки. Ревьюер не будет ждать сообщение на ваш телефон.
Ссылка поддержки ведёт не туда
В карточке приложения есть поле Support URL, и Apple действительно по нему ходит. Ссылка на главную страницу сайта или, хуже того, на экран входа в личный кабинет даёт отказ по пункту 1.5. Нужна отдельная страница с контактами: почта, телефон, форма обращения. Проверьте её открытием в браузере перед отправкой — страница должна отвечать и содержать способ связаться.
Описание обещает то, чего в приложении нет
Проверяющий читает описание и ищет заявленные функции. Если в тексте есть «онлайн-оплата», а оплаты в приложении нет — это отказ. То же со словом «бесплатно» в названии и с упоминанием других платформ.
Простое правило: описание пишется по факту, а не по планам. Функцию добавите — допишете строку в следующей версии.
Запросы разрешений без объяснения
Каждое разрешение — камера, геопозиция, контакты, уведомления — должно сопровождаться внятным текстом, зачем оно приложению. Формулировка «приложению нужен доступ к камере» не подходит: нужно объяснить пользу для пользователя. И само разрешение должно запрашиваться в момент, когда оно действительно требуется, а не на старте пачкой.
Приложение — это просто сайт в обёртке
Если приложение открывает сайт в веб-виде и ничего больше не делает, Apple откажет по пункту 4.2. Спасает не маскировка, а реальная нативная функциональность: работа без интернета, уведомления, камера, сохранение данных на устройстве — что-то, что нельзя получить в браузере.
Как отвечать на отказ
В ответе ревьюеру пишите по существу и коротко: что именно исправлено, где это увидеть, какие шаги пройти. Приложите скриншот или короткое видео, если функция неочевидна. Спорить и объяснять бизнес-логику не стоит: проверяющий смотрит на соответствие правилам, а не на замысел продукта.
Если считаете отказ ошибкой, есть механизм апелляции — но он имеет смысл только когда вы уверены и можете это показать. В остальных случаях быстрее исправить и подать заново: повторная проверка обычно занимает меньше суток.
Что проверить до отправки
Работает ли демо-доступ прямо сейчас. Открывается ли ссылка поддержки и есть ли там контакты. Совпадает ли описание с тем, что в приложении. Объяснены ли разрешения. Есть ли в приложении что-то, кроме содержимого сайта. Пять пунктов, которые снимают большинство отказов.
Google Play: чем отличается
У Google проверка выглядит иначе: она в большей степени автоматическая, отказ приходит быстрее и формулируется конкретнее. Но и последствия жёстче — за повторные нарушения аккаунт разработчика могут заблокировать целиком, а вернуть его крайне сложно.
Частые причины отказов в Google Play: несоответствие описания реальным функциям, неполная или неточная декларация о безопасности данных, разрешения, которые приложению не нужны, и нарушение правил по целевой версии системы — приложение обязано собираться под достаточно свежую версию Android.
Отдельная история — раздел безопасности данных. Заполнять его нужно честно и полно: что собираете, зачем, передаёте ли третьим лицам. Расхождение между заявленным и фактическим поведением приложения находят автоматически, и это одна из частых причин снятия с публикации уже опубликованных приложений.
Что подготовить заранее
Перед подачей соберите пакет, который сокращает переписку с проверяющими. Демо-доступ, который работает и не ломается. Короткое видео сценария, если функциональность неочевидна или требует специфических данных. Заметки для проверки с описанием, что и в каком порядке нажать. Ссылки на политику конфиденциальности и страницу поддержки — обе рабочие и по существу.
Отдельно проверьте политику конфиденциальности: она должна быть на языке карточки приложения и описывать реальные данные, которые вы собираете. Шаблонный текст с чужим названием компании внутри — верный отказ.
Сроки и что от них зависит
Обычная проверка в App Store занимает от нескольких часов до суток, в Google Play — от нескольких часов до трёх дней, дольше для новых аккаунтов. Первое приложение в новом аккаунте всегда проверяют дольше и придирчивее.
Планируя запуск, закладывайте время на один-два отказа: это нормальный ход событий, а не катастрофа. Опасно другое — привязать дату публичного запуска к точному дню и обнаружить за сутки, что приложение не прошло проверку. Подавайте версию заранее с запасом в неделю.