Чтобы обновить приложение в сторах, поднимите номер версии и номер сборки, соберите релиз, загрузите его в App Store Connect и Google Play Console, добавьте текст «Что нового» и пройдите модерацию. Затем включите поэтапный раскат: сначала обновление получают 5–10% пользователей, и только после проверки стабильности — все остальные.

Почему обновления — это часть продвижения, а не рутина

Алгоритмы App Store и Google Play учитывают «свежесть» приложения. Продукт, который не обновлялся полгода, постепенно теряет позиции в поиске стора, а на устройствах с новыми версиями iOS и Android начинает работать нестабильно. Регулярный релиз раз в 4–6 недель — это сигнал алгоритму, что приложение живо, и одновременно повод напомнить о себе пользователям через раздел «Что нового».

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

Версионирование: как нумеровать релизы правильно

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

Семантическое версионирование (X.Y.Z)

Для пользовательской версии мы используем схему «мажор.минор.патч»:

  • Мажор (2.0.0) — редизайн, новая бизнес-логика, изменения, которые пользователь заметит сразу;
  • Минор (2.3.0) — новая функция: онлайн-оплата, тёмная тема, новый раздел;
  • Патч (2.3.1) — исправления багов и мелкие улучшения без новых функций.

Такая схема дисциплинирует команду и помогает поддержке: когда пользователь пишет «у меня версия 2.3.1», сразу понятно, какой набор функций у него на руках.

Номер сборки: versionCode и CFBundleVersion

В Google Play за уникальность релиза отвечает versionCode — целое число, которое обязано расти с каждой загрузкой. В App Store ту же роль играет CFBundleVersion (build number). Стор отклонит сборку с уже использованным номером, поэтому удобно автоматизировать инкремент в CI/CD — это исключает человеческую ошибку, из-за которой релиз «застревает» на этапе загрузки.

Важный нюанс Google Play: откатить versionCode назад невозможно. Если вы загрузили сборку с номером 100 даже в закрытое тестирование, следующая публичная версия должна иметь номер выше.

Чеклист перед загрузкой обновления

Перед каждым релизом мы проходим короткий, но обязательный список:

  • Доступы к консолям. Проверьте, что сертификаты iOS не истекли, а у команды есть права на публикацию. Если аккаунты оформлялись давно или сторонним подрядчиком, разберитесь с этим заранее — как устроены аккаунты разработчика Apple и Google, мы разобрали отдельно;
  • Регрессионное тестирование. Минимум — критические сценарии: регистрация, оплата, push-уведомления, основной пользовательский путь;
  • Скриншоты и метаданные. Если интерфейс изменился, старые скриншоты в сторе вводят пользователей в заблуждение и снижают конверсию страницы;
  • Возрастной рейтинг. Добавили чат, пользовательский контент или ссылки на соцсети — заново пройдите анкету, иначе возможен реджект. Подробности — в статье про возрастной рейтинг приложения;
  • Минимальные версии ОС и SDK. Google Play ежегодно поднимает требования к target API — релиз на устаревшем SDK просто не пройдёт;
  • Миграции данных. Обновление не должно стирать локальные данные пользователя: проверьте сценарий «обновился со старой версии», а не только чистую установку.

Поэтапный раскат: страховка от провального релиза

Поэтапный раскат (staged rollout) — главный инструмент управления риском. Смысл простой: обновление получает не вся аудитория сразу, а небольшой процент. Если в течение 24–48 часов метрики стабильны, охват расширяется.

Google Play: ручное управление процентом

В Google Play Console вы сами задаёте долю аудитории — мы обычно начинаем с 5–10%. Дальше следим за разделом Android Vitals: доля крэшей и ANR не должна расти относительно прошлой версии. Если всё чисто — поднимаем до 25%, 50% и 100%. Если появился критический баг, раскат можно остановить кнопкой Halt: те, кто уже обновился, останутся на новой версии, но остальные её не получат, и вы спокойно готовите исправление.

App Store: семидневный phased release

У Apple механика автоматическая. Включённый phased release раскатывает обновление за 7 дней по нарастающей: 1% → 2% → 5% → 10% → 20% → 50% → 100% пользователей с автообновлением. Процесс можно поставить на паузу (суммарно до 30 дней) или досрочно выкатить на всех. Важно помнить: пользователь, который сам зайдёт на страницу приложения, сможет обновиться вручную в любой день — phased release управляет только автообновлениями.

Что мониторить во время раската

  • crash-free rate в Crashlytics или Sentry — падение ниже 99% на старте раската означает проблему;
  • ключевые продуктовые события: оплаты, регистрации, заказы — баг не всегда проявляется крэшем;
  • свежие отзывы в обоих сторах — пользователи сообщают о проблемах быстрее любых дашбордов;
  • нагрузку на бэкенд: новая версия может изменить частоту запросов к API.

Текст «Что нового»: описание обновления, которое читают

Раздел «Что нового» видят два типа читателей: пользователи, решающие, обновляться ли вручную, и потенциальные клиенты, изучающие страницу перед установкой. Для вторых история релизов — индикатор того, что продукт развивается.

Принципы, которых мы придерживаемся:

  • Конкретика вместо шаблона. «Исправили ошибки и улучшили стабильность» — текст, который не говорит ничего. Лучше: «Исправили ошибку, из-за которой не приходило уведомление о статусе заказа»;
  • Главное — в первых двух строках. На странице стора текст обрезается, и большинство не нажимает «ещё»;
  • Язык пользы, а не задач разработки. Не «обновили библиотеку платежей», а «оплата картой стала проходить быстрее»;
  • Локализация. Для рынка Казахстана готовим текст на русском и казахском, для зарубежных версий — на английском. Несовпадение языка релиз-ноута и аудитории заметно бьёт по доверию;
  • Ключевые слова — аккуратно. В Google Play текст «Что нового» индексируется, поэтому уместное упоминание функций помогает видимости. Но это не место для спама ключами.

Сроки модерации и стоимость обновлений в Казахстане

Модерация Apple в 2026 году занимает в среднем 24–48 часов, у Google — от пары часов до 1–3 дней; первые релизы и приложения с платежами проверяются дольше. Закладывайте запас: релиз «к акции в пятницу» нужно отправлять на ревью минимум во вторник.

Ориентиры по стоимости работ для рынка Казахстана:

Тип обновления Что входит Стоимость, ₸
Патч / hotfix Исправление бага, пересборка, публикация в оба стора от 60 000
Плановое минорное обновление Обновление SDK, мелкие функции, тексты «Что нового», скриншоты 150 000 – 400 000
Крупный релиз Новый модуль или редизайн, регрессионное тестирование, поэтапный раскат с мониторингом от 800 000
Ежемесячная поддержка Регулярные релизы, мониторинг крэшей, ответы на отзывы, соответствие новым требованиям сторов 150 000 – 450 000 / мес

Вилки зависят от стека (нативный код дороже кроссплатформы в поддержке двух платформ), объёма тестирования и наличия CI/CD. Если приложение разрабатывали мы, инфраструктура релизов настраивается ещё на этапе разработки мобильного приложения — тогда каждое обновление выходит быстрее и дешевле.

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

  • Релиз сразу на 100% аудитории. Любой пропущенный баг мгновенно затрагивает всех — и рейтинг падает раньше, чем вы успеете собрать hotfix;
  • Релиз в пятницу вечером. Если проблема всплывёт в выходные, чинить её будет некому, а модерация исправления займёт ещё сутки;
  • Принудительное обновление без необходимости. Жёсткий force update оправдан только при критических уязвимостях или несовместимости с API — в остальных случаях он раздражает;
  • Игнорирование старых версий. Часть аудитории живёт на версии годичной давности: ломая обратную совместимость API, вы ломаете приложение у этих людей;
  • Молчание в ответ на отзывы после релиза. Ответ разработчика на негатив о новой версии часто превращает одну звезду в четыре — пользователи правят оценки чаще, чем принято думать.

Частые вопросы

Как часто нужно обновлять приложение?

Оптимальный ритм — раз в 4–6 недель. Это поддерживает позиции в поиске сторов, позволяет вовремя закрывать уязвимости и адаптироваться к новым версиям iOS и Android. Реже допустимо для простых приложений, но пауза больше 4–6 месяцев уже воспринимается алгоритмами и пользователями как признак заброшенного продукта.

Можно ли откатить обновление, если что-то сломалось?

Прямого отката нет ни в одном сторе. В Google Play можно остановить поэтапный раскат, в App Store — поставить phased release на паузу, но пользователи с новой версией останутся на ней. Единственное решение — срочно выпустить исправляющую сборку. Именно поэтому раскат на малый процент аудитории обязателен.

Нужно ли заново проходить модерацию при каждом обновлении?

Да, каждая сборка проходит ревью. У Apple это обычно 24–48 часов, у Google — от нескольких часов до трёх дней. Метаданные (описание, скриншоты, текст «Что нового») тоже проверяются. Если обновление добавляет новые типы контента или функций, может потребоваться обновить анкету возрастного рейтинга и раздел о конфиденциальности данных.

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

Внимательно прочитать причину реджекта: в 2026 году чаще всего это устаревший target SDK в Google Play, проблемы с описанием сбора данных и нарушения правил платежей. Исправьте конкретное замечание и отправьте сборку повторно — повторное ревью обычно проходит быстрее. Спорные решения Apple можно оспорить через Resolution Center.

Сколько стоит поддержка приложения в Казахстане?

Регулярная поддержка с плановыми релизами, мониторингом крэшей и работой с отзывами стоит от 150 000 до 450 000 ₸ в месяц в зависимости от сложности продукта. Разовый hotfix — от 60 000 ₸. Applications.kz берёт на поддержку и приложения, разработанные другими командами: проводим аудит и готовим смету за 24 часа — +7 (707) 928-13-15.