- En los foros de Swift surgió una queja de que incluir Swift en el OS terminó creando una situación peor para los desarrolladores.
- Como respuesta, hubo una opinión sarcástica dándoles la bienvenida al mundo de las bibliotecas que se distribuyen junto con el OS.
- Este artículo, basado en la experiencia de desarrollar Swift en Apple, explica el contexto de cómo Swift pasó a ser parte del OS y los problemas que eso trajo.
Dependencia del OS
- En el pasado, las computadoras personales permitían que el proceso en ejecución controlara toda la máquina, pero hoy el kernel del sistema operativo siempre está en ejecución y proporciona los servicios básicos del OS.
- La mayoría de los OS modernos permiten crear programas que pueden solicitar ciertas operaciones privilegiadas a través de una interfaz de llamadas al sistema.
- En los OS actuales de Apple, como la interfaz de llamadas al sistema no es estable entre versiones del OS, es necesario usar la biblioteca estándar de C/POSIX y sus extensiones para realizar tareas básicas.
El modelo de Apple (antes de Swift)
- Antes de Swift, la mayoría de las API públicas de Apple estaban escritas en C u Objective-C y se distribuían en forma de código nativo.
- Las nuevas versiones del OS incluían nuevas versiones compatibles a nivel binario de las bibliotecas existentes, ofreciendo un superconjunto que incluía las API de versiones anteriores.
- La principal desventaja de este modelo era que las nuevas funciones y API quedaban atadas a las nuevas versiones del OS.
Swift "beta" 1 ~ 5
- Desde Swift 1 hasta Swift 5 hubo muchos cambios, y la estabilidad de ABI siempre fue un objetivo de Swift.
- Al pasar a Swift 5, la mayoría de los problemas se resolvieron y hubo que encontrar una forma de incluir Swift en el OS sin afectar las apps y proyectos existentes.
La transición
- Durante el proceso de incluir Swift en el OS, fue necesario encontrar una manera de no romper las apps y proyectos ya construidos.
- Se usó una función llamada
rpath para que los ejecutables pudieran buscar bibliotecas dinámicas en una serie de directorios, en lugar de depender de una ruta codificada de forma fija.
Lo que perdimos
- Al integrarse Swift en el OS, las apps ya no tuvieron que incluir Swift por su cuenta, y al distribuirse juntos los runtimes de Swift y Objective-C se hizo posible mejorar el rendimiento.
- Sin embargo, los contribuidores externos de Swift se enfrentaron al problema de que las nuevas API solo existen en los OS nuevos.
Alternativas
- Hay varias formas razonables en que Apple podría ofrecer una mejor situación para los desarrolladores, aunque no está claro si la empresa las llevará a cabo.
Conclusión
- Que Swift se incluyera en el OS pudo haber sido un mal trato para los desarrolladores de apps, pero Apple no podía renunciar a la opción de escribir bibliotecas del sistema en Swift.
No es algo nuevo relacionado con Swift
- Muchos de los problemas asociados con Swift son consecuencia de las bibliotecas que se distribuyen junto con el OS.
- Tanto los cambios técnicos como los cambios sociales alrededor de Swift influyen en estos problemas.
Opinión de GN⁺
- Que Swift pase a ser parte del OS impone mayores restricciones a los desarrolladores, pero eso es una consecuencia inevitable del modelo de distribución de bibliotecas de Apple.
- Este artículo explora los desafíos técnicos y operativos que surgieron durante la integración de Swift en el OS, así como las soluciones planteadas, subrayando la complejidad del desarrollo de software y la importancia de gestionar bien las bibliotecas.
- La integración de Swift en el OS trajo a los desarrolladores de apps archivos más grandes y problemas de compatibilidad, pero para Apple significó la capacidad de escribir y actualizar bibliotecas del sistema en Swift, lo que ayuda a mantener la consistencia y la seguridad del sistema en su conjunto.
Aún no hay comentarios.