En 2015, sur la scène de la WWDC, Craig Federighi avait annoncé au public que Swift deviendrait open source. Cette déclaration a surpris beaucoup de monde et a été très appréciée par la communauté iOS et macOS. Cela signifiait que Swift serait ouvert à un plus grand nombre de développeurs pour l'utiliser dans leurs projets, ouvrant une immense porte sur le monde Apple.
Il est bien connu qu'Apple n'ouvre généralement pas, ou presque jamais, les ouvre beau jardin clos. Ils aiment que les gens vivent à l'intérieur de ces murs, où tout fonctionne. Cela est très visible lorsque vous essayez de rendre leurs produits compatibles avec certains produits extérieurs. car il est presque garanti que vous rencontrerez des problèmes de compatibilité à un moment donné.
Mais dans ce cas, ils ont décidé de partager un peu et permettez à chacun de rejoindre Swift et de contribuer à sa croissance. Une initiative audacieuse, mais cela signifie-t-il que les choses sont en train de changer à Cupertino, ou s'agit-il simplement d'une décision stratégique ?
Le concept qui sous-tend open source est de fournir utilisation, distribution et modification gratuites du code. Cela signifie que tout le monde peut corriger les bogues et résoudre les problèmes, tout en facilitant la recherche des bogues, puisque toute une communauté s'y intéressera.
De cette façon, la solution peut être trouvée par un grand nombre de personnes et pas seulement par l'équipe qui a développé le langage. Il sécurise le langage et attire de nombreux nouveaux développeurs avec de l'expérience dans d'autres langages qui peuvent aider le code à grandir et à mûrir.
C'est l'avantage du Swift d'Apple, mais le les développeurs en tirent également beaucoup. Les langages open source attirent plus de monde, ce qui permet une croissance plus rapide, suscite plus d'intérêt et accroît leur popularité plus rapidement. Il en résulte un flux constant de nouvelles fonctionnalités qui profitent aux deux parties.
Apple est content de l'aide de la communauté et la communauté est heureuse de recevoir une bonne langue stable avec beaucoup de soutien pour se développer. Ça a l'air parfait, non ? Eh bien, oui et non.
Il se passe quelque chose.
Swift a remplacé Objective-C comme langage utilisé pour développer des applications iOS et macOS. C'est un nouveau langage qui offre aux développeurs une syntaxe simple et cohérente. qui a été influencé par d'autres langages bien connus tels que Ruby et Python.
Lorsque Swift est devenu open source, il a attiré l'attention d'un grand nombre de programmeurs. Sa popularité a augmenté et de nombreux commits et pull requests ont été effectués sur GitHub. En conséquence il a grandi avec la communauté et a continué de croître au cours des années suivantes.
Le langage est aujourd'hui plus mature et possède de nombreuses nouveautés. Cette évolution l'a rendue plus souhaitable et le fait qu'il puisse désormais être utilisé côté serveur est une bonne chose. À cet égard, IBM a également joué un rôle.
« Lorsque swift.org a été lancé en décembre, l'une des premières choses que nous voulions faire était de contribuer à développer l'écosystème des développeurs. Nous avons compris l'intérêt de ce langage et nous voulions le présenter rapidement à d'autres développeurs. »
— IBM
IBM utilise Swift depuis le début dans divers projets et en l'aidant à mûrir. Ils créent également de nombreuses applications et outils d'entreprise pour fonctionner côté serveur (Kitura) et tout semble bon à ce sujet.
Cependant, ce conte de fées n'est pas parfait. Il s'est passé quelque chose et La popularité de Swift est en train de se noyer, comme TIOBÉ rapports.
L'une des raisons de cette baisse est le fait que de nombreux développeurs peuvent être très tentés de travailler avec des frameworks multiplateformes, où ils peuvent développer des applications mobiles similaires pour iOS et Android. Même si ce n'est pas la même chose que de créer des applications natives (cela entraîne souvent plus de problèmes et moins de possibilités), le résultat peut être moins cher et plus rapide.
De plus, d'autres frameworks apparaissent et suscitent beaucoup d'intérêt, comme en témoigne la popularité de Samarim, Apache Cordoue, Ionique et React-Native est en constante augmentation.
« Jusqu'à récemment, il était assez courant de programmer des applications Android en Java et des applications iOS en Swift/Objective-C. C'est assez fastidieux car vous devez gérer deux bases de code qui font presque la même chose. » — Paul Jansen, PDG de Tiobe
C'est un sujet controversé, mais voir Swift dans Android, rapprochant le développement des deux plateformes, serait très intéressant.
Il y a quelque temps, des rumeurs circulaient selon lesquelles Google utiliserait Swift sur Android, en raison des problèmes auxquels ils étaient confrontés avec Oracle. Cependant, même s'ils y parvenaient, un autre problème se poserait.
Bien que Swift soit open source, Google dépendrait d'Apple plutôt que d'Oracle. Même s'ils voulaient bifurquer le code, il leur faudrait beaucoup de travail pour le maintenir à jour.
L'effort qu'il faudrait aux développeurs Android pour apprendre Swift serait pénible et beaucoup d'entre eux ne sont pas motivés pour le faire. Et ne parlons même pas de problèmes de compatibilité. Dans tous les cas, la question demeure :
Est-il possible de créer une application mobile dans Swift pour Android ?
Ce n'est pas facile, mais ce n'est pas impossible non plus. Dans un présentation en 2017, Eric Wing montre son processus et comment il l'a fait.
Ce n'est pas simple, mais en gros, il commence par Java, car Android a besoin d'une activité pour commencer, puis appelle une fonction native écrite en C. Ensuite, il appelle une fonction qui ressemble à une fonction C, mais qui est en fait une Fonction Swift.
C'est déroutant, mais ça marche. Pouvons-nous en faire une norme ? Non, la solution pour y parvenir n'en vaut tout simplement pas la peine. Le fait est que même Google utilise Swift et y contribue, en effectuant des pull requests pour la langue. Cela montre à quel point le fait qu'un langage soit open source peut avoir un impact.
Swift est un langage devenu open source, qui a reçu beaucoup d'aide de la part de la communauté pour grandir et mûrir au cours des dernières années. Le développement d'applications à partir d'iOS et de macOS a beaucoup changé à cet égard, mais compte tenu de l'incroyable baisse de popularité, quelle sera sa qualité à long terme ?
Seule Apple peut dire quel est le plan pour Swift, mais le fait est que après 4 ans, la langue est maintenant plus mature que jamais et, contrairement à ce que l'on pouvait s'y attendre, elle devient également un peu instable en raison de la perte de popularité.
Décidément, les développeurs qui créent des applications natives ne vont pas abandonner Swift de sitôt, car il n'y a rien de tel qu'une application native avec de bonnes performances et un bon flux. Cependant, il semble sûrement que quelque chose doit changer pour qu'il continue de croître.
En le revoyant maintenant, c'était en effet un très geste audacieux, mais qui a eu un effet positif majeur sur Apple et a prouvé aux sceptiques que l'entreprise pouvait être plus ouverte et accepter l'aide du monde extérieur.
Peut-être que l'ouverture d'une plus grande partie de leurs produits à la communauté pourrait attirer encore plus de personnes, même celles qui n'aiment pas trop leur jardin clos. Swift a montré que les bonnes choses naissent sans aucun doute du partage.
On peut se demander pourquoi Apple ne partage pas plus souvent, mais, vu sous un autre angle, pourquoi devraient-ils s'embêter si tout fonctionne si bien dans leur propre jardin ?
Après tout, pour ceux qui vivent dans le jardin clos, c'est sûrement un monde magnifique.
À Imaginary Cloud nous avons une équipe d'experts en développement d'applications mobiles. Si vous avez besoin d'aide pour créer une application mobile évolutive, nous vous attendons ! Envoyez-nous un message ici!
Vous avez trouvé cet article utile ? Ceux-ci vous plairont peut-être aussi !
Développeur front-end et spécialiste d'Angular 8, TypeScript, Angular Material, flex-layout, Bootstrap, HTML 5, SCSS.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
