Всем привет! Apple удалила «РСХБ Онлайн» из App Store в 2022 году. С тех пор мы выпустили пять новых iOS-приложений — «Учёт надоя», «Ягодный фест», «АгроСкан», «PRO Зерно» и «ПРО Жарка». Каждое рано или поздно удаляли. И каждый раз перед нами вставала одна и та же задача: перевести клиентскую базу со старого приложения на новое. Без App Store. Без возможности обновить бинарник. Без push-уведомлений в устаревшем клиенте.

Я Кирилл Адещенко, в прошлой статье я делился кейсом публикации мобильного банковского приложения РСХБ в условиях ужесточения правил магазинов приложений и санкционных ограничений. В этой статье буду говорить про миграцию: как технически и организационно переселять людей, когда главный канал дистрибуции у тебя отобрали, а клиенты цепляются за привычное.

Зачем вообще мигрировать?

Вопрос не такой очевидный, как кажется. Старое приложение удалили из App Store, ну и что? Оно же установлено на телефонах, оно работает. Клиент заходит, видит свои счета, делает переводы. Зачем его тащить в новое приложение?

Но это по сути замороженный продукт. Приложение, которое нельзя обновить, — это состояние банка на момент удаления из стора. Банк после этого момента не остановился: запускаются новые кредитные продукты, появляются инвестиционные сервисы, меняются клиентские пути, обновляется дизайн. Всё это попадает в актуальное приложение. А клиент на старой версии живёт в прошлом, он пользуется банком образца того дня, когда Apple нажала кнопку «удалить». Чем больше времени проходит, тем больше разрыв между тем, что банк умеет, и тем, что видит этот клиент.

Упущенная выручка уже не абстрактная потеря. Клиент в старом приложении не видит предодобренного кредита, который ему могут выдать. Не видит возможности открытия нового вклада с повышенной ставкой. Не может воспользоваться сервисом, который банк запустил месяц назад. Аудитория есть, десятки, сотни тысяч активных пользователей, а продавать им новые продукты ты не можешь. И эта ситуация длится не неделю, а месяцами, пока тянется миграция.

Нагрузка на разработчиков. Бэкенд развивается, API меняется. Каждое живое старое приложение — это набор эндпойнтов, которые нужно поддерживать, тестировать, не ломать при обновлениях. Когда у тебя одно актуальное приложение и одно предыдущее, это терпимо. Когда параллельно живут четыре версии клиента на разных архитектурах, это уже ощутимая нагрузка на команду. Разработчики тратят время не на новые фичи, а на то, чтобы старый код не упал.

Почему миграция между iOS-приложениями не так проста

Когда Google убирает Android-приложение из Play Store, ты можешь раздать APK и обновить клиент самостоятельно. На iOS всё иначе. Приложение установлено на устройстве, работает, но обновить его ты не в состоянии. Пользователь об удалении из стора не знает, пока не столкнётся с проблемой. Из приложения ему не напишешь — push-сертификаты привязаны к аккаунту разработчика, который может быть заблокирован.

Получается тупик: старое приложение живёт на телефонах клиентов, ты видишь их в аналитике, но достучаться до них средствами самого приложения не можешь. А новое приложение лежит в App Store (пока лежит), но клиент о нём не знает.

Когда мы столкнулись с этим впервые, просто выпустили новое приложение и стали информировать. Результат — аудитория разделилась пополам. Половина перешла, а половина осталась на старом клиенте. Через полгода удалили и новое,  и теперь у нас три группы клиентов в трёх разных приложениях. Стало очевидно, что просто выпустить новое — это не миграция. Это расслоение аудитории. Настоящая миграция требует технических механизмов, организационной машины и способа заставить человека действовать.

Первый и самый болезненный урок: монолитное нативное приложение стало ловушкой в условиях санкций. Когда весь продукт зашит в бинарник, каждая смена приложения — это обнуление. Новый клиент, новая авторизация, потерянные настройки.

Вывод, к которому мы пришли: чем больше продуктовой логики живёт вне бинарника, тем дешевле и мягче каждая следующая миграция. Мы перешли к гибридной модели: мобильное приложение — это контейнер, оболочка. Внутри — web-модули на React микрофронтах, связь между слоями через iFrame и PostMessage. Значительная часть клиентских путей переехала в PWA.

Что это даёт для миграции? Клиент переходит на новое приложение, а внутри видит привычный интерфейс. Контейнер другой, начинка та же — люди перестали чувствовать разрыв. Это сильно повлияло на конверсию: люди перестали бояться «нового приложения», потому что внутри оно не было новым. Ещё важный момент: PWA часть продукта обновляется без пересборки бинарника. Даже если App Store завтра снова выкинет наше приложение, клиенты в текущем приложении продолжат получать обновления.

Коммуникационная машина: big bang вместо последовательности

Миграция — это не только push клиента из старого приложения, но и pull в новое. А pull — это коммуникация. На первых приложениях мы включали каналы информирования по очереди: сначала SMS, потом сайт, потом отделения. Это было ошибкой. Клиент получал SMS, переходил на сайт,  а там ещё старая информация. Звонил в контакт-центр, оператор не в курсе. Разрыв в коммуникации создавал недоверие.

К «Ягодному фесту» мы отладили другой подход: одновременный запуск по всем каналам. Мы называем это big bang. Все каналы включаются в один момент: SMS, email, сторис и баннеры в интернет-банке (отдельно для физлиц, отдельно для юрлиц — у них разные ДБО), IVR в контакт-центре, скрипты операторов, чат-бот, сайт, все коммуникации банка. Всё сразу.

Координировать это непросто. Каждый материал проходит согласование, у разных каналов разные владельцы, у SMS отдельный бюджетный цикл. Но когда клиент видит одно и то же сообщение везде — в приложении, по SMS, на сайте, в Telegram, он верит. Без единства коммуникации мигрирует заметно меньше.

Как заставить пользователя перейти: «окирпичивание»

Вы можете написать идеальный deeplink, сделать бесшовную авторизацию в новом приложении, подготовить красивый лендинг. Но если человеку и так нормально в старом приложении, он не сдвинется. Мы это проверяли: SMS, push, баннеры в интернет-банке. Конверсия есть, но медленная. А время работает против тебя: чем дольше живёт старый клиент, тем сильнее фрагментация и тем больше ресурсов уходит на его поддержку.

Самый мощный инструмент миграции мы нашли не в коммуникации, а на бэкенде. Мы назвали это «окирпичивание». Работает так: меняем ответы сервера на часть REST-запросов. Пользователь старого приложения открывает его и видит пустой главный экран — счета, вклады, кредиты не подгружаются, баланс нулевой. Приложение формально работает, но делать в нём нечего. На экране остаётся только сторис «старое приложение больше не поддерживается» и баннер со ссылкой на новое.

Фактически мы управляем клиентским приложением через серверные ответы, без обновления бинарника. Для пользователя это выглядит однозначно: старое сломалось, вот ссылка на новое. Те, кто не разобрался сам, звонят в контакт-центр — операторы объясняют и помогают установить.

Цифры: после включения блокировок дневная аудитория старых приложений падала на 85–90%. Ни один другой канал не давал такой конверсии. SMS-рассылка на всю базу с прямой ссылкой работала в разы слабее.

Селективная блокировка: не всех сразу

Первую массовую блокировку мы включили на «Ягодном фесте». Работала отлично — аудитория переехала быстро. Но обнаружился побочный эффект: определённая категория клиентов, скажем так, не привыкла к тому, что их банковское приложение вдруг перестаёт работать. Это создало напряжение, которое вышло за рамки продуктовой команды.

Урок: блокировать всех разом рискованно. Но и без блокировки миграция тормозится.

На следующем приложении, «АгроСкане», мы перешли к селективной модели. Обычных клиентов блокируем, для чувствительного сегмента делаем исключения. Технически это фильтр на уровне бэкенда: по сегменту клиента определяется, какой набор ответов он получает.

Такой подход сложнее в реализации, но снимает организационные риски. Команда перестала мыслить бинарно «блокировать или не блокировать» и начала работать с сегментами. По факту это стандартный feature-flag, только применённый не к фиче, а к целому приложению.

Собственная дистрибуция: жизнь без App Store

Одна из ключевых находок: ты можешь строить дистрибуцию iOS-приложения, вообще не имея его в App Store. Началось это стихийно на «Учёте надоя». Новость о выпуске приложения подхватили СМИ и Telegram-каналы: банк с аграрным профилем выпускает «Учёт надоя» с коровой на иконке, рынок отреагировал бурно.

Apple удалила его через три дня. Но к тому моменту больше сотни тысяч человек уже авторизовались, и меньше трети из них пришли через App Store. Остальные через альтернативные каналы. Мы сохраняли IPA-сборки, использовали временные Apple ID, в отделениях ставили ноутбуки с внутренним софтом для установки приложения на устройство клиента. Звучит архаично, но для аудитории в регионах это работало лучше любого маркетинга.

Сейчас собственные каналы дают порядка тысячи установок и авторизаций в день, когда приложения нет в App Store. Основные источники — отделения банка и контакт-центр. App Store, когда доступен, даёт мощный буст. Но мы больше не парализованы без него — и это принципиальное отличие от ситуации 2022 года.

Цена миграции

У миграции есть стоимость, и она не сводится к бюджету на SMS.

SMS-рассылки. Когда запускаешь новое приложение раз в год, затраты на SMS по всей базе терпимы. Но когда это происходит каждые несколько месяцев, суммы складываются в серьёзный бюджет. Мы замерили: блокировка старого приложения даёт конверсию в миграцию кратно выше, чем SMS, — и она бесплатна. Начиная с «АгроСкана» мы стали сознательно сокращать объёмы SMS и перекладывать нагрузку на блокировку. У этого есть ограничение — работает только на активной аудитории. Если клиент заходит в приложение раз в месяц или реже, он не увидит «кирпич» вовремя. Для таких остаётся email и собственныеканалы банка.

Нагрузка на контакт-центр. Каждое включение блокировки — это всплеск звонков. Клиент открывает привычное приложение, видит пустой экран и сразу звонит. В первые дни после включения «кирпича» нагрузка на КЦ вырастает заметно. Операторы должны быть готовы: обновлённые скрипты, понимание ситуации, умение провести клиента через установку нового приложения. Если КЦ не подготовлен, звонки превращаются в негатив, а не в миграцию. Мы закладываем рост нагрузки в план каждого запуска и заранее согласовываем с КЦ усиление на первую неделю.

Упущенная выручка. Пока клиент использует старое приложение, он не видит новых продуктов, разделов, предложений — всего того, что живёт в PWA-слое и доступно только в актуальном контейнере. Это не абстрактная потеря: новые клиентские пути, кредитные продукты, инвестиционные сервисы — всё это монетизируется. Чем дольше тянется миграция, тем больше выручки банк недополучает с аудитории, застрявшей на устаревшей версии.

Репутационные риски. Миграция — это момент, когда банк просит клиента что-то сделать. Причём не один раз, а регулярно. Каждая смена приложения — это повод для недовольства: «опять всё поменяли», «куда делось моё приложение», «я никому не доверяю, это мошенники». Особенно остро это работает с аудиторией, которая не читает банковские рассылки и узнаёт о смене приложения по факту, когда старое перестаёт работать. В соцсетях и на отзовиках каждая миграция оставляет след. Мы научились с этим работать: заранее готовим ответы на негатив, мониторим площадки в первые дни, подключаем SMM. Но полностью избежать репутационных потерь при шести миграциях за четыре года невозможно. Можно только минимизировать.

Стоимость поддержки старых версий. Есть ещё один неочевидный расход. Пока старые приложения живы, их нужно поддерживать. Бэкенд обслуживает несколько версий API, команда тратит время на совместимость, тестирование учитывает всех живых клиентов. Чем быстрее завершается миграция, тем раньше можно отключить старые эндпоинты и высвободить ресурсы.

Три фазы подготовки к миграции

За шесть итераций процесс подготовки выкристаллизовался в три фазы. Делюсь, потому что это можно переиспользовать.

Фаза 1 — до модерации Apple. Пока сборка проходит ревью, параллельно идёт оргработа. Готовим все коммуникационные материалы: сторис и баннеры для ДБО, тексты SMS, email, обновление сайта. Обновляем скрипты контакт-центра и IVR. Если этого не сделать, в день релиза операторы отвечают «я не в курсе» и клиент теряет доверие. Готовим Apple ID для установки без стора. Проектируем экран блокировки для старых приложений — дизайн и текст «кирпича».

Фаза 2 — после публикации. Приложение в App Store, клиенты ещё не знают. Скорость решает всё. Подготавливаем короткую ссылку для SMS (она ведёт прямо на приложение, каждый лишний клик убивает конверсию). Обновляем push-сертификаты. И запускаем все каналы информирования одновременно — тот самый big bang.

Фаза 3 — тиражирование. Самая длинная фаза. Включаем блокировку старых приложений (селективно). Отделения начинают активную установку. Контакт-центр обрабатывает входящий поток. На этой фазе происходит 70–80% миграции.

Весь чеклист по фазам разбит по ролям и срокам, с точками синхронизации между командами. Когда знаешь, что через три месяца будешь делать это снова, готовишься иначе.

Что мы поняли за шесть миграций

За четыре года и шесть циклов мы набили достаточно шишек, чтобы сформулировать несколько принципов.

Во-первых, миграция — это не техническая задача, а продуктовая. Deeplink и бесшовная авторизация — это минимум. Настоящая работа в том, чтобы у клиента в каждой точке контакта был ответ на вопрос «зачем мне переходить».

Во-вторых, архитектура определяет стоимость миграции. Если это монолитный клиент, каждая миграция болезненна.  Если контейнер с web-начинкой, оболочка меняется, продукт внутри остаётся. Мы пришли к этому не от хорошей жизни, но это оказалось правильным решением и без санкционного контекста.

В-третьих, App Store —это  буст, а не фундамент. Пока он доступен, отлично, оттуда идёт трафик. Но строить процесс в расчёте на его доступность, значит каждый раз проходить через кризис при удалении. Мы строим так, будто его нет. Когда он есть, это бонус.

Самым сильным инструментом миграции для нас стал контроль над старым приложением через бэкенд. Никакая рассылка не сравнится с ситуацией, когда привычное приложение перестаёт показывать данные. Но пользоваться этим нужно аккуратно, используя сегментацию и исключения.