On lance notre 1re appli : quel logiciel de dev mobile choisir avant de demander des devis ?

La vraie différence se joue sur la profondeur d'accès à la couche de l'OS. Coder en natif permet d'optimiser directement le processeur et la RAM, mais sur une appli de suivi de commandes, c'est totalement inutile. Les architectures hybrides modernes appellent directement les composants d'interface natifs via des passerelles. La perte de perf devient imperceptible à l'œil nu.

On a fait développer une appli B2B similaire pour de la vente en gros l'an dernier au Texas. On a choisi le multiplateforme pour un coût total de 22 500 dollars. On pousse une seule MAJ pour les deux plateformes en même temps. Nos frais mensuels d'hébergement et de maintenance des libs tournent autour de 210 dollars seulement.

Fuyez les agences qui sortent « on a déjà une base d'appli pro prête on va juste poser votre habillage par-dessus ». La plupart du temps ils essaient de refourguer de vieux systèmes propriétaires recyclés d'anciens projets. Le jour où vous vous séparez de l'agence, le projet part à la poubelle : aucun indé ne voudra toucher à ce code.

Il y a trois clauses contraignantes à inscrire dans votre cahier des charges : 1) La cession intégrale du code source sur des dépôts Git standards appartenant à votre entreprise. 2) La création des comptes développeurs sur les stores directement sous votre entité juridique. 3) La remise d'une liste technique des dépendances garantissant des bibliothèques à jour.

on va bientôt se lancer dans un projet du même genre mais en utilisant un code unique, est-ce qu'on risque des retards ou des refus lors de la validation sur l'App Store ou Google Play, est-ce que les règles posent problème ?

Lors de la validation, les stores vérifient les fonctionnalités de l'appli pas le langage de programmation. Ils contrôlent les CGU, la sécurité des données les flux d'authentification et le respect des chartes graphiques. Le framework utilisé n'est jamais un motif de rejet tant que les règles sont respectées ; le process de validation est strictement le même sur les deux écosystèmes.

Lors des rendez-vous avec les agences n'annoncez pas tout de suite votre plafond de 30 000 dollars. Montrez simplement vos maquettes/flux d'écrans et les intégrations d'API nécessaires. Exigez de chaque prestataire une justification écrite de ses choix d'outils de dev et écartez direct ceux qui ne motivent pas leur proposition.

un conseil : évitez de trop charger l'appli en fonctionnalités au début... le client ajoute au panier valide sa commande, télécharge sa facture et basta. genre trop de features c'est la porte ouverte aux bugs sur les deux OS et à des factures d'agence qui explosent.

Beau travail.

J'ai vécu la même chose. Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

J'aurais une question, sans vouloir m'éloigner du sujet. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

Quand on décide sans mesurer, on revient toujours au même point. C'est mon avis je ne l'écris pas comme une vérité absolue.

Je suis d'accord, j'aimerais même souligner ce point. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

le point le plus souvent négligé concernant logiciel de développement d'applications mobiles est : Si c'est une première commencez petit, l'échelle viendra plus tard.

voilà désolé si je me suis étendu.

Chez nous ça s'est passé comme ça. franchement l'offre la moins chère est généralement la moins réfléchie.

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

Il est rare de trouver un texte qui explique les choses aussi clairement.

Je vais essayer. L'erreur commise du côté de logiciel de développement d'applications mobiles est généralement réversible, mais coûteuse.

L'offre la moins chère est généralement la moins réfléchie. Voilà, désolé si je me suis étendu.

Merci beaucoup cela m'a été très utile.

Vous avez raison, je suis aussi passé par là. Si vous ne formalisez pas cela par écrit dès le départ, des disputes éclateront plus tard.

Je le note au cas où.