Swift reste très minoritaire dans iOS 14
Swift est le nouveau langage de développement d’Apple et depuis sa première sortie en 2014, l’entreprise l’utilise chaque année plus fortement dans iOS (et macOS). Cette année encore, son utilisation a doublé avec 351 binaires et frameworks qui reposent au moins en partie sur lui. C’est une progression constante, mais cela ne veut pas dire que Swift est devenu majoritaire, très loin de là.
Le développeur Timac qui analyse tous les ans depuis iOS 10 la progression de Swift dans les binaires et frameworks conçus par Apple s’est lancé dans une tâche plus ambitieuse encore. Il est remonté à iPhone OS 1.01, la toute première version du système mobile d’Apple sortie en 2007, pour compter le nombre de binaires et le langage utilisé par chacun d’entre eux. Ses résultats ainsi que la méthode sont détaillés sur son blog.
Sur ce graphique, les binaires codés Objective-C sont en bleu clair, ceux en Swift sont en rouge et ceux en SwiftUI en orange. Ce framework d’interface introduit l’an dernier n’est quasiment pas visible, mais c’est logique par rapport à sa jeunesse. Dans iOS 14, Apple l’utilise surtout pour ses propres widgets, et elle n’a pas le choix : c’est la seule technologie disponible dans ce cadre.
On note très bien l’apparition de Swift avec iOS 10 et l’augmentation régulière du nombre de binaires qui exploitent ce langage. Le graphique met bien en perspective ce chiffre par rapport aux binaires codés en Objective-C, le langage historique d’Apple. Non seulement il reste ultra-dominant, mais sa croissance n’a pas baissé avec l’apparition de Swift et il y a de plus en plus de binaires qui l’utilisent chaque année. De ce fait, les binaires d’iOS 14 reposent pour 8 % seulement d’entre eux sur Swift, contre 88 % encore pour Objective-C.
Dans le détail, on peut aussi noter qu’Apple utilise aussi beaucoup C et C++, deux langages plus bas niveau qui restent indispensables notamment pour le noyau du système et certaines fonctions liées au matériel. Si le nombre de binaires en C s’est stabilisé autour de 300 au fil des années, les binaires en C++ continuent d’augmenter chaque année. Dans iOS 14, ils représentent même le double des binaires en Swift.
Au-delà des langages de développement utilisés, cette étude est un bon indicateur de la complexité croissante d’iOS, dont la dernière version repose sur vingt fois plus de binaires que la première. Imaginez qu’iPhone OS 1.0 ne permettait pas d’installer d’apps tierces et ne pouvait même pas changer le fond d’écran derrière les icônes de l’écran d’accueil ! À cette époque, même Objective-C était minoritaire derrière C, qui était probablement indispensable pour obtenir des performances correctes sur le matériel si limité des premiers iPhone et iPod Touch :
Comme à chaque fois, Timac rappelle que le système d’Apple n’étant pas open-source, on ne peut avoir qu’une idée limitée de ce qui le compose. En se basant sur le nombre de binaires, on n’a aucune idée de la complexité sous-jacente ou même du nombre de lignes pour chaque langage, ce qui changerait notre vision du système.
Malgré tout, c’est une plongée intéressante sous le capot d’iOS et un joli rappel que Swift est un langage jeune qui est encore loin de pouvoir répondre à tous les besoins. Il lui reste encore beaucoup de chemin pour devenir le langage universel, capable d’écrire un noyau, une app ou même des scripts. C’était, après tout, son objectif initial :
-
iOS est né sous le nom d’iPhone OS. Ce n’est qu’avec l’arrivée de l’iPad que son nom a changé, avec iOS 4 en juin 2010. ↩︎
@ marc_os : « De plus, je trouve sa syntaxe juste horrible. »
J’ai toujours adoré la syntaxe d’envoi de messages en Objective C (celle que tant de monde dit détester à cause des crochets).
Swift a heureusement conservé l’étiquetage des arguments, mais en introduisant une asymétrie entre la partie du nom de méthode qui se trouve avant les paranthèses et celles qui se trouvent dedans. Ce n’est pas très heureux, même s’il faut bien avouer que ça n’a rien de dramatique à l’usage (c’est toujours largement plus confortable que les langages sans étiquettes pour les arguments).
En revanche, il y a d’autres aspects de la syntaxe de Swift qui, je le trouve, représentent un progrès par rapport à Objective C : l’inférence de type allège agréablement le code en éliminant des redondances inutiles, et l’écriture de closures en Swift est bien plus pratique que celle de blocks en C/Objective C, plus encore avec le principe des trailing closures.
Pour le reste, ça se ressemble (intentionnellement) beaucoup.
bah, c'est bien Objective-C
@oomu,
« bah, c'est bien Objective-C »
👍
Mais bien sûr que c'est super bien Objective-C.
Mais bon quand Apple a décidé de bazarder quelque chose, elle trouve toujours une bonne excuse comme :
- c'est "has been"
- personne s'en sert, donc on vire !
- faut changer pour changer histoire de faire tourner la machine...
Apple comme toujours, certains l'aiment pour cela, d'autres le regrettent !
Microsoft se traîne une rétro-compatibilité de fou ! Je peux faire tourner un vieux jeux de Backgammon écrit par un ami sur Windows 95 avec une interface très rudimentaire sur la toute dernière version de Windows 10 !!!
Je me demande si ce genre d'exploit a été un jour possible avec Apple.
Plusieurs transitions de processeurs passées, d'outils de développement, de systèmes d'exploitation radicalement différents, alors Objective-C n'y échappera pas non plus.
Vive Swift ! (second degré)
😁
Ah, j'avais pas imaginé que la justification d'Apple derrière Swift pour remplacer ObjectiveC serait que ObjectiveC ne permet pas de faire des programmes étanches.
Mais puisque cela a bien convaincu comme justification pour virer le port Jack, autant recycler l'argument, c'est plus drôle ainsi.
Est-ce que les binaires ayant une partie du code en OBJC et Swift sont considérés comme l’un ou l’autre où ni l’un, ni l’autre sans cette étude ?
Ben moi c'est pas cette mise à jour que j'attends c'est plutôt celle de macOS qui ce fait attendre et plus on attend plus je m'inquiète quant a la stabilité de cet os
Pages