Développement mobile 2026 : Flutter 3, React Native, Expo, stores

Choisir une stack mobile en 2026 ne se résume plus à un duel entre Flutter et React Native. Les deux frameworks ont mûri sur des trajectoires distinctes — Flutter 3.41 stabilise son moteur Impeller et son aperçu de widgets côté outillage, React Native 0.85 boucle sa transition vers la New Architecture sans bridge legacy. Autour d’eux gravite Expo, devenu la voie royale pour démarrer en React Native sans toucher à Xcode ni Android Studio. À ces choix s’ajoute une réalité opérationnelle : les pipelines de build mobile coûtent cher, les exigences d’App Store Connect et de Google Play durcissent chaque année, et la signature des binaires reste le point sur lequel cassent la plupart des premières publications. Ce guide trace une carte claire du terrain en mai 2026, avec une recommandation par profil et des sous-tutoriels pour chaque maillon de la chaîne.

Sommaire

• L’état du développement mobile en 2026
• Flutter 3.41 contre React Native 0.85 — la mécanique des deux moteurs
• Expo, la couche qui a tout changé pour React Native
• Choisir une stack en fonction de l’équipe et du produit
• Industrialiser : CI/CD, signature, distribution
• Publication multi-stores : ce que demandent réellement Apple et Google
• Tutoriels pas-à-pas associés
• Erreurs fréquentes qui coûtent un rejet de soumission
• FAQ
• Ressources et références

L’état du développement mobile en 2026

Le développement mobile multiplateforme n’est plus une promesse. C’est une infrastructure : un écosystème stabilisé d’outils, de runtimes, de stores et de canaux de distribution OTA (over-the-air) qui permet à une équipe de trois personnes de livrer une application iOS et Android avec la même base de code, la même CI et le même cadre de tests. Trois mouvements expliquent où on en est aujourd’hui.

Le premier mouvement, c’est la maturité des moteurs de rendu. Flutter a abandonné définitivement Skia au profit d’Impeller depuis Flutter 3.10, et la version 3.41 publiée début 2026 corrige les derniers artefacts visuels (color bleeding sur les blurs, ombres sur Android). React Native, de son côté, a basculé en architecture nouvelle par défaut depuis la 0.76, et la 0.82 (octobre 2025) est devenue le premier release entièrement post-bridge — la New Architecture est désormais la seule. La 0.85 consolide cette transition avec Hermes V1 par défaut et JSI direct, sans aucun fallback résiduel. Concrètement, les deux camps ont tué le débat sur la fluidité : à code raisonnable, on tient 60 fps confortablement et 120 fps sur les écrans qui le supportent.

Le deuxième mouvement, c’est la convergence des outils de build. EAS Build (Expo), Codemagic et GitHub Actions proposent désormais des runners macOS Apple Silicon avec mise en cache des dépendances Cocoapods, gestion automatique des certificats et provisioning profiles. La barrière historique du Mac local pour iOS s’est effondrée : on peut développer une app iOS depuis n’importe quel OS et la builder dans le cloud. La contrepartie, c’est le coût — chaque minute de runner macOS reste plus chère qu’un runner Linux, et il faut savoir lire les grilles tarifaires.

Le troisième mouvement, c’est le durcissement des exigences stores. Google Play impose API 35 (Android 15) pour toute nouvelle soumission ou mise à jour depuis le 31 août 2025, avec un sursis possible jusqu’au 1ᵉʳ novembre 2025. Apple impose Xcode 26 et le SDK iOS 26 pour toute soumission à partir du 28 avril 2026. Les apps déjà publiées avant ces dates restent en ligne, mais aucune mise à jour n’est acceptée si la chaîne d’outillage n’a pas suivi. Ce calendrier n’est pas une formalité administrative : il dicte la version de Flutter, de React Native, de Gradle, de Kotlin et de Ruby qu’on peut utiliser.

Flutter 3.41 contre React Native 0.85 — la mécanique des deux moteurs

Comparer Flutter et React Native avec les mêmes critères n’est plus très utile en 2026. Les deux frameworks visent des publics différents et résolvent des problèmes voisins par des moyens opposés. Ce qui compte, c’est de comprendre comment chacun produit l’image que l’utilisateur voit à l’écran, parce que ce choix d’architecture remonte ensuite jusqu’au profil de votre équipe.

Flutter peint chaque pixel lui-même. L’app dessine ses widgets sur une surface Skia ou Impeller, et n’utilise jamais les contrôles natifs iOS ou Android. C’est ce qui permet à une app Flutter de ressembler exactement à la même chose sur les deux plateformes — c’est une force pour les marques qui veulent une identité visuelle stricte, et une faiblesse quand on veut s’aligner précisément sur les guidelines de chaque OS. Le langage est Dart 3.5, fortement typé, avec null safety par défaut depuis Dart 2.12. La courbe d’apprentissage est raide pour qui vient de JavaScript, plus douce pour qui vient de Java ou de C#.

React Native ne peint rien. Il appelle les composants natifs — un <View> devient un UIView sur iOS et un android.view.View sur Android. La nouvelle architecture (Fabric côté UI, TurboModules côté natif, JSI pour la communication) supprime la sérialisation JSON entre le thread JS et le thread natif, ce qui réduit la latence des animations et des gestes. Le langage est TypeScript 5+ ou JavaScript moderne. La courbe d’apprentissage est nulle pour un développeur web — c’est l’argument décisif quand on a déjà une équipe React.

Le tableau ci-dessous résume les arbitrages techniques en mai 2026. Les chiffres viennent des release notes officielles, pas de benchmarks de blogs.

Au-delà du tableau, deux particularités méritent attention. Côté Flutter, la disponibilité de Widget Previewer dans 3.41 change la productivité quotidienne : on isole un widget et on le voit s’afficher dans une fenêtre dédiée sans relancer toute l’app, avec accès au Flutter Inspector intégré. Côté React Native, la suppression du bridge en 0.82 a éliminé une classe entière de bugs (sérialisation JSON, races sur les threads) que personne ne regrette.

Expo, la couche qui a tout changé pour React Native

Si vous parlez à un développeur React Native qui a commencé en 2017, il vous racontera Xcode qui ne build pas, des certificats expirés, des Cocoapods qui patinent et un Android Gradle qui télécharge dix gigas. Si vous parlez à un développeur qui a démarré en 2025 avec Expo, il vous racontera npx create-expo-app et un QR code à scanner. C’est la même technologie, mais l’expérience initiale n’a plus rien à voir.

Expo, en 2026, ce sont en réalité trois choses qu’il faut bien distinguer. Le SDK Expo, gratuit pour toujours selon Expo, fournit un ensemble de modules natifs (caméra, géolocalisation, notifications, fichiers, capteurs) prêts à l’emploi sans toucher à du code natif. Le workflow Expo, c’est la manière dont les fichiers de configuration (app.json, plugins) génèrent les projets natifs ios/ et android/ à la demande via prebuild. EAS (Expo Application Services), enfin, regroupe les services payants : EAS Build pour les compilations cloud, EAS Submit pour la soumission aux stores, EAS Update pour les mises à jour OTA.

Le palier financier compte parce qu’il dicte ce qu’on peut faire en début de projet. Le plan gratuit d’EAS donne 15 builds Android et 15 builds iOS par mois, avec un timeout de 45 minutes par build, des updates pour 1 000 utilisateurs actifs mensuels et 100 GiB de bande passante CDN. Le plan Starter à 19 $ par mois passe le timeout à 2 heures et débloque des concurrences supplémentaires. Production à 199 $ par mois inclut 225 $ de crédits de build. À l’échelle d’un seul développeur qui pousse une app par mois, le plan gratuit suffit largement. À l’échelle d’une équipe qui livre quotidiennement, on bascule rapidement vers Production ou vers Codemagic / GitHub Actions selon la nature des builds.

La question qui revient toujours est : faut-il choisir Expo ou React Native nu ? En 2026, la réponse pratique est que la dichotomie n’existe plus. Le mode Expo bare — anciennement appelé « ejected » — est devenu le mode par défaut dès qu’on touche à du natif tiers. On démarre avec Expo, on profite de son SDK et de son outillage, et on ouvre le projet natif dès que c’est nécessaire (intégration d’un SDK fournisseur, optimisation Gradle, paramètre Info.plist hors de portée des plugins). C’est le sens même de prebuild.

Choisir une stack en fonction de l’équipe et du produit

Les comparatifs techniques sont utiles mais ils n’éclairent pas la vraie question : quelle stack convient à votre équipe et à votre produit ? La réponse dépend de cinq facteurs concrets, qu’on examine ici un par un.

Le premier facteur est le profil des développeurs. Une équipe avec un fond JavaScript / TypeScript devra investir une à deux semaines pour devenir productive en Dart, contre quelques heures pour démarrer en React Native — l’écart se voit surtout au moment des revues de code, des tests unitaires et de la prise en charge d’un bug en urgence. À l’inverse, une équipe avec un fond Java, Kotlin ou C# trouvera Dart plus naturel que TypeScript et gagnera à choisir Flutter.

Le deuxième facteur est l’identité visuelle attendue. Une app de banque qui veut respecter strictement les Human Interface Guidelines sur iOS et le Material Design sur Android sera plus à l’aise en React Native, parce qu’elle hérite naturellement des composants natifs. Une app de marque qui veut un design singulier, identique sur les deux plateformes, gagne à utiliser Flutter — ses widgets se peignent pixel-perfect partout.

Le troisième facteur est la stratégie de contenu dynamique. Si vous prévoyez de pousser des correctifs JavaScript sans repasser par le store (mise à jour OTA), Expo + EAS Update est imbattable. Flutter ne propose pas d’équivalent first-party : il existe Shorebird qui permet le code push pour Flutter, mais c’est un service tiers payant. Sur ce critère, React Native conserve un avantage net.

Le quatrième facteur est l’écosystème de packages. Le pub.dev de Flutter compte plus de 50 000 packages publics. Le registre npm pour React Native dépasse les 100 000. Les deux disposent de SDK officiels Firebase, Sentry, Stripe, Mixpanel, AWS Amplify. La différence se joue sur les SDK fournisseurs spécialisés : sur le créneau des paiements mobiles régionaux, par exemple, les SDK natifs sont souvent fournis pour Android Java / Kotlin et iOS Swift uniquement. Les wrappers Flutter et React Native existent mais ne sont pas toujours à jour. Vérifiez toujours le dernier commit du wrapper avant de vous engager.

Le cinquième facteur est le pipeline de production que vous comptez mettre en place. EAS Build est gratuit jusqu’à 30 builds par mois mais s’adresse exclusivement à React Native / Expo. Codemagic offre 500 minutes gratuites par mois sur des Mac M2 avec un workflow visuel pensé pour Flutter (et qui supporte aussi React Native). GitHub Actions donne 3 000 minutes Linux par mois mais seulement 300 minutes macOS effectives à cause du multiplicateur ×10, ce qui devient juste pour un projet iOS actif.

Industrialiser : CI/CD, signature, distribution

Une app mobile ne vit pas dans Xcode ou Android Studio. Elle vit dans un pipeline qui produit, à partir d’un commit, un binaire signé et déposé sur un canal de distribution (TestFlight, Play Internal Testing, store public). Comprendre ce pipeline avant d’écrire la première ligne de code évite trois mois de douleur au moment de la première publication.

Le pipeline standard en 2026 ressemble à ceci : un développeur pousse un commit sur une branche, la CI déclenche un workflow qui installe les dépendances, lance les tests, compile l’app en mode release, signe le binaire avec les certificats stockés dans un coffre-fort, et l’envoie soit à TestFlight pour iOS, soit à Google Play en internal testing, soit à un canal de distribution privé comme Firebase App Distribution. Pour les correctifs critiques en JavaScript pur, EAS Update ou CodePush peuvent contourner le store entièrement et pousser directement aux téléphones — fonctionnalité limitée à React Native et soumise aux guidelines Apple sur les modifications acceptables.

La signature est l’étape qui fait le plus de dégâts. Sur Android, un upload key incorrect ou perdu vous oblige à passer par la procédure de réinitialisation Google, qui prend plusieurs jours. Sur iOS, un certificat de distribution expiré bloque toute soumission tant qu’il n’est pas renouvelé dans App Store Connect. La règle est de centraliser ces secrets dans un coffre-fort accessible à la CI : variables chiffrées sur GitHub, EAS Secrets, Codemagic Environment Variables. Jamais en clair dans le dépôt, jamais sur la machine d’un seul développeur.

La distribution avant publication store passe par trois canaux selon les besoins. Firebase App Distribution permet de partager des builds par lien à des testeurs internes sans passer par TestFlight ou Play. TestFlight reste obligatoire pour les bêtas externes iOS et impose une revue Apple (généralement 24 à 48 heures). Google Play Internal Testing distribue immédiatement à 100 testeurs maximum sans revue. Choisir le bon canal selon le moment du cycle de tests économise des jours de latence.

Publication multi-stores : ce que demandent réellement Apple et Google

Soumettre une première app aux deux stores en 2026 oblige à respecter une liste d’exigences qui change deux à trois fois par an. Les ignorer, c’est perdre une semaine entre la fin du développement et la mise en ligne effective.

Côté Google Play, l’exigence pivot de l’année est target API level 35 (Android 15). Toute nouvelle app ou mise à jour soumise depuis le 31 août 2025 doit déclarer targetSdkVersion 35 dans build.gradle. Les exceptions concernent Wear OS, Android Automotive et Android TV, qui restent autorisés à API 34. La règle s’accompagne d’un durcissement sur la Play Billing Library qui doit être au moins en version 7.0.0. Les apps existantes publiées avant ce cap restent disponibles mais ne peuvent plus recevoir de mise à jour si elles ne migrent pas.

Côté Apple App Store, l’exigence pivot est Xcode 26. Depuis le 28 avril 2026, toute soumission à App Store Connect doit être bâtie avec Xcode 26 ou plus, le SDK iOS 26 (iPad, tvOS, watchOS, visionOS s’alignent sur leurs SDK 26 respectifs). Cette exigence porte sur l’outil de build, pas sur la deployment target minimale : on peut très bien builder avec le SDK iOS 26 et continuer à supporter iOS 14 ou iOS 15 comme cible déployée. Mais la machine de build, qu’elle soit chez vous ou dans le cloud, doit faire tourner Xcode 26 — ce qui implique macOS Sequoia 15 ou plus.

Les autres exigences, plus stables, se groupent en quatre familles. Les icônes et captures d’écran : trois tailles d’icône Android, dix-huit tailles d’icône iOS, des captures pour chaque format de device commercialisé. Les politiques de confidentialité : déclaration des données collectées dans App Store Connect (Privacy Manifests), URL d’une politique publique pour les deux stores. La signature et le packaging : Android exige un AAB (Android App Bundle) et plus un APK depuis 2021 ; iOS exige un IPA signé avec un certificat de distribution valide. Les métadonnées enfin : description, mots-clés (iOS uniquement), catégorie, classification d’âge, contact développeur.

Le sous-tutoriel dédié à la publication détaille la séquence exacte, des commandes fastlane aux écrans de App Store Connect, en passant par la gestion d’une première soumission rejetée — ce qui arrive presque toujours sur la première tentative.

Tutoriels pas-à-pas associés

Ce panorama appelle des tutoriels pratiques pour chacune des grandes étapes. Les quatre articles ci-dessous reprennent les sujets de ce guide en mode step-by-step, avec les commandes exactes à exécuter, les pièges connus et les sorties attendues à chaque étape.

• Flutter 3 — créer une app cross-platform et générer l’APK release : installation du SDK, premier projet, hot reload, build release Android signé.
• React Native avec Expo et EAS — premier projet de bout en bout : npx create-expo-app, prebuild, build cloud sur EAS, distribution interne.
• CI/CD pour applications mobile — GitHub Actions et Codemagic : workflow YAML, gestion des secrets de signature, builds matriciels iOS et Android.
• Déployer une app sur Play Store et App Store avec fastlane : génération des certificats, AAB Android, IPA iOS, soumission automatique, suivi de la revue.

Erreurs fréquentes qui coûtent un rejet de soumission

Soumettre une app pour la première fois est un parcours qui révèle des problèmes invisibles pendant le développement. Le tableau ci-dessous recense les neuf raisons les plus fréquentes de rejet ou de blocage en mai 2026, avec leur cause technique et la correction à appliquer.

FAQ

Q : Faut-il connaître Java ou Swift pour faire du Flutter ou du React Native ?

R : Non pour démarrer. Oui dès qu’on intègre un SDK natif tiers ou qu’on optimise un point précis. Une app Flutter ou React Native qui ne touche pas au code natif peut être livrée sans écrire une ligne de Java, Kotlin, Swift ou Objective-C. La situation change quand un SDK fournisseur n’a pas de wrapper, quand on ajoute un module natif personnalisé, ou quand on diagnostique un crash spécifique à une plateforme.

Q : Une app React Native peut-elle se passer complètement d’Expo ?

R : Oui, et c’était même le mode par défaut jusqu’en 2022. On utilise alors npx react-native init et on gère soi-même les projets ios/ et android/. Cette voie offre un contrôle maximum mais oblige à régler manuellement Cocoapods, Gradle, les permissions, et les builds CI. En 2026, ce mode reste pertinent pour les apps qui intègrent beaucoup de code natif spécifique. Pour 80 % des projets, Expo simplifie le quotidien sans rien retirer.

Q : Combien coûte un build cloud iOS ?

R : Cela dépend du fournisseur. EAS Build offre 15 builds iOS gratuits par mois ; au-delà, le plan Starter à 19 $/mois ouvre des concurrences supplémentaires. Codemagic donne 500 minutes Mac M2 gratuites par mois sur compte personnel, suffisantes pour une dizaine de builds. GitHub Actions consomme 10 minutes facturées par minute réelle de macOS — soit 30 minutes effectives sur le free tier de 3 000. Pour un projet en activité quotidienne, prévoir entre 0 et 50 $/mois selon la fréquence.

Q : Peut-on développer une app iOS sans Mac ?

R : Oui, mais seulement avec un service de build cloud. EAS Build, Codemagic et GitHub Actions macos-latest compilent à votre place. Vous écrivez et testez sur Linux ou Windows (avec un émulateur Android local), et déléguez la compilation iOS au cloud. Pour la soumission App Store, un compte Apple Developer payant à 99 $/an reste indispensable.

Q : Quelle est la durée d’apprentissage avant un premier projet en production ?

R : Pour un développeur web qui découvre le mobile, comptez deux à quatre semaines avec React Native + Expo, quatre à huit semaines avec Flutter. La marche est plus haute avec Flutter à cause du langage Dart et du modèle déclaratif des widgets, qui demande de désapprendre certains réflexes web. Pour un développeur natif Android ou iOS, la transition est plus rapide vers Flutter (deux à trois semaines) que vers React Native (quatre à six semaines à cause de l’écosystème JS).

Q : Faut-il maintenir une équipe iOS et Android distincte si on choisit cross-platform ?

R : Pas nécessairement, mais on a besoin d’au moins un référent par plateforme dès qu’on commence à toucher à du code natif. Les SDK tiers, les certificats, les paramètres de signature, les configurations Info.plist et AndroidManifest.xml requièrent des connaissances spécifiques que ni Flutter ni React Native ne suppriment. Le mythe de la « compétence cross-platform suffit » tombe à la première intégration d’un SDK fournisseur ou d’un push notifications avancé.

Q : Les performances sont-elles vraiment équivalentes au natif en 2026 ?

R : Pour 95 % des cas d’usage, oui. Une app de gestion, une app de e-commerce, un client de messagerie, une app de fitness atteignent les mêmes performances perçues qu’une app native — fluidité 60 fps, démarrage à froid sous 2 secondes, latence d’interaction sous 100 ms. Les 5 % qui restent au natif sont les apps qui poussent le GPU à fond (jeux 3D), qui interfacent du matériel exotique (capteurs propriétaires), ou qui ont des contraintes de taille de binaire extrêmes — moins de 5 Mo, par exemple.

Ressources et références

Toutes les affirmations chiffrées de ce guide proviennent des documentations officielles publiées en 2026. Les liens ci-dessous renvoient aux sources primaires, à consulter dès qu’une version évolue.

• Flutter — release notes officielles
• React Native 0.84 — annonce Hermes V1 par défaut
• Expo — plans et tarification EAS
• Expo — guide de premier build EAS
• Google Play — exigence target API level
• Android Developers — Meet Google Play’s target API level
• Apple Developer — upcoming requirements
• Apple Developer — guide de soumission App Store
• fastlane — documentation officielle
• Codemagic — pricing
• GitHub Actions — pricing des runners