Как опубликовать приложение в App Store, Google Play и RuStore
Что подготовить до отправки приложения в магазины, как не застрять на модерации и почему RuStore лучше планировать не в последний день.
Чтобы опубликовать приложение в App Store, Google Play и RuStore, подготовьте аккаунты разработчика, финальную сборку, политику конфиденциальности, описание, скриншоты, иконку, возрастные ограничения, данные о разрешениях, тестовые доступы и план первого релиза. Для RuStore отдельно проверьте требования к разработчику, карточке приложения, подписи Android-сборки и материалам для модерации. Публикацию лучше планировать как этап проекта, а не как кнопку в конце разработки.
Подготовьте запрос на оценку приложения через практичные вопросы
Отметьте нужные функции: аккаунты, корзину, платежи, админку, интеграции, хранение данных и запуск.
Главные выводы
- Публикация начинается до разработки финальной сборки: аккаунты, юридические страницы и карточки магазинов нужно готовить заранее.
- Владелец аккаунтов должен быть бизнес, а не случайный подрядчик. Иначе потом сложнее передавать приложение, обновлять сборки и управлять доступами.
- Для RuStore важны Android-сборка, карточка приложения, проверка разработчика и готовность быстро отвечать на замечания.
- App Store и Google Play внимательно смотрят на приватные данные, платежи, разрешения, тестовые доступы и заявленные функции.
- Скриншоты и описание влияют не только на модерацию, но и на установку: это первая продающая страница продукта.
Что подготовить перед отправкой
| Зона | Что подготовить | Почему это тормозит релиз |
|---|---|---|
| Аккаунты | Apple Developer, Google Play Console, кабинет RuStore, роли команды | Без владельца и доступов невозможно отправить или обновить приложение |
| Сборка | Подписанный Android-файл, iOS-сборка, номер версии, тестовые каналы | Ошибка подписи или версии часто обнаруживается только при загрузке |
| Карточка | Название, описание, категория, иконка, скриншоты, возрастные ограничения | Модерация и пользователи должны понимать, что делает приложение |
| Данные | Политика конфиденциальности, сбор данных, разрешения, удаление аккаунта | Магазины проверяют соответствие заявленных данных фактическому поведению |
| Тест | Тестовый аккаунт, платежные сценарии, демо-данные, инструкции для проверяющего | Если проверяющий не сможет пройти сценарий, приложение могут вернуть |
| Релиз | Страна, этапный выпуск, поддержка, аналитика, план первого обновления | После публикации нужно видеть ошибки и быстро реагировать |
Чем RuStore отличается в плане работ
Документация RuStore для разработчиков показывает, что публикация складывается из проверки разработчика, подготовки приложения, карточки и отправки на модерацию. Для владельца продукта это означает простую вещь: RuStore нельзя оставлять на "после Google Play".
Нужно заранее решить:
- кто создает и подтверждает аккаунт разработчика;
- кто владеет ключом подписи Android-приложения;
- кто готовит описание, скриншоты и возрастную анкету;
- кто отвечает на замечания модерации;
- как будут выходить обновления после первого релиза.
Если приложение уже есть в Google Play, это помогает, но не отменяет отдельной подготовки карточки и проверки. Если приложения еще нет, лучше сразу строить релизный процесс под несколько магазинов: единая версия, единая аналитика, единый план исправлений, но отдельные материалы и требования для каждой площадки.
App Store: на что смотрит проверка
У Apple есть подробные App Review Guidelines. Для нетехнического владельца продукта важнее всего не выучить правила, а проверить сценарии, которые чаще всего создают вопросы.
Если в приложении есть регистрация, нужен тестовый аккаунт. Если есть покупка цифрового контента, подписка или доступ к функциям, нужно заранее разобраться с правилами покупок внутри приложения. Если собираются данные, нужно заполнить сведения о приватности и не обещать меньше, чем приложение реально собирает.
Отдельно проверьте удаление аккаунта. Для продукта с личным кабинетом, платным доступом, медицинскими, финансовыми или образовательными данными это не мелочь, а часть доверия. Если пользователь может зарегистрироваться, он должен понимать, как выйти из системы, удалить аккаунт и куда обратиться по данным.
Есть идея приложения и нужен трезвый следующий шаг?
Разобрать идею приложенияGoogle Play: что важно не забыть
Google Play требует подготовить карточку, политику, сведения о данных, возрастные ограничения, тестирование и соответствие правилам. В разделе правил Google Play есть отдельные темы по данным, контенту, платежам и безопасности.
Для нового проекта особенно важно заранее проверить:
- целевой уровень Android API и совместимость устройств;
- разрешения, которые приложение запрашивает у пользователя;
- форму безопасности данных;
- тестовые каналы и доступ проверяющих;
- платежи и подписки, если они есть;
- страницы поддержки и контакты разработчика.
Не планируйте релиз в день рекламной кампании. Даже если модерация пройдет быстро, вы можете обнаружить ошибки первого запуска: неправильные события аналитики, неработающий платеж, неясный текст на карточке, плохую конверсию скриншотов или падения на конкретной версии Android.
Скриншоты, описание и ASO
Карточка приложения должна отвечать на три вопроса: что это за продукт, кому он нужен и какое действие человек сможет сделать сразу после установки. Для RuStore, App Store и Google Play лучше готовить не случайные красивые экраны, а набор сценариев.
Для приложения записи покажите выбор услуги, календарь, подтверждение и напоминание. Для интернет-магазина — каталог, карточку товара, корзину и оплату. Для онлайн-школы — урок, прогресс, домашнее задание и доступ к материалам. Для сервиса доставки — заказ, статус, карту и поддержку.
Хорошая карточка магазина не должна обещать больше, чем есть в первой версии. Если вы показываете чат, бонусы, подписку или карту, эти функции должны работать в сборке, которую проверяет модерация.
Как Appfyl подходит к публикации
В Appfyl мы не отделяем публикацию от разработки. Когда планируем приложение, сразу отмечаем, какие данные собираются, какие разрешения нужны, как пользователь будет платить, где будет политика конфиденциальности, какие события аналитики докажут успешный запуск и какие скриншоты нужны для карточек магазинов.
Для MVP-проектов Appfyl обычно планирует бюджет в диапазоне 1-1,5 млн рублей. Хорошие средние продукты часто попадают в диапазон 1,5-3,5 млн рублей. Крупные продукты с несколькими ролями, платежами, админ-панелью, интеграциями и несколькими магазинами могут доходить до 3,5-6 млн рублей. Публикация в нескольких магазинах сама по себе не делает продукт огромным, но увеличивает количество проверок, материалов и ответственности.
Если вы еще не уверены, какие функции попадут в первую версию, заполните интерактивный бриф Appfyl и отдельно отметьте, где планируете запуск: App Store, Google Play, RuStore или все площадки сразу.
Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.
Используйте эти выводы, чтобы собрать реалистичную первую версию.
Оценить MVPПревратите исследование в план запуска
Appfyl поможет превратить идею в понятный план приложения, список функций первой версии и план первых работ.
Обсудить план приложенияПолезные ссылки
Частые вопросы
Если российская аудитория важна для бизнеса, RuStore стоит рассмотреть как отдельный канал. Но решение зависит от продукта, аудитории, Android-доли, поддержки и готовности вести еще одну карточку магазина.
Да. Для MVP часто разумно начать с одного основного канала, проверить спрос и только потом расширять публикацию. Но сборку, аналитику и юридические тексты лучше готовить так, чтобы добавление второго магазина не стало переделкой.
Лучше, чтобы аккаунты принадлежали бизнесу. Студия может помогать с настройкой и публикацией, но владелец продукта должен контролировать доступы, юридические данные, платежи и обновления.
Частые причины: неработающий тестовый вход, несоответствие описания функциям, проблемы с приватными данными, неподготовленная политика, спорные платежи, лишние разрешения или ошибки в сборке.
Смотреть аналитику, падения, отзывы, обращения в поддержку и конверсию карточки. Первый релиз — это не конец проекта, а начало наблюдения за реальными пользователями.