- En Swift 6 y el desarrollo de apps iOS más reciente, el aprovechamiento de las herramientas basadas en LLM es notablemente menor, lo que amplía mucho la brecha de productividad frente a Android (usando Kotlin, Compose y Cursor)
- El equipo de Android puede desarrollar rápido y dar soporte a funciones nuevas incluso en sistemas operativos antiguos, mientras que el equipo de iOS experimenta caída de productividad y la carga de migrar la base de código debido a la sintaxis reciente de Swift 6, las restricciones de funciones y la falta de soporte en frameworks
- Como los LLM no entienden bien el nuevo modelo de concurrencia (
concurrency) de Swift 6 ni sus patrones complejos, se limita la capacidad de los LLM para automatizar o acelerar código
- Aunque la adopción de Swift 6 en sí es valorada positivamente por algunos desarrolladores, se señala como problema la falta de compatibilidad con las herramientas LLM
- Se destaca el enfoque amigable para desarrolladores y la retrocompatibilidad del ecosistema de Google con Android, Compose y Cursor, mientras continúan las quejas sobre frameworks de Swift/Apple y la velocidad de actualización de sus API
Productividad de desarrollo en la era de Swift 6 y los LLM
Percepción de productividad: iOS vs Android
- El autor está desarrollando una app nueva con Swift 6 en un pequeño equipo de iOS, mientras trabaja en paralelo con un pequeño equipo de Android
- El equipo de Android, usando Kotlin, Compose y Cursor, puede avanzar rápido y con soporte para funciones modernas, además de cubrir ampliamente hasta Android 10, lanzado en 2019
- El equipo de iOS solo puede dar soporte a iOS 16 (2022) o superior, y con la adopción del más reciente Swift 6 enfrenta diversas limitaciones con funciones como Observable y los generic parameter packs
El desajuste entre Swift 6 y los LLM
- Los grandes cambios de sintaxis y frameworks en Swift 6 coincidieron con la etapa de adopción del soporte de LLM, y los LLM no manejan bien el nuevo sistema de concurrencia de Swift 6
- Las herramientas LLM que generan o recomiendan código automáticamente (por ejemplo, ChatGPT, Claude y Cursor) no han aprendido suficiente sobre los datos y patrones relacionados con Swift 6, por lo que tienen limitaciones para generar código preciso
- Los desarrolladores deben compensar manualmente las partes que los LLM no entienden bien, explicando contexto o agregando reglas → esto provoca menor productividad y trabajo repetitivo
Opiniones y experiencias de la comunidad
- Algunos desarrolladores de iOS expresan envidia por la retrocompatibilidad de las API de Android, la madurez de Compose UI y la herramienta Cursor
- También existe la opinión de que adoptar Swift 6 fue una mala decisión, pero en la práctica hay evaluaciones positivas que, aunque reconocen la necesidad de nuevos patrones y aprendizaje, destacan que la expresividad y calidad del código han mejorado
- Como los frameworks principales de Apple aún no se han actualizado correctamente para alinearse con el sistema de concurrencia (
concurrency) de Swift 6, se comparten experiencias de mayor complejidad del código y menor productividad, incluyendo el uso mixto con GCD
- Algunos equipos están posponiendo la adopción de Swift 6 y priorizando resolver primero los problemas de compatibilidad con la base de código existente
Diferencias entre los ecosistemas de Android y Apple
- Android está fortaleciendo la productividad de los desarrolladores con su política de retrocompatibilidad (
Backport) de nuevas API, y está superando desventajas históricas como la fragmentación y los bugs por dispositivo
- En cambio, Apple mantiene la carga para los desarrolladores de tener que implementar por su cuenta funciones similares de forma repetida debido a sus API privadas o restringidas y a una política de actualizaciones lenta
- Con la adopción de herramientas de IA y automatización como Compose y Cursor, la productividad del desarrollo Android está mejorando aún más rápido
- Entre desarrolladores de iOS y Swift están aumentando los casos de inquietud sobre los cambios en las tendencias de desarrollo y la posición profesional en un momento en que aprovechar los LLM es más difícil
Conclusión e implicaciones para el trabajo real
- Aunque la innovación propia de Swift 6 y la expresividad del código son bien valoradas, por ahora las limitaciones de las herramientas de codificación con LLM e IA hacen inevitable el trabajo manual y las explicaciones repetidas
- En proyectos donde se necesita desarrollo rápido y uso de funciones modernas, la productividad de la combinación Android + Compose + Cursor resulta abrumadoramente superior
- Mientras Apple no acelere la actualización de su ecosistema de frameworks y herramientas, en los equipos que adopten Swift 6 habrá que asumir una caída de productividad y límites en el uso de LLM
3 comentarios
En general, es cierto, pero desde la perspectiva de alguien que probó ejecutar brevemente modelos locales con MLX en dispositivos Apple Silicon, me cuesta estar 100% de acuerdo.
Como referencia, al desarrollar modelos también existe la carga de tener que portarlos con mlx, y aunque se active MPS, en la práctica se siente apenas un poco más rápido en cómputo que la CPU, así que todavía resulta incómodo.
Ah... duele, me dio justo en el hueso...