Публикация мобильной игры: подготовка к App Store и Google Play

Запуск игры в сторы — это не «нажать Publish», а отдельный этап производства, который по трудозатратам часто сравним с финальным спринтом разработки. За годы работы в студии я не раз видел, как хороший билд спотыкался на модерации из-за неверно заполненной карточки или отсутствия тестового аккаунта для ревьюеров. Если подготовка сделана плохо, проект упирается в отклонение, лишние исправления, низкую конверсию страницы и первые негативные отзывы уже в день релиза. Ниже — практический разбор, что нужно проверить перед публикацией мобильной игры в App Store и Google Play, чтобы пройти модерацию с первого раза и не потерять время на доработки.

Что должно быть готово до отправки в сторы

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

• технический;
• юридический;
• контентный;
• маркетинговый.

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

Минимальный набор материалов

Техническая подготовка билда

Многие ошибки всплывают не в коде как таковом, а на финальной упаковке проекта. Для App Store и Google Play нужен именно production-сбор, а не тестовая версия. Разница принципиальная: тестовый билд может быть собран с отладочными флагами, которые замедляют производительность, или ссылаться на dev-сервер, который недоступен извне. Я не раз видел, как команда отправляла на ревью то, что крутилось у них на внутреннем тестировании, а потом удивлялась отказу.

Что проверить перед сборкой

• отключены debug-логи;
• убраны чит-меню и служебные кнопки;
• отключены тестовые подсказки и отладочный UI;
• настроены release signing keys;
• нет ссылок на dev-серверы;
• корректно работают звук, ориентация экрана и масштабирование интерфейса;
• игра не падает в первые 30 секунд после запуска;
• нет критических зависаний на слабых устройствах;
• все покупки, реклама и аналитика работают в релизном окружении.

Почему это важно

На тестовом устройстве игра может выглядеть идеально, но на реальном устройстве пользователя проявятся:

• неверная раскладка UI на маленьких экранах;
• слишком мелкий текст;
• обрезанные кнопки;
• черный экран при первом запуске;
• проблемы с загрузкой ресурсов;
• лаги после первого входа в уровень.

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

Требования App Store: на что обратить внимание

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

Что нужно для App Store

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

Apple также требует, чтобы информация о приватности была заполнена в App Store Connect, включая данные о сторонних сервисах, если их код встроен в приложение. Кроме того, в 2026 году для загрузки в App Store Connect применяются новые требования к сборке на актуальном SDK и Xcode. Это значит, что откладывать обновление инструментов разработки больше не получится — стор просто не примет билд, собранный на устаревшей версии.

Частые причины отклонения в App Store

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

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

Требования Google Play: что нельзя забыть

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

Что нужно для Google Play

• релизный Android App Bundle;
• корректная подпись приложения;
• заполненный store listing;
• описание игры и промо-материалы;
• политика конфиденциальности;
• заполненная форма Data safety;
• возрастной рейтинг;
• сведения о рекламе, покупках и подписках;
• тестирование на реальных устройствах;
• отсутствие критических крашей и ANR.

Google Play требует, чтобы игра была цифрово подписана, а также чтобы информация о собираемых данных была указана честно и без попыток «спрятать» трекинг за общими формулировками. Если вы используете аналитику, рекламные SDK или системы атрибуции — все это должно быть отражено в Data safety. Попытка указать «данные не собираются» при наличии Firebase в проекте почти гарантированно приведет к отклонению.

Типовые ошибки при публикации в Google Play

• выбран не тот тип сборки;
• неправильно настроена подпись;
• в Data safety указано меньше данных, чем реально собирает игра;
• описание слишком общее и не объясняет core loop;
• скриншоты не показывают игровой процесс;
• игра не проверена на разных диагоналях и версиях Android;
• есть проблемы с 64-битной поддержкой или совместимостью устройств.

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

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

Что должно быть на странице

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

Как писать описание без воды

Хорошее описание отвечает на три вопроса:

• что это за игра;
• что в ней делает игрок;
• почему в нее стоит зайти именно сейчас.

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

Пример структуры описания

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

Локализация и культурный контекст для России

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

Что стоит адаптировать

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

Что часто забывают

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

Чек-лист перед отправкой на модерацию

Технический чек-лист

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

Контентный чек-лист

• иконка соответствует стилю игры;
• скриншоты показывают геймплей;
• описание ясно объясняет игру;
• жанр указан честно;
• возрастной рейтинг заполнен;
• все тексты вычитаны;
• локализация завершена.

Юридический чек-лист

• опубликована политика конфиденциальности;
• заполнены privacy-настройки;
• заполнены данные о сборе информации;
• указаны сторонние SDK и сервисы;
• есть информация о монетизации;
• учтены требования к возрастному контенту.

Пошаговая подготовка к публикации

Шаг 1. Закрыть технический долг

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

Шаг 2. Собрать релизный билд

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

Шаг 3. Подготовить метаданные

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

Шаг 4. Настроить приватность и возрастные данные

Заполните все формы честно и без недосказанности. Если игра собирает аналитику, использует рекламу или сторонние SDK, это нужно указать явно. Лучше перечислить лишнее, чем недоговорить — модерация все равно увидит используемые библиотеки при проверке билда.

Шаг 5. Передать билд на ревью

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

Шаг 6. Отслеживать первые отзывы и метрики

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

Типовые ошибки новичков

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

Практический совет: как снизить риск отказа

Если времени мало, в первую очередь проверьте три вещи:

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

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

FAQ

Нужно ли тестировать игру на реальных устройствах перед публикацией?

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

Можно ли публиковать игру без политики конфиденциальности?

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

Что важнее перед релизом: описание или скриншоты?

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

Почему игру могут отклонить, если в ней нет багов?

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

Нужна ли локализация для русского рынка?

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

Вывод

Подготовка мобильной игры к публикации в App Store и Google Play — это не формальность, а отдельный этап, от которого зависит успех релиза. Чем раньше команда начнет думать о приватности, метаданных, локализации и стабильности билда, тем меньше будет отказов, переделок и потерь на старте.

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