Applications natives iOS et Android
C'est le modèle traditionnel d'une application mobile. Que ce soit Google avec Android ou Apple avec iOS, chaque plateforme possède son propre environnement, qui régit la manière de développer et d'exécuter une application mobile. Android propose sa plateforme Java s'appuyant sur Android Studio et un SDK (Software Development Kit) dédié. Cela n'empêche nullement de développer avec d'autres langages tels que Kotlin, voire C/C++ ou Python. Il faut simplement savoir que le SDK est écrit en grande partie en Java et que la machine virtuelle qui exécutera le code compilé utilise un bytecode proche de celui de Java.
Côté iOS, les choses sont tout aussi spécifiques. Les applications sont généralement conçues en Objective-C ou en Swift dans l'environnement de développement Xcode, disponible uniquement sur macOS. Aux langages de développement s'ajoute tout un écosystème spécifique à ces deux environnements. Les outils de construction et de gestion de dépendances sont différents (CocoaPods, Gradle, Carthage, Swift Package Manager…) et il s'avère difficile pour un développeur de parfaitement maîtriser les deux écosystèmes.
Dans la pratique, si la solution native est celle qui permet le plus de souplesse et de performance, elle impose aux entreprises de disposer en interne de deux équipes, une par plateforme. Cela revient à doubler les effectifs, le matériel de développement, les tests et parfois même les spécifications fonctionnelles, notamment lorsqu'on souhaite dissocier le fonctionnement d'une application Android de celui d'une application iOS. Concrètement, cela signifie doubler les budgets.
Applications mobiles hybrides (Cordova, Capacitor)
Les applications mobiles hybrides répondent à la problématique budgétaire des applications natives. Elles s'appuient sur un environnement natif confiné permettant de tirer parti d'un navigateur embarqué pour exécuter des applications Web (HTML/CSS/JavaScript). Ce composant, appelé WebView, joue le rôle d'intermédiaire entre l'application et le système. Tout accès natif au système hôte (Android ou iOS) se fait via des extensions (appelées « plugins ») fournies par des outils tels qu'Apache Cordova ou Capacitor. Dans la pratique, il n'y a donc plus qu'un seul écosystème, celui du Web, avec le trio HTML, CSS et JavaScript maîtrisé par bon nombre de développeurs sur le marché.
Capacitor, développé par l'équipe d'Ionic, est le successeur moderne de Cordova : il reprend son modèle de plugins, reste compatible avec la plupart d'entre eux et s'intègre directement aux projets natifs Android Studio et Xcode. Quant à PhoneGap d'Adobe, aujourd'hui abandonné, il s'agissait d'une distribution de Cordova contenant des ajouts propriétaires. Cordova et Capacitor restent les deux piliers des projets hybrides.
L'inconvénient des applications hybrides tient à leur nature : du fait de l'utilisation d'une WebView, toute interaction native avec le système passe nécessairement par la fourniture d'un plugin, ce qui peut parfois (notamment pour des fonctionnalités natives récentes) poser des problèmes de disponibilité, de compatibilité et de stabilité. Par ailleurs, les performances d'une application hybride sont parfois moindres que celles de ses homologues natives (notamment en cas d'utilisation intensive d'animations graphiques ou de la 2D).
Progressive Web Apps
Contrairement aux applications hybrides, une PWA est une application 100 % Web. Celle-ci s'exécute dans un navigateur Web comme Chrome ou Safari. Il faut imaginer une application HTML dont l'installation se fait via une simple URL, avec un affichage adapté à la taille du périphérique cible (le responsive design joue un rôle important dans ce modèle).
Une PWA offre un ROI (retour sur investissement) intéressant lorsqu'on souhaite cibler tous les types de périphériques à moindre coût, car on utilise une seule et unique technologie pour le développement. Il faut en revanche garder à l'esprit que les PWA, contrairement aux applications hybrides, interagissent avec le système via des API Web. La notion de plugin n'existe pas ici et il faut disposer d'un navigateur assez récent pour interopérer avec des services tels que le Bluetooth, la capture audio/vidéo, le NFC, l'accéléromètre, le GPS, les gestes ou le presse-papiers. Un site recense l'état de l'art dans ce domaine : whatwebcando.today.
Par ailleurs, les PWA ne sont pas encore totalement supportées par les principaux stores du marché, qui leur préfèrent les applications mobiles natives. Il est possible de passer par un composant WebView, mais l'application s'exécutera dans un environnement sécurisé (sandbox) assez contraignant. Cela dit, Google (via les TWA) ou Apple entrouvrent de plus en plus la porte.
Applications React Native
React Native constitue pour nous la plateforme proposant le meilleur compromis entre souplesse, performance, stabilité et coût. React Native part du principe que les performances d'un mobile et l'accès au système hôte sont primordiaux pour qu'une application puisse fonctionner de manière aussi fluide qu'une application native. React Native crée donc simplement une abstraction entre le code et le système. Le code est écrit en JavaScript et tout l'aspect graphique reste sous la responsabilité du système hôte. React Native fournit au développeur des composants graphiques qui encapsulent les composants natifs existants du terminal. Les zones de saisie, les textes, les tableaux, les gestes, les barres de défilement sont ceux du mobile, d'où le rendu fidèle que procure une application React Native.
Les premières versions s'appuyaient sur un système massivement asynchrone d'échange de messages entre l'environnement natif et le moteur JavaScript (le « bridge »). La nouvelle architecture (Fabric, TurboModules, JSI), activée par défaut depuis 2024, permet désormais des appels synchrones et des performances accrues.