En 2019, quelle technologie pour créer une application mobile ?

Tour d'horizon sur les technologies permettant de réaliser des applications mobiles en 2019.

Depuis un certain temps maintenant, on entend dire que le développement natif est mort, que toutes les nouvelles applications mobiles seront faites en [techno au choix]. Pourtant, le développement natif est toujours là tout comme l'est également le développement hybride. Les technologies "hypes" de 2017 ne le sont déjà plus vraiment. Celles de 2016, n'en parlons pas !

Je vous propose de faire un petit tour d'horizon des technologies concentrées autour du développement mobile fin 2018.

Le web aujourd'hui

Le web a énormément évolué depuis ses débuts. Le W3C se montre très actif ces dernières années. De nouveaux standards web ont vu le jour dont :

Les Progressives Web Apps

Avant toutes choses, c'est une expérience utilisateur. Cette expérience utilisateur est garantie par un ensemble de règles à respecter lorsqu'on implémente une PWA.

Fiable : l'application doit être fiable et ne jamais lever d'exception non gérée et cela quelles que soient les conditions réseaux
Rapide : l'application doit être rapide et être composée d'animations fluides
Engageante : l'application doit être engageante et ressembler à une application native

Une fois ces points respectés, il suffit de déclarer un manifeste qui permettra à tout navigateur implémentant cette norme de traiter l'application comme une PWA.

Qu'obtient-on concrètement ?

Une application installable
Indépendamment de l'OS
En rendu 60fps
Dans un conteneur natif
Ayant accès à de riches API nativement
- push-notifications
- web workers (multi-threading)
- stockage local, base de données
- gestion du mode hors-ligne
- accéléromètre, gps, ....

Voir des exemples

Web Assembly (Wasm)

Web Assembly est un format d'instruction binaire interprété par une machine virtuelle. Un binaire Wasm peut être obtenu à partir de la compilation de langages plus haut niveau comme le C/C++ ou le Rust.

Les principes de Wasm sont les suivants :

Performance : optimisé pour un faible temps de chargement, rapide à l'exécution
Sûr : Wasm est exécuté dans un conteneur garantissant la bonne gestion de la mémoire côté client
Ouvert et débuggable : possibilité d'écrire du Wasm à la main, de le tester, ...
Interaction : Peut interagir avec les autres standards du web

Concrètement, Wasm permet d'exécuter du code binaire à partir d'un navigateur.

Une des premières applications, c'est de pouvoir tourner un moteur de jeu dans un navigateur sans avoir à installer préalablement un interpréteur.

Voir l'exemple

Mais il est également possible d'exécuter des algorithmes auparavant trop coûteux en javascript. Dans l'exemple ci-dessous, un ingénieur de Magellium a réalisé le portage d'un algorithme de détection d'avion sur une image satellite écrit en C/C++ vers du Wasm.

Web Components

Largement poussé par Google et dérivé de Polymer, ce nouveau standard permet de réaliser nativement des composants réutilisables pour les navigateurs qui le supporte.

Web Components repose en particulier sur deux standards :

Custom Elements : créer des balises HTML personnalisées
Shadow DOM : encapsuler les styles dans des composants afin d'éviter les effets de bords

Concrètement, ce standard devrait rendre de moins en moins nécessaire l'utilisation de frameworks javascript tel que Angular, VueJS, React, ...

Cela a également pour conséquence de réduire significativement le poids de ces applications (pouvant être environ divisé par 10).

En outre, grâce aux Web Components, il est possible de partager des composants entre différents frameworks/librairies.

Electron (2014)

>Electron est une librarie open source développée par Github pour créer des applications desktop cross-platform avec HTML, CSS et JavaScript. C'est en combinant Chromium et Node.js en un seul runtime qu'Electron accomplit cette tâche. Ainsi les applications peuvent être empaquetées pour Mac, Windows et Linux.

En résumé, avec Electron, il est possible de réaliser des applications desktops (applications lourdes) à partir d'applications web.

Voir l'exemple : le célèbre outil de messagerie Slack

L'hybride

Dans un contexte de développement d'application mobile, le développement natif consiste à développer une application via :

le langage
les composants
le kit de développement
la plateforme (ensemble d'outils)

officiels du système d'exploitation cible (iOS, Android, ~~Windows Phone~~)

Mais réaliser une application pour un système spécifique présente forcément un certain investissement car il faut développer deux fois, voire trois fois la même application en plus de nécessiter d'une connaissance pointue des API/SDK natives.

En partie pour ces raisons, de nouveaux frameworks tentent de simplifier le développement avec plus ou moins différentes approches. Néanmoins, on peut en discerner principalement trois :

Coder une fois pour toutes les plateformes
Coder toutes les plateformes dans le même langage
Partager du code

En plus de ces trois approches, les technologies hybrides se différencient sur le moteur de rendu utilisé. Ce point est important car il va impacter les performances, l'expérience utilisateur et l'évolutivité de l'application.

Sur ce critère, on peut discerner également trois groupes :

Le rendu web : utiliser le moteur de rendu HTML/CSS
Le rendu natif sans composants natifs : utiliser un langage bas niveau (C, C++, ...) ou langage système mais avec des composants natifs retravaillés
Le rendu natif avec des composants natifs : utiliser un langage bas niveau ou langage système mais avec possibilité d'intégrer directement les composants natifs officiels

L'hybride-web

Il s'agit d'écrire la partie vue et d'utiliser un moteur de rendu en HTML/CSS. Ce principe a été popularisé grâce à l'arrivée des SPA (Single Page Application) avec des frameworks tels que AngularJS, BackboneJS, ... C'est une des premières technologies hybride qui est apparue sur le marché principalement parce que les webviews (composant permettant d'encapsuler des navigateurs dans une application native) ont été parmi les premiers composants natifs disponibles.

Le principe du développement hybride-web repose sur un simple postulat :

Faire communiquer du javascript avec le langage système grâce à des callbacks (fonction de rappel) enregistrés auprès de la webview

Cordova, le mal aimé (2011)

Apache Cordova (ou anciennement Phonegap) est un framework de développement open-source initialement développé par Nitobi Software, puis racheté par Adobe et enfin donné à la Fondation Apache qui le renomme en 2011.

Cordova a principalement deux objectifs :

fournir une API native qui expose des plugins basée sur ces callbacks permettant l'intéraction entre le contexte javascript et les fonctionnalités système
encapsuler une application javascript dans une webview étant elle-même dans une application native de façon à pouvoir la déployer sur les stores respectifs des différents OS

Cordova souffre d'une mauvaise réputation car à ses débuts, les applications hybrides souffraient de problèmes de performance. Cela était principalement dû à un outillage, à une qualité des plugins discutable et aux faibles performances des animations CSS dans les anciennes webview.

Cependant, les choses ont évolué et les webviews sont maintenant devenues performantes. Les qualité des plugins s'est bien améliorée et il est possible (avec du bon CSS) d'obtenir des applications aux performances similaires au natif. Il était même possible, grâce à l'excellent plugin de Telerik NativePageTransitions, d'utiliser des transitions natives entre les routes de la SPA (ce plugin est aujourd'hui déprécié).

| Accessibilité | Rapidité de développement | Performances | Évolutivité | Taille du livrable | Rendu Natif | Composants natifs | | :-----------: |:-------------------------:| :-----------:|:-----------:|:------------------:|:-----------:|:-----------------:| | ++ |+ | + | + | +++ | Non | Non |

Ionic (2015)

Ionic est un framework open-source créé par la société portant par le même nom. L'objectif de Ionic est de pallier aux manques de Cordova, qui ne prend en charge que la partie interface avec les API natives, en prenant également en charge les composants UI. Ionic est historiquement couplé avec Angular et a suivi les différentes montées de version de ce dernier.

Grossièrement, le framework Ionic prend en charge le système de navigation et fournit des composants graphiques empruntés et ressemblants à ceux du natif. En plus de cela, Ionic fournit ses services dans le cloud afin d'accélérer autant que possible le développement des applications.

Ionic est aujourd’hui le framework hybride le plus utilisé dans le monde.

Capacitor, la boîte à outil au plein potentiel (2019?)

Capacitor, également à l'initiative de Ionic, se présente en tant que successeur à Apache Cordova. Mais l'approche est toutefois un peu différente. Capacitor va faciliter le processus de développement qui pouvait être long et coûteux auparavant.

Au lieu de masquer l'environnement natif via un CLI comme peut le faire Cordova, Capacitor assume en quelque sorte et se repose sur les environnements natifs. Pour lancer une application Android, on utilisera Android Studio tandis que pour lancer une application iOS, on utilisera Xcode. On y gagne ainsi en évolutivité car on reste plus proche de l'environnement natif.

En outre, Capacitor ne se limite pas aux applications mobiles mais il cible également les applications tournant sur Electron et les PWA.

Pour intégrer l'application web encapsulée dans la webview, Capacitor met à disposition une commande permettant de déployer la partie HTML/JS/CSS dans les assets de l'application native. Cette application web peut être produite grâce à Ionic, mais ce n'est pas un prérequis. Le développeur est libre de choisir le framework web qu'il préfère.

En résumé, ce n'est plus une boîte noire comme pouvait l'être Cordova, mais plutôt un outil ouvert permettant de créer différentes implémentations natives en respectant une interface. La partie web n'occupe plus la place centrale du workflow.

L'hybride-natif

Le moteur de rendu utilisé est écrit en langage système ou bas-niveau afin d'assurer de hautes performances.

Xamarin, la révolution ? (2011)

Xamarin est un framework open source de réalisation d'application mobile multi-plateformes. Il est fortement lié à l'historique de Mono (2004), ce dernier permettant d'exécuter l'environnement .NET sur une plateforme UNIX. Microsoft a racheté la solution en 2016 et l'intègre désormais officiellement dans Visual Studio.

Xamarin a été un des premiers à pouvoir prétendre pouvoir réaliser une applications hybrides avec des composants natifs. Xamarin se base sur Mono qui exécute l'environnement .NET sur la plateforme cible tels que Android et iOS (tous deux dérivant de plateformes UNIX).

Xamarin permet de choisir parmi deux approches : Xamarin Native et Xamarin Forms.

Xamarin Native consiste à utiliser directement les composants natifs propres aux plateformes en C#. Il faudra donc implémenter chaque vue pour les plateformes cibles. Mais en revanche, le modèle de données est partageable. Avec cette technique, on peut directement utiliser les composants natifs et réaliser une application respectant les usages propres à la plateforme cible.

La deuxième technique consiste à utiliser Xamarin Forms. Il s'agit d'une couche d'abstraction permettant de réaliser la même vue indépendamment de la plateforme.

En terme de performance, le résultat obtenu est proche de celui obtenu à partir de code natif. Cependant, d'après cet article, on peut noter qu'il y a une légère différence de performance entre Xamarin Native et Xamarin Forms. Pour des performances optimales, on privilégiera le premier.

Enfin, embarquer Mono n'est pas gratuit. Il faut compter environ 6Mo/3Mo pour Xamarin Native et 14Mo/11Mo pour Xamarin Forms sur Android/iOS.

React Native, l'orienté composant ! (2015)

React Native est un framework open-source créé par Facebook. Basé sur React, il permet aux développeurs javascript d'adresser les applications natives en manipulant des composants natifs avec une architecture orientée composant.

React Native opte pour l'approche suivante :

Un seul langage pour toutes les plateformes

En effet, le framework laisse la possibilité d'écrire des vues et du code spécifique pour chaque plateforme tout en utilisant le même langage. Il est donc possible d'obtenir des vues aux performances quasi-natives et adaptées aux usages de la plateforme.

Le fonctionnement de React Native est possible grâce à son bridge. Ce bridge, développé en C++, permet l’interaction entre la partie javascript et la partie native. Cette interaction est basée sur des files d'attente qui permettent une exécution non bloquante à la manière de NodeJS afin de garantir de bonnes performances (60fps).

Il est assez simple avec React Native de créer un composant natif personnalisé. Cela consiste à faire un wrapper et écrire l'interface en javascript.

D'après cet article, utiliser React/Native c'est partir avec 7Mo supplémentaire sur la taille de du livrable pour Android.

React Native bénéficie d'un écosystème grandissant. C'est clairement le framework hybride orienté composant natif le plus en avance sur le marché. Son succès est en parti du à la part de marché importante déjà occupée par React.

Nativescript, la metadata (2014)

Nativescript est un framework open-source créé par Telerik. Il est basé sur Angular et VueJS permettant également à leurs développeurs d'accéder aux performances natives.

Là où React Native fonctionne à partir d'interface préalablement définies, Nativescript va exposer directement les API natives grâce aux metadatas. En effet, les métadonnées des API natives sont extraites et générées via la réflexivité des langages systèmes. Attention toutefois, cette réflexivité est une opération coûteuse faite à chaque montée de version des plateformes cibles et non au runtime (et fort heureusement).

Les métadonnées vont permettre d'accéder directement aux API natives à partir des composants Angular/VueJS. Bien entendu, pour faciliter le travail, des composants abstraits ont été créés et sont déclinés pour chaque plateforme.

La communication Javascript/Natif se fait grâce à un bridge conçu à partir de la machine virtuelle javascript V8 de Google (qui est )utilisée par Chrome et ses dérivés).

Bien entendu, embarquer le V8 et toutes les metadata a un coût d'environ 10Mo sur la taille du livrable.

Un petit bémol également sur le temps de chargement de l'application qui n'est pas anodin selon la puissance du terminal.

Nativescript peut bénéficier de l'intérêt de la communauté Angular et VueJS qui n'est pas négligeable. Mais, étant donné que Ionic s'adresse aussi à cette communauté, le succès de Nativescript est en demi-teinte.

Le natif réinventé

Flutter (2018)

Flutter est un SDK open-source créé par Google dont la version finale est sortie en décembre 2018. Flutter a la particularité d'être avant tout pensé comme étant le moyen officiel de développer des applications sur le nouvel OS en gestation de Google nommé Google Fuchsia. Mais son périmètre a été renforcé et il est maintenant capable de produire des applications natives iOS/Android avec un rendu non pas 60fps, mais 120fps !

Le SDK Flutter est écrit en langage Dart, langage créé par Google en 2011 ayant pour vocation de remplacer le javascript. C'est un langage réputé facile d'accès pour des développeurs connaissant le Java et le Javascript.

Pour atteindre les 120fps, Flutter utilise un moteur de rendu 2D personnalisé. On ne parle plus de manipuler les composants natifs mais de les réécrire et de les sublimer.

La devise de Flutter est : > Everything is a widget

En effet, avec Flutter, l'interface est décomposée en blocs. Les widgets sont les blocs de base. Ces derniers sont immutables, facilitant le contrôle et limitant les effets de bords pouvant rendre instable l'application.

Un widget peut définir :

Un élément structurel tel qu'un bouton
Un élément de style tel qu'une police
Un élément de positionnement tel qu'une marge

Flutter mise avant tout sur la composition de widgets au lieu de miser sur l'héritage comme le font habituellement les frameworks basés sur des langages typé objet.

Flutter n'a pas besoin de bridge

Contrairement aux précédents frameworks, Flutter n'utilise pas de bridge javascript afin d'éviter la légère perte de performance qu'introduisait ce dernier.

Le fonctionnement de Flutter ressemble à celui utilisé par les moteurs de jeux vidéo. Le moteur de Flutter est écrit en C et C++. Le code Dart est compilé au format binaire. Au chargement de l'application, cette dernière charge Flutter puis exécute le code binaire issu du Dart.

L'usage de Flutter implique un prérequis de 5Mo pour le livrable cible.

En outre, de par sa conception, il n'est pas possible d'utiliser les composants natifs. Il faudra attendre que Flutter en fasse une nouvelle version.

Exemple: Alibaba.com B2B

Kotlin Native (2018)

Kotlin Native s'inscrit dans la continuité du langage Kotlin créé par JetBrains le créateur de l'IDE IntelliJ. Kotlin Native permet de compiler du code Kotlin en binaire natif directement exécutable sur la plateforme cible, sans avoir à passer par une machine virtuelle. Kotlin Native repose sur LLVM, une infrastructure de compilateurs rendant possible la création de binaires exécutables à partir de nombreux langages.

Kotlin Native permet aujourd'hui d'adresser plusieurs plateformes telles que le Web, le serveur, iOS et Android.

En outre, il est interopérable, c'est-à-dire qu'il peut interagir avec du code natif et inversement.

L'objectif des technologies hybrides reste avant tout de gagner du temps ou/et de gagner en coût de maintenance. C'est dans cette optique que Kotlin Native opte pour l'approche : > Le partage de code entre plusieurs plateformes

En effet, avec Kotlin Native, on peut partager le code métier d'une application mobile comme par exemple le presenter, la partie d'accès au données, les appels réseaux, le stockage en base de données, ...

Il s'agit ensuite de définir une interface Kotlin à respecter entre les plateformes et de les implémenter dans le langage cible.

Dans le cas d'une application mobile Android/iOS, seule l'interface sera entièrement native. Elle sera codée en Kotlin pour Android et Swift avec Xcode pour iOS.

L'intéraction entre IntelliJ et Xcode est très efficace. Il suffit de lancer la compilation à partir d'Xcode pour que les dépendances Kotlin soient directement recompilées.

Le principe de Kotlin Native reste donc relativement simple et, fait appréciable, reste proche du natif. Ce n'est pas un framework mais une technologie. L'intégration de Kotlin Native peut donc se faire avec souplesse.

Le surcoût généré par Kotlin Native est négligeable, de l'ordre d'une dizaine de kilo-octets.

Stencil (2018)

Stencil est un framework créé par Ionic. Contrairement aux autres frameworks hybrides vus précédemment, Stencil tente de réunir le meilleur des deux mondes en profitant au maximum des dernières avancées du Web à ce jour.

En effet, Stencil permet de créer des PWA basées sur des Web Components. Dans le cas où le besoin d’interagir avec des API native se présente, il sera aisé d'intégrer Capacitor.

En terme de conception, Stencil permet plus que jamais de faire de l'orienté composant mais directement à partir de Web Components. Stencil fonctionne avec Typescript, du javascript typé utilisé principalement adopté par Angular. Mais Stencil fonctionne également avec JSX, une extension de syntaxe au javascript utilisée par React permettant de déclarer du XML.

Concrètement avec Stencil, il est possible de créer une application web pouvant tourner sur tous les supports que cela soit en web, en application lourde sur desktop, en application mobile, etc... Le tout avec une bonne expérience utilisateur.

En effet, en utilisant les Web Components, Stencil permet de faire des applications web plus légères que jamais et donc plus performantes en matière de temps de chargement. En outre, les composants créés avec Stencil sont réutilisables sur d'autres frameworks javascript.

L'ordre de grandeur d'une application Stencil en PWA est de l'ordre de 100Ko contre 10Mo en natif.

Avec Stencil, il s'agit de laisser tomber les frameworks javascript standards et d’embrasser le potentiel du web natif.

Exemples

Bilan

Le moins que l'on puisse dire c'est qu'il y a le choix. Comment choisir ? Cela dépendra avant tout du contexte dans lequel se trouve le projet.

Si le projet doit être universel et le budget limité, il faut se tourner vers les PWA (+ Capacitor).
Si le projet doit privilégier la performance avec un besoin d'évolutivité dans le temps et que l'équipe est constituée de développeurs natifs, il faut se diriger vers une approche native telle que Kotlin Native.
Si le projet doit privilégier la performance et que le budget est limité, Flutter semble être une bonne option.
Si le projet doit privilégier la performance et que l'équipe est essentiellement constituée de développeurs javascript alors React Native ou Flutter semblent être un bon choix.

Cependant, il faut avant tout s'assurer que la solution technique corresponde avec les besoins du client. Une question que l'on peut souvent se poser : "A-t-on besoin d'une PWA ou d'une application ?"

Merci d'avoir lu cet article. J'espère qu'il vous a été utile.

Je précise qu'une partie de l'article est liée à mon expérience personnelle. Je suis ouvert à toute discussion dans les commentaires ci-dessous ;)

Les notes des solutions techniques sont à débattre...

Tagged with: