Swift a-t-il atteint son plateau ?
Christophe Laporte | | 19:08 | 26On le sait : Apple mise énormément sur Swift ! Dès qu’il en a l’occasion, Tim Cook en personne n’hésite pas à en faire sa promotion et à insister sur le fait que tous les enfants devraient apprendre à programmer (et si c’est avec son langage maison, c’est encore mieux). Il faut dire qu’avec Swift Playgrounds, Apple s’est donné beaucoup de mal pour rendre l’apprentissage de la programmation plus ludique.
Mais c’est très loin d’être la seule initiative d’Apple pour pousser les gens à découvrir son langage de programmation : ateliers dans les Apple Store, partenariats avec de nombreuses universités, développement en open-source, une documentation abondante… Les (futurs) développeurs sont choyés comme jamais par la Pomme.
Incontestablement, Swift a connu un essor considérable ces dernières années. Le langage d’Apple a beaucoup évolué et il est devenu le langage par défaut de nombreux développeurs gravitant dans l’écosystème Apple.
Toutefois, la partie n’est pas gagnée pour autant pour Apple. Certains développeurs reprochent par exemple à la firme de Cupertino son conservatisme à ce sujet. Si elle n’hésite pas à en faire la promotion, les exemples de production 100 % Swift par les ingénieurs d’Apple, sont encore assez rares. D’autre part, certains défauts comme l’absence de stabilité ABI, continuent à être pointés du doigt. Néanmoins, ce problème devrait être corrigé l’année prochaine avec Swift 5.
À plus large échelle, Swift semble toucher ses limites, si l’on en croit les résultats mensuels de Tiobe. Cette entreprise évalue la popularité des différents langages de programmation, en se basant sur les requêtes effectuées sur différents moteurs de recherche (Google, Wikipedia, Amazon…) et sur la littérature publiée à leur sujet sur le web.
Dixième langage le plus populaire en mars dernier (soit son plus haut historique), Swift se classe ce mois-ci seizième avec un score qui est passé pendant cette même période de 2,3 % à 1,668 %. À noter qu’Objective-C est juste derrière le nouveau langage d’Apple, avec un score de 1,513 %.
Alors, comment expliquer ce recul ? Le problème, comme le montre ce guide de 1&1, c’est qu’il y a mille façons de développer une application iOS. Sur son site, TIOBE explique qu’il s’agit sans doute d’une tendance de fond. La manière de développer des apps pour iOS et Android est en train de changer. Au début, il y avait un développement spécifique à iOS en Objective-C et un autre à Android en Java.
Mais au fil du temps, les développeurs tendent de plus en plus à utiliser des solutions multi-plateformes que l’on peut utiliser avec des langages plus connus comme le C# (Xamarin) ou le JavaScript (Cordova ou Ionic). Alors certes, cette pratique permet de gagner du temps et de simplifier la vie des développeurs, mais a-t-on des apps de qualité équivalente par rapport à un développement qui exploite les outils proposés par Apple ? C’est un autre débat.
Reste qu’Apple a sans doute compris très tôt l’intérêt d’ouvrir son langage de programmation le plus possible. Open source, il essaie de se frayer d’autres chemins que la conception de logiciels pour les terminaux Apple, notamment en allant sur le serveur. C’est d’ailleurs pour cette raison que Google, Facebook ou encore Uber portent un intérêt certain à Swift (lire : Google, Facebook et Uber envisagent l'utilisation de Swift). Il va de soi que si Swift devenait l’un des langages de prédilection du géant de l’internet pour développer sur Android, cela changerait beaucoup de choses.
Facebook
Twitter
RSS
26 Commentaires Signaler un abus dans les commentaires
En parlant de cross platform.
J’aurais tendance à privilégier le native mais le fait de maintenir 2 sources différentes est assez chiant.
Quel est votre avis ? Pour ou contre?
Sous iOS et Android, tu peux respectivement appelé du C via Objective-C (et Swing ?) et Java. Il me semble qu'il en est de même pour C++. Il est donc possible de partager du code "natif" entre ces 2 systèmes, au moins pour la partie non graphique. Cependant je ne sais pas comment c'est fait, mais il est également possible de partager la partie graphique avec au moins Qt. https://blog.qt.io/blog/2013/12/10/cross-platform-applications-in-ios-an...
Syntax error line 1, col 45.
@j3r3m067
Seulement du natif en ce qui me concerne. Les raisons ? Sur le site de l’éditeur français Lunabee il y a un très bon article sur le sujet.
https://medium.com/lunabee-studio/why-hybrid-apps-are-crap-6f827a42f549
Si je ne dis pas de bêtises, Instagram, Twitter, Uber sont au moins en partie hybrides. Ca ne les empêche pas d'être tout à fait performants.
Côté Xamarin, il se peut que l'appli soit un peu plus grosse au déploiement, et peut-être un tout petit peu moins rapide (et encore je ne suis pas sûr), mais très honnêtement, j'ai fait une appli pour iOS et Android, sans savoir coder pour iOS ni pour Android (j'exagère mais c'est pour donner une idée).
Si tu sais faire du C# / Xaml, tu ne seras pas perdu à faire une appli Xamarin Forms pour iOS et Android et tu n'auras pas besoin d'apprendre le Swift ou le Java.
Le react native de facebook est une solution hybride intéressante car censée offrir une expérience native (comme son nom l’indique)
@jopaone
Je confirme j’ai eu l’occasion d’en faire une en react native à ses début sous Android et c’est fluide. L’interface est en natif et la logique métier se trouve dans un thread exécutant le JavaScript
La philosophie et les concept derriere une application autonome et une webapp sont totalement opposés.
A ceux qui ont la mémoire défaillante ou qui sont arrivés apres la bataille, le concept de webapp etait majoritaire avant l'iPhone et fut le seul pendant 1 an sur iPhone. L'application native a ete permise par le travail exceptionnel de retro-ingenierie de la communauté Jailbreak!
Et si Apple est revenu sur sa décision et a offert des API et ouvert iOS c'est pour de tres bonnes raisons, tenant a l'autonomie, la puissance, la performance, la plasticité, la reactivité... et l'autonomie (pas celle du a la batterie, mais a l’indépendance de la connexion reseau)
Programmer une webapp, c'est dessiner une interface pour un service WEB, donc faire un frontend. Tout autre idee est une inadaptation, d'autant plus que les fonctions de l'application n'ont aucune dependance ou relation a un service WEB...
Si on peut programmer une interface WEB adaptable en javascript qui marche plus ou moins pour toutes les plateformes (les navigateurs WEB....) et faire une belle interface native, l'inverse est impossible ou tres dissuasif (cad developper une vraie application en javascript).
Apres, on peut comprendre l'interet de Facebook ou Google de proposer des framework Javascript permettant de réaliser des pseudo-applications: ça permet de garder la surveillance ininterrompu de l'utilisateur et collecter ces données.
Ceci dit, et j'y reviens, l'idée d'une WEB app qui singe un application native, ça a ete tenté depuis longtemps avec des techno de funeste memoire: applet Java et l'infame et dangereux Adobe Flash!!!
Alors, si les API javascript exploitent HTML5 ce qui les rend moins problématiques que Flash ou Java, on reste sur une absurdité qui expose inutilement l'utilisateur et surcharge sans la moindre justification la charge reseau. Il faut le rappeler, le concept de l'iPhone c'est un pc individuel multi connecté, pas un simple terminal a connecter au cloud.
Le choix d'une technologie pour le developpement d'une app iOS ou Android doit etre coherent avec le projet en question :
POC, Hardware Performance stack technique actuelle de l'entreprise, tendance future, budget. Autant de parametre qui font que ce choix est complexe. Que se serait il passe si Google aurait adopte Swift a la place de Kotlin? Bribe de reponse ici :)
https://www.linkedin.com/pulse/et-si-swift-avait-%C3%A9t%C3%A9-choisi-pa...
“Alors certes, cette pratique permet de gagner du temps et de simplifier la vie des développeurs, mais a-t-on des apps de qualité équivalente par rapport à un développement qui exploite les outils proposés par Apple ?“
Voyons plutôt les choses sous cet angle: y a-t-il un intérêt pour les développeurs à faire une version spécifique de leur application pour une petite poignée d’utilisateurs, comparé à l’océan d’utilisateurs android? La réponse est bien évidemment non. Je pense qu’il faut au contraire s’estimer heureux de disposer d’adaptations des apps sous iOS.
Une petite poignée d’utilisateurs ? Un milliard d’iBidules déjà vendus, 200 millions d’iPhone par an. Une poignée ? Il vous faut changer de lunettes.
PS le nombre d’applications payantes, et non gratuites donc, vendues est quasi équivalent entre iOS et Android. En revanche le CA généré avec iOS est substantiellement supérieur à celui d’Android. Concluez vous-même quant à la haute analyse de votre commentaire et à sa validité.
10 % des utilisateurs.
Et un site ne se mesure pas a ce que touche les développeurs dans de nombreux cas, comme tout ce qui est prestations de services de grands groupe ou ce ne sont que des salariés D'aiileurs pour ceux ci le but n'est pas de vendre une appli mais être un dispositif de communication vers le client.
Les applications sur smartphone ne résument à des jeux ou des mini applis.
@ Malum
Pour une fois je suis d'accord avec toi et j'ajouterai, qu'au-dela du CA, par OS, qu'il faut aussi prendre en compte le pouvoir economique des utilisateurs. Meme s'il y a moins d'utilisateurs iOS qu'Android et internet en general, le client Apple va depenser plus et plus fidelisable que l'utilisateur Android et on ne parle meme pas de l'utilisateur internet.
On a aussi la question de la fragmentation qui ne se pose pas sur iOS (ça pose d'autres problemes en terme de liberté de l'utilisateur et d'obscolescence programmée, mais ça ne concerne pas le developpeur).
Et puis. il y a aussi un element non pris en compte ici, c'est le piratage. Pirater une webapp est hypersimple. Pirater meme un service web interfacé par des applications natives demande de sacrées competences et de se reposer aussi sur des incompetences du developpeur. Et il est plus commun d'avoir un developpeur WEB incompetent sur les questions de securité qu'un developpeur d'application native.
Au final, pour revenir au fond de l'article, le gros reproche que l'on peut faire a Apple, c'est au niveau de l'offre developpeur. On pourrait parler de l'outil de developpement qui pourrait etre beaucoup amelioré, mais avant cela il faut se pencher sur la machine de developpement, et la avec l'abandon du Mac, on voit que le developpeur a de quoi se plaindre et s'inquieter. C'est aussi cette cause qui fait emerger des solutions multiplateforme et l'utilisation devoyée des framework Javascript.
@Crkm
Excellent ! Vraiment ! La tendance est à l'opposé de ce tissu d'âneries... J'ai participé au développement de nouvelles fonctionnalités pour l'application d'une banque qui avait justement mis en place une équipe pour faire de la recherche sur des nouvelles fonctionnalités... sous iOS ! Bien sûr la contrepartie Android est toujours prévue mais c'est sur le développement iOS que se porte l'attention quand il y'a les deux plateformes. Il faut se réveiller.
Le développement multi-plateformes a ses avantages mais le natif est souvent privilégié quand il s'agit d'applications complexes et qu'on veut soigner la qualité.
J'ai rarement vu une banque avoir un site web de qualité...
@rikki finefleur
N26.
@Crkm
Pourtant il y a plus d'apps de qualité sur iOS (de moins en moins mais toujours vrai) et les développeurs font plus d'argent sur iOS.
Donc avoir de la chance, je pense pas que c'est une question de chance.
@ Hideyasu
Attention a ne pas confondre qualité de realisation et CA generé. Il faut meme d'ailleurs regarder plus en terme de rentabilite finale qu'en terme de CA, et le ramener a un CA par developpeur plutot que pondre des chiffres absurdes sur la masse.
Des applications natives de qualité sur l'iOS store, il y en a, mais c'est une minorité par rapport a la masse existante. Si on enleve, les calculatrices, les clones de Notes, et autre coussins peteurs, on a tout de meme peu d'applications avec une vraie utilité. Si on considere l'ergonomie et la fonctionnalité on reduit encore cette masse. Certes c'est pire sur Android, mais sur iOS le coussin peteur, il s'achete, sur Android il est gratuit...
@C1rc3@0rc
« on a tout de meme peu d'applications avec une vraie utilité »
C’est faux.
Il y a certes une masse d’apps médiocre et de clones qui les noient un peu, mais les applications utiles, originales et de très grande qualité sont nombreuses, très nombreuses.
Il y a des catégories où certaines apps ont même modifié en profondeur certaines pratiques professionnelles (en médecine d’urgence, par exemple). Ces app ont de fait ensuite été portées sur Android, mais sont nées sur iOS.
« Il va de soi que si Swift devenait l’un des langages de prédilection du géant de l’internet pour développer sur Android, cela changerait beaucoup de choses. »
Peut-être, mais ça ne semble pas être bien parti pour se produire.
Tout dépend de l’application. Les applications assez complexe manque cruellement de fluidité sur les langages hybrides. J’en ai beaucoup vu passé dans mon ancien job. Pour les petites appli simple, pas de soucis ça peut marcher.
Le plus gros soucis de Swift c’est son IDE aka Xcode. Si seulement Apple décidé de passé plus de temps a le refaire plutôt qu’à ajouter les compatibilités des nouvelles versions ça serait un énorme pas.
Des gros projet deviennent rapidement très lourd et demande énormément de puissance.
Pour avoir bosser avec react native les builds quasi instantanée c’est vraiment chouette. Et le fait de pouvoir utiliser l’IDE de son choix convient à n’importe qui.
@diamondtoy
Xcode 9 est une réécriture en swift
Ensuite il y a d'autres IDE
Je pense que l'effort consacré par Apple pour promouvoir Swift n'est pas si important quand on le compare à la concurrence. Il faut voir les efforts déployés par Oracle/Google pour Java/Android et par Microsoft pour .NET.
Par ailleurs, les solutions hybrides ont effectivement le vent en poupe et même sans les avoir essayées, j'imagine qu'elles conviennent dans de nombreuses situations (la plupart des apps ne font que reproduire les services d'un site web, à savoir afficher du texte, des images, etc.
Enfin, pour l'avoir réutilisé récemment, Xcode est mis au tapis par Android Studio dans presque tous les domaines maintenant (le seul où ils avaient vraiment de l'avance était le simulateur mais depuis que Google a intégré Genymotion...). Et les projets Xcode avec leur fichier .xcodeproj, c'est vraiment pas propre à versioner.
Genymotion n’a jamais été intégré à Androïd studio...si tu préfères les IDE de JetBrains, CLion et AppCode permettent de faire du Swift et pas que sur iOS pour CLion
Sinon, pour information, Xamarin compile du code natif. Donc soit, ce n'est pas du "natif" au sens ou le code n'a pas été écrit en Swift par exemple, mais normalement, si c'est bien codé, une appli Xamarin qui tourne sur un iPhone doit avoir exactement les mêmes performances qu'une appli Swift qui tourne sur un iPhone...