Progressive web app for iOS : créer une application web progressive pour iPhone et iPad

Créer une application pour iPhone ou iPad implique souvent de choisir entre deux chemins : développer une application native, avec son lot d’outils et de contraintes, ou miser sur le web. La progressive web app, ou PWA, propose une troisième voie : une application accessible depuis un navigateur, installable sur l’écran d’accueil et capable de fonctionner en partie hors ligne.

Sur iOS, cette promesse vient toutefois avec quelques astérisques. Apple a progressivement amélioré la prise en charge des PWA, mais Safari et les autres navigateurs de l’écosystème n’offrent pas exactement les mêmes possibilités que les plateformes Android. Voici comment créer une PWA pour iPhone et iPad, et surtout comment éviter les mauvaises surprises au moment de la tester.

Une PWA, c’est quoi au juste ?

Une PWA est un site web enrichi de fonctionnalités qui le rapprochent d’une application : installation sur l’écran d’accueil, affichage sans l’interface habituelle du navigateur, mise en cache de certaines ressources et, selon la plateforme, notifications push.

Imaginez un site comme un restaurant accessible depuis la rue. Une PWA, c’est le même restaurant, mais avec une porte d’entrée dédiée, une partie de la carte déjà disponible et un service qui continue de fonctionner quand la connexion joue les divas. Ce n’est pas forcément une application native déguisée : c’est d’abord un site, conçu pour offrir une expérience proche d’une application.

Sur iPhone et iPad, l’utilisateur ajoute généralement la PWA à son écran d’accueil depuis Safari. L’application s’ouvre alors dans une fenêtre autonome, sans barre d’adresse permanente. Elle peut aussi bénéficier d’un cache hors ligne et, depuis iOS 16.4, envoyer des notifications web push si certaines conditions sont respectées.

Les fondations à prévoir

Une PWA iOS repose sur les mêmes bases qu’une PWA ailleurs : un site responsive, une connexion sécurisée en HTTPS, un fichier manifeste et un service worker. Chaque élément joue un rôle précis. Le manifeste décrit l’application ; le service worker gère notamment la mise en cache ; le responsive évite de transformer l’iPhone en version miniature d’un site de bureau.

HTTPS : indispensable pour utiliser les service workers en production, sauf sur localhost pendant le développement.
Un site adapté au mobile : le contenu doit rester lisible et les commandes faciles à utiliser au doigt.
Un manifeste web : il définit le nom, les icônes, les couleurs et le mode d’affichage de l’application.
Un service worker : il intercepte certaines requêtes et permet de servir des ressources mises en cache.

Un site qui n’a que le manifeste peut déjà être proposé à l’installation, mais il ne devient pas magiquement utilisable hors ligne. À l’inverse, un service worker sans stratégie claire peut faire ressortir une vieille version du site au moment le moins opportun. La PWA est une petite mécanique : autant savoir quelles pièces on installe.

Lire Créateur d'application mobile : comment choisir le bon outil pour concevoir son application

Créer le manifeste de la PWA

Le manifeste est un fichier JSON, souvent nommé manifest.webmanifest. Il indique au navigateur comment présenter l’application lorsqu’elle est installée. Voici un exemple minimal :

{  "name": "Carnet de recettes",  "short_name": "Recettes",  "start_url": "/",  "display": "standalone",  "background_color": "#ffffff",  "theme_color": "#3b6b4b",  "icons": [    {      "src": "/icons/icon-192.png",      "sizes": "192x192",      "type": "image/png"    },    {      "src": "/icons/icon-512.png",      "sizes": "512x512",      "type": "image/png"    }  ]}

Le champ display détermine la présentation de l’application. La valeur standalone demande une fenêtre sans interface classique du navigateur. start_url indique la page à ouvrir au lancement : elle doit être accessible et correspondre au parcours réellement souhaité, pas simplement à une URL choisie au hasard un vendredi à 17 h.

Ajoutez ensuite le manifeste dans l’en-tête HTML :

<link rel="manifest" href="/manifest.webmanifest"><meta name="theme-color" content="#3b6b4b"><meta name="viewport" content="width=device-width, initial-scale=1">

Prévoyez des icônes nettes, aux tailles annoncées dans le manifeste. Sur iOS, une icône spécifique pour l’écran d’accueil reste utile : elle permet de mieux contrôler le résultat que l’icône générée automatiquement à partir du site.

<link rel="apple-touch-icon" href="/icons/apple-touch-icon.png">

Installer la PWA sur iPhone ou iPad

Sur iOS, l’installation ne passe généralement pas par une bannière automatique comparable à celle que certains utilisateurs connaissent sur Android. L’utilisateur ouvre le site dans Safari, touche le bouton de partage, puis sélectionne « Sur l’écran d’accueil ». Selon la version du système, le libellé ou l’emplacement peut varier légèrement.

Cette étape est importante pour gérer les attentes : votre PWA ne va pas nécessairement proposer d’elle-même un bouton d’installation natif. Vous pouvez expliquer le parcours avec un message discret, affiché au bon moment. Par exemple, après que l’utilisateur a consulté quelques recettes, plutôt qu’à la seconde où il arrive sur le site. Personne n’a envie de recevoir un mode d’emploi avant même d’avoir vu le menu.

Une fois ajoutée, l’application peut s’ouvrir en mode autonome. Testez ce parcours sur un véritable iPhone ou iPad : l’aperçu dans les outils de développement ne reproduit pas toujours les détails de l’installation, de l’icône ou des comportements du système.

Le service worker et le mode hors ligne

Le service worker est un script qui s’exécute en arrière-plan et peut intercepter les requêtes du site. Il ne remplace pas le serveur et ne transforme pas toutes les pages en contenu disponible hors ligne. C’est à vous de définir ce qui doit être enregistré et comment l’application réagit lorsqu’une ressource manque.

Un premier exemple consiste à mettre en cache les fichiers essentiels : page d’accueil, feuille de style, script principal et icônes. Voici une version volontairement simple :

const CACHE_NAME = "recettes-v1";const ASSETS = [  "/",  "/offline.html",  "/styles.css",  "/app.js"];self.addEventListener("install", event => {  event.waitUntil(    caches.open(CACHE_NAME).then(cache => cache.addAll(ASSETS))  );});self.addEventListener("fetch", event => {  event.respondWith(    fetch(event.request).catch(() => caches.match(event.request))  );});

Dans cet exemple, le navigateur tente d’abord une requête réseau, puis cherche une copie en cache si la connexion échoue. C’est une stratégie utile pour comprendre le mécanisme, mais pas une recette universelle. Une application de lecture, un outil de réservation et une boutique n’ont pas les mêmes besoins. Une page dynamique peut, par exemple, nécessiter un message « Vous êtes hors ligne » plutôt qu’une ancienne réponse potentiellement périmée.

Lire Comment choisir une app evenementiel adaptée à vos besoins professionnels

Pensez aussi à versionner le cache. Lors d’une mise à jour, le nouveau service worker doit pouvoir remplacer les anciennes ressources. Sinon, vous risquez de corriger un bug côté serveur tout en laissant les utilisateurs consulter la version précédente. Le cache est pratique, mais il a une mémoire d’éléphant — et parfois un sens du timing assez discutable.

Les spécificités d’iOS à connaître

Les PWA sont utilisables sur iOS, mais certaines capacités dépendent de la version du système, du navigateur et du mode de lancement. Les restrictions évoluent avec les mises à jour : il faut donc vérifier les comportements ciblés sur les versions réellement utilisées par votre audience.

Notifications push : depuis iOS 16.4, les web apps ajoutées à l’écran d’accueil peuvent recevoir des notifications web push. La demande d’autorisation doit être déclenchée à la suite d’une action explicite de l’utilisateur, et le site doit être installé dans ce mode.
Installation : l’ajout à l’écran d’accueil passe par le menu de partage. Ne partez pas du principe qu’une invite automatique identique à celle d’autres plateformes sera affichée.
Stockage : les données locales et le cache sont soumis aux règles de gestion du système. Évitez d’y conserver l’unique copie d’informations importantes.
Fonctions natives : l’accès à certaines capacités du téléphone peut différer de celui d’une application native. Vérifiez chaque API nécessaire avant de bâtir tout le produit autour d’elle.

Pour les notifications, la technique ne suffit pas. Il faut un serveur capable d’envoyer les messages via le protocole Web Push, gérer les abonnements et demander l’autorisation au bon moment. Une notification « Nous avons changé notre logo » n’est pas une stratégie d’engagement. C’est juste un excellent moyen d’être ignoré avec méthode.

Soigner l’expérience sur petit écran

Une PWA peut être techniquement installable et pourtant frustrante à utiliser. Sur iPhone, les détails de l’interface comptent : boutons suffisamment grands, formulaires courts, navigation prévisible et contenu qui ne se retrouve pas sous l’encoche ou la barre d’accueil.

Les zones de sécurité peuvent être prises en compte avec les variables CSS prévues à cet effet. Par exemple, un bandeau fixé en bas de l’écran peut ajouter une marge adaptée :

.barre-actions {  padding-bottom: calc(1rem + env(safe-area-inset-bottom));}

Testez aussi le comportement du clavier, les changements d’orientation et le retour dans l’application après une mise en veille. Une interface qui fonctionne parfaitement dans un onglet ouvert depuis trente secondes peut se comporter différemment après plusieurs minutes en arrière-plan.

Lire Coût création application : guide des prix et des solutions de développement mobile

Enfin, annoncez clairement l’état de la connexion. Si une action nécessite Internet, mieux vaut l’expliquer avant qu’un utilisateur remplisse un formulaire complet dans le métro pour découvrir ensuite que rien n’a été envoyé. Une sauvegarde locale temporaire peut aussi éviter ce scénario — toujours moins coûteuse qu’un courriel intitulé « Votre application a perdu mes données ».

Tester avant de publier

La checklist de lancement ne se limite pas à vérifier que la page s’affiche. Testez l’installation, l’ouverture en mode autonome, la navigation hors ligne, les mises à jour du service worker et les tailles d’écran ciblées. Pour les notifications, vérifiez le parcours complet, depuis le consentement jusqu’à la réception du message.

Ouvrir le site dans Safari sur un appareil réel.
Ajouter la PWA à l’écran d’accueil et vérifier son icône et son nom.
Activer puis couper la connexion pour observer les écrans disponibles.
Mettre à jour les fichiers du site et confirmer que le nouveau cache est utilisé.
Vérifier l’accessibilité : contraste, navigation, taille des textes et libellés des commandes.

Les outils de développement des navigateurs de bureau aident à inspecter le manifeste et le service worker, mais ils ne remplacent pas les essais sur appareil. L’iPhone reste le juge de paix, avec ses gestes, ses contraintes d’écran et ses propres règles de gestion des ressources.

PWA ou application native : le bon choix dépend du projet

Une PWA est particulièrement intéressante lorsqu’il faut publier rapidement, partager une seule base de code et rendre le service accessible par une URL. Pour un média, un catalogue, un outil métier ou un service de consultation, elle peut offrir un compromis très efficace.

Une application native sera parfois préférable si le projet dépend fortement de fonctions système avancées, exige une intégration poussée à iOS ou doit respecter les exigences d’une distribution précise. Les deux approches ne sont pas des camps ennemis : elles répondent à des besoins différents.

Pour créer une PWA iOS solide, partez donc des usages, pas de la liste des technologies à cocher. Un site rapide, lisible et fiable hors ligne sur les parcours importants vaudra toujours mieux qu’un bouton d’installation spectaculaire posé sur une expérience bancale. La bonne PWA ne cherche pas à faire oublier qu’elle vient du web : elle fait simplement le travail, proprement, jusque sur l’écran d’accueil.