Swift for Android - Développement d’apps entièrement natives sur Android avec Swift

• Un framework permettant de développer des applications Android natives uniquement avec Swift, de l’UI au manifeste en passant par le cycle de vie, le tout dans un seul langage
• Fournit une structure pour construire l’UI Android en mode déclaratif, sans utiliser du tout XML, Java ou Kotlin
• Fonctionne comme un framework Android natif pur, et non comme un wrapper web ou un transpileur
• Permet de définir l’UI avec une syntaxe déclarative proche de SwiftUI, tout en masquant entièrement la complexité de la couche JNI
• Offre une expérience de développement unifiée où même le manifeste Android et la configuration Gradle sont définis directement en code Swift
• Représente une nouvelle alternative native pour les développeurs Swift qui veulent s’étendre à Android, et un tournant ouvrant de nouvelles possibilités pour le développement cross-platform basé sur Swift

---

Aperçu de Droid

• Droid est un framework conçu pour développer des applications Android natives en utilisant uniquement le langage Swift
• Il permet de gérer l’UI, la configuration de l’application, le cycle de vie et le manifeste dans un seul langage et une seule base de code
• Il élimine la dépendance à XML, Java et Kotlin, longtemps considérés comme indispensables au développement Android
• Il inclut des composants Android natifs comme AndroidX, Flexbox et Material Design
• Il fournit une syntaxe déclarative similaire à SwiftUI pour simplifier la définition de l’UI
• Il masque complètement la couche JNI et permet d’y accéder via des API de haut niveau

Objectifs de conception et caractéristiques

• Basé sur Pure Swift, avec l’UI, le manifeste et l’ensemble de la configuration de l’application écrits en Swift
• Adopte une UI déclarative en mettant l’accent sur la lisibilité et la composabilité
• Conserve une approche de développement No XML, sans utiliser XML du tout
• Adopte un modèle d’exécution Android natif, et non une approche web ou de conversion de code
• Propose une structure unifiée où l’UI, le manifeste et les dépendances Gradle sont définis au même endroit

Mode de composition de l’UI déclarative

• Compose l’UI Android de manière déclarative à l’aide d’API adaptées à Swift
• Représente en code Swift des widgets Android comme ConstraintLayout, VStack, TextView et MaterialButton
• Définit directement dans le code les contraintes de layout, les événements de clic et les styles

Écrire l’Android Manifest en Swift

• Déclare l’Android Manifest lui-même en code Swift
• Gère au niveau du code l’icône de l’application, le thème, les activités et la configuration des fragments
• Intègre dans un seul fichier Swift le traitement des événements du cycle de vie et la logique de configuration

Documentation et environnement de développement

• Une documentation officielle est fournie et continue de s’enrichir
• Toutes les fonctionnalités d’Android ne sont pas encore documentées, mais les guides existants sont proposés sous une forme affinée
• Il est possible de commencer à développer immédiatement via l’IDE Swift Stream

Périmètre de prise en charge

• Prise en charge des widgets Android classiques
• Prise en charge des bibliothèques AndroidX
• Prise en charge des composants Material Design
• Prise en charge du layout Flexbox

État du projet

• Le projet est en développement actif et évolue rapidement
• L’API est en cours d’amélioration tout en restant ouverte à l’extension, mais la vision centrale est maintenue
• Les retours et les contributions sont vivement encouragés

[GN⁺]

Commentaires Hacker News

• Publication de Swift Stream IDE v1.17.0. Il est désormais possible de développer des applications Android entièrement natives uniquement en Swift
  Sans jamais toucher à XML, Java ou Kotlin. En interne, le framework SwifDroid que j’ai créé gère le cycle de vie Android, les Activity, les Fragment, les widgets UI (Material, Flexbox, etc.) et administre aussi automatiquement les dépendances Gradle
  Il compile le code Swift pour générer un projet exécutable directement dans Android Studio. L’outil comme le framework sont publiés sous licence open source MIT

  • Intéressant. Je me demande où se situe le point de croisement entre l’expérience Android nécessaire pour un développeur Swift et l’expérience Swift nécessaire pour un développeur Android/Kotlin
    Il est dit qu’il n’y a pas besoin de toucher à XML, Java ou Kotlin, mais je me demande si un développeur Swift sans aucune expérience Android peut réellement créer une application avec succès
    J’aimerais aussi savoir quel pourcentage des applications Kotlin ou Flutter, aujourd’hui et l’an prochain, pourrait être écrit en Swift
  • L’un des points forts de Swift est son interopérabilité avec les bibliothèques C/C++. Elles sont généralement fournies comme dépendances SwiftPM ou Bazel, donc je me demande comment les dépendances SwiftPM sont gérées
  • Je suis curieux de savoir comment est fait le binding du code Java/Kotlin vers Swift
    Nous essayons quelque chose de similaire avec Rust plutôt qu’avec Swift
  • Félicitations. J’envisageais moi aussi d’unifier mon environnement de développement autour de Swift, c’est vraiment un superbe travail

• Ce genre d’initiative finit forcément par passer par JNI, donc il y a une limite puisque 80 % de l’API n’est exposée qu’en Java
  Ce type de projet est toujours intéressant, mais il finit inévitablement par se heurter au problème de la leaky abstraction
  Un peu comme sur iOS où il faut connaître Objective-C, ou sur Windows où il faut connaître .NET/COM

  • Aujourd’hui, même dans l’écosystème Apple, il faut savoir manier à la fois Swift et Objective-C pour réussir
    D’après mon expérience côté Unity, le marshalling de C# vers C est fluide, mais Swift demande beaucoup plus de travail
    En pratique, il faut une prise en charge dédiée pour chaque nouveau framework

• Utiliser un langage commun entre plateformes, comme Swift ou Kotlin, paraît séduisant sur le papier, mais en pratique je ne pense pas que ce soit aussi efficace qu’on l’espère
  On finit par maintenir deux bases de code, avec beaucoup de différences et de contournements, donc autant laisser chacun apprécier et utiliser son langage
  La plupart des développeurs construisent leur carrière en apprenant plusieurs langages, et la transition n’est pas si difficile. C’est un avis personnel, mais je trouve quand même le projet excellent

  • Malgré tout, ce genre d’initiative permet à un ingénieur familier d’une plateforme de travailler aussi sur l’autre
    J’avais moi aussi étudié pendant quelques mois le développement natif Android en Java, mais je n’y ai pas pris plaisir et j’ai fini par abandonner
    Je préfère le développement entièrement natif, et malgré des décennies passées à utiliser des frameworks cross-platform, je n’ai jamais vu de grand succès durable
    Changer de langage implique toujours un coût de changement de contexte. Quand je passe de Swift à PHP et inversement, je fais souvent des erreurs de syntaxe
    Même si un langage s’apprend vite, maîtriser les SDK, les bibliothèques standard et les frameworks demande beaucoup de temps
  • Ces frameworks accélèrent le développement de fonctionnalités simples, mais deviennent au contraire un frein dès qu’on veut utiliser des fonctionnalités spécifiques à la plateforme
    Surtout qu’aujourd’hui, avec les outils d’IA, les tâches simples sont déjà beaucoup plus rapides, donc le gain sur le temps total de développement n’est pas si important
    À moins que l’application soit en pratique au niveau d’une web app, je ne les recommande pas
  • Kotlin et Swift se ressemblent énormément, et pour les points où ils diffèrent, je pense justement qu’il vaut mieux ne pas chercher à les abstraire
    Je trouve Swift meilleur en tant que langage, mais KMP est plus ancien et plus stable, donc en pratique j’utiliserais probablement ça
  • Connaître plusieurs langages donne au contraire plus de liberté
    En revanche, je préfère éviter de devenir encore plus dépendant d’un écosystème de grand groupe
    Et puis, personnellement, je trouve Swift peu agréable comme langage, donc je n’ai pas particulièrement envie de l’utiliser aussi sur d’autres plateformes

• Je me demande comment cela se compare à Skip
  Ce projet semble se concentrer non pas sur le portage de code SwiftUI iOS vers Android, mais sur le développement Swift dédié à Android
  J’aimerais savoir si cela peut mener à une meilleure qualité d’application, et s’il existe des cas concrets

• Rien que le fait de pouvoir éviter Android Studio ou IntelliJ me paraît être une grande amélioration. Beau travail

  • Utiliser Xcode pour éviter Android, c’est un peu comme choisir de manipuler de l’acide chlorhydrique
  • Je me demande aussi s’il est possible d’éviter Gradle, et donc de sauter ce cauchemar de gestion des dépendances

• La fenêtre de consentement aux cookies donne l’impression de ne pas être conforme à la réglementation européenne

• Je ne comprends pas pourquoi le développement mobile est à ce point pénible par rapport au PC
  Je me demande pourquoi même faire un simple Hello World en assembleur sur mobile est aussi compliqué

  • C’est possible. Mais c’est aussi douloureux que de faire un Hello World en assembleur sur PC, donc personne ne le fait

• Cela fait un moment que je n’ai pas fait de développement Android, donc si je résume la situation actuelle
  Avant, iOS c’était Swift et Android c’était Java
  Aujourd’hui, Java a été remplacé par Kotlin, et il existe des frameworks cross-platform comme Flutter ou React Native
  Je me demande si Swift on Android est une autre couche d’abstraction du même genre, ou si c’est plus proche du natif
  Au final, le plus rapide n’est-il pas toujours le code natif ?

  • React Native n’est pas basé sur une webview. C’est une couche de traduction native qui convertit le JSX en code UI SwiftUI/Kotlin
    Personnellement, je préfère Flutter. Beaucoup de développeurs Android natifs disent aussi que Flutter pourrait être l’avenir du développement Android
    Voir cette discussion liée : ce fil Reddit

• Ce projet adopte une approche différente de SwiftCrossUI ou Skip
  SwiftCrossUI et Skip exécutent SwiftUI tel quel sur plusieurs plateformes,
  alors que SwifDroid consiste à écrire une UI spécifique à Android en Swift
  L’objectif est de créer une application Android complète en Swift, sans Java, Kotlin ni XML, tout en utilisant directement le système de View et les API d’Android
  Autrement dit, ce n’est pas du « write once, run anywhere », mais une démarche visant à reproduire l’expérience native Android en Swift

• Je me demande quelle est la manière idiomatique de gérer les requêtes HTTP et le parsing JSON en Swift