Se podría pensar que Swift de Apple es un lenguaje de programación solo para macOS e iOS. Es una conclusión natural, ya que Swift está estrechamente vinculado al entorno de desarrollo Xcode de Apple. Pero a menudo se pasa por alto una parte de la historia de Swift: Swift es un lenguaje de programación multiplataforma, compatible con Linux, Android y Windows. Gran parte de la confusión proviene de que Apple proporciona herramientas de interfaz de usuario solo para sus propias plataformas. Para otras plataformas, Swift pretende ser un lenguaje de programación de sistemas portátiles, que le permite llevar la lógica empresarial desde dispositivos móviles y de escritorio a la nube, agregando API para interfaces web. Si desea una interfaz de usuario, necesitará un navegador web, ya que existen varios marcos web para Swift, principalmente dirigidos a la versión de Linux. Uso de Swift en Windows Uno de los beneficios de Swift como lenguaje es que proporciona una alternativa más segura. a C, con muchas características de Objective C. A diferencia de muchos lenguajes compilados, Swift admite el uso de un entorno de prueba y depuración basado en REPL. Puede evaluar el código antes de la compilación y utilizar los campos de juego de Xcode para explorar estructuras más complejas. Este enfoque de «depurar mientras codifica» tiene como objetivo mejorar la productividad del desarrollador, haciendo que la depuración sea parte de su flujo normal y manteniendo la eliminación de errores en el contexto del código que está escribiendo. Es la falta de una capa de interfaz de usuario lo que hace que Swift se sienta como un ciudadano de segunda clase en Windows. Si desea programación básica de sistemas, escriba una aplicación de consola C#. Las tareas más complejas a nivel de sistemas generalmente requieren C++ o Rust, que Microsoft está usando ahora en Azure. Volviendo a los ‘puentes’ de Windows 10, si bien no podemos esperar que Swift para Windows implemente toda la experiencia de usuario de macOS o iOS, tiene alguna forma. de herramientas de interfaz de usuario haría mucho más fácil trasladar todo tipo de aplicaciones y herramientas de macOS a Windows. Microsoft intentó algo como esto para Objective C, como parte de su proyecto “puentes” de Windows 10) en Project Islandwood (ahora un proyecto de código abierto en GitHub). WinObjC, como finalmente se llamó, toma proyectos Xcode existentes y los convierte en proyectos de Visual Studio, asignando controles y servicios comunes a sus equivalentes de Windows. Aunque todavía está disponible, WinObjC está prácticamente obsoleto. Más allá de la política del repositorio y las actualizaciones de la documentación, los últimos cambios importantes se realizaron hace más de cuatro años. Tanto las estrategias de desarrollo de aplicaciones de Apple como las de Microsoft han cambiado considerablemente desde que Microsoft lanzó WinObjC por primera vez y, lo que es más importante, también lo han hecho sus herramientas de interfaz de usuario. SDK de aplicaciones de Windows y proyecciones de lenguaje Microsoft ha pasado gran parte de la última década pensando y reconsiderando su estrategia de interfaz de usuario. Primero fue WinRT de Windows 8 con sus controles Metro. Esto evolucionó hasta convertirse en la plataforma Windows y la biblioteca de interfaz de usuario de Windows, WinUI. A medida que la historia subyacente del desarrollo de Windows cambió, WinUI evolucionó con ella, llevándonos hoy a WinUI 3. WinUI 3, que se entrega como parte del SDK de aplicaciones de Windows, ofrece controles modernos para todos los lugares donde se ejecuta Windows. Diseñado para admitir el desarrollo de .NET, el modelo WinUI se basa en la conocida base XAML, separando el diseño y la disposición del código. Los diseños se crean a partir de controles y utilizan un lenguaje declarativo para definir la ubicación y los enlaces. Es una herramienta poderosa que funciona bien con muchos patrones de diseño diferentes. Con el tiempo, WinUI se ha separado de Windows y ahora se actualiza según su propio cronograma y se envía como parte del SDK de la aplicación de Windows. Si bien WinUI es quizás más conocido como una herramienta para .NET, se ha adaptado a otros entornos de Windows, incluido C++. La proyección del lenguaje C++ WinRT proporciona una biblioteca de encabezados de archivos que le permite usar las API del SDK de aplicaciones de Windows desde cualquier compilador de C++ compatible con los estándares, como Clang de LLVM o incluso GCC. Aquí es donde el cambio de Microsoft hacia bases de código abierto muestra sus ventajas. Otras empresas pueden tomar, modificar y utilizar herramientas y tecnologías de desarrollo fundamentales como WinUI para crear y utilizar (y compartir) sus propios derivados, así como para llevar aplicaciones al escritorio de Windows que de otro modo no obtendrían una adaptación.WinUI en Swift en Windows Hace un par de semanas, un tweet de Miguel De Icaza, uno de los creadores del proyecto Mono, me señaló el trabajo que está realizando The Browser Company para utilizar las herramientas CppWinRt para crear su propio conjunto de proyecciones de lenguaje para agregar compatibilidad con WinUI. a Swift. Esto les permitirá llevar su nuevo navegador Arc, integrado desde cero, a Windows, sin necesidad de reescribir completamente su código Swift existente. Ese es un requisito importante para un equipo pequeño. Si todo lo que tiene que cambiar es la interfaz de usuario, entonces no necesita duplicar el desarrollo central, ni tener que traducir de un modelo de programación a otro, con el riesgo adicional de una mayor superficie de ataque. En su lugar, puede concentrarse, como The Browser Company, en crear una alternativa a Chromium, Gecko y WebKit que siga el ritmo de los estándares web y proporcione a los usuarios las funciones y la velocidad que esperan. Eso requiere que todas las versiones para cada plataforma se lancen al mismo tiempo. El equipo que creó la versión para Windows del navegador Arc ha estado usando Swift con COM, por lo que tener enlaces de idiomas basados ​​en las herramientas C++ WinRT no es un gran paso. El código necesario para ofrecer una interfaz de usuario de Windows con estos enlaces le resultará familiar a cualquiera que haya creado aplicaciones de Windows utilizando un lenguaje moderno. La sintaxis es puramente Swift y las llamadas para agregar componentes de UI a su aplicación son muy similares a las que se usan para brindar una experiencia de iOS o macOS. De Swift a WinUI a través de WinRTA WinUI usa interfaces WinRT, la proyección de Swift se basa en definiciones de interfaz de WinRT. traducir el C IDL (lenguaje de definición de interfaz) subyacente en llamadas a funciones. Si bien se puede trabajar con la API directamente desde Swift utilizando sus capacidades de interoperabilidad, no es práctico hacerlo de esa manera. Es un enfoque que agrega complejidad, en lugar de proporcionar una ruta simple para agregar una interfaz de usuario de Windows como una compilación alternativa para un proyecto Swift. Al crear una proyección de lenguaje, el equipo de desarrollo de The Browser Company ha asignado propiedades y métodos de WinRT a sus equivalentes Swift, incluido soporte para controladores de eventos. El objetivo es hacer que la codificación con estas API se sienta natural, que estás trabajando con las API Swift nativas. Eso significa que la biblioteca resultante debe funcionar en secreto para resolver los desajustes entre la forma en que funcionan las API de Windows y la forma en que Swift espera que funcionen. Si bien el trabajo multiplataforma de Microsoft se centra naturalmente en llevar el código de Windows a otras plataformas, es bueno Vea cómo The Browser Company adopta un enfoque diferente. Al igual que el trabajo de Google con Flutter, que lleva aplicaciones creadas para una plataforma diseñada para Android a otros sistemas operativos, este es un paso para hacer lo mismo con iOS y macOS. Es importante recordar que el SDK de aplicaciones de Windows es mucho más que WinUI 3, por lo que, si bien las proyecciones de lenguaje rápidas resultantes son una herramienta útil, son solo una parte de lo que se necesita para migrar el código de iOS a otro ecosistema. Próximos pasos Tener una forma viable de sacar el código Swift de iOS y macOS es algo bueno, y poder trasladarlo a WinUI y Windows podría dar a los desarrolladores acceso a otro mercado, uno que ya cuenta con una tienda de aplicaciones y un conjunto de servicios en la nube. herramientas de compilación alojadas que pueden automatizar el proceso de pasar de la solicitud de extracción a la disponibilidad de la tienda. Lo que necesitamos a continuación es que alguien tome las antiguas herramientas del Proyecto Islandwood, o tal vez parte del trabajo de Xamarin, y las use para integrar más API de Windows en aplicaciones Swift. , basándose en la herencia Objective-C de Swift. Después de todo, todos son de código abierto. No importa quién lo haga, las nuevas herramientas de The Browser Company son un progreso definitivo en la construcción de un mundo más abierto y multiplataforma. Será interesante ver hacia dónde va Swift en Windows desde aquí. Copyright © 2023 IDG Communications, Inc.

Source link