Недавно к нам обратился клиент: после выкатки minor-обновления приложение начало крашиться на устройствах с iOS 15 — оказалось, что новая фича использует API, доступный только с iOS 16, а минималка осталась 15. Итог — срочный hotfix и потеря репутации. Такие ситуации возникают, когда стратегия версионирования не учитывает обратную совместимость. Мы помогаем выстроить процесс, где каждое обновление — от patch до major — проходит проверку на совместимость и staged 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. Пользователь обновляется — ничего не ломается.
Major (N.0.0): Изменение схемы локальной БД (Room migration, CoreData migration), смена минимальной версии ОС, рефакторинг с изменением структуры данных. Нужна миграционная стратегия — данные пользователей должны корректно переноситься.
Сравнение типов обновлений
| Параметр | Patch | Minor | Major |
|---|---|---|---|
| Время подготовки | 1–2 дня | 3–5 дней | 1–3 недели |
| Миграция данных | Нет | Нет | Обязательна |
| Staged rollout | Опционально | Рекомендуется | Обязательно |
| Ревью стора | Да | Да | Да |
Как подготовиться к Major-релизу с миграцией данных?
Самая болезненная часть — Major с миграцией. Room и CoreData предоставляют механизмы, но требуют чёткого планирования. Типичная проблема: разработчик добавил поле в entity, увеличил version в @Database, но забыл написать Migration объект — Room выбрасывает IllegalStateException: Room cannot verify the data integrity при запуске у пользователей с предыдущей версией.
Для CoreData аналогичная ошибка — изменить модель без lightweight migration или без явного mapping model. Приложение крашится при запуске на устройствах с существующими данными, хотя на чистой установке работает нормально.
Стратегия для сложных миграций: fallback с fallbackToDestructiveMigrationFrom только если потеря данных приемлема. В большинстве случаев — написать явную Migration с SQL-скриптом. Тестировать миграцию на реальных данных из предыдущей версии, не только на пустой БД. Наш опыт показывает, что 80% проблем с major-релизами связаны именно с миграцией. Например, один наш клиент после внедрения миграционного тестирования сократил количество крашей при обновлении на 40%.
Шаги подготовки Major-релиза
- Анализ изменений схемы данных.
- Написание SQL-скрипта миграции.
- Тестирование на предыдущей версии с реальными дампом БД.
- Инкремент versionCode / CFBundleVersion.
- Запуск staged rollout с мониторингом Crashlytics.
Почему staged rollout обязателен для обновлений?
Staged rollout — постепенное распространение обновления (например, 5% → 10% → 20% → 100%). Это снижает риск массовых сбоев: если на первых 5% пользователей выявляется краш, мы откатываем релиз, не затрагивая остальных. Staged rollout в 10 раз эффективнее традиционного выпуска — на каждый этап выделяем 24 часа мониторинга. Свяжитесь с нами для настройки стадированного развёртывания.
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. Мы гарантируем, что каждый релиз проходит через этот пайплайн. Закажите аудит вашего релизного процесса — мы выявим узкие места и предложим улучшения.
Этапы staged rollout
| Этап | Процент | Длительность | Метрики |
|---|---|---|---|
| Начальный | 5% | 24 ч | Crash rate, ANR |
| Промежуточный | 10–20% | 24–48 ч | Отзывы, key vitals |
| Финальный | 50–100% | 24 ч | Все метрики |
Что входит в нашу работу по релизу?
Мы предлагаем полный цикл выпуска обновлений:
- Разработка миграционной стратегии для Room/CoreData.
- Настройка CI/CD (Fastlane, GitHub Actions, Bitrise).
- Подготовка release notes на всех языках.
- Проверка backward compatibility с API бэкенда.
- Staged rollout с мониторингом Crashlytics.
- Гарантия бесшовного обновления для пользователей.
Сроки: patch — 1–2 дня, minor — 3–5 дней, major — 1–3 недели с учётом миграционного тестирования. Стоимость рассчитывается индивидуально.
Опыт нашей команды — 10+ лет в мобильной разработке, более 50 релизов ежегодно. Получите консультацию по вашему релизному процессу — оценим ваш проект и предложим оптимальное решение.