PWA sur iOS 14 Beta : modifications subtiles

C'est encore une fois que nous explorons tous les changements avec la dernière version d'iOS - iOS 14 Beta 6 - et discutons avec vous de ce qui a changé, des nouveautés avec l'état de l'adoption des PWA sur iOS. Comme on l'a vu dans notre dernier article PWA iOS 13, il y avait beaucoup de bonnes nouvelles à avoir dans la dernière version, et il semblait bien qu'Apple devenait plus convivial pour PWA. Mais maintiennent-ils leur rythme d'adoption des PWA, ou abandonnent-ils complètement les PWA de peur de perdre les revenus des applications ? Eh bien, c'est ce que nous sommes ici pour découvrir.

Notes de version

Voici quelques-uns des changements importants que nous savons apporter à Safari dans cette nouvelle version (certaines des parties non pertinentes ont été omises) :

• Prise en charge des extensions Web Safari sur macOS.
• Prise en charge de HTTP/3.
• Amélioration du taux de réussite des tests de la plate-forme Web pour WebDriver, XHR+Fetch, Service Workers, CSS et SVG.
• Activation du blocage complet des cookies tiers et de l'API d'accès au stockage en mode de navigation privée.
• Suppression de la prise en charge de Flash
• Ajout d'un authentificateur de plate-forme d'authentification Web utilisant Face ID ou Touch ID, selon la capacité présente.

Nous pouvons dire à quoi vous pensez - des changements pas si importants, n'est-ce pas ? Eh bien, il s'avère qu'il y a plus à PWA iOS 14 qu'il n'y paraît.

Creuser plus dedans

C'est la partie où nous creusons davantage dans le système d'exploitation et découvrons l'état actuel de PWA dans iOS 14 - y compris quels sont les changements et comment PWA a été amélioré, et à quoi pouvons-nous nous attendre lorsque iOS 14 atteindra la version stable mondiale.

Les biens

Premier signe de Service Worker

Il y a une nouvelle fonctionnalité WebKit dans cette mise à jour qui s'appelle App-Bound Domains et, avec cette fonctionnalité activée, l'API Service Workers peut en fait être activée sur les domaines liés. Bien qu'il n'y ait pas de documentation officielle sur ce que nous pouvons attendre des techniciens de service - ni de confirmation quant à savoir si cette fonctionnalité est là pour rester ou non - nous pensons que c'est toujours une nouvelle très prometteuse pour les passionnés de PWA.

Domaines liés aux applications

Ce que cette nouvelle fonctionnalité apporte à la table est un moyen pour les développeurs de restreindre la navigation dans l'application à un certain nombre de domaines et, à son tour, de garantir plus de sécurité pour les utilisateurs finaux. Ces domaines « liés à l'application » sont spécifiés dans le fichier info.plist , sous la clé WKAppBoundDomains , comme ceci :

 <plist version="1.0">
<dict>
<key>WKAppBoundDomains</key>
<tableau>
    <string>exemple1.com</string>
    <string>exemple2.org</string>
    ...
</array>
</dict>

Avec les domaines liés à l'application activés, nous pouvons désormais enregistrer les techniciens de service :

Il n'y a cependant que de vagues explications sur la raison pour laquelle les service workers sont activés lorsque nous avons configuré des domaines liés aux applications. Et comme il n'y a aucun moyen de déboguer les instances de service workers, le tout est encore relativement vague même pour les développeurs les plus expérimentés.

Prenons par exemple le stockage en cache, la caractéristique déterminante des techniciens de service. Il est introuvable sous Stockage dans Safari DevTools, et l'enregistrement des techniciens de service, pour citer les développeurs expérimentés qui ont effectué le travail majeur : "n'est pas partagé avec Safari, les applications Web de l'écran d'accueil ou d'autres applications utilisant WKWebView et App Bound Domains sur les mêmes origines.

Bien que nous n'ayons pas encore une image complète, le fait que Service Worker soit une chose dans iOS est toujours un motif de célébration, et nous ne pouvons qu'espérer que la version stable pourra nous donner une image plus complète.

Nouveau support pour TouchID et FaceID

Récemment introduits lors de l'Apple Worldwide Developers Conference (WWDC), Touch ID et Face ID sont enfin disponibles sur Safari via l'API WebAuthn. Une fois intégrées, ces fonctionnalités offriront une expérience sans friction pour votre PWA et, à leur tour, amélioreront l'expérience utilisateur.

Possibilité de changer de navigateur par défaut

À partir d'iOS 14, les utilisateurs peuvent enfin choisir différents navigateurs par défaut . C'est (en quelque sorte) une bonne décision d'Apple et une bonne nouvelle pour les utilisateurs d'Apple du monde entier, car la modification des applications par défaut n'était tout simplement pas possible auparavant. Mais tenez votre cheval pour l'instant, cela ne signifie pas que les utilisateurs d'Apple peuvent bénéficier de toutes les fonctionnalités intéressantes que les différents moteurs de navigateur Web apporteront - en fait, c'est la même chose. Les navigateurs tiers sont toujours soumis à la restriction de s'appuyer sur WebKit d'Apple comme moteur de navigation sous-jacent , ce qui signifie que même si vos nouveaux navigateurs Web par défaut peuvent sembler brillants et différents à l'extérieur, rien n'est vraiment changé à l'intérieur.

Géolocalisation pour le Web

Alors, qu'en est-il de l'état de l'API de géolocalisation du W3C dans Safari ? Eh bien, certains changements se traduisent par un meilleur suivi de la localisation, mais pas en conséquence directe des améliorations apportées à l'API de géolocalisation du W3C. Étrange? Nous savons. Plongeons-nous davantage dans ceci :

Lorsque l' emplacement précis est activé par application dans la nouvelle version bêta d'iOS 14, nous pouvons demander à Safari de suivre notre emplacement approximatif :

L'emplacement approximatif n'est connu que par le système d'exploitation, et pendant le processus d'analyse de ce nouveau comportement de suivi de l'emplacement dans iOS, personne n'a vraiment trouvé de réponse concluante à la façon dont le nouvel iOS 14 Beta 6 fournit des emplacements approximatifs aux PWA. Mais en regardant les données jusqu'à présent, cela semble prometteur. Vous trouverez ci-dessous un exemple du travail de Flirt qui utilise Iguazu comme emplacement de suivi.

Comme vous pouvez le constater, l'API détermine et affiche avec précision l'emplacement du sujet. Nous pensons que ce résultat impressionnant a quelque chose à voir avec les modifications à venir de l'API Core Location qui ont été présentées dans cette vidéo WWDC2020.

Clips d'application - peut-être une bonne chose

Avec le nouveau App Clip, les développeurs peuvent offrir une expérience "de type installation PWA" simplement en utilisant une balise meta :

 <meta name="apple-itunes-app" content="app-id=myAppStoreID, app-clip-bundle-id=appClipBundleID,affiliation-data=myAffiliateData, app-argument=myAppArgument">

Vous pouvez imaginer que cette nouvelle fonctionnalité App Clip fonctionne de la même manière que l' application instantanée sur Android, à la différence qu'elle est davantage axée sur la numérisation NFC et QR et permet aux utilisateurs d'installer éventuellement des applications natives.

Quel est le potentiel de cette nouvelle fonctionnalité ? Nous ne savons pas, mais cela pourrait s'avérer être un pas vers les PWA installables que nous avons sur Android.

Les mauvais

Nouvelle galerie d'applications ignorant les PWA

La nouvelle bibliothèque d'applications est une fonctionnalité automatisée qui trie et organise votre application par utilisation de l'application, catégories, etc. n'est pas cohérent et est sujet à des changements.

En réalité, les premiers testeurs ont découvert que les PWA étaient ignorées et n'apparaissaient pas du tout dans la nouvelle bibliothèque d'applications, que ce soit dans le groupe " Récemment ajoutés " ou " Suggestions ". Ainsi, bien qu'il puisse être agréable que les PWA bénéficient du même type de traitement que les applications natives, c'est toujours une nouvelle choquante pour nous car nous ne nous attendions pas à ce que les PWA soient simplement ignorées.

Aucune modification de la prise en charge du manifeste d'application Web

Comme vous vous en doutez, il n'y a aucun mouvement de la part d'Apple pour faire pression pour la prise en charge de Web App Manifest. L'état de la prise en charge du manifeste d'application Web reste Partiellement pris en charge , ce qui signifie qu'il n'y a pas de prise en charge des icons , minimal-ui , fullscreen , orientation ou theme-color .

Barre d'état

Bien qu'il soit agréable de voir iOS prendre la ou les valeurs de theme-color à partir du manifeste de l'application Web, nous devrions nous contenter de moins en attendant. À partir de la version 5 d'iOS 14 beta, nous ne pouvons plus avoir de barre d'état blanche et les seules valeurs acceptées sont black et black-translucent .

Les laids

Les fonctionnalités de base ne sont toujours pas prises en charge

C'est une grosse mise à jour, mais il manque encore quelque chose. Cela a probablement quelque chose à voir avec le fait que certaines fonctionnalités de base de PWA ne sont toujours pas prises en charge, et il n'y a presque aucun mouvement d'Apple pour pousser ces fonctionnalités :

• Poussée Web
• Synchronisation en arrière-plan
• Cycle de vie des pages
• Service Workers sur WebViews (ce qui signifie qu'il n'y a pas de PWA sur Chrome, Firefox, Instagram ou Facebook où la navigation Web n'est pas l'objectif principal)
• Liens universels / Capture de lien

Conclusion

Que pensez-vous de tous ces changements à venir ? De notre côté, on sent qu'on se retrouve avec une note décevante après avoir passé en revue tous les changements. Il y a quelques changements - par exemple les domaines liés aux applications, la géolocalisation - qui semblent être un pas dans la bonne direction, mais Apple n'a pas vraiment pris la peine de pousser pour plus de fonctionnalités de base de PWA dans cette mise à jour. Et cela a du sens, nous supposons, puisque c'est d'Apple dont nous parlons ici - dont nous avons toujours su qu'il était si catégoriquement contre le Web.