Нюансы разработки PWA для Банка Санкт-Петербург от первого лица
Классический мобильный банкинг для физлиц — это нативные приложения под iOS и Android. В силу санкционного давления и стремления к оптимизации процесса разработки наш клиент переходил на PWA (Progressive Web Application). Логичный шаг — так делают многие компании, попавшие под ограничения магазинов приложений.
Мы уже подходили к идее создать PWA около двух лет назад и уперлись в огромное количество проблем. Если верить презентациям, все нужные технологии доступны и должны работать очень гладко. Но взаимодействуя с API, на каждому углу мы обо что-то спотыкались. Поддержка PWA зависит от платформы (iOS / Android) и версии браузера. В Android Google Chrome поддерживает большинство нативных функций для PWA, а вот в iOS ограничений в самой системе, связанных с безопасностью, больше.
Сейчас видно, что год от года ограничений у того же Apple становится меньше, устройства у пользователей, а значит и версии ОС, обновляются. В итоге PWA все больше похожи на нативные приложения, а мы взялись таки за разработку. В этой статье рассказываем о том, с чем нам пришлось столкнуться.
PWA — веб-приложение с поддержкой ряда нативных функций: можно запускать камеру, использовать отпечатки пальцев, получать Push-уведомления и реализовывать на их основе различные пользовательские сценарии. Выглядит оно как классическое мобильное приложение, в частности позволяет создать ярлык на рабочем столе и не отображать строку браузера. Однако, у него есть некоторые особенности установки и настройки. Приложение скачивается не с Apple Store или Google Play, а с сайта банка, и кроме того имеет некоторые ограничения при работе с нативными функциями.
Почему PWA
PWA как технология выгодна по нескольким причинам.
Во-первых, Progressive Web Application позволяет обойти ограничения на сторах. Для банковской сферы это очень актуальная проблема. Отрасль нащупала некоторые альтернативные решения, которые больше похожи на танцы с бубном:
Приложение можно выложить на сайте банка. Но способ этот не полностью заменяет стор: не все пользователи Android готовы идти на сайт и скачивать установочный файл. А для iOS такая установка вообще невозможна.
Если банк ранее покупал коллег по рынку, которые не попали под санкции, можно воспользоваться их «брендом», чтобы разместить приложение в официальных магазинах. Но это сложно, путанно и приложение все равно может быть заблокировано.
Можно разместить приложение под названием, напрямую не связанным с банком. Но тут встанет вопрос клиентского доверия — у людей, появляются сомнения, что именно они устанавливают.
Если посчитать затраты банка, в условиях санкций ставить клиентам нативные приложения любым из этих путей дорого. С PWA мы фактически получаем еще один вариант веб-сайта, который решает ту же задачу проще и дешевле.
Во-вторых, PWA позволяет сэкономить ресурсы разработки благодаря простоте и кроссплатформенности. Мы фактически делаем одно веб-приложение и получаем версии под разные платформы. А изменения можно вносить один раз и они будут доступны сразу на всех платформах. Не нужно ничего придумывать с синхронизацией разработки под Android и iOS или поддержкой на бэкенде нескольких версий нативного приложения, когда эта синхронизация провалилась.
Под PWA мы можем сформировать меньшую команду.
Чтобы получить нативные приложения под все платформы нужно было несколько команд. В нашем случае (два года назад) это была команда фулстек, которая реализовывала веб и его бэкенд, команды платформ — отдельные для Android и iOS, а также еще одна команда, которая делала BFF слой на бэкенде для нативного фронта.
Для PWA команда бэка все также нужна, но помимо нее в общем случае требовалась только одна команда веба, которая делала верстку PWA для Android и iOS. А мы обходились всего одной командой фулстеков, даже с учетом нюансов поддержки нативных функций на разных платформах.
При выборе в пользу PWA стоит учитывать и состав команды. Технология эта достаточно простая, так что джуны под надзором более опытных разработчиков могут войти в проект довольно быстро. От них при этом не требуется никаких необычных навыков. Наши сениоры отмечали, что их присутствие создает более продуктивную атмосферу в коллективе — есть, для кого делать хорошо.
Взвесив все за и против, клиент принял решение переходить на PWA.
В roadmap было заложено три основных этапа: MVP, MMP и готовая версия. Но начали мы с разработки дизайн-системы.
Дизайн система
Вне зависимости от используемого цифрового канала у клиента должен быть единый паттерн работы с банковскими услугами. Разработка дизайн-системы позволила оптимизировать данный процесс. По сути дизайн-система — это набор компонент, из которых достаточно быстро можно собирать экраны приложения (клиентские сценарии) без больших трудозатрат на программирование. Их можно легко интегрировать с бэкендом и выкатывать на клиентов, чтобы как можно быстрее начинать тестировать гипотезы.
Дизайн отдельных элементов делали в Figma, а разрабатывали дизайн-систему, используя StoryBook (https://storybook.js.org/). Это приложение React, которое показывает компоненты на разных страницах. По сути оно позволило дизайнерам заходить в систему и контролировать воплощение дизайна — насколько система соответствует изначальной задумке. Так они могли непосредственно влиять на качество.
Дизайн-систему писали коллеги, которые имели опыт как в дизайне, так и в разработке. Это очень положительно сказалось на ее качестве, поскольку они применили разные интересные паттерны, вроде atomic design.
В целом по рынку мы заметили тенденцию, что если раньше бизнес приветствовал расширение компетенций на соседние сферы разработки, например между фронтом и бэком, то сейчас аналогичный процесс наблюдается между разными профессиями, в частности, разработчиками и дизайнерами. Разработчики с навыками дизайна и дизайнеры с навыками разработки приносят в проект интересные идеи. И мы стараемся в компании следовать этому тренду.
MVP
Разработку MVP мы запустили в начале сентября 2023 года, а в конце января 2024 выкатили первую версию.
На этом этапе было реализовано:
Аутентификация: быстрый логин и связанные с этим сценарии — забытый пароль или логин.
Дизайн главной страницы, где отображаются счета и продукты.
Базовые функции: отображение остатков по счетам, история операций, а также самый сценарий перевода между своими счетами.
Сканер номеров карт и QR кодов для оплаты по СБП. На тот момент распознавали только 70% квитанций и 40% номеров карт, при этом сам функционал оплаты пока не работал.
На этапе MVP мы оттачивали работу PWA с разными браузерами и моделями телефонов. Пришлось разбираться, какая версии ОС стоит на клиентском устройстве и как включить в настройках браузера нужную функцию. По требованиям заказчика мы должны были поддерживать довольно старые версии iOS и Android. Но функции PWA реализованы не во всех устаревших версиях браузеров.
На этом этапе сильно помогло, что у нас в офисе есть достаточно большой парк устройств — как новых, так и старых. Гипотезы проверяли на большом многообразии смартфонов. Если на какой-то версии браузера что-то не работало, приходилось придумывать свое кастомное решение — доставать эмуляторы и фиксировать проблемы, описания которых нет на StackOverflow.
Некоторые проблемы требовали перестройки пользовательских сценариев. Например, есть такое ограничение безопасности — если пользователь не сделал никакого действия (не ткнул в экран), то клавиатура не появится. Часть Web API требует Media index. Поэтому все сценарии, подразумевающие ввод данных с клавиатуры, перерабатывали так, чтобы человеку нужно было нажать в окно или на кнопку на экране.
Обновление PWA
Отдельно стоит поговорить про обновление приложения. Выше мы упоминали, что быстрое обновление — одно из преимуществ PWA. Но тут тоже важны нюансы. Для пользователя обновление выглядит как рефреш страницы, причем не такой уж быстрый.
Сначала мы сделали обновление через стандартный диалог: «Хотите обновить? Да / Нет». Но обновления приходят довольно часто, поэтому диалоги всем надоели еще на этапе разработки MVP. Так мы пришли к идее обновляться в фоне.
Проблема в том, что обновление прерывает пользовательский ввод. Допустим, мы запросили биометрию, в этот момент происходит рефреш. В таком случае биометрию пользователю придется «предъявлять» заново. Поэтому мы сделали обновление после логина, когда пользователь переходит на страницы, где нет никакого ввода (главная страница, страница настроек).
Сканирование QR-кодов
Пожалуй, сканер был самым сложным элементом — реализовать его в PWA оказалось нетривиально. У нас были достаточно высокие требования со стороны заказчика — приложение должно распознавать не менее 95% квитанций, которыми пользуются клиенты банка. Иными словами, мы работали на то, чтобы PWA было не хуже привычного нативного приложения.
Для распознавания QR-кодов мы использовали стороннюю on-premise библиотеку от одного из лидеров рынка, написанную на C++ и скомпилированную в WebAssembly. Изначально мы не закладывали ресурсы на аналитику и разработку того, как выбирать камеру, как обеспечивать фокусировку и т.п. Но на это пришлось потратить определенное время. Библиотека просто парсила готовые картинки с помощью встроенной нейронной сети, а процесс их получения был на нашей стороне.
Наша реализация работает в двух потоках следующим образом:
Оказалось, что не так просто определять, какой камерой нужно сканировать QR-код. Устройства отличаются, каждое имеет свое количество камер. В iPhone встречается три камеры, а в некоторых аппаратах Android — пять или шесть (считая фронтальные). Каждая из них имеет свои параметры — широкий или узкий угол, диапазон фокусировки.
API предоставляет список камер, но нигде не отражено, какая из них лучше подойдет под задачу. У некоторых устройств для камер есть флаг FacingMode, который показывает, в каком направлении «смотрит» камера (селфи-камера или обычная). Но к сожалению, он доступен не везде. Проблема и ее решение описаны на StackOverflow: https://stackoverflow.com/questions/68253653/webrtc-selecting-the-main-camera-in-a-webapp-when-the-device-has-multiple-bac. Мы оставили пользователям на всякий случай возможность переключить камеру при необходимости и запоминаем этот выбор на будущее в Local Storage.
Тестирование
Для тестирования PWA вместо классической команды на стороне разработки мы пришли к полной автоматизации. Практически полностью реализовали в автотестах пирамиду тестирования (юнит-тесты, снэпшоты, интеграционные тесты, end-to-end тесты) с высоким уровнем покрытия. По тем же юнит-тестам в соответствии с требованиями заказчика у нас покрытие 80%. Кроме того подключили сервис для отслеживания качества кода — Sonarqube.
Ручное тестирование подключалось у нас уже со стороны банка на стадии приемки. Это ускорило и удешевило разработку.
В ходе тестирования мы экспериментировали не только с самими функциями приложения, но и со связью. В отличие от веб-сайта, PWA хороши тем, что при полном отсутствии интернета пользователь видит не белый экран, а интерфейс, в котором он до этого находился. При восстановлении подключения он может продолжить работу с того же места, где остановился. Нашему приложению для работы достаточно уровня сигнала «Edge».
MMP
На этапе MMP мы реализовали основные функции daily banking и отображения банковских продуктов — вкладов, накопительных счетов и кредитов. Добавили полноценную поддержку платежей по СБП, повысили скорость и стабильность работы. Кроме того добавили поддержку программ лояльности — кэшбэка и баллов.
На этом же этапе мы встраивали сбор метрик по вопросам безопасности и «здоровья» приложения, а также по различным пользовательским сценариям, которые формируют воронки на стороне банка. Это инструмент уже для бизнеса — для повышения качества и количества цифровых продаж.
Версию MMP мы закончили к началу июля 2024 года.
Для теста мы выпустили приложение на ограниченную аудиторию в 10 тыс. пользователей. 4 тыс. — это сотрудники банка, а еще 6 тыс. — внешние пользователи.
Интересно, что именно эти 6 тыс. оказались самыми эффективными тестерами. Мы ожидали более активного отклика от сотрудников банка, поскольку это лояльная аудитория, которая может в достаточном объеме совершать типовые операции и не боится рассказать про проблемы. Но так совпало, что как раз в момент выпуска приложения банк активно работал со студентами — проводил выездные сессии в вузах, раздавая карты для выплаты стипендии. Вместе с картами сотрудники распространяли короткий гайд, как установить себе PWA и какие задачи с его помощью можно решать.
Студенты оказались очень лояльными тестерами. У них почти не было вопросов по онбордингу — это поколение, которое выросло на смартфонах и понимает, как что работает.
По итогам теста со всех 10 тыс. человек мы получили лишь несколько негативных отзывов, которые сводились к тому, что относительно нативного приложения для смартфона изменился дизайн и пользователю непросто сходу сориентироваться в новом интерфейсе.
Полная версия
Переходя к полной версии, мы продолжили работать над скоростью и стабильностью, а заодно повысили детализацию отображения различных услуг. Попутно запустили витрину, чтобы из PWA можно было открывать сложные продукты — вклады под различные ставки. Реализовали даже калькулятор, где под свои условия можно было сравнить несколько вариантов вкладов, чтобы выбрать наиболее выгодный.
Был интересный кейс, связанный с подтверждением учетной записи на Госуслугах. На этапе обсуждения проекта мы обращались к статистике банка и на тот момент этой функцией практически никто не пользовался. Но стоило нам выпустить MMP, все стали говорить, что именно ее и не хватает. В полной версии мы ее реализовали и действительно трафик на эту функцию существенно вырос.
Тестирование ограниченной аудиторией закончилось вместе с выпуском полной версии приложения — в начале ноября 2024 года. В этот момент мы открыли приложение для всех пользователей банка. У нас уже были написаны дополнительные скрипты для колл-центра, чтобы операторы могли объяснить пользователям, как с этим правильно работать. Вопросов по онбордингу было довольно много — в основном от аудитории 35+.
Что дальше?
В общей сложности с учетом относительной «новизны» решения для нас самих разработка заняла 14 месяцев. Это очень сжатый срок для такой большой задачи и маленькой команды.
Мы продолжаем развивать приложение и сейчас сосредоточились на том, чтобы сократить количество экранов, которые необходимо пройти пользователю до получения услуги. Например, если у него есть предпочтительный банк в СБП, мы сразу представляем его в интерфейс перевода, чтобы не пришлось ничего выбирать из выпадающего списка.
А также:
Движемся в направлении расширения возможностей digital-офиса, чтобы через приложение можно было заказать все основные справки даже по сложным продуктам — остатки по счетам, справки для консульства, налоговой или о закрытом кредите.
Работаем над реализацией безбумажного офиса, т.е. над возможностью подписывать присланные из банка документы в электронном виде прямо в приложении.
Продолжаем развивать интеграцию с налоговой и Госуслугами, чтобы можно было выполнять основные операции или подтверждать паспортные данные без личного визита в офиса банка.
Вывод
Поддержка PWA в браузерах определенно развивается. Еще два года назад реализовать подобное приложение было бы сложно. Сейчас у нас все получилось. Но работы пришлось проделать много — было множество реквестов, что что-то хорошо работает на iOS, но не работает под Android, и наоборот. Мы же старались решать все эти проблемы так, чтобы код на обеих платформах был одинаковый — не хотели уходить от унификации. В целом это интересный опыт, который для нас еще не закончился.
Спасибо за помощь в подготовке материалов нашей команде PWA-разработки:
Евгению Евдокимову, лиду разработки Липтсофт,
Дмитрию Державину, фронтенд-разработчику Липтсофт.
