Нещодавно до нас звернувся клієнт: після викатки 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 релізів щорічно. Отримайте консультацію щодо вашого релізного процесу — оцінимо ваш проект та запропонуємо оптимальне рішення.