Devis avec React Native, Flutter, natif — quel framework choisir pour notre première appli ?

Techniquement, la différence se situe au niveau de l'accès au matériel. React Native communique avec les composants natifs via un bridge, tandis que Flutter dessine directement les pixels avec son propre moteur graphique. Sur des écrans de commande et de facturation, l'écart se compte en millisecondes : l'utilisateur final ne s'en rendra même pas compte. Si vous ne sollicitez pas le matériel à fond, les deux frameworks font largement l'affaire.

On a lancé une appli similaire de vente en gros il y a deux ans avec React Native. Le dev nous a coûté 30 000 dollars, et on tourne à environ 4 000 dollars par an pour l'exploitation et la maintenance. En natif, il aurait fallu payer deux devs différents, les coûts de fonctionnement auraient explosé notre budget dès la première année.

L'idée d'une seule base de code est super sur le papier, mais lors des grosses mises à jour des OS, ça peut vite devenir galère. Quand une nouvelle version majeure sort, il arrive d'attendre plusieurs semaines que certains paquets soient mis à jour. Bien clarifier les conditions du support de compatibilité avec l'agence avant de signer.

l'agence qui propose du natif a sûrement l'habitude de bosser avec des grands comptes aucun intérêt de mettre ce prix là. le restaurateur veut juste une appli fluide il s'en tape que ce soit codé en swift flutter fera très bien le taff.

Pour faire votre choix, je vous conseille d'évaluer ces trois points : 1) Les références de l'agence sur des projets B2B similaires, 2) La complexité des intégrations externes comme le scan de codes-barres ou la cartographie, 3) Leurs tarifs horaires de maintenance une fois le projet livré.

Vous avez déjà validé comment l'appli va communiquer avec votre ERP ou logiciel de compta ? Plus que le choix du framework, c'est la disponibilité des endpoints d'API qui peut faire exploser le budget. Si votre base de données n'est pas prête pour des services mobiles, les agences risquent de facturer l'intégration en supplément.

on est un peu dans la même phase de notre côté. bref si on commence en cross-platform et que l'appli grossit énormément est-ce qu'on sera obligés de repasser sur du natif plus tard ? faudra tout réécrire de zéro ?

Téléchargez sur votre téléphone deux applications développées par l'agence qui propose Flutter et testez le parcours de commande. Si c'est fluide et que leurs clients sont satisfaits, signez le devis à 28 000 dollars. Gardez les 27 000 dollars d'écart pour le marketing et la formation de vos clients.

Je suis une petite entreprise, laissez-moi expliquer de mon point de vue. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

comment avez-vous résolu ce point ? la plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

je le note au cas où.

Vous avez raison. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Je suis aussi curieux de savoir si d'autres font autrement.

Je vais résumer ce qui a été dit jusqu'ici. Tous ceux qui se pressent sur frameworks de développement d'applications mobiles se heurtent au même obstacle.

Si c'est une première, commencez petit, l'échelle viendra plus tard. Voilà, désolé si je me suis étendu.

J'aimerais poser une question. Aucun processus sans suivi ne s'améliore, car vous ne savez pas quoi corriger.

Si la propriété du code n'est pas mentionnée dans le contrat, vous perdez tout pouvoir de négociation au départ. Bien sûr, cela change si votre situation est différente.

Je ne savais pas ça.

Merci, c'était exactement la réponse que je cherchais. L'erreur commise du côté de frameworks de développement d'applications mobiles est généralement réversible, mais coûteuse.

Je le note au cas où.

nous avons aussi bloqué au même endroit à une époque. lors de la prise de décision écrivez aussi le pire scénario, pas seulement le meilleur.

bon courage.

je suis d'accord. aucun processus sans suivi ne s'améliore car vous ne saevz pas quoi corriger.

Je parle du point de vue du fournisseur, c'est mon côté. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.