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

Что реально требуется перед отправкой на модерацию

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

Список кажется простым, пока не начать проверять узлы, где проект соприкасается с политиками площадок и законом. Доступы и юридические сведения — от налоговой информации до подтверждения прав на контент — запрашиваются раньше, чем отправится первая сборка. Платформы ждут понятной витрины: скриншотов на точные устройства, промо-роликов с безошибочными рейтингами, описаний без обещаний, нарушающих правила. Техническая сторона раздражающе конкретна: на Android — Android App Bundle, актуальный target API, 64-битные сборки; на iOS — корректные сертификаты, профили, версии SDK. Без приватности никуда: политики в публичном доступе, App Privacy и Data Safety без расхождений с реальным сбором данных. И последнее — внутреннее тестирование, чтобы модератор не оказался первым игроком.

• Аккаунты разработчика: App Store Connect, Google Play Console, Steamworks
• Юридические данные: налоговые формы, реквизиты, договоры на IP
• Сборки: iOS (подпись, профили), Android (AAB), PC (Steam депо)
• Метаданные: названия, подзаголовки, описания, ключевые слова
• Витрина: скриншоты, иконки, баннеры, превью-видео
• Политики: конфиденциальность, обработки данных, для детей (при необходимости)
• Рейтинги: IARC/ESRB/PEGI, возрастные категории, ограничения регионов
• Тестирование: краши, прогресс, оплаты, восстановление покупок

Метаданные и визуальные материалы: как собрать витрину, которая пройдёт и продаёт

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

Описание должно продавать механику, не обещая чудес, запрещённых правилами: без «быстрого заработка», навязчивых сравнений и вводящих в заблуждение формулировок. Ключевые слова на iOS в отдельном поле, на Android — в описании и кратком описании; абзацы лучше выстраивать от сильного тезиса к конкретике. Скриншоты — это рассказ на мини-кадрах, и каждый должен быть читаемым на маленьких экранах. Видео-превью повышает конверсию, если отражает реальный геймплей и не содержит скрытой рекламы. Иконка — единственный знак, который игрок видит ежедневно; чрезмерная детализация теряется, простая форма запоминается. Важно помнить об адаптации под локали — лексика и образы несут культурные коды: то, что вдохновляет на одном рынке, путает на другом.

Какие материалы обязательны и какие — желательны

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

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

Ниже — ориентировочный перечень активов, который удобно держать как чек-лист при сборке витрины.

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

Технические требования: сборки, подпись, SDK и политика данных

Площадки ждут строго определённые форматы, уровни API, корректную подпись и честный отчёт о данных. Почти все отказы по технике — про несовпадение ожиданий и факта.

На Android релизится Android App Bundle, целевой уровень API должен соответствовать текущему требованию Google Play, а поддержка 64-бит — обязательна. Подпись — через Play App Signing или собственным ключом с безупречной сохранностью. На iOS публикация идёт через Xcode или Transporter, важны действующие сертификаты, профили, корректные Entitlements и согласованные версии SDK. App Tracking Transparency запрашивается честно и вовремя, а SKAdNetwork объявляется, если реклама на атрибуции. И Apple, и Google требуют формы о данных: App Privacy и Data Safety должны отражать действительный сбор, иначе доверие рушится при первом сравнении аналитики и форм.

Критические параметры сборки для разных платформ

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

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

Возрастные рейтинги, политика для детей и юридические нюансы

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

Google Play предлагает анкету контент-рейтинга (IARC) и программу для семей, где ограничения на сбор данных и рекламу особенно жёсткие. App Store придерживается своей классификации и повышенных требований к сбору данных у детей, а также к использованию аккаунтов и социальных функций. Юрчасть — это права на контент, музыкальные треки, шрифты и сторонние ассеты, лицензионные соглашения и вкладки конфиденциальности на сайте. Ошибка на этом участке — блокировка релиза до разбирательства и отозванные апдейты, если нарушение вскрывается после релиза.

• Рейтинговые системы: IARC (Google Play), ESRB/PEGI (регионы), классификация App Store
• Политики для детей: запрет профайлинга, ограниченная реклама, родительские шлюзы
• Интеллектуальная собственность: права на музыку, арты, шрифты, движки/плагины
• Юридические страницы: Privacy Policy, Terms of Service, Support
• Региональные ограничения: соответствие локальным законам и возрастным нормам

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

Тестирование и поэтапный релиз: как снижать риски

Ступенчатый запуск делает релиз управляемым: сначала внутренние тесты, потом закрытые круги, затем открытая бета и только после — прод. Ошибки, найденные на малых аудиториях, обходятся дешевле и безопаснее.

Google Play даёт гибкие треки: internal, closed и open с возможностью доливать версии и переманивать тестеров по ссылкам. App Store предлагает TestFlight с удобной аналитикой крашей и откликов. На Steam удобны бета-ветки, переключаемые в клиенте. Важно закладывать метрики заранее: в каждый тестовый этап входят целевые сценарии — покупка, восстановление, онбординг, первый бой или первый уровень. При поэтапном выкате в прод добавляется поэтапный процент аудитории: растущая волна быстро показывает регрессии. Если метрики тонут — откат, фиксы, новый билд.

Ключевые шаги по тестовым трекам

Смысл треков — отделить проверку стабильности от проверки экономики и удержания. Каждый трек отвечает на свой вопрос.

1. Internal: сбор крашей, базовая совместимость, грубые регрессии
2. Closed: UX-замечания, сложности онбординга, платежи
3. Open/TestFlight внешние: A/B витрины, ретеншн первых дней
4. Staged rollout: контроль рисков, мониторинг при росте трафика

Хорошая дисциплина релиза — чек-лист до кнопки Submit: отсутствие крашей на первом экране, корректность paywall, равномерные FPS на слабых устройствах, отсутствие «зависших» разрешений на трекинг и доступы без смысла. В отчётах предзапуска Google Play стоит отслеживать скриншоты ошибок и поведение на специфичных моделях; типичная ловушка — обрезанные UI в нестандартных пропорциях экрана.

Типичные отказы модерации и способы предотвратить их

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

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

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

Разные сторы — разные правила: мобильные и PC под одной лупой

Мобильные площадки регулируют приватность и платежи строже, чем PC-магазины, а PC-сторы жёстче к стабильности и поддержке железа. На уровне витрины принципы схожи, различаются детали и акценты.

На App Store контроль точен и формализован: соответствие гайдлайнам, честность трекинга, подписки без трюков. Google Play добавляет требование по актуальному API и формам Data Safety, а также программы для семей. Steam делает ставку на качество сборок, честность отзывов и прозрачность контента: ложные теги и искусственный хайп оборачиваются репутационными потерями. Время ревью и каналы поддержки тоже различаются. Для ориентирования — компактная таблица.

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

Монетизация и соответствие биллингу: как не попасть под санкции

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

Встроенные покупки и подписки — зрелая экосистема, где допускается простор механик, но нет пространства для хитрых формулировок. Откат старых библиотек платежей ведёт к массовым отказам, а в подписках важна прозрачность: цена, период, условия продления, отмена одним касанием. На Android обязательна актуальная Google Play Billing Library, на iOS — корректное применение StoreKit и механик восстановления. Для регионов с ограничениями по платежам действуют дополнительные правила, и обходить их публицистикой в описании — путь к блокировке.

Что проверить в магазине перед отправкой на ревью

Проверка монетизации — это короткий список, который легко забыть в спешке. Его стоит держать перед глазами в момент сборки.

• Версия библиотеки платежей соответствует текущим требованиям площадки
• Условия подписок и триалов прозрачны в интерфейсе
• Восстановление покупок работает на «холодном» запуске
• Нет внешних платежей или призывов «купить на сайте»
• Цены и валюты выровнены по регионам, налоги учтены

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

Сроки, ожидания и планирование релиза

Релиз длится дольше, чем кажется: модерация, правки, откаты и повторные проверки съедают недели. Планы выживают, если заложены запас и параллельные задачи.

Время ревью зависит от истории аккаунта, типа приложения и сезона. Крупные апдейты магазинов или крупные праздники тянут очереди. Корректное ожидание — это спринт задач на время модерации: работа над локализациями, допиливание витрины, подготовка ивентов. Желательно держать наготове «горячий» фикс на случай быстрой правки. Таблица ниже — ориентир, а не гарантия, однако она помогает расставить маяки в календаре.

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

FAQ по публикации игры: вопросы, которые задают перед релизом

Сколько времени обычно занимает модерация в App Store и Google Play?

От нескольких часов до нескольких дней, иногда дольше для новых аккаунтов. Сезон, история нарушений и тип контента влияют на скорость.

Если аккаунт только создан, ожидание может растянуться: площадки пристальнее смотрят на новые записи и неполные юридические данные. Праздники и массовые обновления политик увеличивают очередь. Практика показывает, что заранее подготовленные правки и готовый фикс экономят до недели в сумме. Для апдейтов существующих приложений ревью обычно быстрее, особенно при хорошем «послужном списке».

Нужно ли отдельное видео-превью, если уже есть трейлер?

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

Трейлер для соцсетей и Youtube часто строится на эмоции и нарративе, а превью в сторе должно мгновенно показать механику. Платформы не приветствуют агрессивные заставки, ор и резкие вспышки; негромкий старт и честный геймплей повышают конверсию и снижают риск отказа за «вводящую визуализацию».

Можно ли использовать внешние платежи в мобильной игре?

Нет, встроенные покупки должны идти через механизмы магазина. Исключения узкие и зависят от региона и категории приложения.

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

Чем грозит расхождение между формами App Privacy/Data Safety и реальным сбором данных?

Отказом в ревью и риском удаления приложения, если несоответствие выявится после релиза. Доверие площадки хрупко.

Формы должны отражать фактическое поведение: даже «спящий» SDK, имеющий доступ к данным, считается сбором. Рекомендуется инвентаризация библиотек, проверка разрешений и логики отправки событий. Если сбор данных меняется, формы обновляются синхронно с билдом.

Как подтвердить права на музыку и ассеты в игре?

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

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

Нужен ли сайт с политикой конфиденциальности?

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

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

Финальный аккорд: как собрать релиз в единый ритм

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

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

1. Проверить аккаунты и юридические данные, подготовить политики на сайте.
2. Собрать билды под требования платформ: AAB/IPA, подпись, актуальные SDK.
3. Заполнить формы о данных (App Privacy/Data Safety), синхронизировать с кодом.
4. Собрать витрину: иконка, скриншоты, видео, тексты, локали.
5. Пройти треки тестирования: internal → closed → открытая бета/TestFlight.
6. Проверить платежи: версии библиотек, восстановление, прозрачные условия.
7. Отправить на ревью с понятными комментариями к нетипичным функциям.
8. Выкатить по этапам, мониторить метрики, держать «горячий» фикс.

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