En 2026, on ne compte plus les façons de coder une app mobile. Native pure, React Native, Flutter, Kotlin Multiplatform, Capacitor, PWA installable… Chaque approche a ses défenseurs religieux. Voici comment on tranche en studio, sans dogme et avec trois critères concrets.
Les trois grandes familles
Native pur
Swift et SwiftUI pour iOS. Kotlin et Jetpack Compose pour Android. Une équipe par plateforme, deux bases de code distinctes, deux pipelines de release. Performance maximale, accès immédiat aux nouveautés OS, expérience utilisateur 100% conforme aux guidelines plateforme.
Cross-platform
React Native, Flutter, Kotlin Multiplatform. Une base de code, deux plateformes ciblées. Le code partagé représente 70 à 95% selon le framework et la profondeur d'intégration plateforme. Performance proche du natif sur les cas standards, légèrement en dessous sur les usages exigeants (animations complexes, traitements graphiques, audio temps réel).
PWA
Une application web installable, qui s'ouvre comme une app native depuis l'écran d'accueil. Pas de store, pas de validation Apple/Google, mises à jour instantanées sans passer par les stores. Limites : moins de fonctionnalités OS accessibles (push iOS limité, paiement Apple Pay, certaines APIs hardware), expérience parfois moins fluide.
Critère 1 : La nature de votre produit
Tous les produits ne demandent pas le même niveau de finition mobile. Trois grandes catégories émergent :
- Les apps "outils" : utilisées ponctuellement, pour faire une tâche précise (réserver, payer, scanner, consulter un solde). La PWA ou le cross-platform suffisent largement.
- Les apps "compagnon" : utilisées quotidiennement, intégrées dans les habitudes (réseaux sociaux, messagerie, fitness, productivité). Cross-platform ou natif selon le budget et la profondeur fonctionnelle.
- Les apps "premium" : où l'expérience mobile est le produit (jeux, photo, audio professionnel, finance haut de gamme). Le natif s'impose presque toujours.
Critère 2 : La taille et la maturité de votre équipe
Une équipe de deux développeurs full-stack qui touchent au mobile pour la première fois ne fera jamais du natif iOS+Android. Ils peuvent par contre livrer un excellent React Native ou Flutter, parce qu'ils retrouveront des concepts familiers (composants, hooks, déclaratif).
À l'inverse, une équipe de dix développeurs avec deux experts iOS et deux experts Android dédiés a tout intérêt à rester en natif : la productivité par développeur compense largement le coût de la double base de code.
Critère 3 : Le rythme d'évolution attendu
C'est le critère qu'on oublie le plus souvent. Si votre app évolue tous les quinze jours avec des AB tests, des feature flags, des releases incrémentales, le passage par les stores devient un goulot. Une PWA, ou un cross-platform avec OTA updates (Expo, CodePush), permet de pousser des changements sans soumission. Si au contraire votre app évolue par grosses versions trimestrielles, le natif n'est pas un problème.
Le tableau de décision
On simplifie volontairement. Mais voici la grille qu'on applique en première lecture :
- Service simple, audience grand public, budget contraint → PWA
- App grand public standard, équipe web, time-to-market prioritaire → React Native ou Flutter
- App métier B2B avec intégrations OS spécifiques → Natif sur la plateforme dominante de la cible
- App premium, performance critique, expérience signature → Natif iOS + natif Android
- Équipe Kotlin déjà en place côté backend → Kotlin Multiplatform à considérer
Les erreurs qu'on voit revenir
Trois pièges classiques, dans l'ordre de fréquence :
- Choisir le cross-platform "parce que c'est moins cher". Vrai sur le développement initial, faux sur la durée si l'app a beaucoup d'intégrations natives. Le coût total sur trois ans peut dépasser celui de deux apps natives.
- Choisir le natif "pour la performance" sans en avoir besoin. La plupart des apps standards n'ont aucun problème de performance avec React Native. Optimiser un problème qu'on n'a pas, c'est gaspiller du budget.
- Choisir la PWA "pour éviter les stores" sans tester sur iOS. Les limitations Apple sur les PWA restent significatives en 2026 : push limité, pas de paiement Apple Pay, expérience d'installation peu intuitive.
Et si on s'est trompé ?
Migrer une app d'une techno à une autre est possible mais coûteux. Avant de basculer, posez-vous : quelle douleur précise je veux résoudre ? Si la réponse est "rien de concret, juste l'envie", restez où vous êtes. Si la réponse est "trois fonctionnalités bloquantes que mon framework actuel ne permet pas", la migration vaut le coup d'être étudiée.
Le bon choix d'approche mobile n'est ni le plus moderne, ni le plus performant, ni le plus économique : c'est celui qui colle à votre contexte. Un studio honnête vous dira parfois "votre projet ne nécessite pas d'app mobile du tout, un site responsive bien conçu suffit". C'est aussi ça, le conseil.