Всем привет! Мы — архитектор разработки публичных веб-приложений Борис и разработчик системы-шлюза отправки нотификаций Данила. Расскажем о том, как создавались веб-пуши iOS в Тинькофф, как их настраивали и с какими проблемами столкнулись в процессе разработки.
Длинные и короткие пуши
С выходом iOS 16.4 Apple добавила возможность отправлять пуши в 
Раньше Apple позволяла отправлять пуши в десктопную версию Safari. У нас в компании они были с незапамятных времен и нашли применение в области инвестиций. Многие пользователи получали уведомления в режиме реального времени во время дневной торговли, что позволяло им быть в курсе последних изменений на рынке.
Когда наше приложение удалили из App Store и возможность отправлять пуши пропала, мы начали активно искать альтернативу обычным пушам и решили попробовать веб-вариант в PWA.
Отправлять веб-пуши можно, используя компанию-агрегатора или наше существующее решение — собственный Push-шлюз.
У варианта с агрегатором мы столкнулись с нюансом, что есть разные подходы при отправке пушей: длинный и короткий.
Короткий пуш отправляется в облако со всем контентом. Такой способ требует шифрования. Шифрование нужно для проверки фронтендом, что это именно твой бэкенд прислал тебе пуш.
Длинный, или триггерный, пуш сложнее в процессе доставки. На фронтенд отправляется триггер с информацией о том, что для клиента есть уведомление, которое нужно показать. Фронтенд принимает триггер и сам идет за контентом пуша — например, по его ID. С триггерными пушами шифрование не требуется. Бэкенд не посылает контент пуша, а фронтенд сам его забирает и рисует пуш по заданной логике.
Наша интеграция с агрегатором настроена так, что отправка коротких пушей не поддерживается, только триггерных. На фронтенде поддержать оба способа отправки было невозможно, поэтому мы выбрали вариант целевой схемы с использованием нашего собственного Push-шлюза.
Проблемы во время разработки
В итоге мы выбрали короткие пуши, но во время разработки возникли трудности с их обработкой и процессом запуска. Для доставки пушей мы использовали существующие у нас инструменты — собственную библиотеку и service worker. Библиотека встраивалась в наше приложение, позволяла запрашивать разрешение и создавать подписку. А service worker принимал пуши и отображал их на устройствах пользователей. Такой функционал позволял успешно обеспечивать потребности пользователей, хотя мы столкнулись с рядом проблем.
Безопасность процесса доставки pushsubscriptionchange, которое должен отправлять браузер сервис-воркеру, просто не имплементировано в iOS Safari. После небольшого исследования мы поняли, что проблема небольшая, тем более что у нас уже установлена переподписка на каждый вход пользователя в приложение.
Например, если адрес устройства — 
Имплементация перехватчика. Параллельно с баннером мы разрабатывали тестовую модель для веб-пушей и в процессе выяснили, что при переходе по пушу, когда авторизационные токены протухли, пользователь бесконечно смотрит на спиннер авторизации. Проблема оказалась в том, что service worker содержал имплементацию перехватчика fetch, — пользователю показывалась специальная страничка, если у него не было интернета. При этом devtools Safari не отображал загруженный sw, мы оказались перед trade-off: выключить эту часть sw или ехать на прод с багом в пушах. Мы отказались от перехватчика fetch, и проблема полностью исчезла.
После реализации баннера мы были готовы катиться на прод, у нас была хорошая тестовая модель и мониторинг, соблюдены все функциональные требования. Но мы не понимали, как фича будет работать на больших масштабах, ведь она новая для iOS. Решили катить небольшими сегментами — повезло, что механизм конфигурации, разработанный ранее, поддерживал это.
Проблемы после запуска
Запущенные веб-пуши работали в проде и доставлялись пользователям: мы отслеживаем это по статусам доставки — так же, как и обычные пуши. Но оказалось, что при нажатии на уведомление ничего не происходит или происходит переход на главную страницу интернет-банка. Это плохо, потому что многие веб-пуши должны вести клиента на какое-то окно с дальнейшим действием. Тем более что в PWA не подразумевается отображение главной страницы банка, оно должно выглядеть как приложение.
Например, для подтверждения операции или оформления карты по маркетинговому предложению пользователь не может перейти на следующий этап и компания теряет лояльность клиента. Пуши работают, но не нацелены на пользователя. Смысла запуска таких уведомлений нет: вместо уведомлений клиенту могла бы прийти СМС со ссылкой для перехода, поэтому функционал откатили.
Проблема была в том, что На самом деле командами была проделана огромная работа по изменению сценариев. На текущий момент большая часть пушей запустилась и может отправляться в PWA, но есть некоторые типы сообщений, которые сейчас находятся в процессе переключения.
Еще одна проблема, с которой мы столкнулись, — отсутствие звуков и вибрации при получении уведомления в Safari. На текущий момент стандарт Safari такого не поддерживает. UPDATE: это исправили, теперь доставляется с звуком по умолчанию.
Иногда пуши могут приходить пачками. Так может работать APNS для того, чтобы сохранить время работы устройства, просыпаясь только для получения сообщений, когда батарея разряжена.
На текущий момент есть проблемы, которые мы решить не можем: иногда iOS просто перестает принимать пуши. Нашли такую же проблему на форуме Apple. К сожалению, остается только ждать.
Доставляемость держится на уровне 75%. На процент доставки влияет еще много факторов: работа облака Apple, работа устройства клиента. Например, наличие интернета на телефоне.
Если подытожить всю эту историю, то мы добавили отправку веб-пушей в PWA на iOS. Нам удалось решить большинство трудностей при разработке, переработать сценарии отправки нотификаций. Приятным бонусом стало то, что эти доработки сподвигли нас перевести большую часть отправки пушей с вендороского решения на отправки через собственные системы.
ссылка на оригинал статьи https://habr.com/ru/articles/776658/
Добавить комментарий