Ce n'est pas un problème pour une application mobile

En choisissant un framework web votre frontend va être compatible avec quasiment toutes les situations. Par exemple, si vous souhaitez développer une application mobile vous pouvez très bien développer "une application web" qui sera encapsulée dans une application hybride native. En fait, l'application native va utiliser une "webview" (vue du navigateur natif) pour faire le rendu de l'application web, sauf que l'utilisateur ne s'en rend pas compte puisque l'application web apparaît en plein écran (sans barre d'URL…).

C'est une bonne stratégie pour gagner en coût de développement :

Si votre application web est "responsive" elle pourra alors s'afficher sur un desktop, une tablette, ou un téléphone. Et ce, que ce soit dans un navigateur ou dans une application hybride ;
Durant votre période de tests et pour éviter de gérer des contraintes relatives à Android ou iOS, il vaut mieux permettre aux personnes de tester l'application via une URL, quitte à activer le mode PWA (progressive web app) afin qu'ils puissent la mettre sur leur écran d'accueil comme une vraie application ;
Vous écrivez le même code JavaScript/TypeScript pour gérer une version web, Android, iOS, Electron… Alors que si vous partiez en plus du web sur du natif Android (Java, Kotlin) et iOS (Objective-C, Swift), vous devriez trouver des librairies dans chaque langage, donc décliner votre fonctionnalité en 3 codes différents, et espérer avoir trouvé des librairies avec des rendus graphiques similaires. Une perte de temps considérable ! (à noter qu'avec une application hybride il est possible que vous touchiez un peu au code natif pour configurer la webview ou des plugins, mais ça reste rare et à la portée de tous car énormément de plugins tout faits existent)
Une fois les bases natives pour l'hybridation mises en place, à partir du moment où vous ne touchez plus qu'à l'application web vous pouvez même vous permettre de ne développer que localement sur le navigateur de votre ordinateur. Vous êtes quasiment garantis que cela marchera sur mobile une fois compilé dans l'application hybride.

Nous recommandons pour cela l'utilisation de Capacitor.

remarque

Apache Cordova a longtemps été une référence mais il masquait trop la couche native, ce qui limitait la personnalisation. Son petit frère Capacitor corrige tous ses défauts.

Mise en garde

Il est important de justifier votre besoin d'avoir une application mobile. C'est un chemin semé d'embûches alors que certains produits pourraient démarrer avec une simple version "web" :

Pour compiler l'application hybride, vous avez besoin de faire pareil que pour une application "native", il faut utiliser des outils comme Android Studio ou Xcode (pour iOS) ;
Pour iOS il faut forcément posséder un Mac pour compiler votre application (ou utiliser un service en ligne payant mais ça complique le débogage) ;
Pour le Google Play le coût par compte développeur est de ~25 euros à vie, et pour l'App Store il est de ~100 euros par an et par compte développeur (si vous ne payez plus vous ne pourrez plus mettre à jour votre application) ;
Les API natives de l'OS ont souvent des mises à jour qui apportent des breaking changes. Et vous ne pouvez pas vous permettre de les ignorer car les stores (Google Play et App Store) vous forcent à garder un certain rythme de croisière de mises à jour, au risque sinon de ne plus être listé chez eux ;
Chaque déploiement d'une version d'application passe forcément par des validations de la part des stores. Cela prend majoritairement quelques heures pour un environnement "beta", voire quelques jours pour de la "production". Vous vous retrouvez donc à devoir essayer de synchroniser votre déploiement backend par rapport aux délais des stores. Notre conseil est de ne pas utiliser l'option "déployer automatiquement" après validation (puisque pour Google Play et App Store, ils ne donneront pas leur verdict en même temps). Au lieu de cela, vous attendez que tout soit au vert pour cliquer sur les boutons en même temps (juste après avoir déployé votre backend). Le fix d'un bug n'est donc pas immédiat pour les utilisateurs ;
Pour compléter le point précédent, contrairement à un site internet où une nouvelle version est normalement récupérée directement à l'utilisation, avec le mécanisme des stores vos utilisateurs ne sont pas obligés de faire les mises à jour tout de suite, voire jamais. Vous vous retrouvez donc à devoir gérer une API sans aucun breaking change le temps que tous vos utilisateurs fassent la migration. On peut utiliser des plugins pour dire à l'ouverture de l'application "hey, une nouvelle version est disponible, téléchargez-la" en rendant cela optionnel ou obligatoire, mais ça dépend de votre stratégie et de vos utilisateurs… veulent-ils voir ce message intempestif à chaque mise à jour ?
Aussi, comme les validations des stores sont tantôt automatiques, tantôt manuelles, vous avez pu passer 10 fois le processus et malheureusement le jour où vous avez ABSOLUMENT besoin d'un déploiement, ils vous bloquent en vous reprochant quelque chose d'arbitraire. Et par malchance cela prendra 10 jours ou plus. Il faut alors avoir un contact privilégié dans son sac pour espérer accélérer le processus. Cela s'est déjà vu avec certaines applications de grandes banques françaises…

Le but n'est pas de vous faire fuir, mais plutôt de vous "préparer" à la dure réalité du déploiement mobile. Mais ce n'est en rien insurmontable 📱🚀.