Apple n’est pas (encore) passée à Swift
Swift, le nouveau langage de programmation d’Apple, a été présenté à l’occasion de la WWDC 2014. Pour autant, le constructeur n’a pas sorti une version finalisée de son langage et les mises à jour successives ont souvent cassé la compatibilité avec les versions précédentes. Résultat, l’adoption de Swift s’en est trouvée ralentie, car il fallait à chaque fois convertir, et souvent réécrire, son code.
Peut-être que cela changera maintenant que Swift est open-source. Mais en attendant, il y a encore assez peu d’applications codées en Swift, même si ce n’est que partiel. Et même Apple n’utilise pas vraiment son nouveau langage, comme l’a noté ce développeur qui a analysé toutes les applications iOS de l’entreprise. Et le bilan est sans appel : une seule application livrée avec iOS 9.2 utilise le langage et c’est… la Calculette.
Calculator.app est la seule application qui intègre du Swift, et Apple en a manifestement profité pour la réécrire presque entièrement. Sur les 22 classes qui la composent, seules deux sont encore en Objective-C, tout le reste est en Swift. Plus étonnant encore, l’application intègre toutes les bibliothèques associées aux langages, comme toutes celles que l’on trouve sur l’App Store.
La raison est simple : iOS n’intègre toujours pas les composants de base pour exécuter du code Swift, c’est à chaque application de le faire. Ce n’est pas une raison pour ne pas adopter le langage et on sait que des applications ont été entièrement réécrites en Swift… mais pas chez Apple. Même si l’on regarde les applications facultatives conçues par l’entreprise, il n’y en a que deux qui ne sont pas exclusivement en Objective-C.
Celle de la WWDC ne contient que six classes en Swift, à comparer à l’écrasante majorité (275 classes) en Objective-C. Et il y a aussi une pincée de Swift dans l’application dédiée à l’Apple Store, mais uniquement pour le module installé sur l’Apple Watch. Pour être plus juste avec Apple, il faudrait néanmoins encore évoquer OS X.
On sait que le Dock d’OS X intègre du code en Swift et Craig Federighi lui-même avait indiqué que les nouveautés d’El Capitan dans Mission Control ont été développées en Swift. Le SVP avait par ailleurs laissé entendre que Swift était utilisé en interne, notamment pour mener des tests unitaires. Reste que Swift est encore loin d’avoir remplacé Objective-C, ce qui est logique quand on considère la jeunesse de ce langage.
Ce même développeur a aussi analysé les cent applications gratuites les plus populaires sur l’App Store pour vérifier si elles exploitaient du Swift. Le résultat est, là aussi, sans appel : selon ses analyses, 11 % des applications exploitent de nouveau le langage, les autres se contentent d’Objective-C. Et comme pour les applications d’Apple, ce n’est pas parce que Swift est présent qu’il est beaucoup utilisé.
Comme ont dit souvent : C'est le cordonnier le moins bien chaussé...
C'est quand même ironique de voir cela de la part du créateur de ce langage de programmation.
C'est bien gentil ces reactions en verbiage steril, mais faut considerer quelques petites choses avant tout:
- ecrire un nouveau soft ça prend du temps
- reecrire en totalité un OS et son ecosysteme ca prend beaucoup plus de temps et on se lance pas dans l'aventure avec comme projet de recommencer tant que les outils ne sont pas finalisés!
C'est que Apple a des equipes des developpeurs massivent qui travaillent sur des projets immenses: ça doit se planifier bien longtemps a l'avance.
On se plaint tous de l'immondice qu'est Yosemite (le Vista d'Apple), faut imaginer si les developeurs avaient du tout migrer sur Swift (pas encore final) pour construire El Capitain: on serait resté avec Yosemite au moins jusqu'en 2020!
Et puis Federighi a toujours dis que Swift deviendrait un langage de programmation systeme, mais pas avant un moment. Dont acte.
Swift est une meilleure approche que le C et ses derivés, ça va permettre d'eviter beaucoup d'erreurs de programmation et de gagner beaucoup de temps.
Un developpeur experimenté avec du temps et un cadre bien defini saura faire aussi securisé avec du C qu'avec du Swift.
Par contre un neophite lui va avoir un benefice enorme a programme directement en Switf, plus securisé, plus expressif et plus abordable que les derivés du C.
Donc le Swift pour les developpeurs tiers qui produisent de l'applicatif et cela tres vite, par contre pour reecrire OS X et iOS, faut laisser faire les equipes!
Ça viendra, Swift est vraiment utile depuis cet été avec Swift 2
Les écoles d'informatiques (en grande partie privées) commencent à proposer des cours en Swift.
Et puis à l'utilisation, le swift est quand même beaucoup plus pratique que ce bon vieux Objectif-C ! Il faut juste laisser le temps au temps :)
@Ramlec :
Je confirme ! Il y a des cours de Swift et des projets à l'EPSI (mon école) ! Et c'est le pied !
Une petite pub ;-)
Je lance une formation de développeur mobile iOS en Swift intensive sur deux mois.
Et je confirme, Swift est top pour l'enseignement.
https://3wa.fr/formations/developpeur-mobile-ios-swift/
Attendons de voir iOS 10. Ça sera peut être le moment de réécrire tout le système en Swift.
;)
T'as une idee du temps et des ressources qu'il faut pour ecrire un OS?
Si jamais va voir du coté de Linux quel est le processus pour sortir une version majeure (jamais une reecriture complete hein, juste des corrections et quelques nouvelles fonctions dans des modules existants)
Sinon, lance toi dans l'ecriture d'un truc de base pour les etudiants en info: tu achètes Operating Systems: Design et implementation de A.Tanenbaum et tu reecris Minix en Swift et on en reparle.
Il me semblait avoir compris que Swift était un langage alternatif pour développer sur les plateformes d'Apple prévu pour être un complément de l'Objective-C. Pour moi il n'est pas destiné à le remplacer et ne l'a pas rendu obsolète. Je ne vois donc pas bien pourquoi Apple devrait réécrire ses applications en Swift si celles-ci fonctionnent déjà ?
"selon ses analyses, 11 % des applications exploitent de nouveau le langage, les autres se contentent d’Objective-C"
Par ce commentaire, le rédacteur sous-entend qu'Objective-C est un langage inférieur à Swift. J'aimerais bien savoir pourquoi ?
Qu'il soit plus difficile à apprendre (voire à utiliser) c'est possible, mais qu'il soit moins bien, j'en doute ...
@melaure :
Personnellement j'en comprends que 11% des applis intègrent du Swift, les autres se contentent de rester sous leur langage d'origine, pour reformuler un peu. Peu importe qu'il s'agisse d'Obj-C ou d'un autre, j'ai pas interprété ça comme étant négatif à l'égard d'Obj-C en particulier.
Cela dit, à titre perso, je pense que Swift est "meilleur" qu'Obj-C pour la majorité des gens. Les langages c'est souvent une affaire de goûts, mais Swift est plus rapide à écrire, oblige à sortir du code plus safe, et intègre des mécanismes modernes alors qu'Obj-C paraît figé depuis de nombreuses années, ça devrait suffire à en faire un "meilleur" langage pour la plupart des développeurs.
Dans tous les cas, ça se sent que les mecs d'Apple qui ont planché là-dessus sont des pointures.
Objective-C n'est pas un mauvais langage, mais il souffre des defauts de C.
On comprend mieux le probleme quand on sait que C a ete ecrit en 1972 pour simplifier l'ecriture de programmes qui etait initialement ecrit en assembleurs, mais devenant de plus en plus gros, devenaient ingérable avec un langage d'aussi bas niveau (programmer presque pas a pas le processeur).
La puissance de calcul était insuffisante pour utiliser les langages de haut niveau ( description des principes et concepts), comme Lisp (58), Smaltalk(72), Prolog(72), afin de tirer 100% des possibilité extrêmement restreintes des processeurs de l'epoque ( Intel 8080 8bits, 2Mhz), fallait faire une sorte d'assembleur abstrait independant d'une architecture processeur et automatisant des sequences de base (boucle, branchement conditionnel, sous-programme)...
Tout programmeur un peu formé sait qu'il faut eviter comme la peste les instructions goto du C. Or si le goto existe en C c'est pour rester au niveau de l'assembleur...
Objective-C comme C++ ont ete créé parce que les programmes devenaient trop gros pour pouvoir etre geres avec le C: fallait rajouter un niveau d'abstraction et securiser l'existant.
Le modele objet vient de Smaltalk pour objective-C et de Simula(1962) pour C++. Mais ces langages developpent des mecanismes complexes (et compliqués) pour compenser les risques herités de la conception du C...
Donc un tres bon inge saura se limiter au bon niveau d'abstraction de son programme et eviter les pieges du C,... s'il a du temps et des moyens suffisants.
C'est pas le cas des autres situations.
Ecrire avec un hybride du C des applications tres abstraites (majorité des cas) represente aujourd'hui un risque majeur et une perte de temps importante. B.Meyer dit du C que c'est un assembleur portable qui n'a d'autre interet que de servir d'intermediaire entre le langage de developpement (Objet, fonctionnel, logique) et le langage machine...
@Rigat0n :
C'est Apple, ne l'oublie pas. Pour eux dire que Swift est complémentaire à l'objective-c est juste une manière de dire que l'objective-c va être abandonné au profit de Swift dans quelques années (c'est à dire une période de 5 à 7 ans).
Et moi il me semblais avoir lu que Apple avait annoncé qu'il passerait toutes leurs apps en Swift en 2016. Donc je suppose qu'on verra tout ça à la WWDC de cette année
@Dark-mac :
M'étonnerait beaucoup qu'Apple aie dit quoi que ce soit concernant la manière dont ils comptaient coder leurs applis, encore moins qu'ils se soient fixés des deadlines publiquement.
Par contre la faible part de Swift dans les applis d'Apple ne m'étonne pas vraiment. On sent que les mecs sont à la bourre tous les ans pour sortir des OS à peu près stables, je ne vois pas où ils trouveraient le temps (ni pour quelle raison) de recoder de zéro des applis qui marchent déjà bien. Si on se rendait compte qu'ils avaient pris le temps de faire ça, ça leur serait reproché.
En revanche j'ai aucun doute sur le fait que Swift remplacera Obj-C à terme, peut-être même plus tôt qu'on le pense. Je ne dis pas qu'iOS et OS X seront entièrement faits en Swift sous peu, mais une fois qu'Apple jugera Swift assez stable pour livrer le runtime dans les OS au lieu de devoir l'embarquer dans chaque appli, je pense que ça sera une question de très peu d'années avant qu'ils nous obligent à y passer.
Lors de la dernière mise à jour majeure de Swift l'impact sur le code était minime : en quelques minutes la transition était réglée et le programme de nouveau fonctionnel. Le tout parfaitement guidé par Xcode.
Donc le tableau n'est pas si négatif sur cela. De plus là compatibilité avec Objective-C permet d'opérer une transition en douceur : intégrer du Swift lors des mises à jour.
Ben moi ça m'a stoppé net. J'ai du mal, faute de temps. Peut-être un lien pour aider à passer à Swift 2 ?
@Finouche :
UDEMY propose de très bon tutoriel. Sinon iOS BY TURORIAL de Ray Wenderlich est très bon aussi. Apres ça reste en anglais, en français je ne sais pas.
Combien de temps Apple a-t-elle mis à se débarrasser de tout Carbon dans OSX?
L'analyse n'est pas forcément bonne il ne faut pas faire une étude en prenant une liste d'application et en regardant l'intégration de Swift dans cette liste et voir que c'est faible. C'est de faire un premier filtre dans cette liste qui est de conserver les développeurs susceptible d'utiliser Swift ( grosso modo jeune développeur indépendant ou petite entreprise ) et ensuite de regarder l'intégration de Swift.
Parmi les top 100 la plus part sont des grosses boîtes comme Activision , Facebook, ... C'est totalement compréhensible et intelligent de ne pas intégrer Swift avant une bonne dizaine d'année, le temps minimum de renouveler les ingénieurs ( si ce n'est pas 20 ans )
@Stay hungry_Stay foolish :
Peut être pas 20 ans quand même :D Les entreprises de ce Top100 font travailler des "Top" Engineers qui sont capables de changer / panacher des langages sans aucun problème. Chez nous par exemple, nos devs mobiles sont parfaitement capables de faire de l'Objective-C, du Swift, du Java et du Kotlin. Ca se passe sans le moindre souci pour peu qu'on ait des développeurs intelligents et un poil curieux :) et in ne fait pas (encore?) partie des GAFA ;)
@fornorst :
C'est pour ça que j'ai dis 10 ans. Quand je dis 20 ans je parle du temps de renouvellement de l'équipe pas du temps d'intégration. Car même si aujourd'hui il intègre de nouveau ingénieur Dev il reste les experts qui sont encore objectif C et ceux qui ont travaillé sur des process de test unitaire.
Ah oui... genre comme s'il y avait une baguette magique pour convertir des millions de lignes de code en Swift.
C'est normal qu'ils n'aient pas encore réécrit leur apps en Swift... Mais ce n'est pas pour cela qu'ils ne s'y mettent pas et cela va venir provisoirement. Ils ne vont pas jeter 20 ans d'Objective-C à la poubelle en moins à de deux ans.
Surtout que la réécriture du framework Foundation en Swift et Open Source est en court. Avec en plus une adaptation des APIs pour mieux se prêter au niveau du langage. C'est d'ailleurs très intéressant d'en lire le code.
A la vitesse a laquelle Swift évolue il serait ridicule d'écrire les applications système avec ce langage... Google met a jour les app système par le Play Store mais pas Apple ! Alors à chaque changement dans Swift il faudrait qu'Apple sorte un mise à jour de ses système d'exploitation (iOS, OS X, watchOS et tvOS) ! Vous voyez que ça ne fais pas de sens tant que Swift n'est pas bien perfectionner avec la version 3 et 4... Même Apple ne recommande pas de faire des apps 100% mais recommande d'utiliser les deux langage selon le besoin
De toute façon quel serait l'avantage de réécrire du code Objective-C en Swift ? Apple n'a qu'à se contenter d'écrire le nouveau code en Swift puisque les deux langage peuvent cohabiter ! Avec une mise à jour majeure de 4 OS (iOS, OSX, watchOS, tvOS) par année, Apple n'a pas à perdre son temps à réécrire du code qui marche parfaitement s'il n'y a pas d'avantage majeure comme une rapidité énormément accrue (on en est pas encore vraiment la)
@Mrleblanc101 :
Bien d'accord
@Mrleblanc101 :
+1
Pour les applications objective-c déjà existantes, il faut voir si le nouveau langage apporte une valeur ajoutée court-terme. Et attendre qu'Apple présente des applications Swift plus significatives que le dock ou la calculette (par exemple iTunes et/ou Safari).
Macg découvre le monde du développement. On ne change pas de langage sur une plateforme comme on change de version d'os sur son téléphone.
C'est le genre de chantier qui dure plus de 5ans minimum sur les gros développement.
Alors les gars, on a gelé toute les nouvelles features pour remplacer objc par Swift. Revenez dans 10 ans.
@Gueven :
+1
MacG découvre souvent l'informatique ;)
En tout cas, la calculatrice réécrite en Swift calcule bien !
« 42 »
Nota bene : merci pour le poisson ;-)
Sans oublier le restaurant !
Quel serait l'avantage d'Apple à ré-écrire des apps qui fonctionnent ? Je vois pas trop le but de cette "recherche".
@iPal :
Moins de failles ou de bugs.
Alleger l OS
@Ginger bread :
Ah ? Je ne savais pas que le langage était directement lié à la quantité de bugs et de failles.
Je ne savais pas non plus que Swift permettait "d'alléger l'OS" :o
@Ginger bread :
N'importe quoi...
Cela n'a rien d'étonnant vu la jeunesse du langage.
Sûrement avec iOS 10 ou 11. D'ici là Swift sera plus mature.
Pour ma part, j’attends de voir un peu l’évolution de Swift, en commençant avec Swift 3. Parce que son passage en opensource m’inquiète un peu.
Pas a priori (pour la disponibilité de Swift sur d’autres plateformes, c’est une bonne chose), mais a posteriori, après avoir lu un peu ce qui circule sur swift-evolution : il y a pas mal de délires et de propositions visant à faire partir ce langage dans tous les sens. On y croise aussi un certain nombre de développeurs du genre qui pense que les noms de méthodes les plus courts sont les meilleurs — des dévs qui ne sont donc probablement pas de grands fans de Cocoa, ce qu’on peut trouver inquiétant dans un moment de redéveloppement de Foundation et de grosses retouches de la bibliothèque standard de Swift.
M’enfin, on verra bien comment tout ça est géré par l’équipe en charge. Comme je l’ai dit, j’attends de voir ce que ça donne.
@ Ramlec & Stay hungry_Stay foolish : « Objective C » et non « Objectif C ». ;-)