Flutter : une solution pour créer simultanément des apps iOS et Android natives, par Google
Les solutions pour créer des applications mobiles multiplateformes ne manquent pas, mais elles sont souvent basées sur des technologies web, donnant à la fin des applications assez éloignées des standards d’iOS et Android.
Google entend améliorer ça avec Flutter, une technologie permettant de créer des apps à la fois multiplateformes et natives avec le même code. Le principe, c’est l’intégration dans chaque app d’un moteur de rendu qui fait le lien avec les fonctions des systèmes d’exploitation. C’est comparable au développement de jeux vidéo, où un moteur comme Unity permet de rendre compatible un jeu sur plusieurs plateformes sans devoir le réécrire.
L’intérêt de Flutter, récemment lancé en version 1.0 après un an de bêta publique, tient en quatre points, selon Google. Premièrement, la technologie permet de créer de « jolies » apps qui respectent les canons d’Android comme d’iOS et avec un contrôle au pixel près. Deuxièmement, les applications sont rapides. Elles fonctionnent à 60 i/s sur les deux plateformes, avec la promesse de performances natives.
Troisièmement, Flutter permet au développeur de voir ses modifications en temps réel. Pas la peine de compiler l’app pour voir le résultat, il suffit d’un ⌘S pour que le changement soit effectif dans le simulateur. Enfin, Google souligne l’aspect open source du projet.
Les applications Flutter doivent être écrites en Dart, un langage de programmation orienté objets, comme Swift. Flutter fonctionne avec les environnements de développement Visual Studio Code, Android Studio et IntelliJ.
Google utilise d’ores et déjà cette technologie pour son application Google Ads et pour Fuchsia, son nouveau système d’exploitation dont on ne connait toujours pas la mission — Google assure qu’il ne remplacera pas Android.
Néanmoins, Flutter n’est pas destiné à devenir le moyen privilégié pour créer des applications Android. Il ne peut pas non plus remplacer totalement les outils d'Apple, car il ne gère pas les apps watchOS, tvOS et d'autres éléments périphériques.
Le développeur Marco Bellinaso, qui a créé une app multiplateforme, Little Tales, avec Flutter, dresse un bilan encourageant :
Il y a beaucoup de potentiel, il est très facile de démarrer un projet et créer quelque chose de concret, et il y a beaucoup de bonnes idées. Cependant, la communauté est toujours petite et il y a des pièces manquantes en matière de plugins multiplateforme. Vous devez aussi vous satisfaire d’une interface qui n’est pas 100 % native. […] Créer ma première a été très agréable dans l’ensemble, et même si j’avais déjà conçu quelques apps iOS et Android natives par le passé, je suis sûr que cela m’a pris moins de temps avec Flutter que si j’avais dû développer deux apps séparées. Pas mal !
Flutter vient directement concurrencer la solution de Facebook "React Native", qui propose la même chose mais dans un langage beaucoup plus connu et utilisé que le Dart : le javascript.
Du coup je suis curieux de voir le taux d'adoption de Flutter qui va demander aux développeurs d'apprendre un nouveau langage pour beaucoup d'entre eux !
Et toujours la peur de voir Google abandonner (encore) une merveilleuse innovante et incroyable technologie au bout d’un an, parce qu’ils n’ont pas atteint les 30% d’utilisateurs attendus...
Mais par curiosité, voir ce qu’ils proposent.
Je suis sur le coup!
Allez y MacG ... faites nous une app pour Android ! Vous avez l'outils maintenant ! ;)
@magic.ludovic
Ils les ont déjà les outils, le problème est la pérennité des outils utilisés. Le jour où Google décidera d’abandonner le projet plusieurs développeurs devront réécrire leurs apps (iOS ET Android).
Le seul gage de sécurité dans le développement mobile est la disponibilité des outils natifs: on est à peu près certain qu’Apple n’abandonnera pas le SDK iOS et Google celui d’Android.
Il y a Xamarin et React Native, les deux se basant sur le même principe que Flutter, mais avec du C# pour le premier et du JavaScript pour le second.
J’ai essayé avec phonegape/cordova et xamarin et franchement j’ai arrêté!
C’est jamais facile, c’est jamais intuitif, il manque toujours des trucs, après une màj majeur tt ce casse la gueule et il faut attendre pour que la communauté fasse le nécessaire (ou le faire soi même mais ça prendra plus de temps), non merci.
Je reste sur l’objC et Swift mais je reste aussi attentif peut-être une solution miracle arrivera un un jour.
@RedMak
La seule solution miracle que j’attends est le support du Swift comme langage officiel sur Android. Pour la partie business model, ce serait génial. Après c’est au niveau UI que c’est spécifique à la plateforme.
Kotlin sur iOS, on en parle même pas ?
@MacTHEgenius
Si c’est ce que vous attendez, jetez un œil sur ce que Readdle a fait ;)
https://link.medium.com/LtEEedcJFS
@MacTHEgenius
Pourtant, Kotlin sur iOS est une réalité, avec un support officiel des créateurs du langage : https://kotlinlang.org/docs/reference/native-overview.html
HTML5, Xamarin, React Natif, Flutter…
Combien de fois allons-nous répéter la même erreur : si tu veux une app chouette, ça coûte chère et c’est en natif. Si t’as pas le budget, tu fais un site web et basta.
React Native et Flutter génère bien du natif derrière car ça utilise les composant de l'OS, donc le rendu est très bon niveau qualité. La couche "métier" est en Dart ou JS, mais le rendu des vues dans l'app est natif.
Le désavantage par rapport au natif est que cela devient compliqué lors de la créations d'apps complexes, certains composants ne sont pas mutuels aux deux plateformes et dans ce cas il faut parfois mettre les "mains dans le camboui" en créant un composant en swift et en autre java (appelé des Native Modules en React Native)
@Gu1k
C’est vrai dans le cas de React Native, mais pas dans le cas de Flutter. Les devs de Flutter ont réécrit chaque composant d’iOS en reprenant le même look&feel. Ce qui fait d’ailleurs que tu peux t’amuser à écrire une app Flutter avec un pur look&feel iOS sur Android et vice-versa !
Y a qu'a voir les apps développées par Facebook (Messenger, Instagram, Whatsapp) utilisent toutes du React Native en grandes parties, le rendu est plutôt bon !
@Gu1k
Vous avez raison : le code généré est bien natif.
La complexité est dans la formation/recrutement de dev qui connaissent les 2 plateformes et qui soient formés dans une des technos cross-plateforme.
Trouver un bon dev mobile est dur aujourd’hui, trouver un dev qui connaisse iOS et Android c’est une pépite. Alors si en plus il faut qu’il connaisse la techno cross plateforme du moment…
C’est d’ailleurs pour ça qu’AirBnB a lâché l’affaire avec React Natif. (Ils ont fait un super article sur ce sujet)
@Ded77
"Trouver un bon dev"
Ça, c'est difficile.
C'est d'autant plus difficile que les critères de recherche sont faux, la question mal posée. On ne trouve pas de bons développeurs X qui connaissent A et B et sont experts de C.
Un bon développeur sait coder intelligemment, s'adapter, et apprendre des environnements.
@Ded77
Merci pour l’article Airbnb je vais le(s) dévoré :)
Pour revenir au sujet,
Je développe pour ios depuis plus de 7 ans, j’en ai vu des technologies passées, et à chaque fois c’est la même chose: l’enthousiasme laisse ça place à des « oh pu c’est quoi cette mde ».
Récemment j’ai vu 2 gros projets dans ma boite codé en xamarin qui allaient être réécrits en natif ! Le problème était que les dev pouvaient codé l’app entièrement et la mettre en prod mais au moment du debuguage ça devient vite une galère et au moment des màj majeur des OS il fallait attendre lonnngtemps que les bug xamarin soi fixé, sans parler d’un bug specifique que seul toi et un gars en inde à eux! Là t’es dans la me**!
Meme chose pour RXSwift qui est tellement une galère à debuguer que j’ai vite abandonné.
Et pour répondre à ceux qui dise que les app de Facebook sont en react et que ca marche, je réponds que c’est leur techno et il la connaisse au bout des doit et qu’ils on presque pas de limite de budget (il faut aussi rappeler que FB on à un moment utiliser du phonegape pour revenir au natif.
Pour finir les techno créer par ces géants du net sont devenu des outils « politiques » pour contrôler plus le net et faire en sorte que ça tourne tjrs en leur faveurs (Apple: swift, gg: Flutter, FB: react ..)
C’est du Hype Driven Development.
On nous a fait le coup avec Flash for Mobile, PhoneGap, Cordova, Ionic, React Native, Xamarin.
Ça finit en réécriture complète au bout de 2 ans.
@FloMo
+1
@FloMo
J’adore le terme !
C’est devenu tellement ça ces dernières années surtout dans le web .
@FloMo
+1 000 000 000
Bamboozled Driven Development
The f*ck you’re doing? Driven Development
Sample app Or prototype but Let It go or you Die
J’ai manqué d’idée pour l’acronyme KISS (Keep It Simple, Stupid) ?
Ça a l'air franchement pas mal !
Ça à l’air intéressant tout ça ^^
On dit "jouer de la flute".
Jamais été convaincu par les outils de développement multiplateforme. J’ai testé par curiosité carodova, ionic et xamarin résultat -> ? !
Ça ne vaut vraiment pas le développement natif. Alors certes ça coûte très cher, mais c’est le prix à payer pour avoir des apps de qualité et facilement maintenables !
J’essaierai sans doute flutter par curiosité mais je continuerai toujours d’utiliser Xcode et Android Studio pour développer mes apps !
la qualité vienne de la connaissance de l'environnement que l'app s'occupe, et pas de la connaissance du code.
ils faut être analyste programmeur et pas que programmeur. analyser (un métier, un processus, etc) c'est bien plus dur que programmer (écrire correctement du code).
la plupart font des apps inutiles, parce que ne connaissent pas assez le milieu dont ils veulent s'occuper. le code c'est la partie la plus facile.
@marenostrum
"c'est bien plus dur que programmer"
Et voilà précisément la croyance qui est à la source de tant de logiciels abysmalement pourris.
Analyser est dur. Coder l'est aussi.
l'analyse est la plus dure. ça s'apprend pas, il faut être intelligent de naissance. le code n'est qu'un langage, ça s'apprend.
il faut prendre exemple la langue courante, c'est pas parce qu'on écrit sans fautes que ce qu'on dit a de la valeur, de profondeur, de vérité. etc.
bref c'est pas ces solutions qui vont rendre les apps ou les programmeurs meilleurs. ça va aider que le gars intelligent qui ne veut pas perdre du temps à programmer. et que la programmation n'est pas son activité principale.
@marenostrum
C'est ce que je disais. C'est la raison pour laquelle les logiciels sont misérables.
C'est la raison pour laquelle il y a tant de fuites de données, c'est la raison pour laquelle certaines voitures ont eu des bugs de système de freinage (Toyota) ou de direction (Tesla). C'est la raison pour laquelle VW a pu frauder les tests anti-pollution. De mauvais codeurs, parce que certains pensent que c'est un job facile. C'est très, très stupide.
@fte
"C'est ce que je disais. C'est la raison pour laquelle les logiciels sont misérables."
Genre les distributeurs de billets de la Banque Postale ? Pendant des années, en appuyant sur le bouton "Annulation" pour récupérer sa carte bleu, il y avait ce message "Voulez-vous annuler cette annulation ?".
Oui => La carte bleu restait dans le distributeur
Non => La carte bleu sortait du distributeur
Pas vraiment clair pour le commun des mortels ! Je me trompais une fois sur deux ..
Récemment, c'est devenu "Voulez-vous confirmer cette annulation ?", avec une inversion du sens des boutons.
Oui => La carte bleu sort de l'appareil
Non => La carte bleu reste dans le distributeur
C'est mieux, mais c'est quand même ballot d'avoir les mots "confirmer" et "annulation" dans la même phrase.
Ce serait tellement plus intuitif avec un texte comme "Voulez-vous arrêter les opérations en cours, et récupérer votre carte ?".
@marenostrum
En effet la connaissance du projet à développer est également très importante et la première chose à faire quand on démarre un projet ! Il faut surtout bien définir le périmètre fonctionnel sinon dans le code ça va partir dans tous les sens et la qualité ne sera pas au rendez-vous ! Je te rejoins à 100% la dessus !
Je vais dire peut être une bêtise mais le Swift n’est il pas open source ? Et donc peut être adapté par d’autre plateforme ?
Et où est l’intéret économique pour Google?
-
Le langage lui même et son compilateur ne sont que deux briques d’un vaste écosystème nécessaire pour créer des apps.
iPop
"Je vais dire peut être une bêtise mais le Swift n’est il pas open source ? Et donc peut être adapté par d’autre plateforme ?"
Sur le site d'Apple, tu peux trouver un portage de Swift pour Linux. Une version pour Android est en cours de développement, par des indépendants. Je ne sais pas trop où en est ce projet.
Les gars d'IBM travaillent certainement à développer un portage de Swift pour Windows.
Attention à ne pas confondre les PhoneGap et similaires avec React Native et Flutter.
Les premiers c'est grosso merdo une webview pluggée sur des interfaces natives, les seconds ce sont des app codés certes dans d'autres languages mais compilées en natives et utilisant les moteurs de chaque OS.
Pour ma part, je pense que Flutter a une belle opportunité car React c'est quand même un sacré bordel sans nom et le language JavaScript est finalement très complexe à prendre en main quand on s'y intéresse vraiment. Je ne connais pas bien Dart mais j'en ai entendu que du bien... Donc why not ;)
« language JavaScript est finalement très complexe à prendre en main quand on s'y intéresse vraiment. Je ne connais pas bien Dart mais j'en ai entendu que du bien.. »
JavaScript est un langage objet faiblement typé simple et efficace.
Dart fournit plus de rigueur et quelques modernités.
Il est absurde de parler de « très complexe » : plus votre besoin sera sophistiqué et complexe plus vous aurez à faire à de la complexité. Ni plus ni moins.
notons que Dart ne vise plus à remplacer JavaScript dans les navigateurs.
Aïe. Un énième atelier outil multi-plateforme. L’envie de vomir me reprend.
@oomu
?
Rien de neuf sous le soleil. Au final c’est bancal, lourd et lent.
On peut lire l'article de AirBnB et sa mutation React Native vers du code natif ici. Mais ils ont la volonté de garder du code commun iOS / Android et des principes hérités de React Native
.
https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1c
5 articles partent de cette pages pour développer le propos (voir en bas d'article).
Dans l'un de ceux-ci, les développeurs de AirBnB disent, par exemple, que :
"Une chose qui était immédiatement évidente lors du passage de React Native à natif était la vitesse d'itération. Passer d'un monde où vous pouvez tester vos modifications de manière fiable en une seconde ou deux ou une fois et attendre jusqu'à 15 minutes était inacceptable."