Découvrez WebKit pour SwiftUI

Bonjour, je suis Richard, ingénieur dans l’équipe WebKit. WebKit est le moteur de rendu au cœur de Safari, Mail et d’innombrables apps iOS, iPadOS, visionOS et macOS. WebKit permet aux développeurs de créer des apps riches et dynamiques en y intégrant toute la puissance et la flexibilité du Web et des plates-formes Apple. Cette année, j’ai le plaisir de vous présenter WebKit pour SwiftUI. Avec notre nouvelle API SwiftUI, il n’a jamais été aussi facile d’intégrer des contenus web à vos apps. Vous allez sûrement adorer utiliser WebKit pour SwiftUI, qui combine la puissance du Web prise en charge par WebKit avec la facilité d’utilisation de SwiftUI. Avec la nouvelle API, afficher du contenu web de qualité est aussi simple que de créer une vue web et de lui fournir une URL. Et cela fonctionne sur toutes les plates-formes prises en charge par WebKit. Il est désormais très facile de se lancer grâce à WebKit et SwiftUI. Examinons de nouvelles façons incroyables d’utiliser cette API pour créer votre app. Découvrons les différentes façons de charger et d’afficher votre contenu web, y compris les ressources locales. Voyons ensuite toutes les façons dont vous pouvez modifier votre contenu web ou réagir à ses modifications. Enfin, apprenons à personnaliser l’interaction des utilisateurs avec votre contenu web : modificateurs de vue existants et nouveaux, activation de la recherche dans la page, position de défilement, etc.

Cela fait beaucoup de choses, alors commençons. Pour montrer toutes les possibilités de la nouvelle API, je crée une app sur les lacs dans le monde. Je vous montre comment charger et afficher du contenu d’articles web dans l’app, communiquer avec JavaScript pour l’animer et observer la navigation. Et comment personnaliser ce parcours du contenu web exactement comme vous le souhaitez. Enfin, nous améliorons l’apparence et l’interactivité de l’app avec une combinaison de modificateurs de vue nouveaux et familiers. Commençons la création de l’app. J’ai déjà configuré une partie du code SwiftUI, nous pouvons nous concentrer sur l’intégration des nouvelles API WebKit. Commençons par les bases, l’affichage de contenu web. La nouvelle API WebView rend cela incroyablement simple. Cette toute nouvelle vue SwiftUI affiche très facilement n’importe quel contenu web. Pour utiliser une WebView, il suffit de lui donner une URL, et elle charge et affiche automatiquement son contenu. Mais vous n’allez pas utiliser WebView uniquement pour afficher une seule URL. Dans cet exemple, nous avons une bascule entre deux URL, et nous donnons à nouveau l’URL à la WebView. Désormais, chaque fois que la bascule est modifiée, la vue web se charge automatiquement et accède à la nouvelle URL. Un jeu d’enfant ! Mais vous pouvez mieux utiliser votre contenu web, comme réagir aux changements apportés à ses propriétés. Dans ces cas, créez simplement une WebPage, puis connectez-la à votre WebView. Ainsi, toutes les modifications apportées au contenu web sont désormais disponibles via la page web, comme le titre de la page.

WebPage est une toute nouvelle classe Observable qui représente votre contenu web. Elle a été conçue pour fonctionner parfaitement avec Swift et SwiftUI.

Vous utilisez WebPage pour charger, contrôler et communiquer avec du contenu web. WebPage peut être utilisée indépendamment. Mais combinée avec WebView, elle vous permet d’améliorer votre contenu web. Regardons comment charger du contenu web à l’aide de WebPage. Charger une URL distante dans votre page web est une action très courante. Il vous suffit pour cela d’utiliser l’API de chargement avec une requête d’URL. Mais WebPage ne se limite pas au chargement d’URL. Vous pouvez également charger du contenu HTML directement en fournissant la chaîne HTML et une URL de base à l’API. L’URL de base est utilisée lorsque le système exécute les URL relatives dans le HTML. WebPage peut également charger directement différents types de données, comme les données d’archives web. Donnez-lui simplement les données à charger, leur type MIME et leur encodage de caractères, ainsi qu’une URL de base. Dans mon app, je commence par créer une classe ArticleViewModel qui représente un article spécifique. Et à l’intérieur, je mets la WebPage associée et l’article Lake associés. Pour que SwiftUI puisse réagir facilement à tout changement sur la page et l’article, je rends la classe Observable. Maintenant que j’ai les bases de la classe, j’ajoute une fonction pour charger l’URL du lac dans la page web. Passons maintenant du côté de la vue. Je crée une WebView à l’aide de la webPage du modèle. Et j’appelle la fonction loadArticle du modèle lorsque la vue s’affiche pour la première fois. Pour faire plus beau, j’utilise également ignoreSafeArea afin que la page s’écoule jusqu’au bas de l’appareil. Désormais, lorsque vous ajoutez une nouvelle URL d’article à l’app et que vous l’ouvrez, elle se charge et affiche son contenu dans la vue détaillée. C’est un très bon début. Pour améliorer l’expérience, je fournis quelques articles préchargés dans l’app. WebKit gère le chargement des URL et des données distantes sans surprise, nativement. Mais il vous permet également de charger du contenu regroupé dans votre app ou d’accéder à des fichiers locaux. Vous pouvez le faire grâce au tout nouveau protocole URLSchemeHandler. Voici comment l’utiliser. Lorsque vous activez votre propre gestionnaire de schéma, toutes les navigations vers une URL avec ce schéma passent par le gestionnaire et utilisent les données que vous fournissez. Mais voyons d’abord ce qu’est un schéma. Le schéma est la partie de l’URL située avant les deux-points, dans ce cas le schéma HTTPS. WebKit gère les schémas courants tels que https, file et about. Mais pour les schémas personnalisés, comme par exemple ce schéma lakes, le protocole URLSchemeHandler permet au code d’application de gérer le chargement des ressources pour les URL du schéma lakes. Pour activer votre propre gestionnaire de schéma personnalisé, créez un type qui confirme le protocole URLSchemeHandler et activez la fonction de réponse du protocole en renvoyant une séquence asynchrone de résultats URLSchemeTask. La fonction vous donne également un paramètre URLRequest pour décider comment répondre. Lors de la création de la séquence d’événements, vous devez d’abord générer une URLSchemeTaskResult qui contient une URLResponse. Après avoir donné une URLResponse, il vous suffit ensuite de fournir quelques données. C’est génial dans la plupart des cas, mais parfois, vous souhaitez diffuser des données de manière asynchrone. Grâce au type de retour AsyncSequence, vous pouvez facilement le faire aussi. Ici, j’obtiens une seule réponse de manière asynchrone. Et je reçois également une AsyncSequence de valeurs de données, que j’ajoute ensuite à la séquence renvoyée. Si la tâche du schéma d’URL est annulée à un moment donné, la tâche à l’intérieur de la fonction est également annulée automatiquement. Dans mon app, je veux préinstaller et charger quelques lacs pour que les utilisateurs débutent avec un contenu existant. Pour activer cette fonctionnalité, je place des ressources HTML et CSS dans mon app, puis j’utilise le gestionnaire de schéma personnalisé que je viens de créer. Maintenant, il ne me reste plus qu’à enregistrer le gestionnaire de schéma auprès de la WebPage. Pour cela, je crée un URLScheme en utilisant le schéma que je veux gérer. Ici, j’utilise à nouveau lakes. Si vous fournissez un schéma déjà géré par WebKit, l’initialiseur renvoie nil. Je crée maintenant une configuration WebPage et j’ajoute le gestionnaire de schéma à son dictionnaire urlSchemeHandlers. Je veille à transmettre la configuration lorsque je crée la WebPage. Avec cela, je peux maintenant créer des valeurs LakeArticle par défaut et leur donner une URL avec mon schéma personnalisé, de sorte que le contenu web soit chargé à partir des ressources enregistrées dans le bundle au lieu d’être récupéré sur le Web. Vous savez maintenant comment charger de nouvelles pages et y accéder. Lorsque la page a fini de se charger, je veux remplir la barre latérale avec sa table des matières. Je peux le faire en observant les événements de navigation qui se produisent sur le contenu web, ce qui est très facile à faire. Vous pouvez désormais accéder facilement à l’état de navigation à l’aide de la nouvelle propriété Observable currentNavigationEvent sur WebPage. Une fois que vous avez cet événement, vous pouvez obtenir son ID de navigation, puis prendre des mesures en fonction du type d’événement. Je sais, ça fait beaucoup. Examinons les différents types d’événements de navigation. Une navigation est composée de plusieurs événements séquentiels. La navigation commence toujours par startedProvisionalNavigation. Vous pouvez obtenir un événement receivedServerRedirect si le serveur redirige la demande. Vous obtenez un événement validé lorsque la page a commencé à recevoir du contenu pour le cadre principal. L’événement d’arrivée arrive lorsque la navigation est terminée, bien que cela ne soit pas toujours garanti. Une navigation peut également échouer à tout moment, auquel cas les événements failed ou failedProvisionalNavigation sont émis. Et lorsqu’une nouvelle navigation démarre, la propriété currentNavigationEvent reflète désormais cette navigation. Vous voulez pouvoir réagir en permanence à toute navigation, comme lorsqu’un utilisateur clique sur un lien ou que vous appelez la fonction de chargement.

Pour cela, vous pouvez utiliser la nouvelle API Observations, disponible dans Swift 6.2. J’utilise Observations pour créer une séquence asynchrone à partir de currentNavigationEvent, puis j’utilise une boucle for-await pour observer chaque modification de l’événement actuel. De cette façon, je peux soit gérer les erreurs qui surviennent, soit mettre à jour les sections de l’article une fois son chargement terminé. Il est ainsi plus facile que jamais de répondre aux changements de navigation dans votre contenu web. Avec currentNavigationEvent, il existe bien d’autres propriétés sur WebPage qui peuvent être observées pour les modifications, et elles fonctionnent toutes parfaitement avec SwiftUI. Par exemple, je veux que la barre de navigation de la vue détaillée affiche le titre de l’article. Je peux le faire en définissant simplement navigationTitle sur la propriété title de la WebPage. Rien de plus simple. Il y a bien d’autres propriétés utiles au-delà du titre de la page, telles que l’URL actuelle, la progression estimée du chargement et la couleur du thème de la page, etc. Ces propriétés sont très utiles. Mais parfois, vous voulez obtenir des informations spécifiques de la page en plus des propriétés standard. Vous avez donc besoin de quelque chose d’un peu plus flexible. C’est ce que nous avons fait. Vous pouvez évaluer directement JavaScript pour communiquer avec une page à l’aide de la nouvelle API callJavaScript. Il vous suffit d’écrire une fonction JavaScript comme d’habitude, puis de la transmettre lorsque vous utilisez callJavaScript. Le type de retour callJavaScript est une valeur Any facultative. Veillez donc à la convertir en un type Swift approprié pour qu’elle soit plus facile à utiliser. Cela facilite la mise en œuvre de ma fonction parseSections en utilisant le HTML de la page et en obtenant tous les identifiants et titres de chaque section. Je convertis aussi le résultat en un tableau de structures de sections pour faciliter sa manipulation.

Désormais, l’app affiche les sections de l’article dans la barre latérale dès son chargement. WebPage vous donne également la possibilité de les stratégies de navigation exactement comme vous le souhaitez, en utilisant le nouveau protocole WebPage.NavigationDeciding. Dans mon app, je mets en œuvre des règles de navigation personnalisées afin que les navigations au sein du contenu web se comportent comme je le veux. S’il y a un lien dans une page vers un site externe, je veux absolument qu’il s’ouvre dans mon navigateur par défaut au lieu de se charger dans mon app. Pour cela, je crée un nouveau type NavigationDecider qui confirme WebPage.NavigationDeciding. Ce protocole vous permet de spécifier différentes politiques pour différentes étapes de votre navigation, comme avant qu’elle ne se produise, lorsque vous recevez une réponse et lorsque l’authentification est nécessaire. Puisque je veux déterminer si une navigation doit être autorisée ou non en fonction de son URL, je spécifie la politique d’une action de navigation. Cette fonction fournit la NavigationAction utilisée dans la navigation, ainsi que NavigationPreferences, que vous pouvez ajuster en fonction de la demande. Si le schéma d’URL est lakes ou si l’hôte est lakes.apple.com, j’autorise la navigation, car le lien fait partie de l’app et n’est pas externe. Si ce n’est pas le cas, je ne veux pas que la WebPage de l’app continue la navigation. Donc, je l’annule et mets à jour la propriété urlToOpen sur ArticleViewModel. Maintenant que j’ai un NavigationDecider personnalisé, je dois configurer ma page web pour l’utiliser. Pour en revenir à ArticleViewModel, je crée un nouveau décideur de navigation et une nouvelle propriété urlToOpen. Et je mets à jour ma WebPage pour prendre en compte le décideur de navigation afin qu’elle utilise la politique que j’ai spécifiée précédemment. Maintenant que la WebPage est configurée, il manque une dernière étape pour réunir toutes ces fonctionnalités.

Dans ArticleView, j’écoute les modifications apportées à la propriété urlToOpen sur le modèle. Si la propriété n’est pas nulle, je sais que la navigation a été annulée. J’utilise donc la valeur d’environnement openURL SwiftUI pour ouvrir l’URL dans le navigateur par défaut. Maintenant, les navigations fonctionnent exactement comme je veux. Passons aux différentes façons dont vous pouvez personnaliser l’interaction avec votre contenu web à l’aide des modificateurs de vue. Commençons par configurer le comportement de défilement afin que la vue web ne rebondisse que verticalement. Par défaut, les vues web rebondissent lorsqu’elles défilent au-delà des bords verticaux ou horizontaux, même si le contenu est plus petit que la vue web. Le modificateur scrollBounceBehavior standard vous permet de personnaliser ce comportement et fonctionne parfaitement avec WebView. Pour configurer l’axe horizontal afin qu’il rebondisse uniquement si le contenu est plus grand que la vue, la valeur .basedOnSize peut être définie pour l’axe horizontal. Ce n’est qu’une des nombreuses fonctionnalités de personnalisation du défilement prises en charge par WebView. Mais ce n’est pas tout. La nouveauté de cette année sur visionOS est le défilement, qui peut facilement être configuré à l’aide d’un seul modificateur de vue.

Sur visionOS, WebView prend en charge la nouvelle apparence ScrollInputKind lors de l’utilisation du nouveau modificateur webViewScrollInputBehavior. Par défaut, Regarder pour faire défiler est désactivé dans WebView. Puisque nous voulons qu’il soit activé dans notre app, j’utilise le modificateur et définis son comportement sur activé pour le type d’apparence. Certains articles sont assez longs, et nous voulons faciliter la recherche. Pour faciliter la recherche dans les articles, ajoutons la prise en charge de Find-In-Page. Le modificateur findNavigator existant fonctionne déjà parfaitement avec WebView, donc la prise en charge de Find-In-Page est vraiment un jeu d’enfant. Pour afficher le navigateur de recherche, j’ajoute un bouton à la barre d’outils de l’app. Sur iOS et iPadOS, le navigateur de recherche s’affiche en bas de la vue web ou sur le clavier à l’écran quand il est visible. Sur macOS et visionOS, il s’affiche en haut de la vue web. L’app commence vraiment à prendre forme maintenant. Rendons-la encore plus accessible en facilitant le défilement. Un autre moyen simple de naviguer dans un article consiste à choisir une section dans la barre latérale et à faire défiler la vue web jusqu’à cette section. Je dois synchroniser la position de défilement de la vue web avec cette section sélectionnée pour la situer. D’abord, j’ajoute une fonctionnalité qui fait défiler la vue web jusqu’à une section de la barre latérale lorsqu’un utilisateur la touche. Pour faire défiler une section, je dois déterminer où elle se trouve, ce que je peux faire à l’aide d’une fonction JavaScript que j’ai précédemment configurée. Pour exécuter le script, j’utilise à nouveau callJavaScript. Cette fois, cependant, je lui fournis un dictionnaire d’arguments. Les clés de ce dictionnaire sont représentées en JavaScript sous forme de variables locales, et leurs valeurs sont converties en valeurs JavaScript. C’est un moyen très puissant, mais facile à utiliser pour créer des fonctions JavaScript génériques réutilisables. Dans ArticleView, j’ajoute un état pour pouvoir contrôler la position du défilement et la section. J’associe une position de défilement à une WebView grâce au nouveau modificateur webViewScrollPosition. Maintenant, je dois définir la position de défilement chaque fois que la section change en utilisant simplement scrollTo sur la position de défilement et en lui donnant la position calculée pour la section. Maintenant que je peux faire défiler jusqu’à une section à l’aide de la barre latérale, je veux également que celle-ci se mette à jour quand je fais défiler. Le nouveau modificateur WebView onScrollGeometryChange peut faire cela et plus encore. Chaque fois qu’une partie de la géométrie de défilement de WebView change, comme son décalage de contenu ou sa taille, par exemple, le modificateur utilise la transformation que vous lui donnez et appelle sa fermeture si la valeur transformée change. Dans la clôture, je calcule la section la plus proche du nouveau décalage de défilement et je mets à jour la section sélectionnée. Et du coup, la section sélectionnée et la position de défilement sont désormais parfaitement synchronisées. Avec cela, l’app Lakes est maintenant terminée. Je pense que ça s’est bien passé. J’ai combiné WebPage et WebView pour charger et afficher les articles, et j’ai même pu pré-remplir l’app avec certains articles par défaut. J’ai également amélioré l’expérience utilisateur en affichant la table des matières dans la barre latérale et en synchronisant la position de défilement. Nous avons vu beaucoup de choses aujourd’hui, alors récapitulons ce que nous avons appris. WebKit pour SwiftUI est une API simple et puissante qui permet d’intégrer facilement du contenu web à votre app. Il offre la possibilité de charger et de personnaliser l’apparence du contenu web. URLSchemeHandling vous permet de gérer efficacement les ressources web locales. De plus, un ensemble de modificateurs d’affichage puissants tels que webViewScrollPosition et findNavigator vous permet de personnaliser l’expérience utilisateur de votre WebView. Et ce ne sont là que quelques-unes des fonctionnalités de WebKit pour SwiftUI. Je vous recommande donc vivement de consulter la documentation pour les développeurs pour plus d’informations. Et bien sûr, avec SwiftUI, votre contenu web est magnifique sur toutes les plates-formes.

Si vous utilisez déjà l’API UIKit ou AppKit WebKit dans une app SwiftUI, ou si vous créez une app de A à Z, c’est le moment idéal pour essayer la migration vers la nouvelle API. Pensez aussi à regarder les autres nouveautés de Swift et SwiftUI, comme la nouvelle API Observations. Enfin, dès que vous aurez essayé cette nouvelle API, envoyez-nous vos commentaires. Rejoignez-nous pour inaugurer cette nouvelle ère fantastique de WebKit.