- Avec Swift 6 et le développement iOS moderne, l’utilité des outils basés sur les LLM est nettement plus faible, ce qui creuse fortement l’écart de productivité par rapport à Android (Kotlin, Compose, Cursor)
- L’équipe Android peut développer rapidement tout en prenant en charge les fonctionnalités récentes jusqu’à des versions anciennes de l’OS, tandis que l’équipe iOS subit une baisse de productivité et la charge de migration du codebase à cause de la syntaxe moderne de Swift 6, des contraintes de fonctionnalités et du manque de support des frameworks
- Les LLM comprennent mal le nouveau modèle de concurrence (
concurrency) de Swift 6 ainsi que des patterns complexes, ce qui limite les capacités d’automatisation et d’accélération du code par les LLM
- L’adoption de Swift 6 elle-même est jugée positivement par certains développeurs, mais le manque de compatibilité avec les outils LLM est pointé comme un problème
- La rétrocompatibilité et l’approche orientée développeur de l’écosystème Google, avec Android, Compose et Cursor, sont mises en avant, tandis que les critiques se poursuivent sur la lenteur des mises à jour des frameworks et API côté Swift/Apple
Productivité du développement à l’ère de Swift 6 et des LLM
Ressenti sur la productivité iOS vs Android
- L’auteur développe une nouvelle application en Swift 6 au sein d’une petite équipe iOS, tout en avançant en parallèle avec une petite équipe Android
- L’équipe Android peut aller vite et prendre en charge les dernières fonctionnalités grâce à Kotlin, Compose et Cursor, avec une compatibilité étendue jusqu’à Android 10, sorti en 2019
- L’équipe iOS ne peut prendre en charge qu’iOS 16 (2022) ou plus, et l’adoption de Swift 6 s’accompagne de diverses contraintes autour d’Observable, des generic parameter packs et d’autres fonctionnalités
Le décalage entre Swift 6 et les LLM
- Les importants changements de syntaxe et de framework de Swift 6 ont coïncidé avec l’essor du support par les LLM, mais ceux-ci gèrent mal le nouveau système de
concurrency de Swift 6
- Les outils LLM qui génèrent ou recommandent automatiquement du code (par exemple ChatGPT, Claude, Cursor, etc.) n’ont pas encore suffisamment appris les données et patterns liés à Swift 6, ce qui entraîne des limites dans la génération de code précise
- Les développeurs doivent compenser manuellement ce que les LLM ne comprennent pas bien, en expliquant le contexte ou en ajoutant des règles → cela entraîne une baisse de productivité et du travail répétitif
Avis et expériences de la communauté
- Certains développeurs iOS expriment une forme d’envie envers la rétrocompatibilité des API Android, la maturité de Compose UI et l’outil Cursor
- Certains estiment que l’adoption de Swift 6 était un mauvais choix, mais beaucoup reconnaissent aussi la nécessité de nouveaux patterns et d’apprentissage, tout en évaluant positivement la qualité et l’expressivité du code
- Les principaux frameworks d’Apple n’ont pas encore été correctement mis à jour pour s’aligner sur le système de
concurrency de Swift 6, et des retours évoquent une complexité accrue du code et une baisse de productivité due à l’usage mixte avec GCD
- Certaines équipes repoussent l’adoption de Swift 6 et cherchent d’abord à résoudre les problèmes de compatibilité avec leur codebase existant
Différences entre les écosystèmes Android et Apple
- Android renforce la productivité des développeurs grâce à une politique de rétroportage (backport) des nouvelles API, et surmonte progressivement ses faiblesses historiques (fragmentation, bugs selon les appareils, etc.)
- À l’inverse, Apple impose des API privées ou limitées et une politique de mise à jour lente, obligeant les développeurs à réimplémenter eux-mêmes à répétition des fonctionnalités similaires
- L’adoption d’outils d’IA et d’automatisation comme Compose et Cursor accélère encore davantage la productivité du développement Android
- Les développeurs iOS et Swift, dans un contexte où l’usage des LLM reste difficile, sont de plus en plus nombreux à ressentir une inquiétude face à l’évolution des tendances du développement et à leur positionnement de carrière
Conclusion et implications concrètes
- Le caractère innovant et l’expressivité de Swift 6 sont salués, mais en raison des limites des outils de codage LLM/IA, il faudra encore pendant un temps compter sur du travail manuel et des explications répétées
- Pour les projets qui exigent un développement rapide et l’exploitation des dernières fonctionnalités, la combinaison Android + Compose + Cursor offre une productivité écrasante
- Tant qu’Apple n’accélérera pas la mise à jour de son écosystème de frameworks et d’outils, les équipes qui adoptent Swift 6 devront accepter une baisse de productivité et des limites dans l’usage des LLM
3 commentaires
Dans l’ensemble, c’est vrai, mais pour avoir brièvement fait tourner des modèles locaux avec MLX sur des appareils Apple Silicon, j’ai du mal à être d’accord à 100 %.
À titre indicatif, il y a aussi la contrainte de devoir porter vers mlx lors du développement du modèle, et même en activant mps, en pratique les calculs ne semblent qu’un peu plus rapides que sur le CPU, donc cela reste encore peu pratique.
Ah… ça fait mal, j’ai pris ça en pleine figure…