Swift 6.3 sur Android : la fin du mur entre iOS et Android ?
Alexandre
··
Durée de lecture : 8 min
Swift peut maintenant builder des apps Android. Officiellement. Avec un SDK maintenu par la communauté Swift et adoubé par Apple. Si on m'avait dit ça l'an dernier, quand j'ai choisi Swift natif pour Livate en refusant explicitement le cross-platform, j'aurais rigolé.
Swift 6.3 est sorti cette semaine avec une liste de nouveautés conséquente, mais c'est le SDK Android qui fait tout le bruit. Premier SDK officiel, outils d'interop Java/Kotlin intégrés, moteur de build unifié cross-platform. Le tout porté par un Android Workgroup qui bosse dessus depuis la WWDC 2025. Le post sur Hacker News a généré 201 points et 116 commentaires en quelques heures. Sur X, c'est le sujet numéro un dans la communauté iOS.
En tant que dev iOS solo qui a construit deux apps en Swift pur, Livate et Waku, cette annonce me touche directement. Un seul langage, deux stores. Ça sonne comme le rêve. Mais est-ce que c'est vraiment utilisable aujourd'hui ? Et surtout, est-ce qu'Apple joue franc jeu ?
Décryptage.
Swift 6.3 débarque sur Android : ce que ça change
Swift 6.3, sorti le 28 mars 2026, inclut le premier SDK officiel pour Android, permettant aux développeurs Swift de compiler du code natif ARM pour Android, de partager des packages entre iOS et Android, et d'intégrer du Swift dans des apps Kotlin/Java existantes via les outils Swift Java et Swift Java JNI Core. C'est la release la plus ambitieuse depuis Swift 6.0 en septembre 2024.
Le SDK est le fruit de mois de travail du Android Workgroup, créé lors de la WWDC 2025. Des pionniers comme Readdle (Documents, Spark, Scanner Pro) et flowkey (app d'apprentissage piano) utilisaient déjà Swift sur Android de manière non officielle depuis des années. La différence, c'est que maintenant c'est supporté.
En pratique : 5 commandes pour compiler Swift sur Android
# 1. Configurer le NDK Android
export ANDROID_NDK_HOME=/path/to/android-ndk-r27d
# 2. Installer le SDK Swift pour Android
./setup-android-sdk.sh
# 3. Vérifier que la cible Android est disponible
swift sdk list
# swift-6.3-RELEASE_android-arm64
# 4. Créer un package Swift classique
swift package init --type executable
# 5. Builder pour Android
swift build --swift-sdk android-arm64
# Produit un .so dans .build/android-arm64/
Le résultat : un fichier .so (shared object, une librairie native) qu'on intègre dans le dossier jniLibs d'un projet Android Studio. Côté Kotlin, on déclare les méthodes natives et on appelle le code Swift directement.
Ce qu'on peut partager (et ce qu'on ne peut PAS)
C'est là qu'il faut être honnête. Voici un exemple de code Swift qui compile pour iOS ET Android sans modification :
// UserGoal.swift — logique métier partageable iOS/Android
import Foundation
struct UserGoal: Codable, Sendable {
let id: UUID
let title: String
let targetDate: Date
var completedActions: Int
var totalActions: Int
var progressPercentage: Double {
guard totalActions > 0 else { return 0 }
return Double(completedActions) / Double(totalActions) * 100
}
var isOnTrack: Bool {
let elapsed = Date().timeIntervalSince(targetDate)
let expectedProgress = min(elapsed / totalDuration, 1.0)
return progressPercentage >= expectedProgress * 100
}
}
Ce genre de code (modèles, calculs, règles métier, networking, async/await, persistence locale), ça compile des deux côtés. C'est typiquement ce que j'ai dans Livate : la logique de suivi d'objectifs, le calcul de progression, les services réseau.
Ce que tu ne peux pas partager : l'UI. SwiftUI ne tourne pas sur Android. Point. Pas de plan annoncé par Apple pour changer ça. Côté Android, c'est Jetpack Compose ou XML. Deux couches UI séparées, un seul langage pour le reste.
Et SwiftUI, c'est 80% du code de Livate. Ma logique métier en Swift pur représente peut-être 20% du codebase. C'est ce 20% qui pourrait être partagé. C'est utile, mais c'est pas "un seul code, deux apps".
Ce que j'en pense
Ce qui me frappe, c'est la différence entre l'ambition et la réalité du tooling. L'idée est puissante : un dev Swift peut maintenant cibler Android sans apprendre Kotlin. En théorie. En pratique, la communauté Hacker News le dit clairement : "the experience of using Swift for anything other than apps for Apple platforms is very painful." Trois toolchains à installer, une documentation encore sparse, un onboarding qui prend plusieurs semaines.
Mais je me souviens de SwiftUI à sa sortie en 2019. Buggé, incomplet, limite inutilisable en prod. Aujourd'hui c'est le standard. Swift sur Android est au même stade : les fondations sont là, le reste va suivre.
Cliquer pour agrandir
Swift vs Kotlin Multiplatform : le match que personne n'attendait
Swift 6.3 offre la meilleure performance brute sur Android (compilation native, pas de runtime managé) mais le tooling le moins mature des solutions cross-platform actuelles, face à un Kotlin Multiplatform qui a 3 ans d'avance en production et une intégration Android Studio native. C'est le constat qui ressort de toutes les comparaisons publiées cette semaine.
Critère
Swift 6.3
Kotlin Multiplatform
Flutter
Performance
Natif (pas de runtime)
Natif (Kotlin)
Quasi-natif (Skia)
UI partagée
Non (SwiftUI iOS only)
Non (UI native)
Oui (widgets Dart)
Hot reload
Non
Non
Oui
Maturité tooling
Faible
Bonne
Élevée
Langage
Swift
Kotlin
Dart
Avantage
Langage natif iOS
Intégration Android Studio
Hot reload, communauté
Le concurrent direct, c'est Kotlin Multiplatform. Même philosophie : code partagé pour la logique métier, UI native sur chaque plateforme. Jacob's Tech Tavern a fait une analyse détaillée : KMP a l'avantage de l'intégration Android Studio native, d'une communauté plus large, et de plusieurs années d'avance en production. Swift a l'avantage de la performance brute et du fait que c'est LE langage natif d'iOS.
Flutter, de son côté, reste imbattable sur la vitesse d'itération avec le hot reload. Mais tu quittes l'écosystème natif des deux côtés, et les binaires sont plus lourds (étude comparative IJIES, mars 2026). Pour un dev iOS qui veut rester "natif", c'est un compromis difficile.
Le chaînon manquant : Skip.dev
Skip.dev a sorti Skip 1.8 dans la foulée de Swift 6.3 (annonce). Skip transpile du SwiftUI en Jetpack Compose natif. C'est le chaînon manquant : tu écris en SwiftUI, tu obtiens du Compose côté Android. Encore jeune, mais c'est le seul outil qui promet du "write once" complet en Swift.
Mon avis
En tant que dev Swift, KMP est le rival que je surveille le plus. Même approche (code partagé, UI native) mais avec 3 ans d'avance en production.
Ce que Swift 6.3 apporte, c'est un argument que personne d'autre n'a : c'est le langage natif d'iOS. Si tu es déjà dev iOS, tu n'as rien à apprendre. Ton Swift, tes packages, tes habitudes, tout passe sur Android. KMP te demande d'apprendre Kotlin. Flutter te demande d'apprendre Dart.
Swift 6.3, c'est le seul qui te dit : reste où tu es, on vient à toi.
Honnêtement, pour Livate et Waku, je ne vais pas porter sur Android demain. Le tooling n'est pas là. Mais la direction est claire. Et pour un dev solo qui construit tout avec Claude Code, rajouter une cible de build Android à un projet Swift existant, ça pourrait devenir aussi simple qu'un flag dans le Package.swift.
Cliquer pour agrandir
Apple joue à quoi ? (et pourquoi SwiftUI ne tournera jamais sur Android)
Apple n'a jamais officiellement positionné Swift comme un langage cross-platform, mais la création de l'Android Workgroup et le support du SDK dans Swift 6.3 constituent un changement de stratégie implicite visant à contrer Kotlin Multiplatform et ancrer les développeurs dans l'écosystème Swift. C'est le non-dit de cette release.
Kotlin Multiplatform grignotait le terrain depuis 2 ans. Des équipes iOS commençaient à migrer leur logique métier vers Kotlin pour le partager avec Android. C'est exactement le scénario cauchemar pour Apple : des devs iOS qui apprennent Kotlin et se disent "au fait, pourquoi je fais pas tout en Kotlin ?". Swift sur Android, c'est la réponse : reste en Swift, on te donne Android.
Pas de SwiftUI Android = calcul délibéré
SwiftUI ne tourne pas sur Android, et Apple n'a rien annoncé pour changer ça. C'est un choix, pas une limitation technique. Apple veut que l'expérience UI reste supérieure sur iOS. Que les apps iOS aient quelque chose que les apps Android n'ont pas. Le code partagé, oui. L'expérience utilisateur identique, non.
Peter Bisljak, dev iOS, le résume bien sur X : "The only thing holding multiplatform Swift/SwiftUI back is the fact that there's no official endorsement by Apple, and we're all relying on third-party tools." Et sur Hacker News, un commentaire populaire va plus loin : "There is also the question of trust." Est-ce qu'Apple va maintenir cet effort ? Ou est-ce que c'est une opération de rétention qui sera abandonnée dans 2 ans ?
WWDC 2026 en juin : la pièce manquante ?
La WWDC 2026 est dans 10 semaines. Si Apple annonce un support officiel de SwiftUI sur Android, ou même un subset de SwiftUI cross-platform, ça change tout. Si Apple ne dit rien, le message sera clair : le cross-platform Swift, c'est du code partagé, pas du UI partagé. Et la communauté devra décider si ça suffit.
Mon take : Apple ouvre la porte mais garde la clé
Honnêtement, je comprends la stratégie. Si SwiftUI tournait sur Android avec la même qualité, pourquoi un utilisateur achèterait un iPhone plutôt qu'un Android ? L'expérience app fait partie de l'équation. Apple le sait. Et ils ne vont pas la brader.
Mais pour nous, devs, ça veut dire qu'on est dans une zone grise. On peut partager du code. On ne peut pas partager l'expérience. Et c'est à chaque dev de décider si cette moitié de promesse suffit.
Swift 6.3 arrive avec un avantage que personne d'autre n'a : c'est le langage natif d'iOS. Mais il arrive aussi avec une limite que les autres n'ont pas : pas de UI partagée. C'est la tension de cette release. Et elle ne sera pas résolue avant la WWDC.
En attendant, voici 3 choses concrètes à faire :
Ton code Swift a plus de valeur qu'avant. Chaque ligne que tu écris pour iOS pourrait demain compiler pour Android. Ton investissement en Swift n'est plus limité à un seul écosystème.
Attendre avant de porter, mais architecturer pour. Séparer ta logique métier de ton UI. Utiliser des protocols plutôt que des dépendances SwiftUI directes dans tes services. Quand le tooling sera prêt, tu seras prêt aussi.
Surveiller Skip.dev et la WWDC 2026. Ce sont les deux événements qui décideront si Swift cross-platform reste une promesse ou devient une réalité.
Conclusion : une porte ouverte, pas un pont
Swift 6.3 ne résout pas le cross-platform. Il ouvre une porte. Le SDK Android est officiel, le build system est unifié, l'interop Java/Kotlin est là. C'est réel, c'est utilisable, c'est supporté.
Pour moi, dev iOS solo qui construit Livate et Waku en Swift pur, c'est la meilleure nouvelle de l'année. Pas parce que je vais porter mes apps demain. Mais parce que pour la première fois en 10 ans de Swift, "et si on allait sur Android ?" n'est plus une question absurde. C'est une question de timing.
Et toi, si tu es dev iOS, est-ce que Swift 6.3 te donne envie de regarder du côté d'Android ? Dis-le moi sur X, LinkedIn ou en commentaire.
Alex
À retenir
Swift 6.3 inclut le premier SDK officiel pour Android : code Swift natif sur les deux plateformes
SwiftUI ne tourne PAS sur Android : seul le code métier est partageable, pas l'UI
KMP est le vrai concurrent : même approche, 3 ans d'avance en production
Skip.dev et la WWDC 2026 sont les deux événements à surveiller pour le futur du cross-platform Swift
