Application native ou cross-platform : React Native/Expo, Swift/Kotlin ou Flutter ?

Dès qu'on prépare une application, la question tombe très vite : native ou cross-platform ? Elle a l'air technique, mais la réponse dépend surtout de votre budget, de vos délais et de ce que fait votre application au quotidien. Voici comment je trancherais en 2026, avec les compromis exposés sans détour.

Natif ou cross-platform : de quoi parle-t-on ?

Le développement natif consiste à construire chaque plateforme avec ses propres outils : Swift (le plus souvent avec SwiftUI) pour iOS, et Kotlin (le plus souvent avec Jetpack Compose) pour Android. Vous vous retrouvez avec deux bases de code, souvent maintenues par deux personnes ou deux équipes.

Le développement cross-platform (ou multiplateforme) consiste à écrire une seule base de code publiée sur les deux stores. Aujourd'hui, deux options sérieuses dominent :

• React Native, généralement avec Expo : vous écrivez du TypeScript et du React, et l'application affiche de vrais composants natifs (un vrai bouton iOS, une vraie liste Android).
• Flutter : vous écrivez du Dart, et Flutter dessine lui-même chaque pixel avec son propre moteur de rendu, au lieu d'utiliser les composants de la plateforme.

Une voie intermédiaire plus récente existe : Kotlin Multiplatform, qui partage la logique métier (et éventuellement l'interface via Compose Multiplatform) tout en gardant du code natif là où vous le souhaitez. C'est solide, mais son écosystème et son vivier de développeurs restent plus réduits que ceux des trois autres options, donc je ne le détaillerai pas ici.

Le comparatif côte à côte

La ligne « coût » est celle qui intéresse le plus les fondateurs. Avec une seule base de code, vous concevez, développez, testez et corrigez chaque fonctionnalité une fois au lieu de deux. D'après notre expérience, un développement cross-platform coûte souvent nettement moins cher que deux applications natives de même périmètre, même si l'écart exact dépend de la part de travail spécifique à chaque plateforme. Pour des chiffres concrets, consultez combien coûte le développement d'une application.

React Native et Expo en 2026

React Native est maintenu par Meta et utilisé dans de grandes applications en production un peu partout. Expo est le framework et l'outillage cloud construits par-dessus, et l'équipe React Native elle-même recommande désormais de démarrer un nouveau projet avec un framework comme Expo. Plusieurs évolutions ont changé la donne ces deux dernières années :

La New Architecture

La New Architecture de React Native (le moteur de rendu Fabric, les TurboModules et JSI) a remplacé l'ancien « bridge » asynchrone entre JavaScript et le code natif. JavaScript peut désormais appeler le code natif directement, et de façon synchrone si besoin, le rendu est plus prévisible et les fonctionnalités concurrentes de React fonctionnent. Elle est devenue la configuration par défaut des nouveaux projets fin 2024, et les versions récentes de React Native et d'Expo ont abandonné l'ancienne architecture. La plupart des critiques sur les performances que vous lirez dans de vieux articles visaient ce bridge.

EAS Build, Submit et Update

• EAS Build compile vos binaires iOS et Android dans le cloud : plus besoin d'un Mac de build soigneusement configuré pour chaque développeur.
• EAS Submit envoie ces builds vers App Store Connect et Google Play.
• EAS Update distribue des mises à jour over-the-air (OTA) : les modifications de votre JavaScript et de vos ressources arrivent sur les téléphones au lancement suivant, sans attendre la validation des stores.

Ajoutez à cela Expo Router (une navigation basée sur les fichiers qui fonctionne aussi sur le web), les config plugins qui modifient les réglages des projets natifs sans retoucher Xcode à la main, et une large bibliothèque de modules maintenus pour l'appareil photo, les notifications, la géolocalisation, les paiements et bien plus. Pour la plupart des applications, on n'écrit presque jamais de code natif.

Flutter : Dart et son propre moteur de rendu

Flutter, développé par Google, adopte une autre approche. Au lieu de demander à iOS et Android de dessiner les composants, il embarque son propre moteur de rendu (Impeller) et peint lui-même toute l'interface. Cela a de vrais avantages :

• Une interface identique au pixel près sur tous les appareils, idéale pour des designs très personnalisés et fortement brandés.
• Des animations fluides et une bibliothèque de widgets mature.
• Un hot reload rapide et une chaîne d'outils bien intégrée.

Les contreparties : vous écrivez en Dart, un langage peu utilisé en dehors de Flutter, donc le vivier de développeurs est plus restreint. Comme Flutter dessine ses propres widgets, coller au rendu exact de chaque nouvelle version d'iOS ou d'Android dépend de la réactivité de l'équipe Flutter. Enfin, Flutter sur le web dessine dans un canvas : cela convient à des tableaux de bord de type app, beaucoup moins à du contenu que vous voulez voir indexé par les moteurs de recherche.

Flutter est un bon choix, et je ne conseillerais jamais à une équipe solide sur Flutter d'en changer. La principale raison pour laquelle je ne le choisis pas par défaut, c'est le partage de code avec le web, dont je parle plus bas.

Le natif : Swift/SwiftUI et Kotlin/Jetpack Compose

Développer en natif est bien plus agréable aujourd'hui qu'il y a dix ans. SwiftUI et Jetpack Compose sont deux frameworks d'interface déclaratifs, proches de React dans l'esprit. Vous accédez dès le premier jour à chaque nouveauté annoncée par Apple et Google, vous profitez des meilleurs outils de débogage et de profilage, et aucune couche d'abstraction ne vous freine.

Le prix à payer, c'est la duplication. Chaque écran, chaque correctif et chaque fonctionnalité est développé deux fois, dans deux langages, et les deux applications ont tendance à diverger avec le temps si personne ne veille à les garder alignées. Pour un produit financé avec des équipes iOS et Android distinctes, c'est gérable. Pour une startup ou une PME avec un seul budget, rarement. Si une seule plateforme suffit pour le lancement, une application native unique peut avoir du sens : voir développement d'application iOS et développement d'application Android.

Quand le développement natif l'emporte

Optez pour le natif, ou prévoyez au moins une part importante de code natif, quand votre application repose avant tout sur une capacité de la plateforme :

• Graphisme lourd et médias en temps réel : 3D, réalité augmentée, jeux, montage vidéo ou audio professionnel, traitement de l'image caméra à chaque frame.
• Intégration poussée au système : CarPlay ou Android Auto, logique audio ou de géolocalisation en arrière-plan au-delà des modules courants, matériel Bluetooth aux contraintes de timing strictes, services d'accessibilité, claviers personnalisés.
• Produits centrés sur les widgets ou la montre : si le widget d'écran d'accueil, la Live Activity ou l'app Apple Watch est le produit, vous écrirez de toute façon du Swift et du Kotlin pour ces surfaces.
• Les nouveautés du système dès le premier jour, quand sortir avant tout le monde constitue l'avantage concurrentiel.

Une nuance utile : une application React Native peut contenir du code natif. Widgets, extensions Apple Watch et modules natifs sur mesure peuvent cohabiter avec une app React Native, et les config plugins d'Expo savent ajouter ces cibles au projet. La vraie question est donc souvent « quelle part de code natif nous faut-il ? » plutôt que « natif ou pas ? ».

Quand le cross-platform l'emporte (la plupart des applications métier)

La plupart des applications se composent de formulaires, de listes, de fils d'actualité, de messagerie, de cartes, de paiements, de notifications, de comptes utilisateurs et d'un backend. Cela couvre les marketplaces, les apps de réservation, les outils internes, les apps d'intervention terrain, les apps communautaires, les compagnons mobiles de SaaS et la plupart des applications dopées à l'IA. Pour tous ces cas, le cross-platform est la meilleure décision business :

• Vous sortez sur les deux stores en même temps, au lieu de choisir une plateforme et de laisser la moitié de votre marché attendre.
• Votre budget va plus loin : soit un coût total plus bas, soit plus de fonctionnalités pour le même prix.
• Les correctifs ne se font qu'une fois. Un bug trouvé sur Android est corrigé sur iOS du même coup.
• Une seule équipe porte tout le produit, ce qui compte énormément quand on démarre et qu'on change de cap chaque semaine.

C'est encore plus vrai pour un MVP, où la vitesse d'apprentissage est tout l'enjeu. Notre guide sur le temps nécessaire pour développer une application montre combien les délais raccourcissent quand on ne développe pas tout en double.

Partager le code avec une application web

Beaucoup de produits ont aussi besoin d'une application web : un back-office, un espace client ou une version navigateur de l'application elle-même. C'est là que React Native a un avantage structurel. Votre application web sera très probablement développée en React, donc une équipe React Native peut partager :

• Les types TypeScript, la validation et la logique métier.
• Les clients d'API, la récupération des données et la gestion d'état.
• Le code backend. Avec un backend temps réel comme Convex, les mêmes requêtes et mutations alimentent le téléphone et le navigateur.
• Dans certains cas, l'interface elle-même, grâce à React Native for Web et Expo Router.

C'est aussi un seul langage et une seule logique sur toute la stack : les mêmes développeurs passent du mobile au web et au backend. Notre propre produit Star fonctionne ainsi : une app tablette pour piloter setlists et présentations, plus une application web sur app.starapp.io, toutes deux construites sur la même base TypeScript. Si un produit navigateur fait partie de votre projet, voyez notre offre de développement d'application web.

Notre choix par défaut chez Loha.dev, et pourquoi

Soyons transparents : chez Loha.dev, nous développons les applications mobiles avec React Native et Expo, et c'est ce que nous recommanderons pour la plupart des projets. Il vaut mieux que vous connaissiez ce parti pris. Voici le raisonnement qui le justifie :

1. Une seule base de code TypeScript pour iOS, Android et souvent le web, ce qui garde le coût et les délais raisonnables pour les fondateurs et les petites entreprises.
2. Les mises à jour over-the-air nous permettent de corriger la plupart des problèmes le jour même, sans attendre la validation des stores.
3. Le vivier de développeurs est le plus large de toutes les options : vous n'êtes jamais prisonnier de nous. Un autre développeur React Native peut reprendre le code.
4. Les portes de sortie vers le natif existent. Quand une fonctionnalité exige du Swift ou du Kotlin, nous écrivons cette partie en natif au lieu de changer toute l'application.

Quand nous vous dirions le contraire : si votre application est une expérience 3D ou de réalité augmentée, un jeu, un outil média professionnel ou avant tout une app pour montre, une approche native (ou un moteur de jeu) est la réponse honnête, et nous vous le dirons, même si cela signifie travailler avec quelqu'un d'autre. Découvrez notre approche du développement d'application mobile, ou passez directement à l'étape suivante et obtenez un plan gratuit pour votre application.

Une méthode rapide pour choisir

Quel que soit votre choix, le framework compte moins qu'un périmètre clair, un bon backend et une équipe qui livre. Bien choisir dès le départ vous évite une réécriture plus tard.