Annonce du SDK Swift pour Android

 (swift.org)
10 points par GN⁺ 2025-10-25 | 1 commentaires | Partager sur WhatsApp
  • Alors que le langage Swift a gagné en maturité en s’étendant au cloud, à Windows, aux navigateurs et aux microcontrôleurs, le SDK Swift pour Android est désormais disponible
  • Ce SDK est le fruit de plusieurs mois d’efforts du groupe de travail Swift Android et permet aux développeurs de créer des applications natives Android en Swift
  • Le SDK est inclus dans l’installateur Windows ou peut être téléchargé séparément pour Linux et macOS, avec du code d’exemple et des guides
  • Le projet swift-java prend en charge une interopérabilité bidirectionnelle entre Swift et Java, avec génération automatique de bindings pour garantir performances et sûreté
  • Cette publication est considérée comme un tournant qui accélère l’expansion de l’écosystème cross-platform de Swift et ouvre de nouvelles possibilités pour le développement mobile

Aperçu de Swift SDK for Android

  • Dans le contexte d’un langage Swift qui s’est étendu au cours des dix dernières années des services cloud à Windows, aux navigateurs et aux microcontrôleurs, son arrivée sur la plateforme Android devient désormais officielle
    • Grâce à l’interopérabilité (interoperability) de Swift, le partage de code entre plusieurs plateformes est facilité
  • Le groupe de travail Android (Android workgroup) est un groupe ouvert auquel tout le monde peut participer, avec pour objectif d’étendre Swift à Android
  • Cette annonce correspond à la publication d’un build nightly (preview) de Swift SDK for Android, résultat d’une longue collaboration de la communauté

Principales fonctionnalités du SDK et mode de distribution

  • Les développeurs peuvent désormais utiliser Swift pour créer directement des applications natives Android
    • Cela ouvre de nouvelles possibilités pour le développement cross-platform
  • Le SDK est fourni avec l’installateur Windows et peut être téléchargé séparément pour Linux et macOS
  • Swift.org explique, via le guide “Getting Started”, comment configurer du code Swift sur un appareil Android
    • Le dépôt GitHub Swift for Android Examples présente un workflow applicatif de bout en bout

Compatibilité des packages et extension de la communauté

  • Le SDK Swift permet de porter des packages Swift existants vers Android
    • Plus de 25 % des packages de Swift Package Index prennent déjà en charge des builds Android
    • La page Community Showcase indique la compatibilité Android
  • Cette extension renforce la prise en charge multiplateforme de l’écosystème Swift

Projet swift-java et interopérabilité

  • Le projet swift-java est une bibliothèque et un générateur de code fournissant l’interopérabilité (interoperability) entre Swift et Java
    • Il gère automatiquement l’intégration bidirectionnelle entre Swift et Java et génère des bindings sûrs et performants
  • Les développeurs peuvent ainsi porter leur logique métier vers Android, avec davantage d’informations dans la vidéo de présentation du Swift Server Side Meetup

Participation de la communauté et feuille de route

  • Cette preview ouvre de nouvelles opportunités pour améliorer les outils et élargir l’écosystème
    • Il est recommandé de partager expériences, idées, outils et applications dans la catégorie Android des forums Swift
    • Cette annonce fait également l’objet de discussions dans le fil officiel du forum
  • Le groupe de travail Android rédige actuellement un document de vision (vision document) qui présentera les domaines prioritaires et l’orientation future de Swift sur Android
    • Un project board permet de suivre les principales avancées, et le système officiel de CI sert à gérer la qualité du SDK
  • L’équipe Swift encourage la participation de la communauté et vise à renforcer la place de Swift dans l’écosystème Android

À lire aussi

1 commentaires

 
GN⁺ 2025-10-25
Avis Hacker News

  • La question centrale de tous les frameworks cross-platform est la gestion de l’UI
    Si l’on utilise un système de design qui paraît étranger à chaque plateforme, comme Adobe Flex Builder, on finit par devoir recréer soi-même le ressenti natif
    Flutter essaie de reproduire parfaitement le thème Cupertino d’iOS, tandis que React Native exploite les widgets natifs de la plateforme pour que des éléments comme le défilement paraissent naturels
    C’est dommage que ce point crucial ne soit pas abordé dans le billet de blog
    Même si Apple lance Swift pour Android, il est possible que cela paraisse étrange sur Android à cause de la philosophie de design propre à Apple
    La direction que prendra ce projet dépendra probablement du fait qu’il soit piloté directement par Apple ou qu’il s’agisse plutôt d’une initiative open source portée par la communauté

    • Je préfère les frameworks qui permettent d’écrire une UI native plutôt que de partager l’UI
      C’est pour cela que j’aime KMP. On peut écrire l’UI en SwiftUI sur iOS et en Kotlin sur Android, tout en ne partageant que la logique métier
      Dès qu’on essaie de partager l’UI, on tombe dans le cauchemar du « write once, debug everywhere »
      Swift for Android semble pouvoir permettre ce même type de partage de logique au niveau du langage
    • Le Swift SDK for Android n’impose aucune approche d’UI
      Même dans les exemples, on conserve Jetpack Compose tel quel tout en appelant la logique Swift
      Il garde une structure identique au modèle mémoire à comptage de références de Swift, ce qui assure une bonne cohérence
      En tant que personne travaillant chez Apple sur les outils pour développeurs, j’espère que cette technologie servira de point de départ à une nouvelle innovation
    • Comme dans le cas où Browser Company a porté SwiftUI sur Windows, il est possible que SwiftUI soit mappé à Jetpack Compose sur Android
      SwiftUI n’est pas à l’origine une « UI native », mais plutôt un langage déclaratif que le système interprète pour générer des UIView ou des NSView
    • Cette release ne contient aucun portage de SwiftUI ou UIKit vers Android
      À moins de les reproduire directement comme Flutter, il est impossible d’utiliser telle quelle l’UI d’Apple sur Android
    • Le Swift SDK ne spécifie aucune technologie d’UI
      À la place, des projets comme Skip.tools font le pont entre SwiftUI et Jetpack Compose
      On peut en voir un exemple dans l’application Skip Showcase
      Je travaille sur les produits Skip, je fais partie du Swift Android Workgroup et j’ai participé à cette release en tant que release manager

  • Je suis vraiment ravi que cela ait été annoncé comme projet officiel
    J’ai utilisé RN et Flutter, mais le problème a toujours été le manque de ressenti natif
    Il existe aussi KMP, mais la plupart des développeurs commencent par iOS puis étendent vers Android
    Partager le code via Swift Package rend ce flux bien plus naturel

    • Il y a bien plus de développeurs Android, et la distribution y est aussi plus simple
      En revanche, les développeurs Swift/Objective-C sont bien moins nombreux
      Hors des États-Unis, la part de marché de l’iPhone est plus faible, donc les entreprises ont tendance à penser avant tout en termes de Windows ou de navigateur
    • Dire qu’on « commence par iOS » me semble être une vision centrée sur les États-Unis
      KMP est déjà utilisé dans de grosses applications comme Google Workspace, et son niveau de maturité est élevé grâce à Kotlin et aux investissements de JetBrains
      Le cycle de release de Flutter était trop rapide pour être facile à suivre
    • La logique métier basée sur JavaScript ne doit pas non plus être négligée
      Avec JavaScriptCore ou QuickJS, elle peut fonctionner sur iOS, Android et le Web, avec du hot reload
      En revanche, les politiques des app stores rendent difficiles les gros changements fonctionnels, et cela convient plutôt à des corrections de bugs
      Vu la lenteur des cycles de déploiement mobile, je pense que cette approche représente une vraie opportunité
    • Chez Proton, ils partagent plus de 80 % de leur logique en Rust, et implémentent le reste selon la plateforme
    • En réalité, cette structure était déjà possible avec .NET et MvvmCross
      Une bibliothèque cœur partagée + un projet d’UI native par plateforme, et cela fonctionne bien

  • Je me demandais si cela avait un lien avec le projet autour du transpileur SKIP que j’avais vu sur le blog de Skip.tools
    Je voulais porter une app SwiftUI sur Android, mais sans passer par RN

    • Oui, Skip utilise depuis plus d’un an des versions preview du Swift SDK et, avec le mode Fuse, construit sur Android de véritables apps SwiftUI natives
      Skip propose deux modes : le mode Lite, qui convertit le code Swift en Kotlin, et le mode Fuse, qui compile directement Swift pour Android
      Les deux peuvent être utilisés ensemble pour s’intégrer à l’écosystème Kotlin (Lottie, Firebase, etc.)
      Une comparaison détaillée est disponible dans la documentation Skip
      Je suis ravi que le SDK officiel soit sorti, car cela permet désormais d’utiliser la version officielle au lieu de builds maison
    • Skip est l’un des principaux contributeurs à cet effort
    • Il est désormais possible d’exécuter Swift nativement sans transpileur, avec une compatibilité bien meilleure

  • J’espère que cela ne s’arrêtera pas à un simple proof of concept, comme Swift Embedded
    Swift est un langage élégant, mais il y a un climat d’inquiétude autour du leadership de la communauté

    • guard let self = self else { return } — une blague familière pour les développeurs Swift

  • J’aimerais qu’on arrête un peu avec RN et Flutter
    Je suis fatigué des UI anguleuses et de la lenteur de réaction au toucher

    • On peut aussi régler le rayon des coins dans Flutter, et les performances sont rapides
      Si la réaction semble lente, c’est probablement un problème d’implémentation de l’app
    • Je n’aime pas non plus particulièrement RN ni Flutter, mais rien ne garantit que Swift on Android sera meilleur qu’eux
      Apple pourrait vite perdre l’intérêt pour le sujet

  • « You got Kotlin in my iOS. »
    « You got Swift in my Android. » — formule bien trouvée

    • C’est une analogie parfaite. On pourrait vraiment finir avec un hybride Kotlin + Swift façon pub Reese’s
    • Kotlin on iOS est compilé statiquement et interopère nativement avec Swift/ObjC
      Voir Kotlin Native Overview

  • Cette annonce ressemble à une démonstration de réussite du nouveau système de SDK Swift
    Avant, le support d’autres plateformes était compliqué à cause des enchevêtrements avec CMake, mais désormais, tant qu’on respecte les règles du SDK, le portage vers n’importe quelle plateforme devient possible
    Au-delà d’Android, cela devrait aussi s’étendre à Linux, wasm, embedded, et bientôt Windows
    L’interopérabilité avec la JVM n’est pas encore complète, mais l’indépendance vis-à-vis des plateformes s’est clairement renforcée

  • J’aime Kotlin Multiplatform, mais Swift for Android m’intéresse aussi
    Pouvoir partager des bibliothèques Swift natives pour des tâches sensibles à la mémoire semble utile
    En revanche, pour migrer toute la logique métier en Swift, KMP paraît encore plus mature aujourd’hui

    • Quelqu’un a déjà créé des applications desktop avec KMP ? Je suis curieux de connaître son niveau de maturité global

  • Le partage de logique métier était déjà un problème résolu
    La vraie douleur, c’était de devoir écrire l’UI deux fois
    Il faudrait un framework d’UI commun qui ne soit pas aussi pénible que React Native

    • React Native s’est beaucoup amélioré récemment avec sa New Architecture
      Avec Expo, l’expérience développeur s’est nettement améliorée

  • Je partage du code entre Android et iOS depuis longtemps, mais partager l’UI a toujours été un cauchemar
    Je ne partageais que la logique complexe en C/C++/Rust, ce qui finissait par faire trois langages différents
    KMP et Swift for Android permettent désormais de partager uniquement en Kotlin/Swift, ce qui est bien plus propre
    Cette approche est bien plus réaliste et efficace que les frameworks qui forcent le partage de l’UI