Публикация в App Store и Google Play

01Версионирование: имя версии и номер сборки

У каждой сборки два числа. Версия для пользователя (на iOS CFBundleShortVersionString, на Android versionName) следует семантическому версионированию: 2.4.0 для релиза с новыми функциями, 2.4.1 для исправления. Номер сборки (на iOS CFBundleVersion, на Android versionCode) нужен сторам и всегда должен расти: Google Play отклоняет versionCode, который уже видел, а App Store Connect требует уникальный номер сборки для каждой версии. Держите один источник истины и позвольте CI увеличивать номер сборки, например по номеру запуска пайплайна. Помечайте git-коммит тегом с версией, чтобы всегда можно было пересобрать то, что лежит в сторе. И помните, что OTA-обновления (если вы их используете) должны быть привязаны к runtime version, чтобы JavaScript-обновление никогда не попало на бинарник с другим нативным кодом.

1// android/app/build.gradle
2android {
3  defaultConfig {
4    versionCode 2041      // integer, must always increase
5    versionName "2.4.1"   // shown to users
6    targetSdk 36          // Play: API 36 for new apps and updates from Aug 31, 2026
7  }
8}
9// iOS (Xcode build settings):
10// MARKETING_VERSION = 2.4.1       -> CFBundleShortVersionString
11// CURRENT_PROJECT_VERSION = 2041  -> CFBundleVersion

02Подпись: сертификаты и профили iOS, keystore Android

Подпись доказывает, что сборка сделана вами и не была изменена. На iOS нужны членство в Apple Developer Program, App ID (bundle identifier), сертификат распространения (приватный ключ в вашем keychain или в CI) и provisioning profile, который связывает сертификат, App ID и capabilities (push, Sign in with Apple, associated domains). Автоматическая подпись в Xcode подходит небольшим командам; в CI обычно используют fastlane match или учётные данные EAS, чтобы безопасно ими делиться. На Android вы подписываете сборку upload key из файла keystore; с Play App Signing (обязательно для новых приложений, которые выпускаются как AAB-бандлы) настоящий ключ подписи приложения хранит Google и переподписывает сборки. Если вы потеряете upload key, можно запросить его сброс; без Play App Signing потеря ключа означала, что приложение больше никогда нельзя обновить. Никогда не коммитьте keystore или пароли в git; храните их в менеджере секретов или в секретах CI.

1# Create an Android upload key (keep the file and passwords in a secret store)
2keytool -genkeypair -v -keystore upload-key.jks -alias upload \
3  -keyalg RSA -keysize 2048 -validity 10000
4 
5# Build a signed Android App Bundle
6cd android && ./gradlew bundleRelease
7 
8# iOS: archive and upload with fastlane (certificates via match)
9bundle exec fastlane ios beta

03Тестовые треки: TestFlight и тестирование в Play

Никогда не отправляйте в продакшен сборку, которую реальные люди не устанавливали через собственный конвейер стора. На iOS загрузите сборку в App Store Connect и используйте TestFlight: внутренние тестировщики (члены вашей команды) получают сборки почти сразу; внешние тестировщики (до 10,000, по email или публичной ссылке) требуют короткого бета-ревью для первой сборки версии. Сборки истекают через 90 дней. На Android в Play Console есть internal testing (быстро, до 100 тестировщиков), closed testing (списки или группы) и open testing. Обратите внимание: новые личные аккаунты разработчиков должны провести закрытый тест как минимум с 12 тестировщиками, участвующими 14 дней подряд, прежде чем смогут запросить доступ к продакшену; аккаунты организаций от этого освобождены. Тестируйте release-сборку, а не только debug: минификация, подпись, push и deep links часто ведут себя по-другому.

• Тестируйте обновление с предыдущей версии из стора, а не только чистую установку
• Проверяйте push, deep links, платежи и вход на release-сборке
• Держите наготове аккаунт для ревью/демо с примерами данных

04Страницы в сторах и информация о приватности

Страница в сторе продаёт приложение и заодно заявляет факты, которые сторы проверяют. Нужны название, подзаголовок/короткое описание, описание, ключевые слова (iOS), скриншоты для обязательных размеров устройств, иконка, категория, анкета возрастного рейтинга, URL поддержки и URL политики конфиденциальности. Оба стора требуют раскрытия информации о приватности: «этикетки» App Privacy от Apple и форма Data safety в Google Play должны соответствовать тому, что на самом деле собирают приложение и его SDK (аналитика, отчёты о падениях, платежи). На iOS приложения и сторонние SDK должны включать privacy manifests с описанием использования данных и API с «required reason». Если приложение отслеживает пользователей в приложениях или на сайтах других компаний, нужно использовать App Tracking Transparency. Локализуйте страницы для каждого целевого рынка. Готовьте скриншоты с реальной сборки на реалистичных, неперсональных демо-данных.

05Правила ревью и частые причины отказов

Apple проверяет каждую версию по App Review Guidelines; Google сочетает автоматические проверки с ревью на соответствие политикам. Большинство отказов предсказуемы. Падения или сломанные сценарии во время ревью. Отсутствие демо-аккаунта или экран входа, который ревьюеры не могут пройти. Создание аккаунта без возможности удалить его внутри приложения (Apple этого требует). Вход через сторонние соцсети без равноценного варианта с упором на приватность, такого как Sign in with Apple. Продажа цифровых товаров или подписок в обход in-app purchase там, где он обязателен (физические товары и реальные услуги, например заказ еды, используют обычных платёжных провайдеров). Запросы разрешений без понятных purpose strings. Контент-заглушки, битые ссылки или приложение, которое является просто обёрткой над сайтом. Этикетки приватности, не соответствующие SDK. Отвечайте спокойно и по существу в Resolution Center; многие отказы снимаются объяснением или коротким видео.

• Предоставьте рабочий демо-аккаунт и заметки для ревьюера
• Дайте возможность удалить аккаунт внутри приложения, если пользователи могут его создавать
• Пишите конкретные purpose strings для разрешений (камера, геолокация, фото)
• Держите сборки для стора на актуальных SDK: Apple и Google ежегодно поднимают минимальные требования

06Поэтапные rollout, хотфиксы и OTA-обновления

Не выпускайте релиз сразу на 100%. На iOS Phased Release распределяет автоматические обновления на семь дней (1%, 2%, 5%, 10%, 20%, 50%, 100%) и может быть поставлен на паузу; пользователи всё равно могут обновиться вручную. В Google Play staged rollout позволяет выбрать процент и увеличивать его или остановить, если Crashlytics показывает всплеск. Перед каждым шагом смотрите на crash-free users, ключевые воронки и сообщения в поддержку. На случай аварий держите ветку для хотфиксов и запросы на ускоренное ревью (используйте их экономно), плюс kill-switches в Remote Config. OTA-обновления (EAS Update или self-hosted аналоги; сервис CodePush от Microsoft был закрыт вместе с App Center в 2025) заменяют JavaScript-бандл и ассеты без ревью в сторе. Они отлично подходят для небольших исправлений, но не могут менять нативный код, должны соответствовать runtime version бинарника и не должны менять основное назначение приложения — правила сторов по-прежнему действуют. OTA-обновления тоже выкатывайте постепенно.

07CI-пайплайн, который собирает, подписывает и загружает

Ручные релизы ломаются скучным образом: не та scheme, истёкший сертификат на одном ноутбуке, забытый номер сборки. Перенесите весь путь в CI. Для iOS fastlane match хранит сертификаты и профили в зашифрованном виде в приватном репозитории, а CI забирает их только для чтения; ключ App Store Connect API заменяет вход через личный Apple ID и запросы двухфакторной аутентификации. Для Android CI расшифровывает upload keystore из секрета, собирает AAB и загружает его во внутренний трек. Номера сборок берутся из номера запуска пайплайна, коммит помечается тегом, а job сохраняет артефакты сборки и файлы символов. За людьми остаются решения, требующие суждения, — продвижение в production и увеличение процента раскатки, — а машины выполняют каждый повторяемый шаг.

1# fastlane/Fastfile
2platform :ios do
3  lane :beta do
4    setup_ci
5    app_store_connect_api_key(key_id: ENV["ASC_KEY_ID"], issuer_id: ENV["ASC_ISSUER_ID"],
6                              key_content: ENV["ASC_KEY_P8"])
7    match(type: "appstore", readonly: true)
8    increment_build_number(build_number: ENV["CI_RUN_NUMBER"])
9    build_app(scheme: "MyApp", export_method: "app-store")
10    upload_to_testflight(skip_waiting_for_build_processing: true)
11  end
12end
13 
14platform :android do
15  lane :internal do
16    gradle(task: "bundle", build_type: "Release", project_dir: "android")
17    upload_to_play_store(track: "internal", aab: lane_context[SharedValues::GRADLE_AAB_OUTPUT_PATH])
18  end
19end

08Требования платформ меняются каждый год

Оба стора поднимают минимальные требования в ежегодном ритме, и релиз может заблокировать правило, не имеющее никакого отношения к вашей функции. Apple: с 28 апреля 2026 App Store Connect принимает только сборки, сделанные в Xcode 26 с iOS 26 SDK или новее; privacy manifest и заявленные причины использования чувствительных API проверяются при загрузке. Google: новые приложения и обновления должны таргетировать API 36 с 31 августа 2026, а приложения, таргетирующие Android 15 или выше, должны поддерживать страницы памяти размером 16 KB — значит, нативные библиотеки, включая те, что внутри зависимостей React Native, должны быть собраны с учётом этого. Планируйте фиксированное окно обновлений каждый год (Xcode, Android Gradle Plugin, React Native, SDK), а не узнавайте о правиле во время срочного hotfix, и подпишитесь на новости для разработчиков от Apple и Google.

09Что сторы делают с вашим бинарником

На Android вы загружаете App Bundle, а не APK. Google Play разбивает его на APK под каждую конфигурацию устройства — архитектуру CPU, плотность экрана, язык — и подписывает их ключом app signing, поэтому пользователи скачивают только то, что нужно их устройству. bundletool позволяет воспроизвести эти APK локально и протестировать ровно то, что установит устройство. На iOS App Store Connect обрабатывает загрузку, а App Thinning создаёт варианты под конкретные устройства; отчёт о размере в App Store Connect показывает реальные размеры загрузки и установки по устройствам. Размер влияет на конверсию, особенно в мобильном интернете: следите за нативными библиотеками, встроенными шрифтами и изображениями и неиспользуемыми локалями. Оба стора также запускают автоматические проверки при загрузке — использование приватных API, отсутствующие purpose strings, проблемы privacy manifest, target SDK, — и эти сообщения приходят по email, так что кто-то должен их читать.

1# Reproduce what Play would install on the connected device
2bundletool build-apks --bundle=app-release.aab --output=app.apks --connected-device
3bundletool install-apks --apks=app.apks
4 
5# Check which certificate signed an APK
6apksigner verify --print-certs app.apk
7 
8# Fingerprints of your upload key (needed for API consoles and resets)
9keytool -list -v -keystore upload-key.jks -alias upload

10OTA-обновления: runtime version, каналы и откат

OTA-обновление безопасно только тогда, когда оно попадает на бинарник ровно с тем нативным кодом, которого ожидает. EAS Update отслеживает это через runtime version. Политика appVersion привязывает её к версии приложения: это просто, но ломается, если кто-то меняет нативный код, не повышая версию; политика fingerprint хэширует нативный проект, поэтому любое нативное изменение автоматически даёт новый runtime — ценой более частых сборок для стора. Сборки слушают канал (production, staging), привязанный к ветке обновлений, поэтому обновление можно протестировать на staging-сборках, прежде чем направить на него production. Раскатывайте постепенно по проценту, следите за crash-free users и держите путь отката: повторно опубликуйте предыдущее обновление или откатитесь к обновлению, встроенному в бинарник. Подписывайте обновления (code signing), чтобы скомпрометированный сервер не мог отправить произвольный код.

1# app.json (expo): runtime changes whenever native code changes
2# "runtimeVersion": { "policy": "fingerprint" }
3 
4# Publish to 10% of production users first
5eas update --branch production --message "Fix checkout crash" --rollout-percentage 10
6 
7# Increase, finish or revert the rollout
8eas update:edit
9eas update:revert-update-rollout
10 
11# Emergency: send clients back to the code embedded in the binary
12eas update:roll-back-to-embedded