Mejoras

Existen muchas mejoras que pueden mejorar la conversión y el uso de tu AWP.

Los accesos directos a aplicaciones son una lista estática de vínculos directos a tu AWP y están escritos en tu manifiesto. Especificación del manifiesto de la app web: Te permite definir una lista de accesos directos a diferentes partes o funciones de tu AWP, que aceleran la navegación a las secciones a las que se accede con frecuencia.

Los accesos directos de apps están disponibles en la mayoría de los sistemas operativos de escritorio y Android con WebAPK, y aparecen en un menú contextual en el ícono de la app en la pantalla principal, la estación de carga o la barra de tareas, como en la siguiente imagen:

Accesos directos a aplicaciones en Android y macOS

Para acceder a este menú, los usuarios deben hacer clic con el botón derecho o mantener presionado el ícono de la AWP.

Las combinaciones de teclas se definen en el miembro shortcuts del manifiesto. Se necesita un array de miembros con las siguientes propiedades:

name
Es el texto que se le mostrará al usuario, por lo general, en un menú contextual.
url
La URL que la AWP debe cargar cuando el usuario la inicia desde este atajo. Debe ser una URL dentro del alcance de tu AWP y debe contener un vínculo directo a la función que se describe en name o short_name.
short_name
(Opcional) Es un nombre más corto que se usa cuando no hay espacio suficiente para mostrar el valor completo del campo name.
description
(Opcional) Es una descripción de lo que hará este atajo.
icons
(opcional): Es un array de objetos de íconos con campos src, type, sizes y purpose opcionales que describen qué imágenes deben representar el atajo.

Debes tratar los accesos directos a la app como una función de mejor esfuerzo. Eso significa que no puedes confiar en que estos atajos aparezcan de forma coherente y, aunque aparezcan, no sabes cuántos aparecerán ni si la plataforma ignorará los íconos, ya que depende de los navegadores. No es posible analizar en detalle cada plataforma, pero a continuación, puedes obtener una idea de cómo funciona en Android y computadoras. La mejor manera de abordar esta incertidumbre es ordenar los elementos por prioridad.

En la siguiente muestra de código, se definen diferentes accesos directos a aplicaciones que puedes probar si instalas la app en Android con Chrome o en una computadora de escritorio con Edge o Chrome.

iOS y iPadOS

Cuando publicas AWP, hay algunas mejoras que pueden mejorar la experiencia de los usuarios en Safari para iOS o iPadOS.

Pantallas de presentación

Como se ve en el capítulo Manifiesto de la app web, Android crea pantallas de presentación automáticamente en función de los valores del manifiesto. Ese no es el caso de iOS y iPadOS. En estos dispositivos, debes definir las pantallas de presentación en el código HTML como imágenes estáticas con elementos <link>.

Estas imágenes se conocen como imágenes de inicio en dispositivos Apple y usan la propiedad rel con el valor apple-touch-startup-image, como en el siguiente ejemplo:

<link rel="apple-touch-startup-image" href="ios-startup.png">

El desafío es que la imagen de inicio debe tener el tamaño de ventana exacto que tendrá tu AWP cuando se abra. Por lo tanto, los diferentes dispositivos iOS y iPadOS necesitarán imágenes diferentes. Se deben cubrir más situaciones en el iPad, como las aperturas horizontales o verticales y la renderización de la AWP en modo multitarea (como 1/3, 1/2 o 2/3 de la pantalla).

Puedes consultar una lista actualizada de los tamaños de pantalla de iOS y iPadOS en los Lineamientos de la interfaz humana de Apple.

Se pueden establecer diferentes versiones de la imagen de inicio con una consulta de contenido multimedia dentro del atributo media:

<link rel="apple-touch-startup-image" href="ios-startup.png"
      media="orientation: portrait">
<link rel="apple-touch-startup-image" href="ios-startup-landscape.png"
      media="orientation: landscape">

Patrones de diseño para imágenes de inicio de iOS

Definir imágenes de inicio es un trabajo arduo, por lo que tenemos algunas herramientas para la generación y configuración automatizadas:

  • La generación estática se integra en tu sistema de compilación, crea todas las imágenes estáticas PNG y te brinda el código HTML con elementos <link> para insertar en tu documento. PWA Asset Generator es un ejemplo de una herramienta de este tipo.
  • Generador del cliente, una herramienta de JavaScript que puede incorporar una o más versiones de Base64 de la imagen de inicio en elementos insertados de <link> según el tipo y el tamaño de pantalla del dispositivo actual. Puedes usar un lienzo en memoria, renderizar la imagen y convertirla en un URI data: con un archivo PNG. La biblioteca de compatibilidad de PWA es una biblioteca del cliente fácil de usar que hace esto clonando la pantalla de inicio típica de Android.

Cómo detectar una AWP en plataformas de dispositivos móviles de Apple

Si bien debes usar la mejora progresiva y la detección de funciones en tu AWP, es posible que haya algunos casos extremos en los que necesitemos saber si el usuario está en una AWP en plataformas móviles de Apple, como cuando deseas ofrecer instrucciones de instalación o agregar vínculos a apps específicas de la plataforma que solo son para iOS.

Para evitar leer la cadena de usuario-agente, verifica la propiedad standalone del objeto navigator. Esta es una propiedad no estándar y solo está disponible en el motor WebKit en iOS y iPadOS.

  • Si navigator.standalone es undefined, significa que el usuario no está en un dispositivo iPadOS o iOS.
  • Si navigator.standalone es false, significa que el usuario abrió la AWP en el navegador y la está usando allí.
  • Si navigator.standalone es true, significa que el usuario abrió la AWP desde la pantalla principal y obtuvo la experiencia de la AWP independiente.

Compatibilidad con pantalla completa

En Safari para iOS y iPads, solo se admite display: standalone como modo de visualización para tu AWP.

En la siguiente imagen, puedes ver a la izquierda un diseño independiente predeterminado con un color de tema y, a la derecha, una AWP con un modo de pantalla completa para iOS que te permite renderizar contenido detrás de la barra de estado.

Un comportamiento predeterminado independiente (izquierda) y una pantalla de iOS en pantalla completa (derecha).

Si agregas la siguiente etiqueta en tu código HTML, tu AWP en iOS y iPadOS entrará en modo de pantalla completa, pero será diferente de Android.

<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

En este modo, la barra de estado del dispositivo (la parte superior en la que se ve el reloj, el nivel de batería y los íconos de notificación) sigue siendo visible, pero se renderiza sobre el contenido con un fondo transparente.

Cuando uses este modo, ten cuidado con el diseño, ya que el sistema operativo siempre renderizará los íconos en blanco, por lo que siempre debes contrastar los fondos de la parte superior de la pantalla con contenido claro. Además, es importante usar variables de entorno de CSS para renderizar contenido en el área segura, como se ve en el Capítulo de diseño de apps.

De forma predeterminada, los 0 px superiores de tu viewport estarán debajo de la barra de estado; si agregas una metaetiqueta negra-translúcida, los 0 px superiores de tu viewport coincidirán con la parte superior física de la pantalla.

Confiabilidad de la instalación

En iOS y iPadOS anteriores a la versión 15.4, el archivo de manifiesto solo se carga desde la red cuando el usuario abre la hoja compartida (con el ícono de compartir en el navegador) y no cuando se carga la página. Por lo tanto, el navegador no verifica si tu sitio web es una AWP hasta ese momento, lo que puede generar situaciones en las que el manifiesto no se puede cargar o tarda demasiado, y el navegador lo ignora.

Cuando el navegador no puede cargar el manifiesto a tiempo, presionar "Agregar a la pantalla principal" coloca un ícono en la pantalla principal, pero no proporciona una experiencia de app; solo será un acceso directo a una pestaña del navegador.

Recursos