Из мобильного банка в суперапп: как перезапустить зрелое приложение, не останавливая бизнес

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

Стоимость разработки мобильных приложений

Читать статью

В такой ситуации одного редизайна недостаточно. Чтобы продукт продолжал расти, приходится одновременно обновлять архитектуру, технологический стек и подход к управлению пользовательскими сценариями — и при этом не останавливать выпуск новых функций. Это особенно важно для среднего и крупного бизнеса, у которого мобильное приложение уже стало полноценным каналом продаж и обслуживания, а не просто имиджевым дополнением.

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

За 190 дней команда реализовала более 10 крупных функциональных блоков

Но главное в этом кейсе то, что зрелое приложение удалось превратить в платформу, на которой банк может дальше наращивать экосистему сервисов без новой масштабной перестройки. Именно этот переход — от мобильного банка к супераппу — и стал основной экспертной задачей проекта.

Когда приложение начинает ограничивать бизнес

Заказчик работает с частными клиентами, малым и средним бизнесом и корпоративным сектором. Мобильное приложение уже было полноценным каналом взаимодействия с банком, поэтому его нельзя было просто поставить на паузу и переписать с нуля. Одновременно продукту требовался следующий этап развития:

• расширение набора банковских сценариев; 

• персонализация;

• постепенное объединение в одном приложении сервисов, выходящих за рамки классического банкинга.

Фактически перед командой стояли две параллельные задачи: модернизировать зрелый продукт и продолжать выпускать новую функциональность. Именно это определило дальнейший подход к проекту.

Выбор стратегии ИТ-разработки

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

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

Создание веб-платформы и мобильного приложения для крупной компании

Читать

Был и ещё один фактор — жизненный цикл мобильной платформы. Apple регулярно повышает минимальные требования к версиям Xcode и iOS SDK (наборов инструментов и технологий, необходимых для разработки приложений под актуальные версии iOS) для публикации приложений в App Store. Поэтому в рамках большого перезапуска было важно не просто обеспечить совместимость на текущий момент, а перейти на актуальный набор инструментов, который будет проще поддерживать дальше.

На iOS команда сразу перешла на последнюю версию языка программирования Swift 6. Это позволило совместить редизайн и развитие супераппа с обновлением технологической основы, а не выносить ещё одно масштабное технологическое обновление версии языка в отдельный будущий проект. Интерфейс приложения полностью реализовали на SwiftUI — современном UI-фреймворке Apple ((User Interface или пользовательский интерфейс). Для продукта, в котором регулярно появляются новые экраны и сценарии, декларативный подход упрощает разработку и изменение UI, снижает объём вспомогательного кода и позволяет быстрее развивать интерфейс.

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

Сначала — архитектурная основа

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

Поэтому проект начали с пересмотра архитектуры. При этом разработка новых сценариев не останавливалась: изменения внедряли поэтапно, формируя новую основу и постепенно переводя на неё функциональность. Такой подход позволил не превращать модернизацию в изолированный технический проект. Архитектурные изменения сразу работали на расширение продуктовых сценариев.

Вернули в приложение основную банковскую функциональность

После подготовки архитектурной основы команда сосредоточилась на банковском ядре продукта — базовой функциональности, необходимой клиенту для повседневного взаимодействия с банком: управлении банковскими продуктами, платежах, переводах и контроле операций. Эти сценарии перенесли на новую архитектуру и подготовили к дальнейшему развитию. Архитектура должна была позволять постепенно добавлять новые сервисы, персонализированные предложения и дополнительные пользовательские сценарии, не перестраивая приложение каждый раз при расширении продуктовой линейки.

Смысл этого этапа был не просто в переносе отдельных экранов. Чем больше базовых операций пользователь может выполнить в мобильном приложении, тем меньше ему приходится переключаться на другие каналы взаимодействия с банком — обращаться в отделение, звонить в контакт-центр или подключать поддержку для решения типовых задач. В кейсе это также связано с такими функциями, как история операций, металлические счета и оплата по QR-коду.

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

Добавили сценарии супераппа и продумали безопасность

Целью было сделать приложение точкой входа не только в финансовые операции, но и в повседневные сервисы. В продукт добавили бронирование и оплату отелей и туров, заказ еды, блок «Мои заказы», а для коммуникации с клиентами — формат сторис. Также появились сервисные сценарии: онлайн-очередь и запись в отделение.

В результате внутри одного приложения начали объединяться три группы сценариев:

• банковские операции;

• взаимодействие с банком;

• дополнительные lifestyle-сервисы. 

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

Расширение финансового приложения нельзя рассматривать отдельно от безопасности. В рамках модернизации добавили биометрическую аутентификацию, бесконтактные платежи и предупреждения о подозрительных операциях. Это важно и с продуктовой точки зрения: чем больше сценариев переходит в мобильный канал, тем выше требования к защите операций и к тому, насколько органично механизмы безопасности встроены в пользовательский путь.

Отвязали персонализацию от релизного цикла

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

Как ИИ-помощник помог снизить на 15% отказы от покупок в приложении

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

1. Разные пользователи могут видеть разные предложения и сценарии.

2. Банк может менять состав и структуру ленты без публикации новой версии приложения.

В результате мобильный релиз перестал быть обязательной точкой для каждого обновления персонализированной витрины. Бизнес получил возможность быстрее актуализировать предложения, а команда приложения — отделить развитие части контента от цикла выпуска клиента. Дополнительно в продукт интегрировали механизмы на основе ИИ для персональных рекомендаций и виртуального помощника, который доступен круглосуточно и помогает закрывать часть обращений без ожидания специалиста.

Что получилось в результате

За 190 дней команда реализовала более 10 крупных функциональных блоков. Но главный результат проекта — не количество новых экранов или сервисов. Мобильное приложение получило новую технологическую основу и стало платформой для дальнейшего развития. В одном продукте объединились банковские операции, персональные предложения, бесконтактные платежи, запись в отделение, работа с заказами, туристические и фуд-сервисы, а также виртуальный помощник.

Таким образом, перезапуск решил сразу две задачи: 

• обновил продукт для текущих пользователей

• создал базу, на которой банк может дальше наращивать экосистему сервисов без новой масштабной перестройки приложения.

Подобная задача характерна не только для банков. С ней сталкиваются зрелые цифровые продукты, которые должны продолжать выпускать новые функции и одновременно перерастать первоначальную архитектуру. Подход особенно актуален для ритейла, e-commerce, телекома и других сервисов с быстро меняющимися предложениями и контентом, где бизнесу важно обновлять часть пользовательских сценариев быстрее, чем позволяет стандартный цикл публикации мобильного приложения.

Главный принцип здесь универсален: если продукт превращается из одного сервиса в экосистему, масштабировать только набор функций недостаточно. Вместе с ним должна меняться и технологическая основа, на которой эти функции будут развиваться дальше. Иначе каждая новая услуга будет добавляться всё дороже, а бизнес будет всё сильнее зависеть от релизного цикла мобильного клиента.

Как в России меняется мобильная разработка: тренды рынка 2025–2026 и рейтинг ключевых изменений

Вывод

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

Кейс банка из Казахстана показывает: даже зрелый продукт можно модернизировать без остановки бизнеса, если действовать поэтапно. Именно такой подход превращает мобильное приложение из набора экранов в платформу для роста. Если у вас есть похожие задачи или вопросы по ИТ-разработке, обращайтесь по телефону 8-800-200-99-24 или пишите на request@simbirsoft.com