Développement mobile cross-platform en 2026 : un seul code pour iOS et Android

Le développement mobile cross-platform consiste à écrire un seul code qui tourne sur iOS et Android, et souvent aussi sur le web, plutôt qu'une application en Swift pour iPhone et une autre en Kotlin pour Android. En 2026, ce n'est plus un compromis réservé aux prototypes : les deux frameworks les plus utilisés, Flutter et React Native, font tourner des applications de Google, Meta, Microsoft et Shopify, et une troisième approche, Kotlin Multiplatform, est désormais assez stable pour que Google la recommande aux équipes Android.

La vraie question s'est déplacée. Ce n'est plus « cross-platform ou natif ? » mais « quel cross-platform, pour quelle équipe ? ». Les quatre familles dessinent l'écran de quatre façons différentes, et ce seul fait décide du rendu, des performances, du vivier de recrutement et de la maintenance que vous signez. Ce guide les met à plat, avec des chiffres quand il en existe, puis vous donne un chemin de décision.

Ce que le cross-platform veut dire en 2026

Les données d'adoption les plus fiables viennent du Stack Overflow Developer Survey, qui demande à environ 45 000 développeurs quels frameworks ils ont utilisés dans l'année. Les frameworks mobiles ne représentent qu'une petite part de l'ensemble, mais le classement à l'intérieur de cette part est stable.

Kotlin Multiplatform n'apparaît pas dans cette liste, parce que le sondage ne le proposait pas comme réponse. Il compte quand même : JetBrains a publié Compose Multiplatform 1.8 en mai 2025, qui a rendu stable son interface partagée pour iOS, et Google recommande l'approche pour partager la logique métier entre Android et iOS.

Trois choses ont changé depuis la dernière fois que vous avez peut-être regardé. React Native a supprimé son vieux bridge asynchrone avec la nouvelle architecture, devenue le défaut de tout l'écosystème avec la version 0.85 en avril 2026. Flutter a remplacé son moteur de rendu par Impeller. Et l'approche « web encapsulé » s'est scindée en deux : les progressive web apps qui se passent des stores, et des coquilles comme Capacitor qui mettent une application web dans une fiche de store. Si votre short-list se résume déjà aux deux leaders, notre face-à-face React Native ou Flutter approfondit ce choix précis.

Quatre familles, quatre façons de dessiner un pixel

Les noms cachent la différence importante, à savoir ce que devient votre code sur l'appareil.

React Native, avec Expo

Vos composants React deviennent de vraies vues natives : un contrôle UIKit sur iOS, une View Android sur Android. L'application ressemble à la plateforme et se comporte comme elle parce qu'elle utilise la plateforme. Le vivier de recrutement est le plus large des quatre, puisque tout développeur JavaScript ou TypeScript peut contribuer, et l'équipe React Native elle-même recommande désormais de démarrer avec le framework Expo, qui ajoute la navigation, une bibliothèque standard d'API du téléphone et des builds dans le cloud. Nous détaillons cette couche dans Expo, c'est quoi ?.

Flutter

Flutter fait le pari inverse. Il n'utilise aucun widget natif : son moteur Impeller dessine chaque pixel lui-même, donc l'application est identique sur les deux plateformes et un design sur mesure coûte peu à construire. Le prix, c'est Dart, un langage que votre équipe devra probablement apprendre, et une interface qui ne suit les conventions de chaque plateforme que dans la mesure où la bibliothèque de widgets de Flutter les imite. Google annonçait plus d'un million d'applications livrées avec Flutter dès 2023.

Kotlin Multiplatform

KMP partage les parties que l'utilisateur ne voit jamais : réseau, modèles de données, règles métier, écrits une fois en Kotlin et compilés pour les deux plateformes. Les écrans restent natifs (SwiftUI sur iOS, Jetpack Compose sur Android), ou peuvent être partagés eux aussi avec Compose Multiplatform, stable sur iOS depuis Compose Multiplatform 1.8. C'est le chemin naturel d'une entreprise qui a déjà des développeurs Android et veut une application iOS sans dupliquer la logique.

Capacitor et Ionic : le web dans une coquille

Votre application web existante tourne dans une WebView, et des plugins lui exposent la caméra, les notifications ou le système de fichiers. C'est la voie la plus rapide d'un site web à une fiche de store, et la plus faible sur le ressenti : le défilement, les gestes et les transitions sont ceux du navigateur, pas ceux de la plateforme. Apple refuse aussi les applications qui sont « essentiellement un site web encapsulé » sans valeur native, donc la coquille doit justifier sa place avec de vraies fonctions de l'appareil.

Les arbitrages qui décident vraiment

Le coût : une seule équipe, mais la taxe de plateforme reste

L'économie est réelle et surtout organisationnelle : une équipe, un backlog, une sortie au lieu de deux qui divergent. Ce que le cross-platform ne supprime pas, c'est tout ce que les plateformes facturent de leur côté. Il vous faut toujours une adhésion à l'Apple Developer Program, un compte Google Play Console, un Mac quelque part pour signer les builds iOS (le vôtre ou un Mac dans le cloud), et vous passez toujours par les deux revues de store avec les mêmes règles qu'une application native.

Les performances : suffisantes pour les produits, natif pour les extrêmes

Pour l'immense majorité des applications, formulaires, listes, cartes, messagerie, paiements, caméra et notifications, les quatre familles sont assez rapides pour que l'utilisateur ne voie pas la différence. Le natif garde l'avantage aux extrêmes : 3D et réalité augmentée, traitement audio ou vidéo en temps réel, widgets d'écran d'accueil et intégrations profondes au système, et jeux. Si votre produit est dans cette liste, la décision est prise pour vous.

La maintenance : la montée de version annuelle que personne ne planifie

Chaque mois de septembre, Apple et Google sortent de nouveaux systèmes, et chaque framework publie des mises à jour pour suivre. Expo sort trois versions de SDK par an, Flutter publie chaque trimestre, Kotlin Multiplatform suit le rythme de Kotlin, et une application web encapsulée évolue avec le web. Rien de tout cela n'est difficile si vous suivez ; tout devient pénible si vous laissez passer deux ans. Mettez une montée de version par trimestre dans la feuille de route et le coût reste faible.

Comment choisir : un guide de décision

Partez de l'équipe que vous avez, pas des benchmarks. Le framework qu'une équipe peut recruter et maintenir bat celui qui gagne un test synthétique.

Puis déroulez une courte checklist avant de vous engager :

• 1. Listez les fonctions de l'appareil dont vous avez besoin. Caméra, notifications push, géolocalisation en arrière-plan, Bluetooth, paiements. Vérifiez que chacune a un module maintenu dans le framework envisagé.
• 2. Comptez les personnes qui vont maintenir l'application. Une seule personne peut faire vivre une application Expo ; une configuration KMP avec des écrans natifs demande au moins une main iOS et une main Android.
• 3. Estimez la durée de vie. Une application de campagne de trois mois et un produit de cinq ans ne méritent pas la même architecture.
• 4. Prototypez en une semaine. Construisez les deux écrans les plus difficiles dans votre candidat favori et mettez-les sur un vrai téléphone. La plupart des doutes disparaissent à ce moment-là.
• 5. Planifiez la chaîne de publication. Signature, builds cloud, TestFlight et pistes de test internes. Décidez-le maintenant, pas la semaine du lancement.

Et si vous n'avez aucune équipe mobile

Le cas le plus fréquent pour un fondateur ou une petite entreprise n'est pas « quel framework ? » mais « qui va écrire ça ? ». Un AI app builder répond à cette question avec une vraie stack cross-platform plutôt qu'un modèle figé. Sur Cadrant, un projet mobile natif est une application Expo et React Native : vous décrivez l'application en langage naturel, vous la prévisualisez dans un cadre de téléphone, vous la testez sur votre propre appareil avec Expo Go, puis vous la publiez sur l'App Store via vos propres comptes Expo et Apple. Si une fiche de store n'est pas nécessaire, le même builder livre une progressive web app ou une application WebView à la place. La page créateur d'applications mobiles détaille les trois options.

Le cross-platform en 2026 est une famille de choix mûrs, pas un raccourci. Prenez celui que votre équipe peut s'approprier, budgétez les coûts de plateforme qu'aucun framework ne supprime, et inscrivez la montée de version annuelle au calendrier. Le reste, c'est construire le produit.