🌐 Web as Native

WebView и Web as Native

WebView —  встроенный в мобильное приложение компонент, который отображает веб-страницы (HTML, CSS, JavaScript) внутри приложения

Важно:
🔹 это не отдельное приложение (не Chrome/Safari)
🔹он управляется нативным кодом
🔹 пользователь не видит, что это веб


Web as Native —  подход, при котором веб-интерфейс используется как мобильное приложение

Web —  интерфейс и часть логики
🔸рисует UI
🔸обрабатывает пользовательские сценарии

Native —  оболочка (контейнер)
🔸открывает экраны
🔸управляет WebView
🔸даёт доступ к функциям устройства

WebView —  инструмент
Web as Native —  архитектурный подход
Большинство «Web as native»-реализаций используют WebView как основной инструмент

Как работает WebView

1. приложение создаёт WebView
2. передаёт URL
3. WebView загружает страницу
4. отрисовывает интерфейс
5. пользователь взаимодействует с ним

Если нужен доступ к устройству — используется bridge (API между Web и Native внутри приложения)


Пример архитектуры

Пользователь
     ↓
Мобильное приложение
     ↓
  WebView
     ↓
Web Frontend
     ↓
Backend API

WebView — только “контейнер”,  вся логика чаще всего в вебе


Способы открытия WebView


➡️ Прямое открытие экрана

Самый простой вариант: пользователь нажал → открылся экран с WebView

Минус: видна загрузка (белый экран), что создаёт ощущение “медленного” приложения

➡️ Предзагрузка

Приложение:
🔹создаёт WebView заранее
🔹загружает страницу в фоне

→ пользователь открывает — страница уже готова
→ улучшает perceived performance (ощущаемую скорость)


➡️ Skeleton / Loader

Пока WebView загружается показывается нативный placeholder или skeleton UI

→ создаёт ощущение скорости, даже если фактическая загрузка не изменилась

➡️ Кэширование

🔹WebView использует кэш
🔹можно хранить статические ресурсы

→ ускоряет повторное открытие и снижает нагрузку на сеть


➡️ Гибридный экран (частично native)

🔹шапка и кнопки — нативные
🔹контент — WebView

→ снижает ощущение “веба” и улучшает UX за счёт нативных элементов


Где используется WebView

🔸статьи и контент
🔸 личные кабинеты
🔸формы и платежи
🔸 fallback-экраны


Пример: маркетплейс

Почему WebView
➖ UI часто меняется → веб позволяет обновлять без релиза приложения
➖ маркетинг управляет страницами → не требует участия мобильной команды
➖ важно быстро выкатывать изменения → веб быстрее в доставке

Web:
🔹 каталог
🔹 карточка товара
→ высокая изменяемость, много UI-логики

Native:
🔹оплата
🔹push
🔹доступ к устройству
→ критичные функции, требующие безопасности и интеграций

Сценарий: покупка

1. User → Web: нажимает "Купить"
2. Web → Native: startPayment
3. Native → Backend: выполняет запрос
4. Native → Web: возвращает результат


Безопасность

Риски:
🔸XSS уязвимость 
  → вредоносный JS может вызвать нативные методы через bridge
🔸загрузка чужих URL 
  → можно отобразить фишинговую или вредоносную страницу
🔸доступ к cookies 
  → возможна утечка пользовательских данных

❗️Главная зона риска — взаимодействие между Web и Native,
здесь веб получает доступ к возможностям устройства


Плюсы и минусы

➕ быстро → можно использовать уже готовый веб и не писать UI с нуля
➕ дёшево → меньше затрат на разработку и поддержку двух платформ
➕ единый код → изменения делаются в одном месте и сразу доступны всем

➖ медленнее → из-за дополнительного слоя (браузерный движок + рендеринг) 
➖ хуже UX → веб-интерфейс уступает нативному по отзывчивости и плавности 
➖ зависимость от сети → без интернета приложение может частично или полностью не работать


📎 Материалы
1. Из браузера — в приложение: внутренняя кухня WebView
2. От Web к Native с React
3. ОМП рассказала о новых возможностях WebView в ОС «Аврора»
4. WebView: забыть нельзя интегрировать

#веб

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу