Публикация приложения в RuStore: требования, модерация и checklist

Короткий ответ: семь ворот публикации

Рабочая последовательность такова: оформить кабинет на реального издателя и раздать роли; зафиксировать package, сертификат и стратегию версий; загрузить APK или AAB; заполнить карточку, данные и обоснования разрешений; проверить релизную сборку; пройти модерацию; опубликовать и наблюдать production. Если любой этап остаётся «в голове у разработчика», релиз трудно повторить при обновлении или смене команды.

1. Кабинет разработчика и ownership

Регистрация разработчика бесплатна и проходит через VK ID. Доступны аккаунты физического и юридического лица; ИП идёт по сценарию юридических лиц. Для формы юрлица или ИП актуальная справка требует квалифицированную электронную подпись. При этом опубликованный 22 июля 2026 года FAQ отделяет регистрацию от проверки личности: отдельная верификация личности больше не нужна для создания аккаунта, но понадобится при подключении монетизации. Это разные процедуры, их не следует сводить к фразе «верификация обязательна всем».

Новое приложение добавляет пользователь с ролью владельца компании. Загружать версии могут также администратор, релиз-менеджер и разработчик. Значит, подрядчику не нужен пароль от единственного VK ID владельца. Бизнес создаёт кабинет, сохраняет восстановление и юридические данные у себя, затем выдаёт минимально достаточную роль. Владелец, администратор и релиз-менеджер управляют пользователями; после проекта лишние доступы снимают по актуальному реестру.

Представьте обычную передачу разработки: APK лежит в чате, а ключ — на ноутбуке сотрудника. Формально приложение существует, но бизнес не способен безопасно выпустить исправление. Ownership pack должен фиксировать владельцев кабинета, keystore, репозитория, CI, backend/Firebase, домена, почты поддержки и аналитики. Секреты хранятся в контролируемом vault, а документ описывает процедуру доступа, резервное восстановление и ответственного — не раскрывает пароли.

2. Package, signing, version_code и формат сборки

На 30 июля 2026 года RuStore принимает APK и AAB размером до 5 ГБ. Утверждение «только APK» устарело. Для первой загрузки APK требуется уникальное имя пакета, цифровая подпись и проверенная сборка. При загрузке AAB подпись приложения добавляют отдельно по процедуре RuStore — не копируют механику Play App Signing из Google Play.

Для обновления package и сертификат должны совпадать с предыдущей версией, а номер версии быть выше. В Android техническую упорядоченность определяет version_code: красивое изменение versionName для пользователя не исправляет повторяющийся код. После альфа-тестирования код основной версии должен быть выше и публичной, и альфа-сборки. Поэтому номера не назначают вручную в последний момент: CI выдаёт монотонный code, сохраняет mapping «внутренний release ID → store → version_code → checksum» и не переиспользует значение.

Сертификат — часть идентичности приложения. Если обновление подписано другим ключом, Android не установит его поверх существующей версии. RuStore рекомендует один сертификат для всех версий. Замена возможна через поддержку после подтверждения принадлежности, но это не переключатель: после замены версии архивируются, затем их нужно загрузить и опубликовать заново. Безопаснее до первой публикации решить, где хранится keystore, кто имеет доступ, как создан backup и кто проводит ротацию секретов CI.

Обработанный после загрузки файл хранится 14 дней; если не отправить его на модерацию, он удаляется. Это срок хранения артефакта, а не обещание длительности проверки. В release log сохраните имя файла, package, version_code, versionName, формат, checksum, отпечаток сертификата, commit и дату загрузки. Тогда спор «тот ли APK проверяли» решается записью, а не воспоминанием.

3. Требования: что нельзя переносить из другого стора

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

Запрещены незаконные товары и услуги, фишинговые и нерелевантные ссылки, нарушения интеллектуальных прав, ссылки на сторонние магазины и ряд опасного или запрещённого контента. Для пользовательского контента нужна премодерация либо постмодерация по жалобам. Слово «официальный» и заявления о партнёрстве могут потребовать доказательств. Это не место для маркетингового предположения: права на бренд, контент и договорённости подтверждают до отправки.

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

4. Карточка: описание, изображения и контакты

Название ограничено 30 символами и должно быть уникальным; краткое описание — 80, подробное — 4000 символов. В подробном описании указывают только доступную на момент публикации функциональность. Обязательны категория, возрастное ограничение и хотя бы один контакт разработчика: email, группа VK или сайт. До пяти поисковых тегов и FAQ необязательны. Название установленного приложения и иконка должны совпадать с карточкой.

Мобильные скриншоты обязательны. Для каждого заявленного типа устройства нужны минимум три; одновременно интерфейс позволяет добавить от одного до десяти изображений. Скриншоты показывают реальный актуальный интерфейс, а не набор заставок, баннеров, логина и заглушек. Для телефона принимаются PNG/JPG до 3 МБ, максимальное мобильное разрешение — 2160×3840. Если не приложить отдельные изображения планшета, телефонные будут показаны и там.

В официальных страницах на дату проверки есть расхождение по иконке: инструкция публикации указывает 512×512 и до 3 МБ, общий гайд — квадрат от 32×32 до 512×512 и до 1 МБ. Консервативный preflight: 512×512, 1:1, PNG/JPG, не более 1 МБ, со сплошным фоном; затем проверить текущий валидатор Консоли. Это честнее, чем выбрать удобную цифру и назвать её единственной.

5. Данные, permissions и документы

Для каждой версии заполняют «Категории и типы данных»: перечисляют всё, к чему обращается приложение. Если обнаружены чувствительные permissions, Консоль просит обосновать каждое. Декларируются категории Dangerous, Special и Signature; Normal не декларируются. Разрешения с пометкой Not for use by third-party applications запрещены и приводят к автоматическому отклонению версии.

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

Не переносите автоматически Google Play Data safety или его требования к privacy policy. В изученных актуальных страницах RuStore подтверждены декларация категорий данных и обоснование чувствительных разрешений, но не найдено универсального правила об отдельном URL политики для абсолютно любого приложения. Юридическая обязанность может следовать из закона, типа данных или продукта — её оценивают отдельно. Store checklist не заменяет правовую консультацию.

6. QA релизной сборки и сценария проверки

Проверять нужно именно подписанный артефакт с production-конфигурацией. Минимальный P0 включает чистую установку, запуск, регистрацию или вход, основную бизнес-операцию, восстановление доступа, критичные deep links, push и выход из аккаунта. Для обновления добавьте установку поверх предыдущей публичной версии и проверку миграций. Если есть оплата, камера, геолокация или загрузка файла, прогоните разрешение, отказ и повторный запрос.

Приоритизируйте дефекты просто: P0 блокирует ключевой сценарий или создаёт неприемлемый риск; P1 серьёзно мешает, но имеет обход; P2 не ломает релизный путь. Открытый P0 означает stop независимо от календаря кампании. Подробная матрица есть в чек-листе качества перед релизом, а карта видов тестирования поможет выбрать проверки по риску, не превращая preflight в бесконечный аудит.

Evidence pack содержит запись экрана P0, модель устройства и Android, ожидаемый результат, логи критичных ошибок, checksum сборки и отметку ответственного. Модерация магазина не заменяет QA: она проверяет соответствие площадке, а не весь бизнес-процесс. Хорошая сборка способна пройти модерацию и всё равно упасть на недоступном production API.

7. Модерация, замечания и повторная отправка

После обработки файла и заполнения формы версию отправляют на модерацию. Черновик можно сохранить, обработка продолжается в фоне. Если разрешения вызывают вопросы, RuStore может запросить пояснения по email владельца и контактному адресу аккаунта. Поэтому почта должна принадлежать действующей роли, а письма — попадать в release inbox, а не в забытый ящик подрядчика.

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

После отклонения создайте issue: версия и checksum, точный текст замечания, ссылка на правило, владелец, исправление и новое доказательство. Если проблема в карточке — не пересобирайте код без причины; если в permission — проверьте manifest, поведение и декларацию вместе. Затем повторите затронутый P0 и отправьте исправленную версию. Такой delta-подход уменьшает случайные изменения и сохраняет причинно-следственную связь.

8. Обновления, staged publication и предел rollback

RuStore поддерживает автоматическую и ручную публикацию. Отложенный выход доступен только для обновлений: после модерации версия публикуется в выбранные дату и время. Поэтапная публикация тоже относится к обновлениям; можно выбрать целый процент от 1 до 100 и затем только увеличивать его. Это полезный рычаг снижения охвата ошибки, но не замена мониторингу.

Поэтапную публикацию можно остановить: новая версия деактивируется, последняя активная снова становится активной. Аналогично можно снять обычную текущую версию и активировать прежнюю. Но пользователи, уже установившие неудачное обновление, останутся на нём. Это не удалённый downgrade. Поэтому backend должен поддерживать соседние версии, опасные функции — выключаться feature flag, а команда — иметь готовый hotfix с новым version_code.

Архивированную версию восстановить нельзя. При выпуске новой частичной версии прежняя частичная автоматически архивируется. Version parity между магазинами — не обязательное правило RuStore, а управленческое решение. Практичнее вести единый внутренний release ID и отдельные store-статусы: package, version_code, checksum, signing, feature manifest, карточка, процент и дата. Тогда «версии одинаковые» означает совпадение функций и backend-контракта, а не случайно похожую надпись.

9. Что делать после появления версии

После публикации установите приложение из RuStore на чистое устройство и повторите P0. Проверьте карточку, deep links, вход, основную операцию, server-side события, push и поддержку. Сегментируйте ошибки по version_code, Android, модели и типу установки. Назначьте человека, который может остановить распространение, отключить feature flag и начать hotfix без собрания всей команды.

В Консоли можно читать и фильтровать отзывы, видеть версию, ОС и модель устройства, выгружать данные в CSV и публично отвечать. Ответ разработчика проходит модерацию; после редактирования — повторную. На нарушения можно пожаловаться, но после отклонённой жалобы повторно пожаловаться на ту же публикацию нельзя. Отзывы — слабый ранний сигнал, а не единственная телеметрия: молчаливый сбой входа лучше обнаружить мониторингом, чем ждать оценки пользователя.

Stop conditions фиксируют до релиза: какой сигнал останавливает rollout, кто принимает решение, как проверяют denominator, что сообщает support и по какому доказательству возобновляют выпуск. Завершение релиза — это не статус в Консоли, а подтверждённая установка и рабочий production-сценарий.

Как 13FOX организует публикацию

13FOX публично включает публикацию в магазинах в контур разработки; команда также работала с RuStore и использует review/checklist process. Практическая ценность не в обещании «пройти с первого раза», а в артефактах: ownership map, реестр сборки и подписи, отдельная матрица требований стора, P0 evidence, журнал замечаний и план после выхода. Публичных approval rate или гарантированных сроков для такого опыта нет — мы их не придумываем.

На старте мы отделяем продуктовый блокер от store-задачи. Если падает основной сценарий, неизвестен владелец данных или потерян ключ, красивое описание не решает проблему. Если же продукт готов, delta-аудит показывает конкретные разрывы между APK/AAB, карточкой, permissions и эксплуатационным планом. Посмотреть, как эти решения сочетаются с реальными продуктами, можно в портфолио 13FOX; для оценки полного контура разработки полезен материал о приложении под ключ.

Когда отдельное сопровождение не нужно

Не заказывайте услугу ради кнопки, если кабинет и recovery уже принадлежат бизнесу, signing и CI документированы, команда ведёт RuStore checklist, сверяет данные и permissions, готовит карточку, прогоняет P0 и дежурит после выхода. Для обновления без изменений доступа к данным, критичных SDK и metadata часто достаточно внутреннего delta-preflight.

Сопровождение преждевременно, если приложение нестабильно, права на контент не подтверждены или неизвестно, кто издатель. Сначала закрывают базовый риск. Иногда разумнее выпустить ограниченный продукт, сайт или PWA, если установка из магазина не даёт задаче ценности. 13FOX может рекомендовать более простой формат после разбора входных данных — до оценки нельзя честно обещать цену, срок или необходимость полноценной разработки.

RuStore preflight: карточка, которую можно отдать команде

1. Кабинет: тип издателя, владелец, recovery, роли и рабочие контакты подтверждены.
2. Сборка: package, version_code, checksum, commit и сертификат занесены в release log.
3. Карточка: название, функция, иконка и скриншоты совпадают с релизом.
4. Документы: права, возрастная маркировка, контакты и продуктовые документы актуальны.
5. Данные: SDK, категории данных и чувствительные permissions сверены по сборке.
6. QA: чистая установка, обновление и P0 пройдены на подписанном артефакте.
7. Модерация: inbox, владелец ответа и журнал замечаний назначены.
8. После выхода: мониторинг, stop conditions, feature flags и hotfix готовы.

Официальные источники и дата проверки

Требования проверены 30 июля 2026 года. Интерфейс и правила меняются, поэтому перед каждой отправкой сверяйте текущую Консоль и официальную справку для конкретной версии.

• RuStore: как опубликовать приложение.
• RuStore: требования к приложениям.
• RuStore: подписи APK и AAB.
• RuStore: декларирование разрешений.
• RuStore: автоматическая и ручная публикация.
• RuStore: поэтапная публикация.
• RuStore: работа с отзывами.

FAQ

Можно ли гарантировать срок модерации приложения в RuStore?

Нет. В официальной документации нет общего гарантированного срока модерации. Указание «в течение часа» относится только к появлению версии в RuStore после успешной модерации при автоматической публикации.

RuStore принимает APK или AAB?

На 30 июля 2026 года RuStore принимает APK и AAB размером до 5 ГБ. Для первой версии важны уникальное имя пакета и корректная подпись; для обновления должны совпадать package и сертификат, а version_code должен быть выше.

Можно ли использовать в RuStore ту же сборку, что и в другом магазине?

Часто можно переиспользовать код и подписанный артефакт, если это соответствует стратегии команды. Но карточку, декларации данных, разрешения, требования, version_code и процедуру публикации нужно отдельно сверять с RuStore.

Что делать, если версию отклонили?

Зафиксируйте замечание и версию, найдите расхождение в сборке, карточке, разрешениях или документах, исправьте именно подтверждённую причину, повторите P0-сценарий и отправьте версию заново. Не меняйте одновременно несвязанные части без журнала изменений.

Можно ли откатить неудачное обновление в RuStore?

Можно остановить поэтапную публикацию или вернуть активной последнюю активную версию, но пользователи, уже установившие новую версию, продолжат ей пользоваться. Это не принудительный downgrade, поэтому нужны совместимый backend, feature flags и готовый hotfix.

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

Оно не нужно, если кабинет и ключи контролирует бизнес, команда ведёт отдельный RuStore checklist, умеет сверять permissions и карточку, воспроизводит сборку, проводит P0 QA и дежурит после выхода. Для простого обновления достаточно внутреннего delta-preflight.

Проведём RuStore preflight до отправки

Пришлите тип аккаунта и список ролей, package, version_code, APK/AAB, отпечаток сертификата, перечень SDK и permissions, черновик карточки и P0-сценарий. На первой встрече 13FOX разделит блокеры по ownership, signing, данным, требованиям и QA. На выходе вы получите карту расхождений, приоритеты исправлений и план отправки/наблюдения. Решение и срок модерации остаются за RuStore; наша зона — сделать релиз согласованным и воспроизводимым.

Разобрать публикацию