Эта статья описывает процесс проверки приложений в сторах и даёт советы, которые помогут пройти её быстрее. Информация основана на официальных правилах публикации:

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

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

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

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

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

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

Как устроена проверка

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

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

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

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

Шаг 2: Проверка живым рецензентом

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

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

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

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

Завершённость

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При проектировании пейвола придерживайтесь следующих принципов:

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

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

  Чётко разграничивайте разовые покупки и продукты с регулярными платежами.

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

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

  

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

• Восстановление доступа

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

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

  Приложение должно распознавать встроенные покупки, совершённые со страницы продукта в сторе или в другом месте магазина.

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

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

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

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

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

Что делать после отказа

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

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

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

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

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

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

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

В период с 2024 по 2025 год Google удалил 47% приложений из Play Store, чтобы повысить их среднее качество.

Заброшенное приложение тоже несёт риски. И Google, и Apple снимают с публикации приложения, которые не обновляются и не скачиваются.

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

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