Выпуск обновлений мобильного приложения (Major/Minor/Patch)
Жизненный цикл приложения после первого релиза — это непрерывный поток обновлений разного веса. Patch-обновление с хотфиксом нужно выпустить за несколько часов. Major-релиз с новой архитектурой данных требует недель подготовки и поэтапного rollout. Подходить к ним одинаково — значит либо тормозить критические фиксы бюрократией, либо выкатывать большие изменения без нужной подготовки.
Семантика версий в мобильном контексте
Semver (Major.Minor.Patch) в мобильной разработке работает немного иначе, чем в серверном софте. versionName — это маркетинговая строка, которую видит пользователь. versionCode (Android) и CFBundleVersion (iOS) — монотонно возрастающие числа, которые используют сторы для определения «новее/старее». Рассинхронизация между ними — источник реальных проблем.
Patch (x.x.N): Хотфикс краша, правка опечатки, фикс неверного перевода. versionCode инкрементируем, versionName меняем минорно. Для iOS можно использовать CFBundleVersionString без смены CFBundleShortVersionString — но сторы это видят как обновление, ревью всё равно требуется.
Minor (x.N.0): Новая фича, изменение UI, добавление нового экрана. Нет Breaking Changes в схеме данных, нет изменений в API-контрактах. Пользователь обновляется — ничего не ломается.
Major (N.0.0): Изменение схемы локальной БД (Room migration, CoreData migration), смена минимальной версии ОС, рефакторинг с изменением структуры данных в Keychain/SharedPreferences. Здесь нужна миграционная стратегия — данные пользователей, сохранённые старой версией, должны корректно переноситься.
Самая болезненная часть — Major с миграцией данных
Room (Android) и CoreData (iOS) предоставляют механизмы миграции, но они требуют чёткого планирования. Типичная проблема: разработчик добавил поле в entity, увеличил version в @Database, но забыл написать Migration объект — Room выбрасывает IllegalStateException: Room cannot verify the data integrity при запуске у пользователей с предыдущей версией.
Для CoreData аналогичная ошибка — изменить модель без lightweight migration или без явного mapping model. Приложение крашится при запуске на устройствах с существующими данными, хотя на чистой установке работает нормально.
Стратегия для сложных миграций: fallback с fallbackToDestructiveMigrationFrom (Room) только если потеря данных приемлема. В большинстве случаев — написать явную Migration с SQL-скриптом. Тестировать миграцию на реальных данных из предыдущей версии, не только на пустой БД.
Release процесс
Android: Сборка AAB, подпись, загрузка в Play Console. Используем staged rollout — начинаем с 5-10%, мониторим Android Vitals (crash rate, ANR rate) 24 часа, затем расширяем. Для patch-обновлений rollout можно ускорить. Для Major — обязательная пауза на каждом этапе.
iOS: Сборка через Xcode Cloud или Fastlane с gym. Загрузка через Transporter или fastlane deliver. Используем Phased Release (7 дней, по 1-2-5-10-20-50-100%) для minor и major обновлений. Для hotfix — можно запустить без Phased Release, но ревью всё равно займёт своё время.
Автоматизация через Fastlane: lane :release с increment_build_number, тестами, сборкой и загрузкой. CI/CD через GitHub Actions или Bitrise — каждый merge в main после прохождения тестов готовит сборку для TestFlight/Internal Testing.
Что проверяем перед каждым релизом
- Миграции данных протестированы на реальных сценариях апгрейда (не только чистая установка)
-
versionCode/CFBundleVersionбольше предыдущего опубликованного - Release notes написаны на всех поддерживаемых языках
- Проверен backward compatibility с API бэкенда (особенно важно при Major)
- Firebase Crashlytics или Sentry подключены и работают в release-конфигурации
Сроки зависят от типа обновления: patch — один-два дня, minor — три-пять дней, major — одна-три недели с учётом миграционного тестирования.