Всем привет! 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 —это буст, а не фундамент. Пока он доступен, отлично, оттуда идёт трафик. Но строить процесс в расчёте на его доступность, значит каждый раз проходить через кризис при удалении. Мы строим так, будто его нет. Когда он есть, это бонус.
Самым сильным инструментом миграции для нас стал контроль над старым приложением через бэкенд. Никакая рассылка не сравнится с ситуацией, когда привычное приложение перестаёт показывать данные. Но пользоваться этим нужно аккуратно, используя сегментацию и исключения.
Комментарии (33)
andre538
26.05.2026 07:11Взгляд со стороны клиента одного из банков, оказавшихся в такой ситуации: не ставил и не буду ставить однодневных учетов надоя. Пользуюсь старой версией приложения, пока оно работоспособно. От отсутствия рекламных предложений со стороны банка не страдаю. Когда банк отключает старое приложение, поминаю его недобрым словом ("обвожу в кружочек") и перехожу на веб версию. Рано или поздно политика приучения к сомнительным однодневкам сыграет против банков - появится подделка, а пользователь, приученный доверять всякому хламу, ее поставит.
onets
26.05.2026 07:11Вот да, когда началась вся эта канитель - новые странные приложения казались мне банковским скамом. Что интересно - у моего банка оригинальное приложение (я на iOS) проработало очень долго, отваливалась периодически только логин и одна-две функции внутри, ну и пуши.
Потом я все же начал ставить все эти новые приложения, старые не удалял, и пользовался всеми понемногу. И по прошествии времени заметил, что оригинальное приложение было самым удобным и интуитивно понятным. Это что типа аппловские гайды и проверки перед публикацией так влияют?
Ну а сейчас вообще оно ставиться как один большой Iframe (или даже как мини браузер) и просто тупо ведет на веб версию. Никакой апп стор не нужен и работает на полностью зарубежном айфоне в другой стране. Но что интересно - даже предлагает включить Face ID.
zverkov
26.05.2026 07:11...запускаются новые кредитные продукты, появляются инвестиционные сервисы, меняются клиентские пути, обновляется дизайн. Всё это попадает в актуальное приложение. А клиент на старой версии живёт в прошлом...
Спасибо за технические детали. Но как клиент поделюсь: Вы не поверите, как хорошо живётся на старом приложении без отвлекающих баннеров новых ненужных мне услуг. Я являюсь клиентом другого банка с похожей ротацией приложений. Пользуюсь базовой функциональностью, о новой узнаю из рассылок. Тот случай, когда клиент может позволить себе остаться на старом приложении.
Yuriy_krd
26.05.2026 07:11Читая статью, пришла в голову известная фраза: "хотели как лучше, а получилось - как всегда".
Т.е. Вы хотели переводить людей на новые приложения, чтобы не распыляться на поддержку старых (это здраво), НО! Некоторым клиентам не блокируете старые приложения
для чувствительного сегмента делаем исключения. Технически это фильтр на уровне бэкенда: по сегменту клиента определяется, какой набор ответов он получает.
И в чем смысл тогда ваших ковровых блокировок? Если, все равно, приходится поддерживать несколько версий приложения.
kaparray Автор
26.05.2026 07:11Хороший вопрос, тут важно уточнить, что селективность — это не «оставили часть клиентов на старом приложении навсегда», а перенос их миграции в другой канал.
Для чувствительного сегмента работает персональный процесс: с клиентом связывается его менеджер, помогает установить новое приложение, проводит через первый вход. Это дороже массовых блокировок по стоимости касания, но конверсия в итоге сопоставимая, просто растянутая во времени. То есть эти клиенты тоже мигрируют — через несколько недель или месяцев после массового запуска, но мигрируют.
Смысл ковровой блокировки в том, что она за несколько дней снимает основную массу аудитории, и дальше старый API нужно поддерживать уже не для сотен тысяч активных пользователей, а для управляемого хвоста, который к тому же постепенно тает. Поддержка нескольких версий остаётся, но это временная нагрузка с понятным горизонтом, а не вечный долг.
needsomedata
26.05.2026 07:11На сколько же product manager далек от пользователя, если готов окирпичивать приложение для того чтобы показать новые баннеры продуктов и предложений.
kaparray Автор
26.05.2026 07:11Окирпичивание — это не про баннеры. Это единственный доступный инструмент принудительной миграции в условиях, когда у тебя нет доступа к push-уведомлениям, нет возможности обновить бинарник и нет App Store. Все «мягкие» каналы — SMS, email, баннеры в интернет-банке — давали конверсию в разы ниже.
Можно долго рассуждать о близости к пользователю, но если клиент застрял на приложении двухлетней давности — он не видит новых продуктов, не может воспользоваться актуальными предложениями и теряет доступ к функциям, которые уже доступны другим. Небольшое неудобство при переходе — это способ дать клиенту больше, а не меньше.
vvzvlad
26.05.2026 07:11он не видит новых продуктов, не может воспользоваться актуальными предложениями и теряет доступ к функциям, которые уже доступны другим. Небольшое неудобство при переходе — это способ дать клиенту больше, а не меньше.
И вместе с этим “больше” впарить новые рекламные банеры и сторис в приложении.
kaparray Автор
26.05.2026 07:11Честно — да, баннеры и сторис там тоже есть, спорить не буду. Но они идут в комплекте с переводами, вкладами, кредитами и всем остальным. Вопрос не в том, нравятся ли рекламные механики, а в том, что альтернатива — оставить клиента на приложении, которое вообще не развивается и не поддерживается.
Devastator82
26.05.2026 07:11Но они идут в комплекте с переводами, вкладами, кредитами и всем остальным.
Т.е. в старом приложении не было переводов?
Newbilius
26.05.2026 07:11Типичная ситуация: регулятор потребовал, чтоб в формочке перевода или кредита теперь появился новый блок с какими-то предупреждения, "оценивайте свои возможности, ириски". Старое приложение вы обновить не можете, а платить штрафы - наверное не захотите)
lazarus_net
26.05.2026 07:11Вывод, к которому мы пришли: чем больше продуктовой логики живёт вне бинарника, тем дешевле и мягче каждая следующая миграция. Мы перешли к гибридной модели: мобильное приложение — это контейнер, оболочка. Внутри — web-модули на React микрофронтах, связь между слоями через iFrame и PostMessage. Значительная часть клиентских путей переехала в PWA.
А вариант ограничиться web-версией не катит? Поддержка -0, всегда актуальная версия, зависимость от Apple Store -0. Что вы туда такое уникальное впихнуть хотите кроме попытки найти установленный vpn у клиента, что нельзя сделать с помощью обычного web-сайта?
kaparray Автор
26.05.2026 07:11Веб-версия — это не серебряная пуля. Вот конкретные вещи, которые нативное приложение даёт там, где браузер не справляется:
— Push-уведомления на iOS в браузере до сих пор работают хуже, чем в нативе, особенно на старых версиях системы, а наша аудитория далеко не всегда на последней iOS.
— Биометрия (Face ID / Touch ID) в вебе через WebAuthn работает, но с ощутимыми ограничениями по сравнению с нативным Keychain.
— Офлайн-режим и работа в условиях плохого соединения — критично для регионов, где живёт значительная часть нашей аудитории.
— Доступ к камере для сканирования документов, QR-кодов, чеков — в браузере есть, но с заметно худшим UX.
— Доступ к контактам для переводов по номеру телефона — в браузере недоступен совсем.
— Наконец, просто конверсия: пользователь, у которого приложение на главном экране, возвращается чаще, чем тот, кто должен каждый раз вспоминать адрес сайта.
Мы не спорим, что гибридная модель с PWA — это во многом вынужденное решение. Но полностью уйти в веб и потерять всё перечисленное — это не упрощение, а деградация продукта для конкретной аудитории.
lazarus_net
26.05.2026 07:11— Биометрия (Face ID / Touch ID) в вебе через WebAuthn работает, но с ощутимыми ограничениями по сравнению с нативным Keychain.
Я лично не пользуюсь и другим не советую.
— Офлайн-режим и работа в условиях плохого соединения — критично для регионов, где живёт значительная часть нашей аудитории.
Хотелось бы подробностей. Что вы офф Лайн предоставляете? Перевод офф Лайн не работают. Ваш рекламный спам можно закешировать. Плохое соедениение- если клиент скачал большую часть вашего кода на телефон но надо по https загнать минимум информации. Если не рекламное видео.
— Доступ к камере для сканирования документов, QR-кодов, чеков — в браузере есть, но с заметно худшим UX.
Не факт. Опять таки, меньше доступа - меньше дырок.
— Доступ к контактам для переводов по номеру телефона — в браузере недоступен совсем.
Импорт/ экспорт контактов уже не существуют? Плюс не надо вам лезть во все мои контакты чтобы я мог 10-ти людям перевод по номеру телефона послать.
— Наконец, просто конверсия: пользователь, у которого приложение на главном экране, возвращается чаще, чем тот, кто должен каждый раз вспоминать адрес сайта.
Уже писал- можно сохранить сайт как приложение на телефоне. Технологии 2023 года или даже раньше.
В общем - рекламам не лезет, поэтому будем пихать нативное приложение.
warhammerman2
26.05.2026 07:11Как минимум, все эти PWA плохо выглядят и работают. Если мой банк откажется от нативного приложения - откажусь от банка. ВТБ с Аэрофлотов уже так поступили - уж лучше б втихаря приложения выпускали.
annika_spencer
26.05.2026 07:11Зачем вообще мигрировать?
По сути причина тут может быть только одна: чтобы юзер видел новый дезигн. Всё остальное (новые кредитные продукты и т.п.) решается простым добавлением нового элемента в массив, который возвращает эндпоинт
/products?v=uchet.nadoyakaparray Автор
26.05.2026 07:11Не совсем так, и статья как раз подробно объясняет почему.
«Добавить элемент в массив» работает только для продуктов, которые укладываются в существующую архитектуру отображения. Но в статье речь о другом: старое приложение — это замороженный бинарник, который вообще нельзя обновить. Никакой серверный ответ не добавит в него новый клиентский путь, инвестиционный сервис или обновлённый бизнес-процесс оформления кредита — всё это живёт во фронте, а не в данных с бэкенда.
В нашем случае, как и в случае других банков, оказавшихся в похожей ситуации, это напрямую приводит к упущенной прибыли: клиент в старом приложении не видит предодобренного кредита, нового вклада с повышенной ставкой. Это не про дизайн, это про деньги.
И третья причина — нагрузка на разработчиков: каждая живая старая версия — это отдельный набор эндпоинтов, которые нужно поддерживать и не ломать. Когда параллельно живут четыре версии клиента на разных архитектурах, это уже реальная нагрузка на команду.
Дизайн — это видимая верхушка. Настоящие причины — в деньгах, поддержке и том, что бинарник на телефоне пользователя в принципе не обновить.
CitizenOfDreams
26.05.2026 07:11клиент в старом приложении не видит предодобренного кредита
Предодобренный кредит - это когда нажимаешь кнопку "согласен", и у тебя на кредитном счету появляется оговоренная сумма. То, что предлагают российские банки - заполнить в приложении заявку, пойти ногами в отделение и получить совсем другую сумму на совсем других условиях, а то и вовсе отказ - это, извиняюсь, ни хрена не "предодобренный кредит".
Все остальные "выгодные предложения", которые появляются в новых версиях банковских приложений - это такой же бесполезный для клиента мусор. Ну и бонусом приходится привыкать к новому UI, а теперь еще и не забывать каждый раз отключать VPN.
Kenya-West
26.05.2026 07:11Всё, что угодно, лишь бы не развивать веб-версию личного кабинета. Там ведь даже ServiceWorker'а полтора года назад не было, ни пасскеев, ни TOTP. Могли бы уж нанять кого-нибудь, чтобы он из жалости к браузерной версии сделал вам нормальное решение.
Впрочем, ЛК для меня бесполезен теперь. Кто придумал, что после двух неправильных попыток ввода пароля + самостоятельного восстановления + ещё двух неправильных попыток ввода пароля = надо идти пешком до отделения банка и доказывать свою личность там? Для вас привязанные Госуслуги - уже не авторитет?
kaparray Автор
26.05.2026 07:11По веб-версии: мы её развиваем, и PWA, и полный интернет-клиент живы. Но мы — банк для физлиц, и распределение аудитории жёсткое: подавляющее большинство пользователей живёт в мобильном приложении, веб-каналы — это важная, но маленькая доля.
Про блокировку и поход в отделение — понимаю фрустрацию. Это не продуктовая прихоть, а требования по безопасности. Над выбором из более удобных способов восстановления работаем.
lazarus_net
26.05.2026 07:11Вроде как апреле позволяет сохранить иконку приложения на «столе» телефона и оно не будет ничем отличаться от встроенного приложения, но нет- мыши плакали, кололись но продолжали есть кактус
Devastator82
26.05.2026 07:11Будь у ваших продактов чуть побольше мозгов - доброй половины шишек можно было бы избежать. Разве не в этом их работа? Отдельный привет автору идеи с монолитом. Вместо того чтобы использовать чужой опыт - можно набить своих шишек и в итоге прийти к тому же результату, но позже и «своим путем».
Мне как пользователю вообще никуда не упиралось новое приложение. Потому что основной функционал появился в большинстве банковских приложений в момент их создания. Это управление счетами, возможность перевести деньги и оплатить услуги. И это должно быть быстро, удобно и легко. Попытки впарить мне акции компании, сим-карту, кэшбэк на стрижку питона, аренду велосипеда, билеты в театр - я не считаю заботой о пользователе. Попытки сломать привычный и удобный UX в угоду втюхивания своих услуг - отдельный вид искусства. (Привет Сберу, который воткнул вкладку «Кредиты» на место «Истории платежей», убрав последнюю в меню. Кредитов у меня нет и надеюсь, что не будет. А вот историей платежей я пользовался регулярно доя ведения бюджета) Если какой-то из банков выкинет трюк с блокировкой старого приложения для миграции, а я в этот момент буду вне дома - я не буду ставить новое приложение. Воспользуюсь веб-версией, а потом закрою все счета и переведу деньги в другой банк, который подобной ерундой не занимается (Привет, Совкомбанк).
lazarus_net
26.05.2026 07:11Уважаемый авто, давайте разберемся с миллионами пользователей которых вы из одного приложения App Store в другое перетягиваете. Поиск по интернету дал некоторые цифры. Оценка количества пользователей ниже.
На конец 2021 года у РСХБ было порядка 7,5 млн розничных клиентов (это банк публиковал). Доля iOS-устройств в России на тот момент — около 30%. При проникновении мобильного банкинга в активной клиентской базе около 50–60% (типично для РСХБ, который сильно отстаёт от лидеров), приложение в App Store могло иметь по грубой оценке порядка 1–1,5 млн установок
Согласитесь что 1-1.5 млн установок это не миллионы. Хотя наверное и много.
Было бы интереснее информацию от товарищей из Сбера получить что там у них творится. У Сбера около 80 млн пользователей на apple/ android это у них проблемы мигрировать массу клиентов, а не у вас с 8 млн клиентов всего.
В физике параметром можно приенебречь если он в 10 и более раз меньше остальных …
jameskotov
26.05.2026 07:11Что нужно сделать, чтобы попасть в сегмент чувствительных клиентов и не ставить обновления?
K0styan
26.05.2026 07:11Попасть в какой-то верхний перцентиль приносимого банку дохода, очевидно. Ничего личного, просто бизнес.
you_been_pwn3d
26.05.2026 07:11Кусок про "упущенную выручку" и иже с ним напомнили мне, как я "старшему поколению" объяснял, как пользоваться новым приложением банка (ВТБ купил РНКБ, приложение сменилось, все такое).
Так вот, там даже я терялся от обилия всякой
нахрен не нужной, рекламнойвсячины. И, кстати, много где так до сих пор.Ребят, бОльшая часть людей пользуется функционалом: посмотреть баланс, перевести по номеру, оплатить по qr.
Не надо остальное впихивать в приложение. Сделайте НОРМАЛЬНУЮ веб версию для тех, кто на ios и не делайте людям мозги.
electroboogie
26.05.2026 07:11Не обновлял приложение Тиньков банка с 2022 года, никакими функциями не обделён. Практику "Не обновишься - не пустим", считаю категорически неуважительной к пользователю.
K0styan
Вот тут удивительно: неужели понадобились санкции для такого вывода?
Я в своё время делал апп для ритейла и мы пришли к модульной конструкции ещё в 2019-м. И это не потому, что я такой прозорливый) Просто упёрлись в возможности монолита по актуализации бизнес-сценариев. И это ещё до того, как онлайн-продажи запустили - даже у оффлайновых историй темпы были слишком высокими.
Притом модульность была нативной. Выбрали несколько типовых блоков - от ленты товаров до полностью кастомизируемых через веб-вьюшки экранов - и дали возможность через админку пересобирать эти модули в любом порядке, подключая к разным источникам данных.
kaparray Автор
Справедливо, санкции тут не первопричина, а ускоритель. К модульности рано или поздно приходят все, у кого продукт активно развивается — просто потому что монолит не успевает за бизнесом.
Интересно, что вы пошли в нативную модульность с пересборкой через админку. Мы в итоге выбрали web-модули внутри контейнера — у банка специфика в том, что регуляторных и продуктовых изменений много, и переиспользовать одну и ту же логику между iOS, Android и интернет клиенте оказалось дешевле, чем поддерживать три нативные реализации. Но в ритейле, где UX-требования к скорости и анимациям выше, ваш выбор выглядит логичным.
K0styan
Дело не в UX, у нас хватало именно продуктовых изменений. Тут всё даже хуже, чем с регуляторкой: требования рынка в ритейле в те годы росли очень быстро.
Ну и веб-вью мы совсем-то не избегали: именно благодаря ему удалось затащить онлайн-продажи, пусть и в супер-базовом виде буквально за 2 недели с началом ковидного карантина.
Но все изменения очень неплохо кластеризовались по типам, и в итоге гибкости набора модулей хватало.
onets
Тоже показалось, что банк, которым я пользуюсь - перешел на такую схему еще задолго до. Прям куски интерфейса менялись.
kaparray Автор
Да, ваше наблюдение верное — подход не новый, крупные банки переходили на web-модули внутри контейнера в разные годы. Мы полноценно живём в этой архитектуре с начала 2024 года, и большинство правок интерфейса действительно едет без выкатки клиента — эффект «куски меняются сами» ровно отсюда. Миграция на новое приложение, про которую статья, нужна в тех случаях, когда изменения выходят за рамки контейнера — меняется схема API, появляются новые нативные компоненты.