Публикация Android-приложения в RuStore: полный гайд

После ухода Google Play многие разработчики столкнулись с необходимостью публиковать приложения в RuStore. RuStore — официальный магазин приложений для Android в России, но он предъявляет собственные технические требования: APK вместо AAB, обязательная поддержка 64-битной архитектуры, отсутствие ссылок на Google Play. Для push-уведомлений и встроенных покупок нужна интеграция фирменных SDK — RuStore Push и RuStore Billing. По данным официальной статистики RuStore, более 60% Android-устройств в России не имеют Google Play Services, поэтому переход на RuStore — не просто альтернатива, а необходимость для охвата аудитории. Наши клиенты экономят на комиссии до 50%: при 10 000 покупок по 100 ₽ экономия составит 150 000 ₽ в год. Мы помогаем пройти этот путь: от регистрации аккаунта до успешной модерации. Оцените наш подход — мы гарантируем прохождение модерации с первого раза.

Требования к APK для RuStore

RuStore принимает только APK (AAB не поддерживается). Основные требования:

Приложение не должно содержать ссылок на Google Play или политики Google — это автоматическое нарушение при модерации. Если в коде есть прямые URL вида https://play.google.com/store/apps/details?id=... — их нужно убрать или заменить условной логикой. RuStore запрещает использование любых сервисов Google, включая Google Maps, FCM и Google Sign-In. Для карт можно использовать Яндекс.Карты или OpenStreetMap, для авторизации — VK ID или Сбер ID.

Почему RuStore выгоднее для монетизации?

RuStore поддерживает In-App Purchases через RuStore Billing SDK. Комиссия — 15%, что вдвое ниже 30% у Google. При среднем чеке 500 ₽ экономия с каждой покупки — 75 ₽. Эквайринг — через российские платёжные системы (Сбербанк, Тинькофф), что критично для приложений, которым недоступен Google Pay. RuStore не требует отдельного кабинета для выплат — все транзакции отображаются в Developer Console.

Как интегрировать RuStore Push SDK?

Если приложение использует push-уведомления, нужна интеграция с RuStore Push SDK. На устройствах без Google Play Services (а таких в России становится всё больше) FCM не работает. RuStore Push SDK работает на любых устройствах под управлением Android, независимо от сервисов Google.

// build.gradle (app)
implementation 'ru.rustore.sdk:pushclient:2.1.0'

// Инициализация в Application.onCreate()
RuStorePushClient.init(
    application = this,
    projectId = "your_project_id",  // Из Developer Console
    logger = DefaultLogger("RuStorePush")
)

// Обработчик push-сообщений
class MyPushService : RuStoreMessagingService() {
    override fun onNewToken(token: String) {
        // Отправить token на свой сервер
        sendTokenToServer(token)
    }

    override fun onMessageReceived(message: RemoteMessage) {
        // Показать уведомление
        showNotification(message.notification?.title, message.notification?.body)
    }
}

Регистрация сервиса в AndroidManifest:

<service
    android:name=".MyPushService"
    android:exported="true">
    <intent-filter>
        <action android:name="ru.rustore.sdk.pushclient.MESSAGING_EVENT" />
    </intent-filter>
</service>

Если приложение уже использует FCM — оба SDK можно использовать одновременно, маршрутизируя по наличию GMS/RuStore на устройстве. Однако для упрощения кода рекомендуем полностью перейти на RuStore Push SDK.

Как интегрировать RuStore Billing SDK?

Добавьте зависимость ru.rustore.sdk:billingclient:3.0.0 в build.gradle. Инициализируйте RuStoreBillingClient с контекстом и ключом проекта. Используйте методы purchase, consume и acknowledge для работы с покупками. API схож с Google Play Billing Library, поэтому миграция обычно занимает 1–2 дня.

Особенности модерации в RuStore

RuStore проверяет:

• Наличие Privacy Policy с актуальным URL
• Соответствие описания реальному функционалу
• Отсутствие запрещённого контента по российскому законодательству (ФЗ-149, ФЗ-436)
• Для приложений с push-уведомлениями — отдельная проверка на наличие пользовательского соглашения

Финансовые приложения, медицинские сервисы и приложения для детей проходят расширенную проверку с дополнительными документами. Типичный срок модерации — 1–3 рабочих дня. Результат приходит на email, указанный при регистрации. Если модерация не пройдена, в письме указывается причина — чаще всего это отсутствие политики конфиденциальности или несоответствие описания. Мы помогаем исправить замечания и пройти повторную проверку без доплат.

Как избежать отклонения при модерации?

• Проверьте, что Privacy Policy доступна по прямой ссылке и не содержит ссылок на Google.
• Убедитесь, что в приложении нет скрытого функционала, не описанного в листинге.
• Если приложение запрашивает опасные разрешения (камера, микрофон, контакты), обоснуйте это в описании.
• Для приложений с детским контентом предоставьте сертификат соответствия.

Процесс публикации

1. Регистрация и верификация. Создание аккаунта разработчика на rustore.ru/develop, предоставление документов. Занимает 1–5 дней.
2. Подготовка APK. Анализ кодовой базы, удаление зависимостей от Google Play, сборка APK с правильной подписью.
3. Интеграция SDK. Подключение RuStore Push SDK и Billing SDK, тестирование на эмуляторе и реальных устройствах.
4. Заполнение листинга. Составление описания, загрузка иконок, скриншотов, загрузка APK.
5. Модерация. Отправка на проверку, отслеживание статуса, исправление замечаний при необходимости.
6. Публикация и поддержка. После публикации — мониторинг отзывов, обновление версий, помощь в исправлении ошибок.

Что входит в наши услуги по публикации

• Помощь в регистрации и прохождении верификации
• Адаптация кода: удаление зависимостей от Google Play, замена на аналоги
• Интеграция RuStore Push SDK и Billing SDK под ключ
• Подготовка пакета документов для модерации (Privacy Policy, соглашения)
• Тестирование на реальных устройствах и в среде RuStore
• Поддержка после публикации: обновление версий, устранение ошибок

Наш опыт: более 5 лет разработки Android, 50+ успешно опубликованных приложений в RuStore и других магазинах. Мы сертифицированные специалисты по мобильной разработке и знаем все тонкости модерации RuStore. Получите консультацию по вашему проекту — мы оценим сложность и подготовим коммерческое предложение в течение дня.

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

Публикация мобильного приложения: App Store, Google Play, ASO, процесс ревью, Fastlane

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

Почему App Store отклоняет приложения? Реальные причины

Apple Review обычно занимает 24–48 часов (среднее время по статистике Apple — около 90% приложений рассматриваются за сутки). Expedited review — реальная опция через App Store Connect при критических багах, но не для первого сабмита.

Частые причины отклонения, которые съедают время:

• Guideline 2.1 — App Completeness. Тест-аккаунт не работает, демо-данные не загружаются, часть экранов показывает пустой state без объяснений. Ревьюер видит сломанное приложение. Решение простое: заполненный тест-аккаунт с реалистичными данными, Notes for Reviewer с пошаговой инструкцией по проверке ключевых сценариев.

• Guideline 4.3 — Spam. Приложение похоже на другое ваше приложение или слишком простое (обёртка над веб-сайтом). Это одна из самых субъективных причин. Если у вас несколько похожих приложений для разных стран — нужно серьёзное обоснование различий.

• Guideline 5.1.1 — Data Collection and Storage. Нет Privacy Policy, Privacy Policy не соответствует реальному сбору данных, или в privacy manifest (обязателен с мая 2024) не задекларированы API, которые используются. Privacy Manifest — PrivacyInfo.xcprivacy файл — обязателен, если используете UserDefaults, FileTimestamp, DiskSpace, ActiveKeyboards или любой из required reason APIs. Apple начала отклонять без него в текущем цикле.

• Guideline 3.1.1 — Business — Payments. Внешние ссылки на оплату там, где должен быть IAP. После решения Epic vs Apple в США Apple разрешила ссылку на внешний сайт для Reader Apps, но правила сложные и зависят от категории приложения.

Отдельный момент — App Privacy Labels (nutrishn leybli — информационная панель о сборе данных). Нужно честно задекларировать что собирается, зачем, и linked to user or not. Ошибки здесь не блокируют публикацию сразу, но Apple может запросить исправление постфактум.

Как избежать отклонения по 5.1.1? Инструкция

Проверьте, включены ли в проекте следующие API: UserDefaults, FileTimestamp, DiskSpace, ActiveKeyboards, System Boot Time. Если да — обязательно добавьте PrivacyInfo.xcprivacy с указанием reasons. Шаблон можно взять из документации Apple. Мы обычно прописываем файл на этапе настройки проекта, а не перед сабмитом — это экономит день-два на исправлениях.

Google Play: автоматизация и скрытые сюрпризы

Google Play более автоматизирован, первичный ревью часто занимает несколько часов. Но есть нюансы.

• Target SDK level — Google регулярно повышает требования. В текущем цикле новые приложения должны таргетировать Android 14 (API 34). Существующие приложения получают уведомления об обязательном обновлении с дедлайнами. Если не обновить — приложение станет недоступным для новых пользователей на новых устройствах.

• 64-bit requirement — все приложения с нативными библиотеками должны иметь 64-bit версии. Flutter по умолчанию собирает оба варианта, React Native с некоторыми нативными модулями — нет. Проверяйте заранее, иначе придётся пересобирать бинарники.

• Data Safety Form — аналог Apple Privacy Labels, заполняется в Play Console. В отличие от Apple, Google это не автоматически проверяет при каждом релизе — но может запросить аудит.

• Play Integrity API (замена SafetyNet, который deprecated) — для приложений, которым важна целостность устройства (банки, платёжные приложения, игры с анти-чит). Требует сервера для верификации токена.

Что делать, если приложение сняли с публикации на третий день?

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

ASO: App Store Optimization

ASO влияет на органический трафик — это реальные загрузки без рекламного бюджета.

Ключевые факторы ранжирования в App Store и Google Play:

• Название приложения — самый весомый фактор. Ключевые слова в названии работают лучше всего. Ограничение: App Store — 30 символов, Google Play — 50.

• Ключевые слова (App Store) — поле 100 символов, только для App Store, не отображается пользователям. Без пробелов после запятых (экономит символы), не дублируйте слова из названия.

• Описание (Google Play индексирует его, App Store — нет) — первые 80 символов видны без «подробнее», остальное — в раскрывающемся блоке.

• Визуальные материалы — иконка, скриншоты, preview-видео. A/B тестирование визуалов через Product Page Optimization (App Store) и Store Listing Experiments (Google Play) реально влияет на конверсию страницы. Разница между плохим и хорошим скриншотом — 15–30% конверсии.

• Рейтинг и отзывы — алгоритм учитывает свежесть, а не только среднее. Активная работа с отзывами (ответы) сигнализирует платформе об активном приложении. SKStoreReviewRequest.requestReview() (iOS) и ReviewManager.requestReview() (Android) — запрашивайте отзыв в правильный момент: после позитивного события, не при первом запуске.

Fastlane: автоматизация публикации

Ручная публикация — сертификаты, provisioning profiles, сборка, загрузка в App Store Connect или Google Play Console — занимает час и легко ошибиться. Fastlane автоматизирует весь пайплайн.

Ключевые lanes:

• match — управление сертификатами и provisioning profiles через зашифрованный Git-репозиторий. Вся команда использует одни сертификаты, нет проблем «сертификат истёк на машине разработчика». fastlane match appstore — синхронизация перед сборкой.

• gym (build) — fastlane gym --scheme "AppName" --configuration Release --export_method app-store. Через Gymfile параметры фиксируются в репозитории.

• deliver (upload to App Store) — загружает бинарник, метаданные, скриншоты. Скриншоты можно держать в репозитории через fastlane snapshot (автоматическая генерация через XCUITest).

• supply — аналог deliver для Google Play, поддерживает all tracks (internal, alpha, beta, production) с rollout параметром для поэтапного выкатывания.

Типичный Fastfile:

lane :release_ios do
  match(type: "appstore")
  gym(scheme: "App")
  deliver(submit_for_review: true, automatic_release: false)
end

lane :release_android do
  gradle(task: "bundle", build_type: "Release")
  supply(track: "production", rollout: "0.1")
end

Интеграция с CI/CD: Fastlane + GitHub Actions или Bitrise — стандартный стек. Переменные среды для API ключей App Store Connect и Google Service Account. Код подписывается автоматически при мерже в main.

Поэтапный выкат и rollback

Google Play поддерживает постепенное развёртывание: rollout: "0.05" — 5% пользователей получают обновление сначала. Мониторим Crashlytics/Firebase Crashlytics, crash-free rate, ANR rate. Если показатели ухудшились — останавливаем rollout через Play Console без отзыва релиза.

App Store не имеет поэтапного выкатывания для обычных приложений (есть Phased Release для app updates — 7-дневный постепенный выкат). Для более гибкого управления используем feature flags (Firebase Remote Config, LaunchDarkly) — новый функционал выключен по умолчанию, включаем через конфиг без нового релиза.

Что входит в работу по публикации

Мы готовим полный комплект для выхода в сторах:

• Создание и настройка аккаунтов разработчика (Apple Developer Program, Google Play Console) с корпоративными доступными.
• Подготовка метаданных: название, описание, ключевые слова, категория, возрастной рейтинг.
• Настройка Privacy Policy и App Privacy Labels / Data Safety Form.
• Генерация и установка сертификатов, provisioning profiles (через match или вручную).
• Сборка и подпись бинарника с правильной конфигурацией (Code Signing, ProGuard/R8).
• Загрузка бинарника и метаданных с помощью Fastlane или вручную.
• Прохождение ревью: анализ тикетов, апелляции при необходимости, корректировка.
• Настройка поэтапного выката и мониторинг метрик после релиза.
• Обучение команды работе с TestFlight / Firebase App Distribution.

Что мы не делаем

Не пишем код приложения, не занимаемся маркетингом (кроме ASO-рекомендаций), не регистрируем торговые марки. Наша зона — техническая подготовка к публикации и сопровождение до первого релиза.

Сроки и стоимость

Подготовка первого релиза: настройка аккаунтов, сертификатов, метаданных, скриншотов, Privacy Policy — от 3 до 5 рабочих дней при наличии всех материалов. Настройка Fastlane + CI/CD — от 2 до 3 дней. Ревью App Store — от 1 до 3 дней. Итого от готового приложения до публикации — от 1 до 2 недель.

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

Типичные ошибки, которые мы находим на аудите

Почему стоит доверить публикацию нам?

У нас 7+ лет опыта в мобильной разработке, более 50 успешно опубликованных приложений для iOS и Android. Знаем все подводные камни App Store Review Guidelines (разделы 4.2, 5.1) и политик Google Play. Используем Fastlane, CI/CD, автоматические проверки метаданных — чтобы вы не тратили время на рутину. Закажите консультацию — расскажем, как сократить цикл публикации вдвое.