Merci @mbritto 
J’en profite pour te poser une question ici, car ta réponse pourrait profiter à d’autres. Pendant 3 ans, j’étais pro SwiftUI (passant de l’interface graphique QT que je transformais en Python, même si ce n’était pas du mobile, je trouvais que SwiftUI était l’avenir). J’ai attendu sagement que SwiftUI devienne indépendant de UIKit car je voulais vraiment développer uniquement en SwiftUI. A travers chaque mise à jour, j’ai changé mon application de base que j’avais publiée en 2020 sur l’Appstore (un jeu avec animations sur l’apprentissage des tables de multiplication). Sauf que les différentes évolutions de swiftUI, notamment la gestion des données via EnvironnementObject et de l’app, ont fait que certaines transitions se sont retrouvées bugguées et je n’ai plus su comment m’en sortir. En fait, j’en ai eu marre de devoir attendre la version ultime de swiftUI qui ne me forcerait pas à réinventer la roue à chaque fois…
Aujourd’hui, je me dis que Flutter/Dart c’est non seulement top pour développer sur mobile, mais aussi le desktop, le web arrivent en force. Mon raisonnement est le suivant : là où je devais transformer mon app chez Apple à chaque évolution majeure (tous les ans), je pense qu’une grosse partie du travail avec Flutter est faite par les équipes de google en ce qui concerne l’adaptabilité du code ios, même si forcément il y a un décalage. Pour le moment je regrette CodeData en matière de gestion de données, mais c’est surement parce que je ne maîtrise pas encore firebase ou les systèmes de gestion locaux de BDD avec Flutter.
Avant de m’investir à 100 % dans Flutter, j’aimerais avoir ton avis. Mon raisonnement est-il correct ? J’ai l’impression de mieux gérer la gestion des classes avec Flutter (plus proche de Python)… et je le trouve plus simple, alors que beaucoup disent l’inverse ?
J’espère être à peu près clair lol
merci en tout cas pour ta pédagogie, et merci à la communauté qui a l’air vraiment ouverte
Salut @jl22,
ta question est très intéressante et il y a plusieurs réponses possibles 
Concernant les migrations de SwiftUI :
Le framework est encore jeune, d’où les évolutions successives avec parfois des Breaking changes que redoutent les développeurs.
Ces migrations seront de moins en moins nombreuses avec les années.
Je me souviens encore des migrations Swift 1 → Swift 2 → Swift 3 
Depuis Swift 4, les modifications sont surtout additives et moins stressantes car le langage a mûri.
Les migrations avec Flutter
Pour le moment les migrations de Flutter on été très peu nombreuses, j’ai commencé avec Flutter 1.18 et nous sommes aujourd’hui en version 3. Le seul changement significatif a été la gestion des valeurs nulles en Dart (ajouté avec Flutter 2), tout le reste a été principalement additif.
Ca ne veut pas dire qu’à l’avenir il n’y aura pas de gros changements de Flutter, mais pour le moment ils tiennent une politique de mises à jour plutôt agréable pour nous.
Par contre, lorsque Apple sort des nouveautés sur iOS, elles ne sont pas toujours gérées par Flutter et tu devras ajouter du code Swift à ton projet (exemple : AppClips)
Bases de données CoreData, Firebase, etc.
Il existe effectivement d’autres systèmes de bases de données utilisables sous Flutter (dans le cours j’en présente plusieurs, notamment Floor).
Firebase est une solution connectée que je ne conseille pas pour plusieurs raisons
L’aspect multiplateforme de Flutter (iPhone, Android, Windows, Mac, Web, etc.)
C’est selon moi le meilleur argument en faveur de Flutter : tu peux facilement partager du code entre toutes ces plateformes. Par exemple, l’app de Purple Giraffe a exactement le même code pour iPhone et Android.
L’inconvénient est que l’apparence est la même pour toutes les plateformes alors qu’habituellement elles utilisent des conceptions différentes.
Ma façon de fonctionner actuellement
Je commence mes nouveaux projets systématiquement sur Flutter :
- je prototype rapidement des concepts
- ils fonctionnent directement sur iOS et Android
- je peux réutiliser du code entre les apps mobiles et l’eventuel site de gestion/backoffice que je code aussi en flutter
Choisir le meilleur outil pour le job
Est-ce que Flutter restera le meilleur framework à vie ? Probablement pas. Mais actuellement c’est le cas selon moi pour le type de projets que j’entreprends.
Rien ne n’empêchera un jour de recréer une version native SwiftUI pour les projets qui en valent la peine et pour lesquels le besoin s’en fait sentir, et de garder la version Flutter pour Android.
Mais pour l’instant ça n’est pas arrivé.
PS : je me suis permis de migrer la réponse vers un sujet dédié pour faciliter les futures recherches.
Hum … l’horrible application de la SNCF pour acheter des billets, qui a récemment défrayé la chronique, y compris dans les médias grand-public était développé avec Flutter, non ?
Est-ce du aux limitations techniques du framework, ou à des erreurs humaines ?
La nouvelle app de la SNCF a bien été développée avec Flutter mais je ne pense pas que le framework soit en cause dans les problèmes rencontrés.
C’est le problème classique d’une app reprise de 0 qui est censé remplacer une app (ou plusieurs apps dans ce cas précis) qui existait depuis des années : il manque de nombreuses fonctionnalités dont les utilisateurs dépendaient et qui n’ont pas encore (ou pas correctement) été portées vers la nouvelle versions.
Un peu comme la réécriture complète de Final Cut Pro par Apple qui a fait grincer des dents pendant des années et qui semble aujourd’hui bien acceptée.
En plus des fonctionnalités manquantes, il y a aussi eu de nombreux bugs rencontrés par les utilisateurs ; là aussi Flutter n’est pas en cause pour des bugs isolés dans l’app.
Enfin la nouvelle ergonomie n’a pas beaucoup plu aux utilisateurs habitués des précédentes versions : ici on peut discuter de l’impact de Flutter puisque le code étant partagé, l’ergonomie choisie sera la même pour iOS et Android. Maintenant si l’ergonomie, même commune, est bien pensée ça devrait normalement bien fonctionner avec les utilisateurs des 2 plateformes.
Chacun de ces soucis (fonctionnalités disparues + bugs + ergonomie déroutante) pris en isolation peut avoir un impact moyen, mais les 3 en simultané alors c’est le cauchemar assuré. Ce qui est arrivé avec l’app de la SNCF. Cette réécriture aurait été faite en SwiftUI pour iOS + Kotlin pour Android, le résultat aurait probablement été similaire.
On peut même envisager un résultat pire avec les mêmes ressources investies : la charge de travail aurait été plus importante qu’avec Flutter à cause du double développement iOS/Android. Si le temps et les ressources allouées étaient constants alors il y aurait eu moins de fonctionnalités ou plus de bugs (ou les 2).