Swift for Android - desarrollo de apps nativas completas para Android con Swift

• Un framework con el que se pueden desarrollar apps nativas de Android solo con Swift, desde la UI hasta el manifiesto y el ciclo de vida, todo con un solo lenguaje
• Ofrece una estructura para componer la UI de Android con un enfoque de UI declarativa, sin usar en absoluto XML, Java ni Kotlin
• Funciona como un framework nativo puro de Android, no como un wrapper web ni un transpilador
• Permite definir la UI con una sintaxis declarativa similar a SwiftUI y oculta por completo la compleja capa de JNI
• Brinda una experiencia de desarrollo integrada en la que incluso el Android Manifest y la configuración de Gradle se definen directamente en código Swift
• Es una nueva alternativa nativa para que los desarrolladores de Swift se expandan a Android, y un punto de inflexión que abre nuevas posibilidades para el desarrollo multiplataforma basado en Swift

---

Resumen de Droid

• Droid es un framework diseñado para desarrollar aplicaciones nativas de Android usando únicamente el lenguaje Swift
• Está estructurado para gestionar la UI, la configuración de la app, el ciclo de vida y el manifiesto en un solo lenguaje y una sola base de código
• Elimina la dependencia de XML, Java y Kotlin, que se consideraban imprescindibles en el desarrollo Android
• Incluye componentes nativos de Android como AndroidX, Flexbox y Material Design
• Ofrece una sintaxis declarativa similar a SwiftUI para simplificar la definición de la UI
• Oculta completamente la capa JNI y permite acceder mediante una API de alto nivel

Objetivos de diseño y características

• Basado en Pure Swift, permite escribir en Swift la UI, el manifiesto y la configuración general de la app
• Adopta una UI declarativa y prioriza la legibilidad y la componibilidad
• Mantiene un enfoque de desarrollo No XML que no usa XML en absoluto
• Adopta un modelo de ejecución nativo de Android, en lugar de un enfoque web o de transformación de código
• Ofrece una estructura integrada para definir en un solo lugar la UI, el manifiesto y las dependencias de Gradle

Forma de composición de la UI declarativa

• Compone la UI de Android de forma declarativa usando una API amigable para Swift
• Expresa widgets de Android en código Swift, como ConstraintLayout, VStack, TextView y MaterialButton
• Define directamente en el código las restricciones de layout, los eventos de clic y la configuración de estilos

Android Manifest escrito en Swift

• Declara el propio Android Manifest como código Swift
• Gestiona a nivel de código el ícono de la app, el tema y la configuración de activities y fragments
• Integra en un solo archivo Swift el manejo de eventos del ciclo de vida y la lógica de configuración

Documentación y entorno de desarrollo

• Hay documentación oficial disponible y sigue ampliándose de forma continua
• Aunque no toda la funcionalidad de Android está documentada, las guías existentes se ofrecen de forma depurada
• Es posible empezar a desarrollar de inmediato mediante Swift Stream IDE

Alcance del soporte

• Soporte para widgets clásicos de Android
• Soporte para bibliotecas AndroidX
• Soporte para componentes de Material Design
• Soporte para layouts Flexbox

Estado del proyecto

• El proyecto está en desarrollo activo y evoluciona rápidamente
• La API sigue mejorándose dejando abierta la posibilidad de expansión, pero mantiene su visión central
• Se fomentan activamente la retroalimentación y la participación

[GN⁺]

Comentarios de Hacker News

• Se publicó Swift Stream IDE v1.17.0. Ahora ya es posible el desarrollo de apps Android completamente nativas solo con Swift
  No hace falta tocar XML, Java ni Kotlin en absoluto. Internamente, el framework SwifDroid que creé se encarga del ciclo de vida de Android, Activity, Fragment, widgets de UI (Material, Flexbox, etc.) y también gestiona automáticamente las dependencias de Gradle
  Compila el código Swift y genera un proyecto que puede ejecutarse directamente en Android Studio. Tanto la herramienta como el framework se publicaron bajo licencia open source MIT

  • Interesante. Me da curiosidad cuál es el punto de cruce entre la experiencia Android que necesita un desarrollador Swift y la experiencia Swift que necesita un desarrollador Android/Kotlin
    Dices que no hace falta tocar XML, Java ni Kotlin, pero me pregunto si un desarrollador Swift sin ninguna experiencia en Android realmente puede crear una app con éxito
    También me gustaría saber qué porcentaje de las apps actuales y de las del próximo año hechas en Kotlin o Flutter se podría escribir en Swift
  • Una de las fortalezas de Swift es su interoperabilidad con bibliotecas C/C++. Normalmente se ofrecen como dependencias de SwiftPM o Bazel, así que me pregunto cómo manejan las dependencias de SwiftPM
  • Me intriga cómo hacen el binding del código Java/Kotlin a Swift
    Nosotros estamos intentando algo parecido, pero con Rust en lugar de Swift
  • Felicidades. Yo también había estado pensando en unificar mi entorno de desarrollo con Swift, y esto de verdad es un gran trabajo

• Este tipo de intento al final tiene que pasar por JNI, así que tiene limitaciones, considerando que el 80% de la API solo está expuesta en Java
  Estos proyectos siempre son interesantes, pero al final chocan con el problema de la abstracción con fugas (leaky abstraction)
  Igual que en iOS hay que saber Objective-C, y en Windows hay que conocer .NET/COM

  • Hoy en día, incluso en el ecosistema de Apple, para tener éxito hay que manejar tanto Swift como Objective-C
    Por mi experiencia con Unity, el marshaling de C# a C fluye bien, pero con Swift da mucho más trabajo
    La realidad es que hay que resolverlo aparte para cada framework nuevo

• Usar un lenguaje común entre plataformas (Swift o Kotlin) se ve bien en la superficie, pero no creo que en la práctica sea tan eficiente como parece
  Al final terminas manteniendo dos codebases, y aparecen tantas diferencias y soluciones alternativas que casi es mejor disfrutar y usar cada lenguaje por su lado
  La mayoría de los desarrolladores hacen carrera aprendiendo varios lenguajes, y cambiar entre ellos no suele ser difícil. Es una opinión personal, pero el proyecto en sí me parece excelente

  • Aun así, este tipo de intentos permite que un ingeniero acostumbrado a una plataforma pueda trabajar también en otra
    Yo antes estudié durante meses para hacer apps nativas de Android en Java, pero no me gustó y lo dejé
    Prefiero el desarrollo completamente nativo, y aunque he usado frameworks multiplataforma durante décadas, nunca he tenido un gran éxito con ellos
    Cambiar de lenguaje siempre tiene un costo de cambio de contexto. Cada vez que desarrollo alternando entre Swift y PHP, cometo errores de sintaxis con frecuencia
    Aunque el lenguaje se aprende rápido, dominar el SDK, la biblioteca estándar y los frameworks toma mucho tiempo
  • Estos frameworks aceleran el desarrollo de funciones simples, pero cuando quieres usar características específicas de la plataforma, más bien estorban
    Sobre todo ahora, con herramientas de IA, las tareas simples ya se hacen rápido, así que el ahorro total de tiempo de desarrollo no es tan grande
    A menos que la app sea prácticamente una webapp, no lo recomendaría
  • Kotlin y Swift son muy parecidos, y en las partes donde difieren creo que es mejor no abstraerlas
    Me parece que Swift es mejor como lenguaje, pero KMP lleva más tiempo y es más estable, así que en la práctica probablemente usaría eso
  • Saber varios lenguajes más bien te da libertad
    Pero no me gusta quedar más atado a un ecosistema de una gran empresa en particular
    Además, en lo personal Swift me parece un lenguaje incómodo, así que no tendría ganas de usarlo también en otras plataformas

• Me pregunto cómo se compara con Skip
  Este proyecto no parece enfocado en llevar código SwiftUI de iOS a Android, sino en el desarrollo de Swift exclusivo para Android
  Quisiera saber si eso puede traducirse en una mejor calidad de app y si hay casos reales de uso

• Solo por el hecho de no tener que usar Android Studio o IntelliJ, ya me parece una gran mejora. Muy buen trabajo

  • Usar Xcode para evitar Android parece una elección parecida a manipular ácido clorhídrico
  • Me pregunto si también se puede evitar Gradle. Quisiera saber si eso se salta esa pesadilla de gestión de dependencias

• La ventana de consentimiento de cookies da la impresión de que no cumple con la normativa europea

• No entiendo por qué el desarrollo móvil es tan incómodo comparado con PC
  Me pregunto por qué incluso hacer un Hello World en ensamblador para móvil es tan difícil

  • Se puede hacer. Pero es algo tan doloroso como hacer un Hello World en ensamblador para PC, así que nadie lo hace

• Dejé de hacer desarrollo Android por un tiempo, pero si resumo la situación actual
  Antes iOS era Swift y Android era Java
  Ahora, en lugar de Java, está Kotlin, y además aparecieron frameworks multiplataforma como Flutter o React Native
  Me pregunto si Swift on Android es otra capa de abstracción como esas, o si está más cerca de lo nativo
  Al final, ¿no es el código nativo lo más rápido?

  • React Native no está basado en webviews. Es una capa de traducción nativa que convierte JSX en código de UI de SwiftUI/Kotlin
    En lo personal prefiero Flutter. Muchos desarrolladores nativos de Android también dicen que Flutter podría ser el futuro del desarrollo Android
    Para más contexto, ver este hilo de Reddit

• Este proyecto tiene un enfoque distinto al de SwiftCrossUI o Skip
  SwiftCrossUI y Skip ejecutan SwiftUI tal cual en varias plataformas,
  mientras que SwifDroid apunta a escribir UI específica de Android en Swift
  El objetivo es crear apps Android completas en Swift usando directamente el sistema de Views y las APIs de Android, sin Java, Kotlin ni XML
  O sea, no va de “escribe una vez y ejecuta en cualquier lado”, sino de implementar la experiencia nativa de Android con Swift

• Me da curiosidad cuál es la forma idiomática de manejar solicitudes HTTP y parseo de JSON en Swift