Обновление приложения без публикации в сторе возможно, но только для части изменений. OTA-обновления «по воздуху» позволяют за минуты заменить код на JavaScript или Dart в приложениях на React Native и Flutter, а удалённая конфигурация — включить или выключить функцию без новой сборки. Изменения нативного кода, новых разрешений и SDK всё равно идут через ревью App Store и Google Play. Ниже сравниваем оба пути по скорости, ограничениям правил Apple и Google и рискам и показываем, как выпустить исправление быстро в любом случае.
- Обычный релиз через стор — универсальный путь, хотфикс можно отправить на ревью за сутки.
- OTA подходит для исправлений в логике и интерфейсе на JS или Dart, но не для нативного кода.
- Правила сторов запрещают менять через OTA основное назначение приложения и обходить ревью.
- Самый безопасный быстрый инструмент — флаги функций и удалённая конфигурация, заложенные заранее.
Как устроено обычное обновление через App Store и Google Play
Стандартный путь выглядит так: разработчик исправляет код, собирает новую версию, отправляет её в App Store Connect и Google Play Console, площадки проверяют сборку, после одобрения обновление становится доступным пользователям. Дальше каждый пользователь должен его установить — вручную или через автообновление.
Ревью Apple обычно занимает 24–48 часов, для критичных исправлений можно запросить ускоренную проверку. В Google Play проверка часто проходит быстрее, но сроки тоже не гарантированы. Поэтому от момента, когда ошибка найдена, до момента, когда исправление у большинства пользователей, проходит от суток до нескольких дней.
Главный плюс этого пути — он подходит для любых изменений: нативный код, новые SDK, разрешения, обновление под новую версию ОС. Главный минус — скорость: вы не контролируете ни время ревью, ни то, когда пользователь нажмёт «Обновить».
Что такое OTA-обновления приложения
OTA — over-the-air, обновление «по воздуху». Приложение при запуске проверяет, есть ли на сервере новая версия кода, скачивает её и применяет при следующем открытии. Без стора, без ревью, без участия пользователя.
Это работает потому, что в кроссплатформенных приложениях значительная часть логики и интерфейса написана не на нативном языке, а на JavaScript (React Native) или Dart (Flutter). Нативная «оболочка» остаётся прежней, а меняется только слой поверх неё. Для React Native есть Expo EAS Update, для Flutter — Shorebird. Нативные приложения на Swift и Kotlin так обновлять нельзя: любое изменение кода требует новой сборки.
Важная деталь: OTA-обновление привязано к версии нативной сборки. Если пользователь давно не обновлял приложение из стора, у него стоит старая оболочка, и новое OTA-обновление может ей не подойти. Поэтому сервис обновлений ведёт несколько каналов под разные версии сборки, а команда следит, чтобы изменения в JS или Dart не требовали нативных библиотек, которых в старой оболочке нет. Без этой дисциплины OTA превращается из ускорителя в источник падений у части аудитории.
| Параметр | Релиз через стор | OTA-обновление | Удалённая конфигурация |
|---|---|---|---|
| Скорость | От суток с учётом ревью | Минуты после выпуска | Мгновенно |
| Что можно изменить | Всё | Код на JS или Dart, ресурсы | Только заранее заложенные параметры |
| Нативный код и SDK | Да | Нет | Нет |
| Ревью площадки | Обязательно | Нет, но в рамках правил сторов | Нет |
| Откат | Новый релиз и новое ревью | Быстро, на прошлую версию | Мгновенно |
Обновление приложения без модерации: что разрешают правила Apple и Google
OTA — не способ обойти ревью. Правила Apple допускают загрузку интерпретируемого кода, если он не меняет основное назначение приложения, не добавляет функций, которые не прошли бы проверку, и не обходит механизмы безопасности. У Google Play похожая логика: приложение не должно обновлять себя в обход Play, кроме кода, который выполняется в интерпретаторе или виртуальной машине и соответствует политикам площадки.
На практике это значит: исправить ошибку в форме, поправить текст, изменить вёрстку экрана, починить расчёт в корзине через OTA можно. Добавить новый раздел с оплатой, изменить работу с персональными данными или превратить приложение доставки в приложение для ставок — нельзя. Формулировки правил меняются, поэтому сверяйте актуальную редакцию App Store Review Guidelines и политик Google Play на дату выпуска.
ПРАВИЛОOTA — для исправлений, а не для новых функций. Всё, что меняет суть приложения, должно пройти ревью.
Плюсы и минусы OTA для бизнеса
- Исправление доходит до пользователей за минуты, а не дни
- Не нужно ждать, пока пользователь обновит приложение вручную
- Быстрый откат, если исправление оказалось неудачным
- Можно выпускать на часть аудитории и проверять
- Работает только для кроссплатформенных приложений и только для слоя JS или Dart
- Нужна инфраструктура: сервис обновлений, подпись, контроль версий
- Ошибочное OTA-обновление ломает приложение у всех так же быстро
- Риск претензий от сторов, если использовать OTA для новых функций
Выпускать OTA-обновления без тестирования, «потому что быстро». Скорость работает в обе стороны: ошибка, которая раньше дошла бы до пользователей через ревью за пару дней, теперь появляется у всех через минуты. OTA требует той же проверки, что и обычный релиз, плюс отлаженного отката.
Удалённая конфигурация и флаги функций
Есть третий путь, о котором вспоминают реже, хотя он самый безопасный. Если заранее заложить в приложение флаги функций и удалённые параметры, например через Firebase Remote Config, можно без новой сборки отключить сломанный экран, скрыть способ оплаты, который перестал работать, поменять текст баннера или порог бесплатной доставки.
Это не исправляет ошибку, но мгновенно останавливает её последствия, пока исправление идёт через стор. Для приложений, которые принимают заказы и оплаты, такой «рубильник» на ключевых функциях окупается при первом же серьёзном сбое. Заложить его проще при разработке, чем добавлять потом, но и на работающем приложении это задача на несколько часов пакета, а не отдельный проект.
Как быстро выпустить исправление приложения: наш порядок
Независимо от того, есть ли в приложении OTA, скорость исправления определяет не технология, а процесс. В поддержке мобильных приложений он выглядит так:
- Узнаём о сбоеCrashlytics или Sentry с алертами дежурному и мониторинг отзывов в сторах. Часто раньше, чем вы.
- Берём в работу за 4 часаКритичный сбой — приложение падает, не проходит оплата или вход — инженер берёт в работу и сообщает срок.
- Снимаем последствияЕсли есть флаги функций, отключаем проблемный сценарий, пока готовим исправление.
- Выпускаем исправлениеЧерез OTA, если это допустимо, или хотфиксом в сторы за сутки с запросом ускоренного ревью.
- Разбираем причинуВ ежемесячном отчёте — что случилось и как это предотвратить.
Ключевую роль играет CI/CD: сборки создаются и уходят в TestFlight и Google Play Internal автоматически, поэтому хотфикс не зависит от того, свободен ли конкретный разработчик с нужным ноутбуком. Мы настраиваем это на этапе подключения к поддержке. Если приложение уже на нашем сопровождении и развивается спринтами, об устройстве релизного процесса можно прочитать на странице поддержки и доработки мобильных приложений.
Что выбрать для вашего приложения
- В приложении подключён мониторинг падений с алертами
- Сборки и отправка в сторы автоматизированы через CI/CD
- На оплате, входе и оформлении заказа есть флаги функций
- Для кроссплатформенного приложения оценена возможность OTA
- Есть отработанный откат на прошлую версию
- Понятно, кто и за сколько часов берёт критичный сбой в работу
Если приложение нативное, ставку делайте на CI/CD, флаги функций и ускоренное ревью — OTA вам недоступно. Если на React Native или Flutter, OTA добавляет скорость, но только вместе с тестированием и правилами, что через него выпускать можно, а что нельзя. Подробнее о том, во что обходится такая поддержка в месяц, — в статье «Сколько стоит поддержка мобильного приложения после запуска».
Если ошибка уже есть, а команды нет, начните с разового исправления: мы делаем срочное исправление ошибок в приложениях на Flutter и нативных с бесплатной диагностикой и фиксированной ценой до старта. А для постоянной работы подключайте сопровождение приложения по SLA: мониторинг, обновления под новые ОС и хотфиксы за сутки — от 150 000 ₸ в месяц.
Можно ли обновить приложение без App Store и Google Play?
Частично. Кроссплатформенные приложения на React Native и Flutter можно обновлять по воздуху на уровне JS или Dart. Нативный код, новые SDK и разрешения обновляются только через стор.
Разрешает ли Apple OTA-обновления?
Правила допускают загрузку интерпретируемого кода, если он не меняет основное назначение приложения и не обходит ревью. Формулировки меняются, сверяйте актуальную редакцию правил на дату выпуска.
Как быстро можно выпустить хотфикс через стор?
Мы берём критичный сбой в работу за 4 часа и отправляем исправление в сторы за сутки. Ревью Apple обычно занимает 24–48 часов, ускоренное — быстрее.
Что делать, если приложение нативное?
Автоматизировать сборки через CI/CD, заложить флаги функций на ключевых сценариях и запрашивать ускоренное ревью для критичных исправлений.
