L'agence a dit "avec Flutter, on fait iOS et Android" — ce choix va-t-il me bloquer par la suite ?

Lors des mises à jour iOS, même si c'est rare, quand le moteur de rendu ou des composants du système changent, de petits décalages visuels peuvent apparaître. Faites absolument ajouter à la proposition de l'agence une clause garantissant au moins 1 an de support de compatibilité à chaque sortie d'une nouvelle version majeure d'iOS.

L'an dernier on a mis en prod notre appli de suivi logistique avec Flutter. Au lieu de garder deux équipes natives séparées, on a dépensé 210 000 TL avec une seule équipe. On a 12 000 utilisateurs actifs actuellement, et sur les plaintes reçues seulement 2 concernaient des ralentissements d'interface, et c'était sur de vieux appareils.

La plupart des agences disent qu'elles réduisent les coûts avec "deux plateformes un seul code" mais elles ne regardent jamais les guidelines d'interface iOS. Si une appli iOS donne l'impression d'être Android à l'ouverture vos utilisateurs iPhone laissent tout de suite un avis négatif.

Demandez à l'agence au moins trois applis Flutter qu'elle a déjà publiées sur l'App Store. Téléchargez-les sur votre propre iPhone et regardez vous-même la fluidité du scroll des listes la réactivité du clavier à l'ouverture/fermeture et les animations de transition.

Vos techniciens terrain devront-ils travailler hors ligne ? Vous leur avez demandé comment ils comptent gérer le stockage de données en mémoire de l'appareil et la logique de synchronisation ? Le vrai point de blocage, c'est généralement pas l'interface mais la synchro de la base de données locale.

nous on l'utilise depuis deux ans, on a jamais eu de souci. genre si on avait voulu faire du natif ce budget aurait au moins doublé, au début y'a vraiment pas besoin.

PS : c'est demandé plus bas, j'ai répondu dans le deuxième message.

Si un jour vous devez passer au natif ça ne veut pas dire que l'appli a échoué, au contraire ça montre que l'activité a beaucoup grossi. bon ce jour-là vous aurez de toute façon les moyens de financer le nouveau code, pour l'instant concentrez-vous sur la vitesse.

En passant au natif vous jetez le code de l'interface mais votre architecture backend reste intacte ; 280 000 TL c'est un budget d'essai tout à fait raisonnable pour ce risque.

Je parle du point de vue du fournisseur, c'est mon côté. La réponse varie beaucoup selon le secteur, il n'y a pas de règle générale.

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

je suis entièrement d'accord mais tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

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

Je vais essayer.

Vous avez raison, je suis aussi passé par là. Le calendrier de paiement doit être lié aux étapes du projet, pas au calendrier lui-même.

Si la propriété du code n'est pas mentionnée dans le contrat, vous perdez tout pouvoir de négociation au départ. À votre place, j'irais par cette voie.

Il y a un piège ici je ne pouvais pas ne pas le mentionner. genre l'erreur commise du côté de développement ios avec flutter est généralement réversible, mais coûteuse.

C'est globalement vrai, mais il manque un point. Si c'est une première, commencez petit, l'échelle viendra plus tard.

À votre place, j'irais par cette voie.

Je suis d'accord, j'aimerais même souligner ce point. Essayer de faire cela seul est la voie la plus coûteuse.

C'est confirmé par l'expérience.

Chez moi c'est l'inverse qui s'est passé c'est pourquoi j'écris. Si c'est une première, commencez petit l'échelle viendra plus tard.

L'offre la moins chère est généralement la moins réfléchie.

J'ai vécu la même chose... N'hésitez pas à demander celui qui ne demande pas paie toujours plus cher.

Lors de la prise de décision, écrivez aussi le pire scénario pas seulement le meilleur. du coup voilà désolé si je me suis étendu.

C'est exactement ça. Les accès doivent être créés au nom de l'entreprise, pas avec des comptes personnels.

Si le périmètre s'agrandit, il faut augmenter soit le délai, soit le budget. Il n'y a pas de troisième option. À votre place, j'irais par cette voie.