Всем привет! ? Меня зовут Мансур, я фронтенд-разработчик в payme — в одном из крупнейших финтех-сервисов в Узбекистане, через который ежедневно проходят миллионы транзакций. Помимо основной функции, мы активно развиваем дополнительное направление Lifestyle-сервисов внутри мобильного приложения. В этом посте хочу поделиться практическим опытом внедрения WebView: расскажу, как мы используем его в продуктах payme avia и payme tickets, почему выбрали именно такой подход, какие преимущества он даёт, и с какими ограничениями приходится мириться на практике. 

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

Почему мы выбрали WebView в Lifestyle-продуктах

У нас в payme есть направление Lifestyle Products, и в нём два ключевых продукта:

• avia — покупка авиабилетов

• tickets — билеты на концерты, спектакли и другие мероприятия

  

Что даёт нам WebView

Вот основные плюсы:

• Скорость вывода на рынок (time to market) — веб-фичи мы выкатываем без обновления всего мобильного приложения. Это особенно важно для быстрых тестов гипотез.

• Независимость от нативной разработки и раздельные релизные циклы — не нужно ждать, когда мобильная команда освободится. Веб выходит хоть каждый день, мобайл — когда удобно. Для концертов в payme tickets мы протестировали новую карточку события с другим CTA — просто развернули мини-редизайн в WebView без необходимости выкатывать нативное обновление. Получили фидбэк за 2 дня и откатили — всё без релиза приложения.

• 14+ млн установок payme (на июнь 2025) — и мы можем доставлять новые сервисы пользователю без дополнительной рекламы, так как вебвью сервис уже живет внутри приложения.

• Слабо связанные команды — веб и мобайл могут работать параллельно, не мешая друг другу.

• Единая кодовая база для веба: Если у вас уже есть веб-версия сервиса, то адаптировать ее под WebView зачастую гораздо проще, чем писать все с нуля под каждую мобильную платформу. Это экономит ресурсы и время.

Тонкости, о которых важно знать

WebView — это не универсальное решение на все случаи. У него есть свои ограничения, и их важно учитывать заранее.

UX не как в нативке

Плавность анимаций, поведение свайпов, жесты — всё это в WebView чувствуется иначе. Пользователь может подумать, что «что-то не так».

Некоторые вещи придётся делать в нативке

Например:

• Доступ к камере

• Геолокация (При использовании navigator.geolocation внутри WebView, пользователю будет показан запрос на разрешение геолокации от имени домена веб-сайта, а не самого приложения. Это значит, что разрешение будет выдаваться не приложению, а конкретному сайту, загруженному в WebView)

• Системные share-меню (navigator.share)

• Уведомления, Bluetooth, NFC — всё это под запретом или работает нестабильно

Проблемы с хранением данных

WebView в iOS, если приложение свёрнуто дольше, чем на час, может выпилить всю память, включая sessionStorage. Поэтому:

• не используйте sessionStorage

• важно синхронизировать сессионные данные с нативной частью (см. разбор проблемы от Axel Springer)

В payme tickets мы столкнулись с проблемой, когда на iOS WebView терял sessionStorage после возвращения приложения из фона — особенно если оно было свёрнуто дольше часа. В результате веб-страница теряла информацию об авторизации, и пользователь попадал в состояние "непонятно что происходит". В качестве временного решения мы показываем модалку с сообщением, что авторизация недействительна (см. скрин). Это неидеально, но позволяет сохранить управляемость сценария. В перспективе мы идём к более надёжной архитектуре: сохранение ключевых данных (например, токена) на нативной стороне через JSBridge (поговорим о нем ниже) и восстановление их при каждом открытии WebView.

Клавиатура

Когда фокус на <input>, экранная клавиатура не изменяет viewport, а просто скроллит к нужному месту. Будьте готовы к странным прыжкам и непредсказуемым отступам.

Роутинг и поведение как у приложения

Пользователь ожидает, что:

• свайпы будут работать (а они могут ломать историю)

• состояние будет сохраняться (а оно может теряться при выгрузке)

• переход назад — это возврат в прошлый экран, а не "назад на сайте"

Время жизни

iOS может выгрузить WebView из памяти, если пользователь сворачивает приложение. При этом само приложение может остаться активным.

Решение: либо сохранять важные данные вне WebView, либо синхронизироваться с мобайлом через JSBridge.

Проблемы с viewport

Однажды в payme tickets в эмуляторе всё выглядело идеально — форма оплаты, верстка, зум. А на Android-смартфоне с WebView 102 после автозаполнения полей форма начинала масштабироваться и вылезала за экран. Проблема была в неправильной интерпретации meta viewport. Спасло явное указание:

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

И да, такой баг ты никогда не увидишь в Chrome DevTools. Только реальное устройство.

Как общаться с нативной частью

Есть два способа:

1. JSBridge

Это прямое API, через которое веб и мобайл могут "разговаривать". Со стороны веба — вы просто вызываете window-функции, которые нативка заранее зарегистрировала и слушает.

Пример:

window.PaymeBridge?.showAuthModal();

Этот вызов может открыть авторизационную форму в нативке. На стороне мобильного приложения (Android/iOS) этот вызов перехватывается и обрабатывается.

Как это работает на нативке:

• iOS — WKScriptMessageHandler

• Android — addJavascriptInterface

Важно: такие функции должны быть безопасными и предусматривать валидацию — не доверяйте вебу "на слово".

2. Action Links

Action links (или action URLs, иногда их называют deeplinks с действиями) — это специальные ссылки, на которые реагирует мобильное приложение, выполняя какое-то действие, а не просто открывая экран.

Это суперполезная штука. Например, можно использовать такой линк:

window.location.href = 'https://exit.from.webview;

И мобайл, увидев этот URL, закрывает WebView. Можно сделать целую систему управления действиями через такие ссылки.

Когда пользователь покупает билет в payme tickets, мы переводим его на нативный экран оплаты, используя action link вроде, https://open-checkout. Мобайл перехватывает такой линк и открывает экран оплаты, где пользователь может совершить оплату как всегда, и потом снова вернуться в вебвью. Это пример использования action links — простых, но очень эффективных.

3. URL Params

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

https://test/tickets?token=abc123&theme=dark&lang=ru

Поддержка браузеров: .browserslistrc

Когда разрабатываешь под WebView, нужно понимать, какие движки браузеров стоят за ним. Это не совсем те же движки, что в Chrome или Safari на десктопе. Обычно это WebKit на iOS и Chromium на Android, но версии могут отличаться от обычных браузеров. Поэтому .browserslistrc может выглядит немного специфично:

last 35 Chrome versions

last 1 Firefox version

last 2 Edge major versions

last 6 Safari major versions

last 6 iOS major versions

Firefox ESR

Указываем поддержку последних версий Chrome (чтобы охватить Android WebView), Safari и iOS (для iOS WebView). Firefox и Edge здесь, скорее, для совместимости на случай, если наш веб-сервис будет открыт во внешнем браузере, а не только в WebView.

Что еще важно учесть?

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

Офлайн-режим: Если ваш сервис может работать в офлайн-режиме, подумайте о Service Workers и кэшировании. Хотя в WebView это может быть не так критично, как в PWA, всё равно полезно.

Тестирование на реальных устройствах: Эмулятор — это хорошо, но ничто не заменит тестирование на настоящих телефонах с разными версиями Android и iOS.

Доступность (Accessibility): Убедитесь, что ваш веб-интерфейс доступен для пользователей с ограниченными возможностями. Семантический HTML, правильные aria-атрибуты, фокусное управление — это важно.

Что бы я посоветовал напоследок

• Не переоценивайте WebView — он удобен, но у него есть ограничения

• Всегда тестируйте на реальных устройствах (и, желательно, на разных версиях iOS и Android)

• Планируйте взаимодействие между нативной частью и вебом заранее

• Важно думать о UX. Даже внутри WebView пользователь хочет видеть приложение, а не сайт.

Если тебе было интересно — ставь лайк, шерь и не забывай подписаться, чтобы не пропустить новые посты :-)

Если ты тоже внедряешь WebView в своём продукте — расскажи в комментах, с какими проблемами сталкивался.