PWA, Swift et Kotlin, ou Expo : choisir une architecture d’application mobile
Comparez les PWA, les applications natives en Swift et Kotlin, ainsi qu’Expo en ce qui concerne la base de code, la présence dans les stores, les performances, l’accès au matériel, la vitesse de publication et le coût, puis choisissez.
Sources: PWA vs Native vs Expo: Pros, Cons, and How to Choose the Right Architecture
L’architecture que vous choisissez pour un produit mobile est difficile à modifier par la suite. Un mauvais choix signifie que l’année suivante sera consacrée à résoudre des problèmes liés à la plateforme plutôt qu’à développer de nouvelles fonctionnalités : conflits de dépendances après une mise à jour du framework, absence d’API matérielle, ou éloignement entre les deux équipes chargées du développement natif. Ce guide compare les trois points de départ les plus courants, à savoir les applications web progressives, les applications entièrement natives écrites en Swift et Kotlin, ainsi qu’Expo basé sur React Native, et propose des critères concrets pour choisir parmi eux, que vous soyez en train de créer un MVP ou de planifier la prochaine étape d’une application existante.
Comparaison des trois options
Base de code
- PWA : une seule base de code web construite à l’aide d’HTML, CSS et JavaScript.
Présence dans les stores d’applications
- PWA : fonctionne sur le web. La mise en liste dans un store est optionnelle et repose sur des enveloppes ou des solutions adaptées à chaque plateforme.
- Natif et Expo : distribués directement via l’Apple App Store et Google Play.
Prestations
- Natif : le meilleur niveau de performance. Animation fluide à la fréquence de rafraîchissement maximale de l’écran, jusqu’à 120 fps sur les écrans compatibles, sans aucune couche d’abstraction qui entrave le fonctionnement.
- Expo : proche du natif pour la plupart des interfaces. React Native affiche de véritables vues natives, et sa nouvelle architecture remplace l’ancien pont asynchrone par des appels directs de JavaScript vers le natif via JSI, ce qui élimine un goulot d’étranglement de longue date.
- PWA : limité par ce que le moteur de navigateur permet, en particulier pour les animations lourdes et les tâches en arrière-plan.
Accès au matériel
- Natif : tout ce que la plateforme met à disposition.
- Expo : couverture étendue grâce au SDK Expo, complétée par des plugins de configuration et des modules natifs personnalisés si nécessaire.
- PWA : l’ensemble de fonctionnalités de base disponibles sur le web, comme la caméra et la géolocalisation, avec des lacunes notables sur iOS.
Vitesse de publication
- PWA : les modifications entrent en vigueur dès la mise en production, sans nécessité d’approbation de la boutique.
- Expo : les mises à jour sans connexion (OTA) permettent d’envoyer instantanément du JavaScript et des modifications d’assets, tandis que les changements dans le code natif passent encore par la procédure normale d’examen par la boutique.
- Natif : chaque version passe par le processus d’examen de la boutique.
Cost
- PWA : généralement le moins cher à développer et à maintenir.
- Expo : un investissement modéré avec une seule équipe.
- Natif : le plus coûteux, car deux bases de code pour différentes plateformes impliquent généralement deux équipes spécialisées.
Applications Web Progressives : l’approche centrée sur le web
le support hors ligne avec des service workers explique les mécanismes.
Avantages. Il n’y a pas de boutique d’applications entre vous et vos utilisateurs. Toute personne disposant de l’URL peut utiliser l’application et l’ajouter à son écran d’accueil. Les mises à jour parviennent à tous lors de la prochaine consultation, et le contenu peut être indexé par les moteurs de recherche, ce qui permet une découverte organique que les fiches de boutique ne fournissent que rarement.
Limites. Apple restreint encore les PWA sur iOS. Le web push n’est disponible que pour les applications ajoutées à l’écran d’accueil, et l’exécution en arrière-plan est fortement limitée. Les API Bluetooth web et autres APIs matérielles similaires ne sont pas du tout prises en charge par Safari. Si le produit dépend du Bluetooth, d’un suivi continu en arrière-plan ou d’une intégration profonde avec le dispositif, un PWA rencontrera rapidement des difficultés. Les politiques de la plateforme ont changé à plusieurs reprises, il convient donc de vérifier l’état actuel pour vos versions iOS cibles.
Swift et Kotlin natifs : contrôle maximal
Choisir une solution native signifie développer et maintenir deux applications : l’une en Swift pour iOS et l’autre en Kotlin pour Android.
Points forts. Rien n’est abstrait, ce qui garantit des performances et une fidélité optimales selon les capacités de la plateforme. Les nouvelles API d’Apple et Google sont disponibles dès leur publication, sans avoir à attendre qu’un framework les intègre. C’est le choix idéal pour des graphismes exigeants, de l’AR ou de la VR complexes, ainsi que pour des traitements en arrière-plan intensifs.
Limites. La charge supplémentaire est importante. Deux bases de code doublent approximativement les efforts de développement et de test, et exigent généralement deux équipes aux compétences différentes. Chaque fonctionnalité doit être développée deux fois et maintenue en synchronisation, et chaque mise à jour, même pour corriger une petite erreur, doit attendre l’approbation de la boutique d’applications.
Expo : une seule base de code, résultats natifs
Expo est un framework et un ensemble d’outils open source basés sur React Native. Il masque une grande partie de la complexité liée à la compilation native sur iOS et Android, permettant ainsi à une même base de code JavaScript ou TypeScript de générer des applications natives fonctionnelles pour ces deux plateformes.
Avantages. Le développement s’effectue rapidement. Les Expo Application Services (EAS) compilent les binaires natifs dans le cloud, de sorte que le travail quotidien nécessite rarement l’ouverture de Xcode ou d’Android Studio. EAS Update permet de déployer des correctifs OTA directement sur les applications installées. Il convient de noter que les mises à jour OTA peuvent modifier le code JavaScript et les ressources, mais pas le code natif, et que les politiques des stores déterminent toujours ce qui peut être modifié ; une nouvelle dépendance native implique une nouvelle compilation par le store.
Limites. Les plugins Config et l’API Expo Modules ont rendu le code natif personnalisé bien plus accessible qu’auparavant, et les versions de développement vous permettent d’inclure n’importe quelle bibliothèque native, et non seulement celles fournies par Expo Go. Néanmoins, les applications qui nécessitent des pilotes matériels de très bas niveau ou du C++ personnalisé complexe exigent encore un travail natif réel, et l’équipe a besoin de quelqu’un qui s’y sente à l’aise.
Pour une vue plus large des options multiplateformes en dehors d’Expo, y compris Flutter et Kotlin Multiplatform, consultez l’aperçu du blog sur les frameworks mobiles multiplateformes.
Choisir la bonne architecture
Adaptez l’architecture au produit plutôt qu’au outil préféré de l’équipe :
- Choisissez une PWA lorsque le budget est limité, que la visibilité via les recherches est importante et que le produit se compose principalement de contenu ou de formulaires : une boutique en ligne, un site d’actualités ou un tableau de bord SaaS. C’est également un moyen judicieux de valider la demande avant d’investir dans des applications pour magasin.
- Choisissez Expo pour une startup, un MVP ou une application en production qui doit atteindre à la fois l’App Store et Google Play rapidement avec une seule équipe. Cela couvre la plupart des applications professionnelles et grand public.
- Choisissez la version native pour les jeux haut de gamme, les produits gourmands en matériel tels que des appareils de fitness qui se synchronisent continuellement via Bluetooth, ou toute application où des interfaces à 120 fps et aucun risque d’abstraction sont des exigences réelles.
Ces choix ne constituent pas des solutions définitives et isolées. Une PWA peut coexister avec une application de magasin, et une application Expo peut intégrer des modules natifs écrits en Swift et Kotlin ; ainsi, une approche hybride est souvent possible lorsque l’une des composantes du produit dépasse les limites de la solution par défaut.
En résumé
Aucune de ces trois solutions n’est en général supérieure. La réponse appropriée dépend de ce que le produit doit faire sur l’appareil, de la rapidité avec laquelle vous devez atteindre les utilisateurs, et du nombre d’ingénieurs que vous pouvez financer. Répondez à ces trois questions avant d’écrire du code : le coût d’un mauvais choix se fait sentir plus tard sous forme de réfacturations et de solutions de contournement pour la plateforme, tandis que le bon choix permet à l’équipe de consacrer son temps aux fonctionnalités que les utilisateurs remarquent.