Web as Native
WebView и Web as Native
WebView — встроенный в мобильное приложение компонент, который отображает веб-страницы (HTML, CSS, JavaScript) внутри приложения.
WebView = браузерный движок внутри приложения
Важно:
- это не отдельное приложение (не Chrome/Safari)
- он управляется нативным кодом
- пользователь не видит, что это веб
Web as Native — подход, при котором веб-интерфейс используется как мобильное приложение.
Web — интерфейс и часть логики
- рисует UI
- обрабатывает пользовательские сценарии
Native — оболочка (контейнер)
- открывает экраны
- управляет WebView
- даёт доступ к функциям устройства
WebView — инструмент
Web as Native — архитектурный подход
Большинство «Web as native»-реализаций используют WebView как основной инструмент.
Как работает WebView
- Приложение создаёт WebView
- Передаёт URL
- WebView загружает страницу
- Отрисовывает интерфейс
- Пользователь взаимодействует с ним
Если нужен доступ к устройству — используется bridge (API между Web и Native внутри приложения.)
Типы WebView
Существует два разных типа WebView.
| Тип | Описание | Где используется |
|---|---|---|
| Системный | Компонент операционной системы, обновляется отдельно от приложения через магазин приложений или OTA-обновления | Android (WebView), iOS (WKWebView) |
| Встроенный | Браузерный движок внутри самого приложения (поставляется как библиотека) | Cordova, старые версии приложений, кастомные браузеры |
Почему важно:
- Системный WebView получает обновления безопасности и веб-стандартов независимо от приложения.
- Встроенный нужно обновлять вместе с приложением — выход новой версии браузера требует перевыпуска приложения в магазинах.
- На iOS все WebView — системные (WKWebView). На Android — обычно системный, но технически можно встроить Chromium в приложение.
Архитектура решения
Пользователь
↓
Мобильное приложение
↓
WebView
↓
Web Frontend
↓
Backend API
Важно:
- WebView — только “контейнер”
- вся логика чаще всего в вебе
Как WebView строит интерфейс (почему он медленнее)
WebView не рисует UI напрямую. Он:
- строит DOM
- применяет CSS
- считает layout
- рисует пиксели
В нативном UI этого слоя нет → он быстрее
Взаимодействие Web ↔ Native (Bridge)
Bridge (в контексте WebView) — механизм взаимодействия между веб-кодом (JavaScript) и нативным кодом мобильного приложения (Android/iOS).
Bridge — “мост”, через который веб и приложение обмениваются командами и данными
Зачем нужен
WebView по умолчанию изолирован: — JavaScript не может напрямую вызвать нативные функции — нативный код не может напрямую управлять JS
👉 Bridge снимает это ограничение
Проблема версионирования bridge
Когда веб-часть обновляется независимо от нативного приложения, возникает рассинхрон версий.
Старое приложение (версия 1.0) → новый веб (вызывает bridge-метод, которого нет в приложении)
↓
Результат: ошибка, падение, неработающая функция
Рекомендации для проектирования bridge:
| Рекомендация | Что делать |
|---|---|
| Обратная совместимость | Новые bridge-методы не удаляют и не изменяют сигнатуру старых |
| Version check | Веб проверяет версию приложения перед вызовом bridge-метода |
| Fallback-поведение | Если bridge-метода нет — выполнить альтернативное действие (например, HTTP-запрос вместо нативного вызова) |
| Документация контракта | Bridge — это API. Его изменения должны проходить тот же процесс согласования, что и REST API |
Ограничение: задержки в bridge
Каждый вызов:
- сериализация
- передача
- обработка
Следствие: нельзя использовать для частых операций (scroll, анимации), так как это приведёт к лагам и деградации UX
Способы открытия WebView
Это критично для пользовательского опыта.
Прямое открытие экрана
Самый простой вариант: пользователь нажал → открылся экран с WebView
Минус: видна загрузка (белый экран), что создаёт ощущение “медленного” приложения
Предзагрузка (preload)
Приложение:
- создаёт WebView заранее
- загружает страницу в фоне
→ Пользователь открывает — страница уже готова → улучшает perceived performance (ощущаемую скорость)
Skeleton / Loader
Пока WebView загружается:
- показывается нативный placeholder
- или skeleton UI
→ создаёт ощущение скорости, даже если фактическая загрузка не изменилась
Кэширование
- WebView использует кэш
- можно хранить статические ресурсы
→ ускоряет повторное открытие и снижает нагрузку на сеть
Гибридный экран (частично native)
- шапка и кнопки — нативные
- контент — WebView
→ снижает ощущение “веба” и улучшает UX за счёт нативных элементов
Примеры
Где используется WebView
- статьи и контент
- личные кабинеты
- формы и платежи
- fallback-экраны
Пример: маркетплейс
Почему WebView
- UI часто меняется → веб позволяет обновлять без релиза приложения
- маркетинг управляет страницами → не требует участия мобильной команды
- важно быстро выкатывать изменения → веб быстрее в доставке
Архитектура
User
↓
App
├── WebView → Web → Backend
└── Native модули (оплата, push, device API)
Разделение
Web:
- каталог
- карточка товара
→ высокая изменяемость, много UI-логики
Native:
- оплата
- push
- доступ к устройству
→ критичные функции, требующие безопасности и интеграций
Сценарий: покупка
1. User → Web: нажимает "Купить"
2. Web → Native: startPayment
3. Native → Backend: выполняет запрос
4. Native → Web: возвращает результат
Проблемы
- рассинхрон состояния → web и native могут “думать” разное о пользователе
- версии bridge → несовместимость между версиями приложения и веба
- производительность → сложные страницы тормозят
- UX разрывы → ощущение, что это “не единое приложение”
Безопасность
Риски
- XSS уязвимость
→ вредоносный JS может вызвать нативные методы через bridge - загрузка чужих URL
→ можно отобразить фишинговую или вредоносную страницу - доступ к cookies
→ возможна утечка пользовательских данных
Главная зона риска — взаимодействие между Web и Native, потому что именно здесь веб получает доступ к возможностям устройства
Рекомендации
- whitelist доменов
→ приложение открывает только доверенные источники - ограниченный bridge
→ уменьшает поверхность атаки - валидация данных
→ защищает от некорректных или вредоносных входных данных - очистка данных
→ предотвращает утечки между сессиями пользователей
Плюсы и минусы
- быстро → можно использовать уже готовый веб и не писать UI с нуля
- дёшево → меньше затрат на разработку и поддержку двух платформ
- единый код → изменения делаются в одном месте и сразу доступны всем
— медленнее → из-за дополнительного слоя (браузерный движок + рендеринг)
— хуже UX → веб-интерфейс уступает нативному по отзывчивости и плавности
— зависимость от сети → без интернета приложение может частично или полностью не работать
Когда WebView не подходит
| Сценарий | Почему WebView не подходит |
|---|---|
| Сложные анимации (60 fps) | Bridge не успевает обрабатывать вызовы, результат — лаги и дерганья |
| Офлайн-карты / тяжёлый локальный контент | WebView плохо управляет большими объёмами локальных данных |
| Биометрия (FaceID / TouchID) с веб-контентом | Для безопасных операций требуется нативный UI, веб не может напрямую вызывать биометрию |
| Real-time интерфейсы (игры, трекеры) | Задержки bridge делают UX некомфортным |
| Фоновая работа | WebView не предназначен для выполнения кода в фоне, ОС может принудительно остановить процесс |
Альтернативы
| Подход | Производительность | UX | Стоимость |
|---|---|---|---|
| WebView | Средняя | Средний | Низкая |
| Native | Высокая | Лучший | Высокая |
| React Native | Средняя/высокая | Хороший | Средняя |
| Flutter | Высокая | Хороший | Средняя |
| PWA | Средняя | Средний | Низкая |
Что важно для аналитика
- границы Web / Native → чтобы избежать дублирования логики и конфликтов ответственности
- контракт bridge → это фактически API, от которого зависит взаимодействие систем
- ограничения → влияют на архитектурные решения (например, нельзя делать real-time через bridge)
- деградация → важно предусмотреть, что будет при отсутствии сети, ошибках или старой версии приложения
Фреймворки для реализации Web as Native через WebView
- Apache Cordova / PhoneGap — классический фреймворк, упаковывающий веб-приложение в нативную оболочку. Предоставляет плагины для доступа к функциям устройства (камера, GPS, файлы).
- Ionic + Capacitor — современная связка. Ionic даёт UI-компоненты под iOS/Android, Capacitor — эффективный мост между вебом и нативным кодом. Наследник Cordova от создателей Ionic.
- React Native — формально не чистый WebView-фреймворк (транслирует JS в нативные компоненты), но использует схожий принцип моста и может рассматриваться как эволюция подхода.
- Electron — для десктопных приложений (Windows, macOS, Linux). Упаковывает веб-код в оболочку с Chromium. Примеры: VS Code, Slack, Discord.
Материалы
- Из браузера — в приложение: внутренняя кухня WebView
- От Web к Native с React
- ОМП рассказала о новых возможностях WebView в ОС «Аврора»
- WebView: забыть нельзя интегрировать
- Android WebView: актуальные проблемы и их решение
- Расширяем возможности мобильного приложения на WebView. Опыт Ozon Банк
- Как ускорить WebView в Android и доказать это цифрами
- PWA и WebView — как сделать ваше веб-приложение доступным в офлайн-режиме
- Две стороны WebView: о быстром запуске проектов и краже персональных данных
- Как всплывающее окно в WebView съело мои два дня (viewport и с чем его кушать)
- WebView: быстрый релиз, никаких ревью в сторах, а минусы есть?
- Flutter VS React Native
- Как проектировать скелетоны
- Что такое XSS-уязвимость и как тестировщику не пропустить ее
- WebView для Android — официальная документация
- WKWebView для iOS — официальная документация
- Web as Native подход от компании Surf
- Cordova — гибридные приложения на WebView
- Capacitor — современная альтернатива Cordova
- WebView performance best practices (Google Developers)
- Безопасность WebView на Android
Видео
- По ту сторону WebView
- Алишер Толебердыев, «Webview — сомнительно? Работает!»
- What, When, Where, How WebView? | BitBuddy
- Как устроен Android WebView. Евгений Мамруков
- WebView-приложения. Время гибридных технологий | Андрей Симонов, Алиса и Умные устройства