Les nouveautés de Swift (2026) : la mise à jour de la WWDC26

Apple a livré deux versions de Swift au cours d’un même cycle WWDC : la 6.3 et la 6.4 sont arrivées ensemble, et la session « What’s new in Swift » a couvert les deux comme un seul et même arc de travail¹. Ce cadrage compte, car les changements se répartissent nettement entre deux publics. La plupart des développeurs bénéficient d’améliorations ergonomiques plus modestes et quotidiennes (supprimer les parenthèses autour des optionnels any, regrouper une douzaine de noms de plateformes @available en un seul anyAppleOS, faire taire un avertissement de dépréciation dans une seule déclaration). Un groupe plus restreint, qui écrit du code sensible aux performances, récolte une avancée préparée de longue date : le système de propriété (ownership) atteint désormais les boucles for, les propriétés calculées et la bibliothèque standard elle-même.

Swift en 2026 est aussi, de toute évidence, un projet multiplateforme et multilangage. Apple a annoncé un SDK Swift officiel pour Android, distribué via swift.org⁶, un pontage JavaScript plus rapide grâce à WebAssembly, la possibilité d’exporter des fonctions Swift vers le C avec un nouvel attribut @C, ainsi qu’un backend Swift Build qui propulse désormais Swift Package Manager par défaut¹. Cet article parcourt les quatre sessions qui définissent l’histoire de Swift en 2026 : les mises à jour du langage et de la bibliothèque (262), le chemin de migration vers Swift Testing (267), les services temps réel avec gRPC (265) et le calcul numérique avec MLX Swift (328).

En bref

• Swift 6.3 et 6.4 ont été livrés ensemble à la WWDC26. Ergonomie quotidienne : any/some optionnels sans parenthèses, disponibilité anyAppleOS, l’attribut @diagnose pour un contrôle des avertissements par déclaration, et les sélecteurs de module (::) pour les collisions de noms¹.
• Le système de propriété a atteint le code ordinaire : un nouveau protocole Iterable permet aux boucles for d’emprunter (borrow) les éléments au lieu de les copier, et les accesseurs borrow/mutate remplacent get/set pour éviter de copier de grandes valeurs dans les propriétés calculées¹.
• De nouveaux types de la bibliothèque standard livrent les versions sûres d’anciens motifs dangereux : UniqueArray, UniqueBox, une Continuation à reprise unique, et Ref/MutableRef pour conserver un emprunt ou une mutation dans une variable¹.
• Swift Testing interopère désormais avec XCTest dans les deux sens, avec quatre modes (limited, complete, strict, none) ; Xcode 27 active l’interopérabilité par défaut². La surface @Test, @Suite, #expect et #require est documentée dans la référence Swift Testing d’Apple⁵.
• gRPC Swift a atteint le point où l’on génère un client typé à partir d’un fichier .proto et où l’on obtient des RPC unaires ainsi qu’en streaming bidirectionnel, déployables dans des conteneurs Linux sur le cloud³.
• MLX Swift apporte à Swift le calcul sur tableaux de style NumPy, avec exécution GPU automatique et différenciation automatique grad, en partageant un seul moteur entre les front-ends Swift, Python, C++ et C⁴.

Ergonomie du langage : les agacements disparaissent

La session s’ouvre sur des changements que « vous remarquerez peut-être à peine, sinon comme de petits agacements qui s’en vont »¹. Il vaut la peine de les nommer, car ils éliminent des frictions accumulées au fil d’une décennie de langage.

Becca et Evan de l’équipe Swift présentent Swift 6.3 et 6.4. La partie sur le langage commence aux environs de 0:45.

Vous pouvez désormais écrire any P? sans l’entourer de parenthèses. Vous obtenez un avertissement lorsqu’une tâche de Swift Concurrency abandonne silencieusement une erreur levée, ce qui vous invite soit à la gérer dans la tâche, soit à conserver la tâche pour la vérifier plus tard. L’ancienne restriction interdisant d’appeler des fonctions async depuis un bloc defer a disparu, si bien que le nettoyage asynchrone s’exécute exactement comme le nettoyage synchrone différé l’a toujours fait (SE-0493, Swift 6.4)⁷. Une classe qui n’avait besoin de @unchecked Sendable qu’à cause d’une propriété weak var peut faire passer cette propriété en weak let et devenir éligible à une vérification Sendable en bonne et due forme. Un type qui ne devrait pas être Sendable peut le dire explicitement avec la nouvelle syntaxe ~Sendable, laquelle n’empêche pas les sous-classes d’être Sendable¹.

Deux changements que vous remarquerez à coup sûr. Le premier concerne la disponibilité : Apple a aligné l’an dernier ses numéros de version d’OS, et Swift va plus loin en vous laissant condenser tous les noms de plateformes en un seul, anyAppleOS. Lorsque la disponibilité concorde sur les plateformes qui vous intéressent, vous les spécifiez toutes d’un coup ; lorsqu’il existe des exceptions, vous définissez anyAppleOS comme valeur par défaut et ajoutez des attributs spécifiques à chaque plateforme pour ces exceptions. Le même nom fonctionne dans les conditions #if os(...)¹.

Le second est l’attribut @diagnose, qui modifie le comportement d’avertissements précis au sein d’une seule déclaration. Vous pouvez demander à Swift d’ignorer le groupe d’avertissements deprecated declaration dans une fonction le temps de migrer vers une nouvelle API, sans le faire taire à l’échelle du projet. Vous pouvez aussi procéder en sens inverse : activer la sûreté mémoire stricte dans une fonction critique pour la sécurité, ou promouvoir dès maintenant un avertissement d’erreur future au rang d’erreur¹. Holly Borla, engineering manager au sein de l’équipe Swift, l’a désigné comme son préféré en clôturant la WWDC26 : « L’une de mes nouvelles fonctionnalités préférées est l’attribut @Diagnose, qui vous laisse contrôler le comportement des avertissements dans votre code ; il permet par exemple de supprimer les dépréciations, mais aussi d’activer la sûreté mémoire stricte ou les diagnostics de concurrence stricte de manière plus granulaire, ce qui aide notamment à la migration vers le mode de langage Swift 6. »⁸ Elle a présenté l’ensemble de la version 6.4 de la même façon : les mises à jour « suppriment des éléments qui sont des points de friction » afin que les développeurs puissent se concentrer sur l’expression de leurs idées dans un code clair et élégant⁸.

Viennent ensuite les sélecteurs de module. Lorsque deux modules importés déclarent tous deux un type nommé View, l’ancien remède était la syntaxe pointée (Rocket.SaturnV), qui ne tient plus dès qu’un module nommé Rocket contient lui aussi un type nommé Rocket, car Swift préfère le type puis échoue à trouver le membre. Swift 6.3 introduit ::, où le nom situé à gauche est toujours un nom de module, de sorte que Rocket::SaturnV se dirige directement vers le module. Le sélecteur fonctionne aussi sur les noms de méthodes et de propriétés. La recommandation d’Apple est sans ambiguïté : utilisez-le pour les conflits entre modules que vous ne contrôlez pas, et de manière défensive dans le code généré par les macros, mais ne concevez pas des API qui entrent intentionnellement en collision pour ensuite vous appuyer sur les sélecteurs afin de les départager¹.

Bibliothèque standard et Foundation

La bibliothèque standard a reçu des ajouts ciblés. Un bouclier d’annulation de tâche (withTaskCancellationShield, SE-0504, Swift 6.4) exécute une courte région où les vérifications d’annulation renvoient toujours false, de sorte qu’un nettoyage asynchrone comme l’achèvement d’une écriture sur disque s’exécute encore après l’annulation de la tâche environnante⁷. mapKeyedValues transmet à la fois la clé et l’ancienne valeur à la closure de transformation, remplaçant la reconstruction manuelle de dictionnaire que mapValues imposait lorsque vous aviez besoin de la clé. Un nouveau type de chemin de fichier, fondé sur celui de Swift System, gère les différences de plateforme dans la représentation des chemins¹.

Foundation a poursuivi sa migration pluriannuelle d’Objective-C vers Swift. Apple a modernisé une plus grande partie de Data (accès par span, vérifications d’égalité, itération et mutation plus rapides) et a unifié NSURL et CFURL en une seule implémentation Swift, plus rapide et consommant moins de mémoire. ProgressManager est un nouveau type de signalement de progression conçu pour async/await, et le paquet Subprocess a atteint la version 1.0 avec un type d’exécution simplifié, une sortie diffusée en AsyncBufferSequence et une méthode strings() qui lit la sortie ligne par ligne tout en respectant les frontières des grappes de graphèmes¹.

La propriété atteint le code ordinaire

C’est l’histoire des performances qu’il faut lire attentivement, car elle marque le moment où un projet de compilateur de plusieurs années devient quelque chose d’utilisable dans des types de tous les jours. Le problème central, c’est la copie : vous avez des données à un endroit, vous en avez besoin à un autre, alors le programme les copie. Lorsque le stockage reste alloué et que les deux côtés respectent les règles d’exclusivité de Swift, la copie est inutile. Un emprunt (borrow) accorde un accès en lecture au stockage existant sans le copier ; une mutation (mutate) accorde un accès exclusif en écriture. Le compilateur vérifie les deux à la compilation, ce qui rend la technique sûre là où un UnsafePointer brut ne l’était pas¹.

La partie sur la propriété et le réglage des performances débute aux environs de 19:55 et couvre le contrôle de l’inlining, la spécialisation et les nouveaux accesseurs.

Plusieurs protocoles fonctionnent maintenant sans copie. Equatable, Comparable et Hashable peuvent s’appliquer à des types non copiables, et Equatable et Comparable s’étendent aux types non échappables. Les types associés peuvent désormais être non copiables ou non échappables, ce qui rend possible la fonctionnalité phare : un nouveau protocole Iterable que les boucles for prennent directement en charge¹.

Le protocole Sequence que tout le monde connaît copie les éléments à mesure qu’il itère. Iterable permet à la boucle de les emprunter à la place, ce qui veut dire qu’il fonctionne avec des éléments non copiables et qu’il évite le comptage de références sur les objets et les types à copie sur écriture (copy-on-write). Il peut lever une erreur durant l’itération, comme le fait une AsyncSequence. Parce que l’emprunt interdit la mutation, la vérification d’exclusivité vous empêche de muter la collection pendant que vous bouclez dessus (un piège de performance fréquent avec Sequence). Une boucle for préfère Sequence quand il est disponible et se replie sur Iterable, et l’itérateur Iterable renvoie les éléments par lots de spans plutôt qu’un à la fois, ce qui rend la boucle mesurablement plus efficace pour les types capables de tout restituer dans un seul span¹.

Les accesseurs ont reçu le même traitement. L’exemple d’Apple est un UniqueBox contenant un InlineArray de 256 Int, une structure de deux kilo-octets sur un appareil 64 bits. Avec get/set, modifier un élément copie l’ensemble du tableau vers l’extérieur puis le réintègre. En faisant passer la propriété calculée à un accesseur borrow (accès en lecture seule sans copie) et à un accesseur mutate (modification exclusive sur place), Swift peut modifier un élément sur place et permet au type de contenir des valeurs non copiables¹.

Plusieurs nouveaux types de la bibliothèque standard livrent les remplacements sûrs de motifs qui exigeaient auparavant du code dangereux :

• UniqueArray se comporte comme Array mais est non copiable, de sorte qu’il stocke des éléments non copiables et évite la surcharge du comptage de références sans s’engager sur une taille fixe.
• UniqueBox est un vrai type de la bibliothèque standard utilisant les nouveaux accesseurs.
• Continuation vérifie à la compilation que vous la reprenez exactement une fois, ce qui la rend plus sûre que CheckedContinuation et aussi efficace qu’UnsafeContinuation.
• Ref et MutableRef se comportent comme un Span pour une valeur unique : un conteneur pour un emprunt ou une mutation que vous pouvez stocker dans une variable, passer, renvoyer et utiliser dans des types génériques. Vous construisez un MutableRef à partir d’un accès en écriture avec un & en préfixe, et, comme les refs sont non échappables, Swift sait que l’accès se termine lorsque la variable quitte la portée¹.

UniqueArray et le RigidArray à capacité fixe résident dans un nouveau module Containers (SE-0527, accepté sur le principe), et vous pouvez utiliser les deux dès aujourd’hui via swift-collections 1.3 avant qu’ils ne s’installent dans la bibliothèque standard⁷.

Pour le contrôle de l’optimiseur, Swift 6.4 ajoute @inline(always) en pendant du @inline(never) de longue date (associez-le à final sur les méthodes de classe, puisqu’une méthode redéfinissable peut toujours ne pas être intégrée par inlining), et Swift 6.3 ajoute @specialized, où une clause where indique au compilateur de pré-générer une version spécialisée d’une fonction générique pour les types concrets que vous utilisez le plus¹. Vous en aurez rarement besoin. Quand ce sera le cas, comme le dit la session, « vous serez content de les avoir »¹.

Swift Testing : la migration est désormais bidirectionnelle

Swift Testing est arrivé dans Xcode 16 en tant que bibliothèque de tests moderne, fondée sur les macros et parallèle par défaut². L’histoire de 2026, c’est la migration, et l’ajout clé est l’interopérabilité des frameworks de test : la possibilité d’appeler l’API d’un framework à l’intérieur d’un corps de test de l’autre, dans les deux sens².

Jerry de l’équipe Swift Testing montre comment appeler des helpers XCTest depuis des tests Swift Testing. La présentation de l’interopérabilité commence aux environs de 5:48.

La stratégie de migration recommandée par Apple n’a pas changé : laissez la plupart des XCTests en place, écrivez les nouveaux tests en Swift Testing et migrez ceux que vous touchez le plus souvent. Les deux frameworks coexistent déjà dans une seule cible. La nouveauté, c’est que vous pouvez réutiliser le code helper que vous avez bâti sur XCTest. Lorsqu’un test Swift Testing appelle un helper assertUnique qui enveloppe XCTFail, cela produit un problème inter-frameworks, et Xcode le gère désormais avec quatre modes² :

• Limited : les problèmes inter-frameworks issus de XCTest sont des avertissements. Les plans de test créés avant Xcode 27 héritent de ce mode, et les paquets Swift en swift-tools-version: 6.3 l’adoptent par défaut.
• Complete : ces mêmes problèmes restent des erreurs. Xcode 27 utilise le mode complete pour les nouveaux projets ; les paquets Swift s’y inscrivent en passant à swift-tools-version: 6.4 ou plus récent.
• Strict : les problèmes inter-frameworks issus de XCTest arrêtent le test sur une erreur fatale, en vous pointant chaque endroit où remplacer une API XCTest.
• None : désactivation complète (à n’utiliser que temporairement, car ces problèmes peuvent signaler de vrais bugs).

Les problèmes inter-frameworks issus de Swift Testing restent des erreurs dans tous les modes, de sorte que vous pouvez appeler en toute sécurité #expect et #require depuis l’intérieur d’un XCTestCase. Vous remplacez la valeur par défaut dans un paquet à l’aide de la variable d’environnement SWIFT_TESTING_XCTEST_INTEROP_MODE (nom du mode en minuscules)². La session 262 sur XCTest confirme le pendant côté bibliothèque standard : les échecs d’assertion XCTest apparaissent désormais comme des problèmes de test lorsqu’ils sont appelés depuis Swift Testing, de sorte que vous migrez sans perdre discrètement de couverture¹.

Le recueil de migration couvre les motifs courants. XCTSkip devient Test.cancel (ou, mieux, un trait .enabled/.disabled qui déplace la logique d’activation hors du corps du test). continueAfterFailure = false devient #require, qui lève une erreur en cas d’échec et stoppe le test, vous laissant choisir, attente par attente, quels échecs interrompent l’exécution². L’interopérabilité prend en charge un ensemble d’API limité mais pratique : toutes les assertions XCTest, les deux macros d’attente (#expect et #require), l’API known-issue pour marquer les échecs XCTest comme connus, et Test.cancel pour ignorer des cas XCTest².

Pour la surface d’API elle-même (les macros, le vocabulaire des traits, ce qui reste dans XCTest), l’article compagnon sur Swift Testing vs. XCTest couvre le modèle mental. Deux remarques en découlent : l’automatisation d’interface utilisateur et les tests de performance restent réservés à XCTest, et le code qui lève des exceptions Objective-C doit rester dans des XCTests écrits en Objective-C, car le code Swift ne peut pas gérer ces exceptions en toute sécurité². Une fois migré, vous obtenez les tests paramétrés (chaque argument devient un cas distinct, tous s’exécutant en parallèle) et les tests de sortie, qui exécutent dans un processus enfant du code censé planter afin de vérifier la terminaison, disponibles sur macOS, Linux, FreeBSD et Windows².

gRPC Swift : des services temps réel typés

L’histoire serveur est la démonstration la plus claire que Swift couvre désormais le client et le backend avec un seul langage. La session gRPC construit une application iOS qui dialogue avec un serveur Swift, entièrement généré à partir d’une spécification .proto³.

George de l’équipe Swift Server explique les quatre types de RPC. La partie sur le streaming, y compris le streaming bidirectionnel, commence aux environs de 11:06.

gRPC est un projet de la Cloud Native Computing Foundation où vous définissez des API sous forme de fonctions aux entrées et sorties typées plutôt que comme des points de terminaison HTTP, et où vous générez le code client à partir de la spécification³. Le déroulé : définir le service dans un fichier .proto, ajouter grpc-swift-nio-transport (réseau sur SwiftNIO) et grpc-swift-protobuf (le plugin de build) comme dépendances de paquet, attacher le plugin run-build-tool GRPCProtobufGenerator, puis recompiler pour générer le client typé.

Un RPC unaire comme ListRaces envoie une requête et reçoit une réponse. La démo de karting de la session le branche dans une vue SwiftUI avec withGRPCClient, puis refactorise pour partager un client unique via l’environnement SwiftUI afin que les vues réutilisent les connexions, et se déconnecte lorsque la scène passe en arrière-plan³. Protobuf sérialise les messages en binaire en les indexant par numéro de champ plutôt que par nom de champ, ce qui rend un message « grosso modo deux fois plus petit que le message JSON équivalent »³, un véritable gain sur les réseaux mobiles médiocres. Apple note que la même efficacité alimente sa propre infrastructure : gRPC Swift gère la communication interprocessus dans le framework open source Containerization et sous-tend Private Cloud Compute, le Trousseau iCloud et Photos, ainsi que le partage de fichiers SharePlay³.

C’est la prise en charge du streaming qui rend le temps réel possible. Au-delà des RPC unaires, il existe le client-streaming (plusieurs requêtes, une réponse), le server-streaming (une requête, plusieurs réponses, comme un fil de commentaires en direct) et le streaming bidirectionnel. La démo utilise le streaming bidirectionnel pour des mises à jour de course en direct : le client diffuse les types d’événements qu’il souhaite tandis que le serveur diffuse les événements correspondants. Côté serveur, cela devient une fonction async dont le paramètre de requête est une AsyncSequence de messages et dont le paramètre de réponse est un writer, le tout géré avec un task group et un ensemble de types d’événements abonnés protégé par un mutex³. Le déploiement passe par un Containerfile multi-étapes (build avec swift:latest, copie du binaire de release dans swift:slim), s’exécute sur Google Cloud Run en HTTP/2, puis le client bascule la sécurité de son transport du texte en clair vers TLS³.

MLX Swift : un calcul numérique qui se lit comme des maths

La session MLX vise un développeur entièrement différent : quiconque écrit des simulations, du traitement du signal, du rendu ou de l’entraînement de modèles. MLX Swift utilise comme abstraction centrale des tableaux n-dimensionnels, à la manière de NumPy, si bien que « la majeure partie du code NumPy peut être traduite en MLX Swift avec des modifications minimes »⁴.

David Koski parcourt l’exemple de Mandelbrot. La comparaison du calcul sur tableaux face au Swift ordinaire commence aux environs de 4:28.

MLX se place aux côtés de la pile numérique Apple existante plutôt que de la remplacer : Accelerate pour les primitives vectorielles CPU optimisées à la main, BNNS pour les briques de réseaux de neurones, Metal Performance Shaders pour les kernels GPU directs, et Swift Numerics pour le type Complex. Vous vous tournez vers MLX Swift quand l’objectif est « d’écrire du code mathématique avec un souci de performance » et que vous voulez que le code ressemble aux maths⁴.

Deux fonctionnalités rendent cela possible. L’évaluation paresseuse (lazy evaluation) construit un graphe de calcul au fur et à mesure que vous écrivez des opérations sur tableaux et n’exécute rien tant que vous n’appelez pas eval ou ne lisez pas une valeur, raison pour laquelle une boucle appelle eval à chaque étape afin de garder le graphe réduit. L’évaluation paresseuse alimente aussi l’exécution GPU automatique et la différenciation automatique via la transformation de fonction grad⁴. L’exemple de Mandelbrot ramène une boucle scalaire par pixel à deux lignes (z = z * z + c appliqué à toute la grille, puis un décompte des itérations bornées), s’exécute sur le GPU par défaut, et la session note qu’« un facteur 10 est tout à fait possible »⁴. Un solveur de distribution de chaleur exprime l’itération de Jacobi sous la forme d’un seul appel conv2d. L’exemple d’ajustement de courbe utilise grad pour calculer des gradients exacts sans aucune dérivée écrite à la main, l’idée même qui sous-tend l’entraînement de tout modèle de ML⁴.

MLX Swift est open source sous licence MIT, installable via Swift Package Manager, et c’est l’un des quatre front-ends (Swift, Python, C++ et C) partageant les mêmes opérations et le même modèle d’évaluation paresseuse, ce qui vous permet de « prototyper en Python et de livrer en Swift »⁴. L’écosystème comprend mlx-swift (le framework central), mlx-swift-lm (les implémentations de modèles de langage) et mlx-swift-examples (des exemples exécutables de LLM, de diffusion et d’entraînement)⁴. Pour le contexte de ML embarqué qui l’entoure, voyez MLX et le ML embarqué sur Apple Silicon.

Par quoi commencer

Hiérarchisez le travail selon qui vous êtes.

Si vous livrez des applications et touchez rarement aux réglages de performance du compilateur, adoptez l’ergonomie dès maintenant et ignorez le système de propriété. Remplacez les lignes @available empilées par anyAppleOS là où vos plateformes concordent, utilisez @diagnose pour faire taire les avertissements de dépréciation précisément aux endroits où vous êtes en pleine migration, et tournez-vous vers les sélecteurs de module (::) la prochaine fois qu’une dépendance entre en collision avec SwiftUI sur un nom comme View¹.

Si vous maintenez une grande suite XCTest, activez l’interopérabilité et commencez dès aujourd’hui à écrire les nouveaux tests en Swift Testing. Faites passer les plans de test existants en mode complete pour que les problèmes inter-frameworks soient des erreurs qui ne vous échapperont pas, réutilisez vos helpers XCTest via l’interopérabilité plutôt que de les réécrire d’emblée, et migrez les fichiers que vous touchez le plus. Conservez dans XCTest l’automatisation d’interface utilisateur, les tests de performance et les tests à exceptions Objective-C¹².

Si vous écrivez du code sensible aux performances, les ajouts liés à la propriété sont l’événement majeur. Auditez les propriétés calculées « chaudes » qui contiennent de grandes valeurs et faites-les passer de get/set à borrow/mutate. Là où vous descendiez auparavant jusqu’à UnsafePointer, regardez du côté de Ref/MutableRef, UniqueArray et la Continuation à reprise unique. Mesurez avant de recourir à @inline(always) ou @specialized, car l’optimiseur a généralement raison et le forcer peut rendre le binaire plus volumineux et plus lent¹.

Si votre travail relève du côté serveur ou du numérique, les nouveaux paquets sont des points d’entrée prêts pour la production : gRPC Swift vous donne un client typé et du streaming bidirectionnel à partir d’un fichier .proto, et MLX Swift vous offre un calcul sur tableaux accéléré par GPU et une différenciation automatique qui se lit comme les maths³⁴.

FAQ

Quelle est la différence entre Swift 6.3 et Swift 6.4 ?

Apple a développé et livré les deux au cours du même cycle WWDC26 et les a présentées ensemble. Grossièrement, Swift 6.3 a introduit les sélecteurs de module (::) et l’attribut @specialized, et a livré le premier SDK Swift officiel pour Android. Swift 6.4 a ajouté la disponibilité anyAppleOS, les any/some optionnels sans parenthèses, le protocole Iterable pour les boucles for, les accesseurs borrow/mutate, @inline(always), l’attribut @C pour exporter des fonctions Swift vers le C, et les améliorations de débogage d’embedded Swift. La session traite les deux comme un seul et même corps de travail continu¹.

Suis-je obligé de migrer de XCTest vers Swift Testing ?

Non. XCTest est toujours livré et fonctionne toujours, et la recommandation d’Apple est incrémentale : écrivez les nouveaux tests en Swift Testing et migrez les anciens à mesure que vous les touchez. L’interopérabilité des frameworks de test laisse les deux coexister dans une seule cible et appeler l’API l’un de l’autre, de sorte que vous pouvez réutiliser des helpers XCTest depuis des tests Swift Testing. L’automatisation d’interface utilisateur, les tests de performance et le code qui lève des exceptions Objective-C restent dans XCTest¹².

Que fait le nouveau protocole Iterable que Sequence ne fait pas ?

Sequence copie les éléments à mesure qu’il itère. Iterable permet à la boucle for d’emprunter les éléments à la place, si bien qu’il fonctionne avec des éléments non copiables et évite le comptage de références sur les objets et les types à copie sur écriture. Il renvoie les éléments par lots de spans plutôt qu’un à la fois, ce qui est plus efficace, et il peut lever une erreur durant l’itération. Parce que l’emprunt interdit la mutation, vous ne pouvez pas muter la collection pendant que vous bouclez dessus. Une boucle for préfère Sequence quand il est disponible et se replie sur Iterable¹.

Quand devrais-je utiliser MLX Swift plutôt qu’Accelerate ou Metal Performance Shaders ?

Utilisez MLX Swift lorsque votre objectif premier est d’écrire du code mathématique avec un souci de performance et que vous voulez que le code se lise comme les maths, avec exécution GPU automatique et différenciation automatique via grad. Accelerate reste le choix pour les primitives vectorielles CPU optimisées à la main, BNNS pour les briques de réseaux de neurones, et Metal Performance Shaders pour l’accès direct aux kernels GPU. MLX se place à leurs côtés plutôt que de les remplacer⁴.

gRPC Swift est-il réservé aux services backend ?

Non. La session WWDC construit une application iOS comme client gRPC, en générant un client typé à partir d’un fichier .proto, et montre des RPC unaires ainsi qu’en streaming bidirectionnel pilotant des mises à jour d’interface en direct. L’encodage binaire de Protobuf produit des messages grosso modo deux fois plus petits que le JSON équivalent, ce qui aide sur les réseaux mobiles médiocres. Apple utilise aussi gRPC Swift pour la communication interprocessus et dans des services tels que Private Cloud Compute, le Trousseau iCloud et Photos, ainsi que le partage de fichiers SharePlay³.

Le cluster de l’écosystème Apple

La mise à jour 2026 de Swift se tisse à travers le reste de la série Apple Ecosystem : l’analyse de Swift Testing vs. XCTest sur le modèle de test, les rouages internes d’Observable dans SwiftUI que les changements de concurrence touchent, de quoi SwiftUI est fait au niveau du framework, et MLX et le ML embarqué sur Apple Silicon pour le contexte du calcul numérique. Le point central de l’ensemble est la série Apple Ecosystem. Pour construire des applications iOS avec des agents IA dans la boucle, voyez le guide de développement d’agents iOS.

Références