Приложения часто отклоняют не из-за качества кода, а из-за проблем на уровне документации и настроек: build не работает полностью, не предоставлен тестовый аккаунт, отсутствует способ удаления аккаунта, не опубликованы данные о конфиденциальности. Всё это прописано в официальных правилах и можно проверить заранее. Ниже — самые частые препятствия в обоих магазинах и порядок их устранения перед релизом.
Нерабочий build — причина номер один
В документе Apple App Review Guidelines раздел 2.1 называется «App Completeness»: отправленный build должен быть финальной рабочей версией. Placeholder-текст, экраны «coming soon», нерабочая кнопка, контент в демо-режиме — любого из этого достаточно для отказа.
В практике самая частая ситуация — модератор не может войти в приложение. Если требуется регистрация, в разделе App Review Information обязательно нужно указать рабочий тестовый аккаунт (логин и пароль). Если вход по SMS-коду, нужно в примечании объяснить модератору, как получить код: иначе он не сможет войти, и заявка вернётся с пометкой «cannot log in».
В приложениях с серверной зависимостью есть ещё одна ловушка — модераторы часто заходят с IP из США. Если backend отвечает только на IP из Узбекистана или включён геофильтр, для них приложение покажет пустой экран. Перед релизом проверьте это через VPN.
Кнопка удаления аккаунта
Если приложение позволяет пользователю создать аккаунт, внутри приложения должен быть и способ удалить этот аккаунт. В Apple это прописано в пункте 5.1.1(v), в Google Play существует отдельная политика «Data deletion», а в Play Console требуется ссылка для запроса на удаление.
Важный момент: текста «напишите в службу поддержки» недостаточно. Удаление должно начинаться из интерфейса самого приложения. Google Play дополнительно требует веб-ссылку на сайте — чтобы человек, удаливший приложение, тоже мог удалить свои данные.
На практике удобно сделать это в два этапа: кнопка в интерфейсе → экран подтверждения → удаление или анонимизация в backend. Если по бухгалтерским или юридическим причинам нужно сохранять некоторые записи, в политике конфиденциальности должно быть явно указано, что именно хранится и почему.
Конфиденциальность: две формы в двух магазинах
Оба магазина требуют декларировать, какие данные собирает приложение, но формы разные:
| Требование | App Store | Google Play |
|---|---|---|
| Декларация | App Privacy («Nutrition Label») | Data safety form |
| Где заполняется | App Store Connect | Play Console |
| URL политики конфиденциальности | Обязательный | Обязательный |
| Удаление аккаунта | Внутри приложения (5.1.1(v)) | Внутри приложения + веб-ссылка |
| Разрешение на отслеживание | App Tracking Transparency | Декларация Advertising ID |
Самая частая ошибка — ответы в форме не соответствуют реальности кода. SDK (аналитика, реклама, crash-отчёты, push) сами собирают данные и должны быть включены в декларацию. Приложение, в котором отмечено «мы ничего не собираем», но внутри работает Firebase Analytics, вернут из-за несоответствия.
Необоснованные запросы разрешений
Камера, геолокация, контакты, микрофон и фоновая геолокация — для каждого из них должен быть ответ на вопрос «зачем это нужно». В iOS таким ответом служат тексты в Info.plist, например NSCameraUsageDescription, которые видит пользователь:
<key>NSPhotoLibraryUsageDescription</key>
<string>E'longa rasm biriktirish uchun galereyaga kirish so'raladi.</string>
Общий текст вроде «App needs access» становится причиной отказа — текст должен объяснять именно сценарий в этом приложении.
На стороне Android есть отдельно контролируемые разрешения: MANAGE_EXTERNAL_STORAGE, доступ к SMS и журналу вызовов, фоновая геолокация. Для них в Play Console заполняется отдельная декларация, и во многих случаях требуется видеодемонстрация. Если разрешение осталось в коде, но не используется, его удаление из manifest упростит проверку.
Если есть пользовательский контент — обязателен набор модерации
Пост, комментарий, чат или фото профиля — любой контент, который загружает пользователь, переводит приложение в другую категорию. Пункт 1.2 Apple требует от таких приложений четырёх вещей: фильтрацию нежелательного контента, механизм подачи жалоб пользователями, возможность блокировать нарушителя и способ связаться с разработчиком.
Это требование часто останавливает marketplace- и социальные приложения уже на первой попытке, потому что многие откладывают кнопку «жалоба» на потом. В опыте создания marketplace Bisyor.uz процесс модерации был неотъемлемой частью продукта — требование магазина направлено именно в эту сторону.
Второй слой — оценка контента. Если анкета заполнена неверно (например, есть чат, но отмечено «нет пользовательского общения»), приложение могут пересмотреть даже после выхода.
Metadata, скриншоты и название
Значительная часть отказов вообще не связана с кодом. Если описание на странице магазина обещает функцию, которой нет в приложении, скриншоты показывают старый интерфейс или в названии используется чужое бренд-имя — это вернут как некорректные метаданные.
Вторая распространённая ситуация — категория «spam». Приложения, сделанные по одному шаблону и отличающиеся только названием и цветом (например, отдельная копия для каждого клиента), отклоняются в Apple по пункту 4.3. В таком случае правильное решение — поддержка нескольких организаций внутри одного приложения.
Третья — обёртка веб-сайта в приложение. Приложение, состоящее только из WebView и не использующее возможности устройства, вернут из-за «минимальной функциональности».
Что делать, если пришёл отказ
Отказ — это не штраф, а переписка. Порядок такой:
- Найдите номер guideline в сообщении (например, 2.1 или 5.1.1) и прочитайте этот пункт в официальном документе — короткий текст в письме часто не показывает полную причину.
- Посмотрите скриншот или запись экрана, которую приложил модератор: это покажет, на каком экране возникла проблема.
- Если причина непонятна, задайте уточняющий вопрос через Resolution Center — до отправки нового build.
- Если причина в metadata или декларации, не обязательно загружать build заново — исправленный текст или форму отправляют на повторную проверку.
- Если нужно изменить код, увеличьте номер build, загрузите его заново и в примечании укажите, что именно изменилось.
Не пропускайте четвёртый пункт: многие команды из-за ошибки в metadata заново собирают полный build и зря тратят несколько дней.
Часто задаваемые вопросы
Сколько времени занимает проверка?
Точный срок не гарантируется и зависит от периода загрузки. На практике в App Store обычно от нескольких часов до нескольких дней, а в Google Play для новых аккаунтов разработчика первые релизы занимают заметно больше времени. Дату релиза лучше планировать с учётом этой неопределённости.
Влияет ли отказ на следующие заявки?
Один отказ сам по себе не влияет на аккаунт негативно — это обычный рабочий процесс. Проблема в повторении: если одно и то же нарушение отправляется снова и снова или обнаруживается попытка обойти модерацию, могут быть приняты меры на уровне аккаунта разработчика.
Могу ли я самостоятельно выпустить приложение?
Да, если аккаунт разработчика, сертификаты и материалы для магазина готовы. Сложность не техническая, а скорее организационная: политику конфиденциальности, процесс удаления аккаунта, формы деклараций и инструменты модерации нужно заложить в план продукта заранее. Делать это на пороге релиза — самый затратный по времени путь.
Нужно ли отправлять в оба магазина одновременно?
Многие команды сначала публикуются во внутренней тестовой сети Google Play, а затем отправляют в App Store — так открытые ошибки находятся на более дешёвом этапе. Но отправлять в оба магазина одновременно не вредно: причины часто разные, и их параллельное исправление сокращает общий срок.
Большинство отказов связано не с кодом, а с документацией и настройками — то есть их можно закрыть за час проверки перед релизом. Если нужна помощь с мобильным продуктом или веб-проектом, самый дешёвый вариант — учесть требования платформ на этапе планирования. Такой подход оправдал себя и в продуктах с долгим жизненным циклом, таких как Zamin.uz.