Что такое фрагментация версий и почему она неизбежна

Не все пользователи обновляют приложение сразу после выхода релиза. Часть отключила автообновление, часть откладывает из-за ограниченного трафика или хранилища, часть просто не замечает уведомления об обновлении.

В результате через 3–6 месяцев после крупного релиза активная аудитория типичного e-commerce приложения может выглядеть так:

Версия 6.2 (текущая):  55% активных пользователей
Версия 6.1:            25%
Версия 6.0:            12%
Версия 5.x и старше:    8%

Последние 8% — потенциальная проблема при каждом изменении API.

Последствия для разработки и продукта

Поддержка API. Пока на старой версии есть активные пользователи, соответствующий эндпоинт нельзя выключить. Это накапливает технический долг: команда поддерживает несколько версий API параллельно.

Rollout фич. Новая персонализация, новый дизайн карточки товара, новый сценарий онбординга — всё это видит только аудитория на актуальной версии. Метрики по новым фичам смешиваются с аудиторией старых версий.

Баги старых версий. Crash rate, ANR rate, ошибки оплаты в устаревших версиях продолжают влиять на общие метрики качества и рейтинг в Play Store.

Стратегии управления фрагментацией

Стратегия Когда использовать
Soft Update Важные обновления с улучшениями: показывать баннер с предложением обновить
Force Update Критичные изменения безопасности или API: блокировать вход без обновления
Remote Config Небольшие изменения поведения без изменения кода клиента
Feature Flags Новые фичи: включать только для актуальных версий
OTA Update Для React Native / Expo: обновление JS-бандла без релиза в стор

Политика минимально поддерживаемой версии

Зафиксируйте явно: команда поддерживает версии N, N-1 и N-2 (три последних минорных). Всё старше — получает force update экран. Политика должна быть известна команде бизнес-аналитиков: при A/B-тестах новых фич нужно сегментировать аудиторию по версиям.

Важно: force update без предупреждения — частая причина всплеска негативных отзывов в сторе. Даже при критических обновлениях давайте пользователю 24–48 часов после мягкого предупреждения, прежде чем включать жёсткую блокировку.