Les systèmes d'exploitation mobiles rendaient les applications tangibles : elles avaient des icônes, des noms, des écrans de lancement et des fenêtres autonomes. Les sites web, eux, avaient des URL. Le manifeste d'application web a comblé cet écart sans empaqueter le site dans un binaire natif.
La spécification du W3C définit un format de fichier basé sur JSON pour les métadonnées associées à une application web : nom, icônes, URL de lancement préférée, orientation, mode d'affichage, portée et comportement de liaison profonde.
MDN décrit l'usage le plus courant du manifeste comme consistant à fournir au navigateur les informations nécessaires pour installer une application web progressive sur un appareil. Cela a rendu le choix de conception puissant : un site web pouvait rester un site web et devenir malgré tout une application lançable.
Placer l'identité de l'application dans manifest.json
JSON correspondait aux outils et aux habitudes de déploiement qu'avaient déjà les développeurs web.
Une balise link permettait à n'importe quelle page d'annoncer son manifeste sans nouveau système de découverte.
Scope et start_url donnaient aux navigateurs des limites suffisantes pour lancer la bonne surface d'application.
Les icônes et le mode d'affichage rendaient les sites web installables cohérents sur un écran d'accueil.
Lorsqu'une plateforme n'a pas d'étape d'installation, ne copiez pas tout le modèle de l'app store. Normalisez les métadonnées dont le lanceur a besoin et gardez l'application sur le web.
Le manifeste d'application web est devenu l'une des pièces centrales des applications web progressives, aux côtés des service workers et de HTTPS. Son génie est modeste : le navigateur effectue l'installation parce que le site a fourni la carte d'identité manquante.
VÉRIFIEZ LES SOURCES
Les sources
- Web Application Manifest World Wide Web Consortium · w3.org ·
- Web application manifest MDN Web Docs · developer.mozilla.org