Webviews: puente nativo a operativas web.

Repasamos en este post las posibilidades que ofrecen actualmente los componentes Webviews y hacemos una aproximación a las Webviews con React Native.

Webviews under the hoods

Son componentes nativos (ios / android) que permiten embeber contenido web dentro de apps nativas. Si consideramos que un navegador de internet está compuesto de dos partes:

• Web rendering engine: Un motor para renderizar HTML/CSS/Javascript.
• Shell/UI de usuario: Barra de url, Tabs, etc.

El componente Webview termina siendo un derivado reducido solamente al motor de renderizado web más un bridge JS para comunicar con la parte nativa.

Con la Webview embebida en la app nativa, el interfaz de usuario que tiene el navegador normal es reemplazado por componentes UI nativos, haciendo parecer que la página web está integrada completamente dentro de la app nativa.

Cada plataforma nativa tiene su implementación. En Android está implementado en este componente y en nuestros móviles lo podemos ver como una app más:

En iOS está implementado en el componente VKWebview.

Las Webview apps llevan tiempo entre nosotros

En la carrera cross-platform por llevar contenido y funcionalidades a los usuarios de dispositivos móviles, hay en el mercado diferentes estrategias. Véanse Progressive Web Apps, No-Code App Builders, React Native, Flutter o Ionic. En muchas de esas formas, por debajo lo que hay es código web. Y es por algo. Si hay una tecnología que aguanta el paso del tiempo es la web: HTML+CSS+Javascript. De ahí que, por su portabilidad y su longevidad, muchas apps nativas que usamos habitualmente contienen Webviews como Facebook, Instagram, Twitter o Gmail.

En las Webview apps (apps nativas con, al menos, una pantalla en Webview), es imposible saber qué pantallas son Webviews y cuáles full native. Otras veces está claro, por ejemplo, cuando en Gmail abrimos un link de un email (in-app browser):

Tip: Una forma un poco drástica de saber qué apps nativas de tu móvil usan Webviews, es desinstalar el componente Webview y ver qué apps siguen funcionando.

Entonces, ¿qué ventajas tienen sobre hacer una web o webapp?

Si el código web es lo mejor de lo mejor, ¿por qué no servimos contenido a los navegadores de los usuarios en web/webapp y ya está? Dos estadísticas nos indican la mayor penetración que tienen las apps nativas sobre los contenidos servidos solo a través de navegadores.

Más de la mitad del tráfico online se hace desde dispositivos móviles.

Aproximadamente el 90% del tiempo de uso de los móviles es utilizando apps. Esto es porque las apps (tanto nativas como Webview apps) son mucho más fáciles de utilizar que los navegadores de los móviles:

Además, las Webview apps tienen otras ventajas:

• Login permanente. A eso le podemos añadir la posibilidad de mantener el login sin tener que iniciar sesión continuamente: menos clics para llegar al contenido / funcionalidad.
• Un único repositorio de código a mantener. Un solo codebase (web code) para tener features para las dos plataformas nativas.
• Más rápido en actualizar contenidos. Tener incrustadas páginas web dentro de la app permite actualizar su contenido con más agilidad al no tener que esperar los procesos de despliegue de las plataformas nativas. Aunque bien es cierto que ahora todas las plataformas nativas disponen de un mecanismo llamado OTA (Over-The-Air) updates que permite hacer “push” de cambios en las apps instaladas.
• Coste. El desarrollo de una app full native frente a una web-app puede suponer que la web-app te cueste hasta un 80% menos. Tengamos en cuenta que en full native se doblan los costes al hacerse el desarrollo en las dos plataformas y que el mantenimiento también es más costoso que con una web-app donde se requiere menos expertise.
• Aprovechar funcionalidad web existente. Hay veces que por determinadas circunstancias (razones de seguridad o que de momento no hay presupuesto para continuar el desarrollo nativo) ciertos flujos web solo pueden ser accedidas desde web. Con una Webview puedes hacerla disponible a los usuarios de la app.
• Conveniencia de abrir links desde una app con un in-app browser. Te ahorras tener que ir cambiando de aplicación para ver webs. E incluso te ahorras la molestia de que te pida con qué navegador quieres abrir el enlace.

No todo es bonito

• Interacción UI. La interacción de usuario que contenga esa webview no va a ser tan fina y suave como lo haría si fuera nativo. Acciones touch como swiping no son tan fluidas.
• Integración con hardware del dispositivo. Cuando necesitas integración con hardware del dispositivo, como cámara, GPS, etc., las webviews no te dan soporte. Mejor llevar esas funcionalidades a la parte full native. Otra cosa es que a través de Javascript interfaces comuniques con la parte nativa para que a su vez gestione acciones en el hardware (apartado más abajo)
• Soporte offline. Las webviews no tienen soporte offline (para esto están las PWA que sí tienen soporte para servir contenido offline pero a la contra son difíciles de publicar en las apps stores)
• Inconsistencia de diseño. Lo ideal es mantener un look & feel consistente a lo largo de todas las pantallas de la app. No siempre es fácil reutilizar los mismos tokens de diseños entre la web y las aplicaciones nativas. Complicado mantener una guía de diseño coherente entre las pantallas nativas y las Webviews. Como mucho se pueden compartir los design tokens, como por ejemplo teniendo los diseños en Figma a través de su API.
• Navegador restringido. Normalmente, está limitado a lo que es un navegador normal. Cierto es que ya hay opciones de abrir Webviews con más funcionalidades de navegador:
  • SFSafariViewController en iOS.
  • Chrome Custom Tabs en Android.

• Problemas de publicación en las apps stores. En general, para que te la acepten en las stores, necesitas que tu app nativa tenga algo más que una simple Webview. Incluye elementos UI nativos y funcionalidades tales como una native tab menu, splash screens, pantalla nativa de login, etc. El objetivo es crear una experiencia de usuario completamente nativa. Además, te pueden pedir que demuestres que el website que se carga en la Webview sea del mismo propietario que el de la app.
• Vigilar de tenerlo actualizado. Cualquier vulnerabilidad que se descubra en el componente Webview podría causar grandes males a millones de usuarios. La importancia de tenerlo siempre actualizado para recibir todas las mejoras y parches (por posibles brechas de seguridad y tener una experiencia de uso optimizada).

Exprimiendo las posibilidades de las Webviews en React Native

Vamos a mostrar aquí las características más reseñables de las webviews en cuanto al control que permiten desde la parte nativa. Elegimos poner ejemplos en React Native junto con el paquete React-Native Webview con el objeto de seguir trabajando sobre código web pero manteniéndonos en desarrollo nativo. El paquete React-Native-Webview soporta iOS, Android, Windows y MacOs.

Integrar una pantalla Webview en una app React Native es bastante simple.

import React, { Component } from 'react';
import { WebView } from 'react-native-webview';

// ...
class MyWebComponent extends Component {
  render() {
    return <WebView source={{ uri: 'https://reactnative.dev/' }} />;
  }
}

Desde el código nativo (React-Native en este caso) tenemos varias opciones de controlar el funcionamiento de la Webview. A continuación os dejo unos ejemplos “copy&paste”:

Inyectando JS en el Webview

• Ejemplo de inyección después de content loaded
• Ejemplo de inyección antes de content loaded
• Ejemplo de inyección en cualquier momento

Controlando la navegación dentro de la Webview

• Ejemplo

Comunicación Javascript bidireccional con la Webview

• Ejemplo
• Post con formas nativas para hacerlo con iOS

Configurando cookies/headers

• En la primera request de la página de la Webview
• En cada request que se haga en la Webview

File Upload

• Guía para hacer File upload (excepciones por plataforma)

File Download

• Guía para hacer File download (excepciones por plataforma)

Todos los ejemplos están disponibles en el siguiente repositorio.

Conclusión

Construir una app full native es el camino si la app va a ser el centro de tu modelo de negocio, pero en todos los demás casos es muy a considerar tener pantallas de tu app hechas dentro de webviews.

En resumen, el componente Webview es una valiosa herramienta para servir contenido a las apps nativas. Si además hacemos los desarrollos nativos en React Native, conseguimos tener código web tanto para renderizar pantallas nativas como para reutilizar funcionalidad web existente.