Публикация в App Store и Google Play не сводится к загрузке файла. Сторы проверяют продукт, документы и то, как вы описали приложение на странице. Если вы не подготовили аккаунты, доступы, юридические тексты и релизные файлы заранее, вы почти всегда теряете время на правки и повторную отправку.
Этот чек-лист помогает бизнесу пройти этап публикации спокойнее. Вы поймёте, что именно нужно подготовить до модерации, кто со стороны компании должен участвовать и где обычно возникают отказы.
Что важно понять перед отправкой приложения в стор
Почему модерация — это проверка продукта и метаданных вместе
Стор проверяет не только работу приложения. Он сравнивает реальный функционал с тем, что вы написали в названии, описании, скриншотах и промоматериалах. Если на скриншотах есть функция, которой нет в сборке, вы рискуете получить отклонение. Если приложение просит доступы и не объясняет зачем, вы тоже рискуете получить отказ.
Думайте о модерации как о сверке обещаний и факта. Приложение должно делать то, что вы заявили. А страница в сторе должна показывать то, что пользователь увидит внутри.
Какие роли нужны со стороны бизнеса и команды разработки
Бизнесу важно назначить одного ответственного за релиз. Он собирает материалы, держит сроки, принимает финальные тексты и отвечает на вопросы модерации.
Обычно нужны роли:
- продукт или владелец бизнеса, чтобы подтвердить модель монетизации, ограничения и аудиторию
- маркетинг, чтобы подготовить тексты и визуалы для страницы приложения
- юрист или человек, который отвечает за документы и согласия, чтобы закрыть вопросы по политике конфиденциальности и обработке данных
- команда разработки, чтобы собрать релизные билды, подготовить подписи, сертификаты и данные для тестирования
- QA, чтобы проверить критические сценарии перед отправкой
Если вы не закрепили роли, команда начинает спорить уже на этапе загрузки сборки. А стор не ждёт.
Какие сроки заложить на проверку и правки
Модерация всегда включает ожидание и итерации. Заложите время не только на проверку, но и на правки и повторную отправку. Это особенно важно, если у вас релиз привязан к рекламе, мероприятию или договорённостям с партнёрами.
Не планируйте запуск впритык. Подготовка аккаунтов, документов и релизных материалов часто занимает больше времени, чем финальная сборка.
Аккаунты разработчика и доступы, которые нужно подготовить заранее
Apple Developer и App Store Connect: что потребуется от компании
Для публикации iOS-приложения вам нужен аккаунт Apple Developer и доступ к App Store Connect. Со стороны компании обычно требуется подготовить данные, которые подтверждают, кто владелец аккаунта и кто имеет право публиковать приложение.
До старта публикации проверьте:
- кто владеет аккаунтом и на чьи данные он оформлен
- кто имеет доступ к App Store Connect и сможет отвечать на вопросы модерации
- кто сможет подписывать соглашения в кабинете, если вы планируете монетизацию
Если аккаунта нет, не откладывайте регистрацию на последнюю неделю. Этот этап часто блокирует весь релиз.
Google Play Console и настройки профиля разработчика
Для Android-публикации нужен доступ к Google Play Console. В профиле разработчика вы указываете данные, которые видит пользователь. И эти данные тоже влияют на доверие и на модерацию.
Перед загрузкой сборки проверьте:
- заполнены ли данные разработчика и контакты
- есть ли рабочая почта поддержки
- кто будет администратором консоли и кто сможет управлять релизами и треками тестирования
Если вы меняете владельца или доступы в последний момент, вы рискуете потерять контроль над релизом.
Доступы для команды и безопасное хранение данных
Дайте команде разработки и QA доступы по ролям. Не делайте один общий логин. Так вы снижаете риск потери аккаунта и ошибок в публикации.
Отдельно подготовьте безопасное хранение:
- доступов к консолям
- сертификатов и ключей подписи
- релизных файлов и материалов для стора
- тестовых учётных данных для модератора
Потеря ключей подписи или путаница с доступами почти всегда превращается в дорогую задержку.
Юридические требования и документы, без которых публикацию остановят
Политика конфиденциальности и страница поддержки
Сторы ожидают, что пользователь сможет прочитать, какие данные собирает приложение и куда обращаться за поддержкой. Вам нужна политика конфиденциальности на публичной странице. Вам также нужна понятная страница поддержки с контактами.
Проверьте два условия:
- политика открывается по ссылке и работает на телефоне
- контакты поддержки соответствуют тем, что указаны в карточке приложения
Если ссылки ведут на пустую страницу или на документ без смысла, вы теряете время на повторную отправку.
Сбор и обработка персональных данных и согласия
Если приложение собирает персональные данные, вы должны объяснить это пользователю. Покажите, какие данные вы собираете, зачем вы это делаете и как пользователь может управлять этим.
На практике важно заранее согласовать:
- какие данные вы реально собираете в приложении
- какие разрешения запрашиваете и почему
- какой текст согласий показываете пользователю и когда именно
Не добавляйте лишние поля в регистрации. Не просите доступы без причины. Модерация обращает на это внимание.
Авторские права, лицензии и использование стороннего контента
Если вы используете чужие тексты, изображения, музыку, видео или бренды, подготовьте подтверждение прав. Это касается и контента внутри приложения, и материалов в карточке приложения.
Перед релизом проверьте:
- не используете ли вы материалы без лицензии
- не создаёте ли впечатление связи с чужим брендом, если её нет
- не копируете ли визуальные элементы, которые могут вводить в заблуждение
Лучше убрать спорный контент до отправки, чем объясняться после отказа.
Подготовка сборки и релизных артефактов
iOS: сертификаты, профили и сборка для загрузки
Для iOS-публикации важны сертификаты и профили, которые связывают сборку с вашим аккаунтом. Команда разработки должна подготовить сборку так, чтобы App Store Connect принял её и смог обработать.
До загрузки проверьте:
- команда использует правильный аккаунт и правильные подписи
- в сборке нет тестовых настроек, которые ломают работу у модератора
- вы понимаете, какой билд вы отправляете в тестирование и какой в релиз
Если вы меняете критичные настройки перед самой отправкой, вы повышаете риск ошибок при обработке билда.
Android: ключ подписи и форматы сборки
Android-релиз требует корректной подписи. Это ключ, который связывает приложение с будущими обновлениями. Потеря ключа блокирует нормальное развитие продукта.
Перед публикацией проверьте:
- где хранится релизный ключ и кто имеет к нему доступ
- какой формат сборки вы готовите для загрузки в консоль
- что вы используете одну и ту же схему подписи для всех релизов
Не переносите ключи в чаты и не храните их в открытом доступе. Это риск для безопасности и для релиза.
Версионирование, окружение и что нельзя менять в последний момент
Стор и пользователи ожидают предсказуемых релизов. Если вы меняете окружение, API, домены или критичные настройки прямо перед отправкой, вы получаете нестабильность, ошибки авторизации и проблемы с оплатой.
Перед финальной сборкой зафиксируйте:
- релизные адреса серверов и интеграций
- настройки аналитики и уведомлений, которые влияют на сценарии пользователя
- список разрешений и экранов, которые увидит модератор
Финальная сборка должна быть именно той версией, которую вы готовы показать пользователю.
Качество приложения перед публикацией
Стабильность на слабом интернете и на разных устройствах
Модератор проверяет приложение как обычный пользователь. Он может запускать его на нестабильной сети. Он может переключать Wi-Fi и мобильный интернет. Он может свернуть приложение и вернуться через минуту.
Перед отправкой проверьте поведение в трёх режимах. Хороший интернет. Плохой интернет. Полное отсутствие сети. Приложение должно показывать понятные сообщения и не зависать.
Дальше проверьте разные устройства и размеры экранов. Не ориентируйтесь только на один флагманский смартфон. Частая проблема — это сломанная вёрстка на маленьком экране. Ещё одна частая проблема — это кнопки, по которым сложно попасть.
Проверьте также сценарии после обновления. Пользователь может установить новую версию поверх старой. Данные не должны пропасть. Авторизация не должна сломаться.
Проверка критических сценариев: регистрация, оплата, восстановление доступа
Стор чаще всего отклоняет приложения не за мелкие баги. Он отклоняет за то, что пользователь не может пройти ключевой путь. Поэтому вы должны прогнать критические сценарии до отправки.
Минимальный список для проверки:
- регистрация и вход, включая ошибки и повторный вход
- восстановление доступа, если пользователь забыл пароль
- оформление покупки или подписки, если вы монетизируете приложение
- доступ после оплаты, чтобы пользователь сразу видел результат
- удаление аккаунта, если приложение создаёт учётные записи
Не оставляйте в релизе заглушки и экраны «скоро будет». Если вы пишете о функции на странице приложения, пользователь и модератор должны увидеть её в сборке.
Краш-логи, аналитика и минимальный набор мониторинга
До публикации настройте базовую диагностику. Вам нужно понимать, где приложение падает и что именно ломается у пользователя. Без этого вы будете угадывать причины отказов и жалоб.
Проверьте три вещи:
- приложение пишет краш-логи и вы можете их читать
- в приложении есть базовая аналитика ключевых действий, чтобы видеть, где люди уходят
- вы фиксируете ошибки сети и серверные ответы, которые влияют на регистрацию и оплату
Если модератор столкнётся с ошибкой, вы должны быстро воспроизвести её и исправить. Это экономит дни на переписке и повторной проверке.
Услуга по теме
Подготовим релиз приложения и проведём публикацию в App Store и Google Play
Соберём аккаунты, доступы, сборки и метаданные, проверим критические сценарии и юридические тексты, подготовим тестовые треки и пройдём модерацию вместе с вами — чтобы релиз не сдвинулся из-за отказов.
Контент для страницы приложения и правила достоверности
Название, описание, ключевые элементы и запреты формулировок
Страница приложения — это часть модерации. Стор сравнивает тексты с тем, что реально делает продукт. Поэтому пишите только про то, что есть в текущей версии.
Соберите основу карточки заранее:
- название, которое ясно объясняет суть
- краткое описание ценности в первых строках
- полное описание с понятной структурой и без лишних обещаний
- контакты поддержки, которые совпадают с вашими страницами и письмами
Избегайте формулировок, которые звучат как недоказуемые заявления. Не обещайте то, что вы не сможете показать в приложении. Не описывайте будущие функции как уже работающие.
Иконка, скриншоты и видео: что должно совпадать с функционалом
Визуалы должны показывать реальный интерфейс. Скриншоты и видео не могут быть фантазией дизайнера. Они должны совпадать с тем, что увидит пользователь после установки.
Проверьте перед загрузкой:
- скриншоты сделаны из актуальной сборки
- на изображениях нет функций, которых нет в приложении
- тексты на скриншотах не противоречат правилам и не вводят в заблуждение
- иконка не копирует чужие знаки и не создаёт ложное впечатление связи с другим брендом
Если вы меняете интерфейс в последний момент, перезапишите скриншоты. Несоответствие — это частая причина правок и отклонений.
Локализация: когда она нужна и как не испортить тексты
Локализация нужна, когда вы публикуете приложение для нескольких рынков или показываете страницу приложения на разных языках. Стор и пользователи ждут, что тексты будут читабельными и точными.
Не делайте локализацию в спешке. Частая ошибка — это машинный перевод без проверки. Он ломает смысл и снижает доверие.
Проверьте минимум:
- название и описание на каждом языке звучат естественно
- термины в приложении и на странице совпадают
- на скриншотах не осталось текста на другом языке, если он важен для понимания
Если вы не готовы к качественной локализации, лучше начать с одного языка и расширяться после релиза.
Настройки публикации и тестовые треки
TestFlight: внутреннее и внешнее тестирование на iOS
TestFlight помогает протестировать iOS-сборку до релиза. Он снижает риск того, что модератор увидит критический баг первым.
Организуйте два уровня:
- внутреннее тестирование для команды, чтобы быстро ловить ошибки
- внешнее тестирование для ограниченной группы, чтобы увидеть поведение реальных пользователей
Подготовьте для теста понятные инструкции. Дайте тестерам конкретные сценарии. Соберите обратную связь в одном месте. Так вы быстрее закрываете ошибки до отправки в App Store.
Треки тестирования в Google Play и требования к предрелизной проверке
В Google Play удобнее выпускать сборки через тестовые треки. Вы можете проверить приложение на реальных устройствах и версиях Android до того, как откроете доступ всем.
Настройте треки заранее:
- внутренний трек для команды
- закрытый трек для группы тестировщиков
- при необходимости открытый трек для более широкой проверки
Заложите время на предрелизное тестирование. Google может требовать тестирование до полноценной публикации. Если вы не планируете этот этап, вы рискуете сдвинуть дату релиза.
Возрастной рейтинг, категории и анкеты контента
Перед публикацией стор попросит выбрать категорию и заполнить анкеты по контенту. Эти ответы влияют на возрастной рейтинг и доступность в странах.
Проверьте согласованность:
- контент в приложении соответствует выбранному рейтингу
- описание и скриншоты соответствуют тому же уровню контента
- вы честно указываете наличие пользовательского контента, рекламы или покупок, если они есть
Не занижайте рейтинг ради охвата. Это частая причина проблем уже после публикации.
Монетизация и покупки: где чаще всего получают отклонение
Подписки и встроенные покупки: прозрачность условий и цены
Если приложение продаёт цифровой доступ, модерация внимательно смотрит на экран оплаты и на формулировки. Пользователь должен понимать, за что он платит.
Проверьте, что вы показываете до покупки:
- точную цену
- периодичность оплаты, если это подписка
- условия отмены и управления подпиской
- разницу между пробным периодом и платной частью, если вы его даёте
Не прячьте условия в мелком тексте. Не меняйте цену в разных местах. Цена в приложении должна совпадать с тем, что увидит пользователь в сторе.
Восстановление покупок и доступ после оплаты
После оплаты пользователь должен сразу получить доступ. Если вы продолжаете показывать пейвол или не открываете функции, модерация считает это ошибкой.
Проверьте два сценария:
- немедленный доступ после успешной покупки
- восстановление покупок на другом устройстве или после переустановки
Сделайте кнопку восстановления заметной. Проверьте сценарий на тестовых аккаунтах. Это снижает риск отказа и жалоб после релиза.
Разрешённые способы оплаты и типичные нарушения правил
Сторы жёстко регулируют способы оплаты для цифровых товаров и подписок. Частая причина отклонения — это попытка увести пользователя на внешнюю оплату там, где стор требует встроенную.
Перед релизом согласуйте с командой:
- какие продукты вы продаёте, физические или цифровые
- какие сценарии оплаты есть в приложении
- куда ведут ссылки из приложения и из карточки в сторе
Если вы добавляете оплату через сайт, проверьте, что правила стора это допускают для вашей модели. Если нет, уберите этот сценарий до публикации.
Что делать, если приложение отклонили, и как пройти повторную проверку
Как читать причину отказа и собирать список правок
Отклонение почти всегда приходит с причиной и ссылкой на правило. Прочитайте сообщение целиком. Не выдёргивайте одну фразу. Стор часто указывает несколько проблем.
Сразу соберите список правок в одном документе:
- что именно не понравилось модератору
- где это находится — экран, ссылка, раздел в карточке
- кто исправляет — разработка, дизайн, контент, юрист
- что вы проверите после исправления, чтобы проблема не вернулась
Не делайте правки вслепую. Воспроизведите сценарий, который описал модератор. Если вы не можете повторить проблему, значит у вас нет достаточных данных или вы проверяете не тот путь.
Как подготовить объяснение для модератора и тестовые данные
Если модератор не может пройти сценарий, он отклонит приложение даже при рабочем коде. Дайте ему возможность проверить продукт.
Подготовьте:
- тестовую учётную запись, если контент доступен только после входа
- тестовые данные, чтобы модератор увидел функции, за которые вы отвечаете
- короткие инструкции, как пройти ключевые сценарии — регистрация, покупка, восстановление доступа
- контакты для связи, если модератор запросит уточнение
Пишите объяснение простыми словами. Укажите, что вы исправили, где это проверить и на какой версии сборки. Не спорьте. Покажите, что вы поняли правило и выполнили его.
Как организовать релиз после одобрения и обновления без рисков
После одобрения у вас появляется соблазн быстро выкатить обновление и доделать мелочи потом. Так вы часто получаете новый отказ уже на следующей версии.
Соберите минимальный план релиза:
- кто нажимает кнопку публикации и когда
- какие метрики вы проверяете в первые часы — установки, регистрации, покупки, ошибки
- как вы принимаете решения по срочному хотфиксу — кто отвечает и где лежат доступы
- как вы ведёте список изменений и версий, чтобы не потерять контроль
Не меняйте критические вещи в день релиза. Не обновляйте тексты и визуалы хаотично. Держите карточку приложения и продукт синхронными. Тогда последующие обновления проходят проще.
