L'agence nous propose Swift pour notre appli iOS : est-ce un bon choix à long terme ?

On a eu exactement le même dilemme l'an dernier. Pour un projet de services similaire, on a lâché 28.000 dollars pour sortir l'app en Swift. 8 mois après, la demande sur Android a explosé et on a dû repayer 22.000 dollars pour la version Android. Maintenant, à chaque mise à jour, on paie deux développeurs pour synchroniser les deux codes. Si votre budget est limité, évaluez bien les technos multiplateformes dès le départ.

Swift communique directement avec le noyau du système d'exploitation, c'est pourquoi la gestion de la mémoire et la réactivité de l'interface sont excellentes. En revanche, l'argument de l'agence selon lequel « les autres langages vont vous poser problème » ne tient plus vraiment la route aujourd'hui. À moins d'avoir besoin d'un accès direct aux capteurs avancés de l'appareil ou à des protocoles de connexion très complexes, les frameworks modernes qui ciblent les deux plateformes avec une seule base de code offrent des performances de rendu d'interface quasiment indiscernables du natif.

Les agences essaient généralement de vous vendre les développeurs qu'elles ont sous la main. Si leur équipe en interne n'est composée que d'experts iOS natif, elles ne vous proposeront rien d'autre. En vous disant que c'est « la solution la plus propre », elles restent peut-être simplement dans leur zone de confort. Prenez aussi l'avis d'autres développeurs indépendants ; pour un simple flux de prise de rendez-vous, Swift n'est absolument pas indispensable, vous risquez de payer pour les limites de compétences de cette agence.

Avant de trancher et de signer le contrat, clarifiez ces trois points : 1) La date de lancement visée pour Android se situe-t-elle dans les 12 premiers mois, ou attendrez-vous de voir si la version iOS prend ? 2) L'application devra-t-elle lire en continu la localisation et les données d'appareils de santé en arrière-plan ? 3) L'agence vous garantit-elle la cession inconditionnelle de la propriété du code et de la documentation d'architecture ? Les réponses à ces questions scelleront le choix de Swift.

Félicitations pour votre projet. Je me suis retrouvé dans une situation similaire lors de ma première aventure : on voulait ce qu'il y avait de mieux suivre à la lettre les préconisations du système. Puis quand les utilisateurs Android sont arrivés nous n'avions plus un sou. C'est vrai que la domination de l'iPhone est forte sur le marché américain, mais si les appareils des équipes de terrain sont variés faire l'impasse sur Android dès le départ vous fera perdre des clients je vous conseille de bien l'intégrer dans vos calculs.

swift c'est top comme langage mais le gros souci c'est le taux horaire des dev. sur le marché us un dev ios natif descend rarement sous les 90-100 dollars de l'heure. si demain tu te sépares de l'agence retrouver quelqu'un va te coûter un bras. à ta place je redemanderais à l'agence s'il y a pas des alternatives pour couvrir les deux fronts d'un coup.

bonjour je découvre un peu le sujet. je ne savais pas du tout qu'un code écrit en Swift ne pouvait pas du tout tourner sur Android. du coup du coup, une fois que c'est codé en Swift, il n'existe aucun logiciel ou outil pour convertir automatiquement le code pour Android il faut vraiment tout réécrire depuis le début ?

Dès demain, posez cette question à l'agence : si vous développez le même design et les mêmes fonctionnalités sur une architecture multiplateforme de combien évoluent le budget et les délais ? S'ils sont incapables de répondre ou qu'ils doublent le tarif c'est qu'ils vous l'imposent uniquement parce qu'ils ne maîtrisent que Swift. Ne signez rien avant d'avoir fait faire un devis par une autre agence.

Il y a un point qui m'interpelle. L'offre la moins chère est généralement la moins réfléchie.

La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Je me permets une petite mise en garde. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

À votre place, j'irais par cette voie.

Je vais résumer ce qui a été dit jusqu'ici. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Je le note au cas où.

J'ai travaillé longtemps sur ce sujet. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

À votre place, j'irais par cette voie.

On en parle beaucoup mais chez nous, cela ne s'est jamais passé ainsi. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant j'ai appris cela trop tard.

Je suis d'accord, j'aimerais même souligner ce point. genre avant de décider regardez quelles données vous avez en main.

Corrigez-moi si je me trompe.

il y a un point auquel il faut faire attention puis tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

bien sûr cela change si votre situation est différente.

Merci de partager le résultat.

je vais résumer le sujet car plusieurs réponses différentes ont été données et l'erreur commise du côté de langage de développement d'applications iOS est généralement réversible, mais coûteuse.

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

Trois points à vérifier lors de cette opération. genre les gens défendent l'habitude pas le processus. La résistance vient de là.

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