В этой статье описан процесс проверки приложений в сторах и даны советы по ускорению одобрения. Информация взята из официальных руководств по публикации:

• Правила публикации в App Store
• Правила публикации в Google Play Store

Пользователям Adapty стоит уделить особое внимание требованиям, связанным с пейволами и встроенными покупками — именно они чаще всего становятся причиной отклонения приложений.

Перед началом

Убедитесь, что приложение готово к публикации.

В Adapty есть чеклист для выпуска, который поможет подготовить приложение к публикации.

Google Play Store требует, чтобы новые разработчики протестировали приложение перед отправкой на проверку. Тестирование должно охватывать не менее 12 человек и продолжаться минимум 14 дней подряд. Это требование введено в 2025 году, чтобы снизить количество сырых приложений, которые попадают на проверку к сотрудникам Google.

Обзор процесса проверки

Шаг 1: Автоматическая проверка

И App Store, и Google Play Store используют схожий двухэтапный процесс проверки. Сразу после отправки приложение проходит автоматическое сканирование, которое может занять несколько часов. Оба стора проверяют приложения на наличие вредоносного ПО, причём Google уделяет этому особое внимание. Система ищет поведенческие признаки вредоносной активности: обращения к подозрительным серверам, необоснованный доступ к пользовательским данным. Если приложение признаётся потенциально опасным, оно помечается и передаётся аналитику безопасности. Приблизительный список проверок, выполняемых на этом этапе, описан в документации Google Play Protect. Сторы также проверяют наличие необходимых метаданных, отсутствие вредоносных или устаревших зависимостей и целостность сборки.

Шаг 2: Проверка человеком

После прохождения автоматической проверки приложение изучает живой рецензент. Этот шаг может занять несколько дней — в зависимости от сложности приложения и текущей очереди на проверку. Приложения, обрабатывающие чувствительные данные, проверяются дольше.

Общие требования

Стабильность

Приложения, которые падают во время проверки, отклоняются. Рецензенты могут намеренно эмулировать нестабильное сетевое соединение, поэтому приложение должно корректно с этим справляться.

Полнота

Как Apple, так и Google устанавливают требование полноты («минимальной функциональности») в отношении контента в сторе.

• Плейсхолдеры, экраны «скоро» и нерабочий функционал ведут к отклонению iOS-приложений.
• Google более гибок, особенно если ваше приложение находится в раннем доступе.
• Оба стора отклоняют приложения с минимальным или отсутствующим функционалом. Это касается приложений, отображающих единственное изображение, PDF-файл или веб-страницу.

Отсутствующий контент попадает в ту же категорию.

• Если приложение не делает то, что вы рекламируете, оно будет отклонено.
• Если вы настроили встроенную покупку в дашборде, но не включили её в сборку, приложение будет отклонено.

Точность метаданных

Вводящая в заблуждение, недостоверная или противоречивая информация в описании, скриншотах и других метаданных может стать причиной отказа.

Не используйте страницу в сторе для рекламы функций, которые ещё не реализованы.

Если приложение не предназначено для широкой аудитории, рецензент будет искать дополнительную документацию с описанием его функций. Включите понятные инструкции в метаданные приложения.

Возрастной рейтинг

Контент внутри приложения должен соответствовать заявленному возрастному рейтингу.

Юридические аспекты

• Политика конфиденциальности приложения должна быть доступна прямо из приложения. Для этого можно использовать кнопку-ссылку в Paywall Builder.
• Предлагайте пользователям ознакомиться с юридическими соглашениями и принять их до того, как они вступят в силу.
• Сообщайте о наличии рекламы в приложении. Отсутствие такого раскрытия может привести к отказу.
• Если ваше iOS-приложение включает встроенные покупки, необходимо принять Paid Apps Agreement в дашборде App Store Connect.

Аутентификация

Если часть контента приложения доступна только после аутентификации, предоставьте рецензенту рабочие учётные данные. Невозможность получить доступ к контенту в полном объёме — основание для отказа.

Если приложение позволяет создавать учётные записи, оно должно также позволять их удалять. Переадресация пользователей на email-поддержку или сайт это требование не удовлетворяет.

Доступ и конфиденциальность

В метаданных приложения необходимо чётко указывать причину запроса каждого разрешения. Наиболее чувствительные разрешения (например, доступ к SMS и журналу звонков) могут потребовать видеодемонстрации.

Тот же принцип применяется к чувствительным данным пользователей: если вы их запрашиваете — объясните зачем.

Требования, связанные с встроенными покупками

Нарушения правил бизнес-политики — одна из самых распространённых причин отклонения приложений. Если основной способ монетизации вашего приложения — подписки и встроенные покупки, к нему будет повышенное внимание.

Требования к пейволам

Ревьюеры ожидают простых и понятных пейволов.

Если вас заподозрят в манипуляции пользователями, приложение будет отклонено. Если несколько проверок выявят признаки недобросовестных практик, ваш аккаунт может быть деактивирован, а приложение приостановлено. Google Play использует систему предупреждений, которая может привести к удалению всех ваших приложений. Придерживайтесь следующих принципов при проектировании пейвола:

• Будьте прозрачны и честны.

  Отображайте точную цену продукта, периодичность списаний, преимущества и условия отмены до того, как предложить пользователю совершить покупку.

  Чётко разграничивайте разовые покупки и продукты, требующие регулярных платежей.

  Если продукт предусматривает бесплатный пробный период, явно указывайте его длительность и условия.

  Не используйте намеренно запутанные формулировки, вводящие пользователя в заблуждение.

• Будьте последовательны.

  Цены на продукты должны совпадать в листинге App Store, на экранах внутри приложения, на экранах управления подпиской и в маркетинговых материалах. Любое расхождение в ценах, даже незначительное, может стать причиной отказа.

  Paywall Builder в Adapty автоматически синхронизирует цены между вашим пейволом и продуктом в App Store Connect. Если пейвол написан вручную, вы должны получить цену каждого продукта из его массива данных.

• Показывайте все уровни на равных условиях.

  Не выделяйте заранее самый дорогой вариант и не скрывайте более дешёвые.

• Избегайте «тёмных паттернов».

  Не создавайте искусственного ощущения срочности или дефицита.

  Не вынуждайте пользователей совершать покупки, намеренно делая бесплатные возможности неудобными или труднодоступными.

  

Гарантия доступа

Приложение должно гарантировать пользователям доступ к их покупкам.

• Немедленный доступ

  Успешная покупка должна сразу открывать доступ к продукту без видимых задержек.

  Промежуточные состояния авторизации платежа не должны вызывать ошибки или нарушать пользовательский опыт.

  После успешной покупки пейвол должен сразу скрываться. Если вы продолжаете показывать пейвол после покупки, пользователь не может получить доступ к оплаченному контенту.

• Восстановление доступа Пользователь должен иметь возможность восстановить доступ к продукту с нового устройства. Разместите кнопку восстановления на видном месте.

Если вы создали пейвол с помощью Flow Builder, кнопка восстановления автоматически запускает процесс восстановления. Если вы реализовали пейвол вручную, добавьте код, вызывающий метод restorePurchases. Adapty восстановит уровень доступа пользователя, если только вы не используете SDK в режиме наблюдателя. Приложение должно распознавать встроенные покупки, совершённые со страницы продукта в сторе или в других местах магазина приложений.

Допустимые способы оплаты

Оба стора запрещают продажу физических товаров через встроенные покупки и требуют использования встроенного биллинга для большинства цифровых товаров.

Требование об использовании встроенного биллинга не действует в ряде географических регионов, включая США и ЕС. В зависимости от страны вы можете полностью отказаться от встроенного биллинга стора или предложить пользователю выбор между биллингом App Store и альтернативными способами оплаты. Некоторые категории приложений (например, читалки электронных книг или приложения для знакомств) могут быть допущены к альтернативным способам оплаты даже за пределами этих регионов. Подробнее читайте в официальных правилах сторов.

Обработка отклонения

Если ваше приложение отклонили, рецензент укажет, какие именно правила были нарушены. Прочитайте соответствующее правило целиком и исправьте нарушение:

• Руководство по проверке приложений App Store
• Правила для разработчиков Google Play Store

Если вы считаете, что отклонение было несправедливым, вы вправе подать апелляцию. Предоставьте доказательства соответствия требованиям и обратитесь в стор.

• Не обновляйте приложение во время проверки.
• Каждый раз при отправке приложения на проверку вам может попасться другой рецензент. Это может сыграть как в вашу пользу, так и против вас.
• Не исправляйте проблемы по одной. Отправляйте приложение на повторную проверку только после того, как все правки внесены.
• Если Google Play отклонил приложение из-за нарушений политики, обновите соответствующие данные во всех треках, даже в приостановленных или неактивных.
• Повторные проверки, как правило, занимают меньше времени, чем первая.
• Ускоренная проверка может быть доступна при критических ошибках и дедлайнах — используйте её с умом.

После проверки: постоянный мониторинг

Оба стора продолжают следить за вашим приложением даже после прохождения модерации.

Если функциональность приложения изменится после одобрения (например, из-за динамически загружаемого кода), оно будет помечено и снято с публикации. Поток негативных отзывов пользователей тоже может стать поводом для дополнительной проверки.

С 2024 по 2025 год Google удалил 47% приложений из Play Store, чтобы повысить их среднее качество. Заброшенное приложение тоже несёт риски. Как Google, так и Apple удаляют из каталога приложения, которые долго не обновляются или не набирают загрузок.

Смотрите также

• Тестирование в песочнице
• Чеклист для выпуска