Swift devait toujours faire partie de l’OS

• Une plainte a été soulevée sur les forums Swift selon laquelle l’intégration de Swift dans l’OS a créé une situation pire pour les développeurs
• En réaction, certains ont répondu avec cynisme : bienvenue dans le monde des bibliothèques livrées avec l’OS
• Cet article, fondé sur l’expérience de l’auteur lors du développement de Swift chez Apple, explique le contexte dans lequel Swift est devenu une partie de l’OS et les problèmes qui en ont découlé

Dépendance à l’OS

• Autrefois, les ordinateurs personnels permettaient aux processus en cours d’exécution de contrôler l’ensemble de la machine, mais aujourd’hui le noyau du système d’exploitation tourne en permanence et fournit les services de base de l’OS
• La plupart des OS modernes permettent de créer des programmes capables de demander certaines opérations privilégiées via une interface d’appels système.
• Les OS d’Apple actuels imposent d’utiliser la bibliothèque standard C/POSIX et ses extensions pour effectuer les tâches de base, car l’interface d’appels système n’est pas stable d’une version d’OS à l’autre.

Le modèle d’Apple (avant Swift)

• Avant Swift, la majorité des API publiques d’Apple étaient écrites en C ou en Objective-C et fournies sous forme de code natif.
• Chaque nouvelle version de l’OS incluait de nouvelles versions compatibles au niveau binaire des bibliothèques existantes, offrant un sur-ensemble qui contenait aussi les API des versions précédentes.
• Le principal inconvénient de ce modèle était que les nouvelles fonctionnalités et API étaient liées aux nouvelles versions de l’OS.

Swift « bêta » 1 à 5

• De Swift 1 à Swift 5, Swift a connu de nombreux changements, et la stabilité de l’ABI a toujours été un objectif du langage.
• Lors du passage à Swift 5, la plupart des problèmes avaient été résolus, et il fallait trouver un moyen d’intégrer Swift dans l’OS sans affecter les apps et projets existants.

La transition

• Pendant l’intégration de Swift dans l’OS, il a fallu trouver comment ne pas casser les apps et projets déjà construits.
• Une fonctionnalité appelée rpath a été utilisée pour permettre aux exécutables de rechercher des bibliothèques dynamiques dans une série de répertoires plutôt qu’à un emplacement codé en dur.

Ce que nous avons perdu

• Une fois Swift intégré à l’OS, les apps n’avaient plus besoin d’embarquer Swift, et la présence conjointe des runtimes Swift et Objective-C a permis des gains de performance.
• En revanche, les contributeurs externes à Swift se sont retrouvés face au problème suivant : les nouvelles API n’existent que sur les nouveaux OS.

Alternatives

• Il existe plusieurs approches raisonnables qu’Apple pourrait adopter pour offrir une meilleure situation aux développeurs, mais rien ne dit qu’Apple le fera.

Conclusion

• Le fait que Swift fasse partie de l’OS a peut-être été un mauvais marché pour les développeurs d’apps, mais Apple ne pouvait pas renoncer à la possibilité d’écrire des bibliothèques système en Swift.

Rien de nouveau du côté de Swift

• Beaucoup des problèmes liés à Swift découlent simplement du fait qu’il s’agit de bibliothèques fournies avec l’OS.
• Les évolutions techniques comme les évolutions sociales autour de Swift ont toutes deux influencé ces problèmes.

L’avis de GN⁺

• Le fait que Swift fasse partie de l’OS impose davantage de contraintes aux développeurs, mais c’est une conséquence inévitable du modèle de distribution des bibliothèques d’Apple.
• En explorant les défis techniques et opérationnels apparus pendant l’intégration de Swift dans l’OS, ainsi que les solutions apportées, cet article souligne la complexité du développement logiciel et l’importance de la gestion des bibliothèques.
• L’intégration de Swift à l’OS a entraîné pour les développeurs d’apps une taille de fichier plus importante et des problèmes de compatibilité, mais elle a aussi donné à Apple la capacité d’écrire et de mettre à jour les bibliothèques système en Swift, ce qui aide à préserver la cohérence et la sécurité de l’ensemble du système.