La Putain d'Approchable
Swift Concurrency

Le Code Asynchone : async/await

La plupart du temps, les apps ne font qu'attendre. Récupérer des données d'un serveur – attendre la réponse. Lire un fichier sur le disque – attendre les octets. Interroger une base de données – attendre les résultats.

Avant le système de concurrence de Swift, vous exprimiez cette attente avec des callbacks, des delegates, ou Combine. Ça fonctionnait, mais les callbacks imbriqués deviennent vite illisibles, et Combine a une courbe d'apprentissage raide.

async/await donne à Swift une nouvelle façon de gérer l'attente. Au lieu de callbacks, vous écrivez du code qui ressemble à du code séquentiel – il se met en pause, attend, puis continue. Sous le capot, le runtime de Swift gère ces pauses efficacement. Mais le fait que votre app reste vraiment réactive pendant qu'elle attend dépend de l'endroit où s'exécute le code, ce que nous verrons plus tard.

Une fonction async est une fonction qui pourrait avoir besoin de se mettre en pause. on l'annote avec async, et quand on l'appelle, on utilise await pour dire « mets-toi en pause ici jusqu'à ce que ce soit fini » :

func fetchUser(id: Int) async throws -> User {
    let url = URL(string: "https://api.example.com/users/\(id)")!
    let (data, _) = try await URLSession.shared.data(from: url)  // Se met en pause ici
    return try JSONDecoder().decode(User.self, from: data)
}

// Le point d'appel
let user = try await fetchUser(id: 123)
// Le code ici s'exécute après que fetchUser a terminé

Votre code se met en pause à chaque await – on appelle ça une suspension. Quand le travail est terminé, votre code reprend exactement là où il s'était arrêté. La suspension donne à Swift l'occasion de faire autre chose pendant qu'il attend.

Attendre toutes les opérations

Et si vous devez récupérer plusieurs résultats ? Vous pourriez les attendre un après l'autre :

let avatar = try await fetchImage("avatar.jpg")
let banner = try await fetchImage("banner.jpg")
let bio = try await fetchBio()

Mais c'est lent – chacune attend que la précédente ait terminé. Utilisez plutôt async let pour les exécuter en parallèle :

func loadProfile() async throws -> Profile {
    async let avatar = fetchImage("avatar.jpg")
    async let banner = fetchImage("banner.jpg")
    async let bio = fetchBio()

    // Les trois se chargent en parallèle !
    return Profile(
        avatar: try await avatar,
        banner: try await banner,
        bio: try await bio
    )
}

Chaque async let démarre immédiatement le travail de récupération des données. Le await ne fait qu'attendre les résultats.

Gérer les Traitements : les Tasks

Une Task est une unité de travail asynchrone que vous pouvez gérer. Jusqu'ici nous avons écrit des fonctions asynchrones, mais une Task est ce qui les exécute réellement. C'est elle qui initie du code asynchrone depuis du code synchrone et donne le contrôle sur son exécution : attendre son résultat, l'annuler, ou la laisser tourner en arrière‑plan.

Imaginons que vous soyiez en train de construire un écran de profil. Afin de charger l'avatar lorsque la vue apparaît, servez-vous du modifier .task qui s'annulera automatiquement quand la vue disparaîtra :

struct ProfileView: View {
    @State private var avatar: Image?

    var body: some View {
        Group {
            if let avatar {
                avatar
            } else {
                ProgressView()
            }
        }
        .task { avatar = await downloadAvatar() }
    }
}

Si les utilisateurs peuvent changer de profil, utilisez plutôt .task(id:) pour recharger la vue quand la sélection change :

struct ProfileView: View {
    var userID: String
    @State private var avatar: Image?

    var body: some View {
        Group {
            if let avatar {
                avatar
            } else {
                ProgressView()
            }
        }
        .task(id: userID) { avatar = await downloadAvatar(for: userID) }
    }
}

Et quand l'utilisateur tape sur un bouton « Enregistrer », créez simplement une Task manuellement :

Button("Enregistrer") {
    Task { await saveProfile() }
}

Accéder aux résultats d'une Task

Quand vous créez une Task, vous obtenez une référence (handle). Utilisez alors .value pour attendre et récupérer le résultat :

let handle = Task {
    return await fetchUserData()
}
let userData = await handle.value  // Se met en pause jusqu'à ce que la tâche se termine

C'est utile quand vous avez besoin du résultat plus tard, ou quand vous voulez conserver le handle de la tâche et faire le await ailleurs.

Et si vous devez charger l'avatar, la bio et les stats en même temps ? choisissez un TaskGroup pour les charger en parallèle :

try await withThrowingTaskGroup(of: Void.self) { group in
    group.addTask { avatar = try await downloadAvatar(for: userID) }
    group.addTask { bio = try await fetchBio(for: userID) }
    group.addTask { stats = try await fetchStats(for: userID) }
    try await group.waitForAll()
}

Les Tasks à l'intérieur d'un groupe sont des tasks enfants, liées au parent. Il y a quelques trucs à savoir :

• L'annulation se propage : annulez le parent, et tous les enfants sont annulés aussi
• Erreurs : une erreur émise par une Task annule les Tasks sœurs et est propagée par le parent, mais seulement quand les résultats sont consommés avec next(), waitForAll() ou par une itération
• Ordre de complétion : les résultats arrivent selon l'ordre de fin des tasks, pas l'ordre dans lequel ils ont été ajoutés
• Tous pour Un : le groupe ne se termine pas tant que chaque enfant n'a pas terminé ou été annulé

C'est la concurrence structurée : du travail organisé en un arbre facile à comprendre et à nettoyer.

La où le Code s'exécute : des Threads aux Domaines d'Isolement

Jusqu'ici nous avons parlé de quand le code s'exécute (async/await) et de comment l'organiser (Tasks). Voyons maintenant : où s'exécute-t-il, et comment reste-t-il sûr ?

L'Ancien Monde : Beaucoup d'Options pour peu de Sécurité

Avant le système de concurrence de Swift, vous aviez plusieurs façons de gérer l'exécution :

Toutes ces solutions fonctionnaient, mais la sécurité reposait entièrement sur le développeur. Le compilateur ne pouvait pas nous aider si on oubliait de dispatcher sur main, ou si deux queues accédaient aux mêmes données en même temps.

Le Problème : Les Data Races

Une data race se produit quand deux threads accèdent à la même mémoire en même temps, et qu'au moins un des deux la modifie :

var count = 0

DispatchQueue.global().async { count += 1 }
DispatchQueue.global().async { count += 1 }

// Comportement indéfini : crash, corruption mémoire, ou valeur incorrecte

Les data races sont un comportement indéfini. Elles peuvent faire crasher l'app, corrompre la mémoire, ou produire silencieusement de mauvais résultats. L'application peut très bien fonctionner en test puis crasher aléatoirement en production. Les outils traditionnels comme les locks et sémaphores peuvent nous aider ici, mais restent manuels eux aussi et sujets aux erreurs.

Changement de paradigme : des Threads vers l'Isolement

Le modèle de concurrence de Swift pose une question différente. Au lieu de « sur quel thread ça devrait s'exécuter ? », il demande : « qui a le droit d'accéder à ces données ? »

C'est ça, l'isolement. Plutôt que de répartir manuellement des tâches sur des threads, vous définissez des frontières autour des données. Le compilateur appliquera ces frontières au moment de la compilation, pas à l'exécution.

Les Trois Domaines d'Isolement

1. MainActor

@MainActor est un actor global qui représente le domaine d'isolement du thread principal. Il est spécial parce que les frameworks d'UI (UIKit, AppKit, SwiftUI) exigent un accès sur le thread principal.

@MainActor
class ViewModel {
    var items: [Item] = []  // Protégé par l'isolement de MainActor
}

Quand quelque chose est annoté avec @MainActor, on ne dit pas « envoie ça sur le thread principal » mais plutôt « ceci appartient au domaine d'isolement de MainActor ». Le compilateur s'assurera donc que tout ce qui y accède est déjà sur MainActor ou doit faire await pour franchir la frontière.

2. Actors

Un actor protège son propre état mutable. Il garantit qu'un seul morceau de code peut accéder à ses données à la fois :

actor BankAccount {
    var balance: Double = 0

    func deposit(_ amount: Double) {
        balance += amount  // Sûr : l'actor garantit un accès exclusif
    }
}

// De l'extérieur, il faut utiliser await pour franchir la frontière
await account.deposit(100)

Les actors ne sont pas des threads. Un actor est une frontière d'isolement. C'est le runtime Swift qui décide sur quel thread s'exécute réellement le code de l'actor. Vous ne contrôlez pas ça, et vous n'avez pas besoin de le faire.

3. Nonisolated

Le code annoté avec nonisolated sort de l'isolement de l'actor. Il peut être appelé depuis n'importe où sans await, mais, en échange, ne peut pas accéder à l'état protégé de l'actor :

actor BankAccount {
    var balance: Double = 0

    nonisolated func bankName() -> String {
        "Acme Bank"  // N'accède pas à l'état de l'actor, peut donc être appelé de n'importe où de manière sécurisée
    }
}

let name = account.bankName()  // await n'est pas nécessaire

// S'exécute sur MainActor (par défaut)
func updateUI() async { }
// S'exécute sur un thread d'arrière-plan (opt‑in)
@concurrent func processLargeFile() async { }

Voyager entre les Domaines d'Isolement : Sendable

Les domaines d'isolement protègent les données, mais on a parfois besoin de passer des données entre eux. Quand on le fait, Swift vérifie que l'échange est sûr.

Réfléchissez‑y : si vous passez une référence vers une classe mutable d'un actor à un autre, les deux actors pourraient la modifier simultanément. C'est exactement le type de data race qu'on essaie d'éviter. Swift doit donc savoir : est‑ce que ces données peuvent être partagées en toute sécurité ?

La réponse est le protocole Sendable. C'est un marqueur qui dit au compilateur « ce type est sûr, il peut franchir la frontière de l'isolement » :

• Les types Sendable peuvent passer en toute sécurité (types valeur, données immuables, actors)
• Les types Non‑Sendable ne le peuvent pas (classes avec état mutable)

// Sendable – c'est un type valeur, chaque endroit en obtient une copie
struct User: Sendable {
    let id: Int
    let name: String
}

// Non‑Sendable – c'est une classe avec état mutable
class Counter {
    var count = 0  // Si c'est modifier à deux endroits = catastrophe
}

Rendre les Types Sendable

Swift infère automatiquement Sendable pour beaucoup de types :

• Les structs et enums dont toutes les propriétés sont Sendable sont implicitement Sendable
• Les actors sont toujours Sendable parce qu'ils protègent leur propre état
• Les types @MainActor sont Sendable parce que MainActor sérialise l'accès

Pour les classes, c'est plus difficile. Une classe ne peut conformer à Sendable que si elle est final et que toutes ses propriétés stockées sont immuables :

final class APIConfig: Sendable {
    let baseURL: URL      // Immuable
    let timeout: Double   // Immuable
}

Si vous avez une classe qui est thread‑safe par d'autres moyens (locks, atomiques), vous pouvez utiliser @unchecked Sendable pour dire au compilateur « fais‑moi confiance, je gère » :

final class ThreadSafeCache: @unchecked Sendable {
    private let lock = NSLock()
    private var storage: [String: Data] = [:]
}

Comment l'Isolement se Propage

On a vu que les domaines d'isolement protègent les données, et que Sendable sécurise ce qui transite entre eux. Mais comment le code se retrouve dans un domaine d'isolement au départ ?

Quand vous appelez une fonction ou que vous créez une closure, l'isolement se propage dans votre code. Avec Approachable Concurrency, votre app commence sur MainActor, et cet isolement se propage au code que vous appelez, sauf si quelque chose le change explicitement. Comprendre ce flux vous aide à prédire où le code s'exécutera et pourquoi le compilateur se plaint parfois.

Appels de Fonctions

Quand on appelle une fonction, son isolement détermine où elle s'exécute :

@MainActor func updateUI() { }      // S'exécute toujours sur MainActor
func helper() { }                    // Hérite de l'isolement de l'appelant
@concurrent func crunch() async { }  // S'exécute explicitement hors de l'actor

Avec Approachable Concurrency, la plupart du code hérite de l'isolement de MainActor. La fonction s'exécute là où l'appelant s'exécute, sauf si elle en sort explicitement.

Closures

Les closures héritent de l'isolement du contexte où elles sont définies :

@MainActor
class ViewModel {
    func setup() {
        let closure = {
            // Hérite de MainActor depuis le ViewModel
            self.updateUI()  // Sûr, même isolement
        }
        closure()
    }
}

C'est pour cela que les closures d'action de Button en SwiftUI peuvent mettre à jour un @State en toute sécurité : elles héritent de l'isolement MainActor de la vue.

Tasks

Un eTask { } hérite de l'isolement de l'actor depuis lequel il est créé :

@MainActor
class ViewModel {
    func doWork() {
        Task {
            // Hérite de l'isolement MainActor
            self.updateUI()  // L'appel est sûr, await n'est pas nécessaire
        }
    }
}

C'est généralement ce dont vous avez besoin. La task s'exécute sur le même actor que le code qui l'a créée.

Casser l'Héritage : Task.detached

Parfois vous avez besoin d'une task qui n'hérite d'aucun contexte :

@MainActor
class ViewModel {
    func doHeavyWork() {
        Task.detached {
            // Pas d'isolement d'actor, s'exécute dans le pool coopératif
            let result = await self.expensiveCalculation()
            await MainActor.run {
                self.data = result  // on retourne explicitement sur MainActor
            }
        }
    }
}

Préserver l'Isolement dans les fonctions Asynchrones

Parfois vous avez besoin d'écrire une fonction asynchrone générique acceptant une closure – un wrapper, un helper de retry, un scope de transaction. L'appelant passe une closure et votre fonction l'exécute. Simple, non ?

func measure<T>(
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Mais quand on appelle ce genre de fonction depuis un contexte @MainActor, Swift se plaint :

Que se passe‑t‑il ? Votre closure capture de l'état de MainActor, mais measure est nonisolated. Swift voit une closure non Sendable qui franchit une frontière de l'isolement – exactement ce qu'il est censé empêcher.

La solution la plus simple est nonisolated(nonsending). Ça dit à Swift que la fonction doit rester sur l'executor de l'appelant :

nonisolated(nonsending)
func measure<T>(
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Maintenant, toute la fonction s'exécute sur l'executor de l'appelant. Appellez‑la depuis MainActor, elle reste sur MainActor. Appelle‑la depuis un actor personnalisé, elle reste sur celui-ci. La closure ne franchit jamais de frontière d'isolement, donc la vérification Sendable n'est pas nécessaire.

Si vous avez vraiment besoin d'un accès explicite à l'actor, utilisez plutôt un paramètre #isolation :

func measure<T>(
    isolation: isolated (any Actor)? = #isolation,
    _ label: String,
    block: () async throws -> T
) async rethrows -> T {
    let start = ContinuousClock.now
    let result = try await block()
    print("\(label): \(ContinuousClock.now - start)")
    return result
}

Les deux approches sont essentielles pour construire des fonctions utilitaires asynchrones agréables à utiliser. Sans elles, les appelants devraient rendre leurs closures @Sendable ou faire des acrobaties pour satisfaire le compilateur.

La Vue d'ensemble

Prenons du recul et voyons comment toutes les pièces s'imbriquent.

Swift Concurrency peut sembler plein de concepts : async/await, Task, actors, MainActor, Sendable, domaines d'isolement. Mais en réalité, il n'y a qu'une seule idée au centre de tout ça : l'isolement se propage par défaut.

En activant [Approachable Concurrency, votre app démarre sur MainActor. C'est votre point de départ. Ensuite, À partir de là :

• Chaque fonction que vous appelez hérite de cet isolement
• Chaque closure que vous créez capture cet isolement
• Chaque Task { } que vous générez hérite de cet isolement

Vous n'avez rien à annoter. Vous n'avez pas à penser en threads. Votre code s'exécute sur MainActor, et l'isolement se propage simplement à travers votre programme automatiquement.

Lorsque vous voulez vous passer de cet héritage, vous le faites explicitement :

• @concurrent dit « exécute ça sur un thread de fond »
• actor dit « ce type a son propre domaine d'isolement »
• Task.detached { } dit « commence de zéro, n'hérite de rien »

Et lorsque vous passez des données entre domaines d'isolement, Swift vérifie que c'est sûr. C'est pour ça que Sendable existe : marquer les types qui peuvent franchir les frontières en toute sécurité.

C'est tout. Voilà tout le modèle :

1. L'isolement se propage depuis MainActor dans le code
2. Vous en sortez explicitement lorsque vous avez besoin de traitement en arrière‑plan ou d'un état séparé
3. Sendable surveille les frontières lorsque les données change de domaines

Quand le compilateur se plaint, il vous dit qu'une de ces règles a été violée. Remontez la chaîne de l'héritage : d'où vient l'isolement ? Où ce code essaie‑t‑il de s'exécuter ? Quelles sont les données qui franchissent une frontière ? La réponse devient généralement évidente une fois que vous vous posez la bonne question.

Et Après ?

La bonne nouvelle est que vous n'avez pas besoin de tout maîtriser d'un coup.

La plupart des apps n'ont besoin que des bases. Annotez vos ViewModels avec @MainActor, utilisez async/await pour les appels réseau, et créez des Task { } quand vous devez démarrer du travail asynchrone depuis un tap de bouton. C'est tout. Ça couvre 80 % des apps du monde réel. Le compilateur vous dira si vous avez besoin d'en faire plus.

Quand vous avez besoin de traitements en parallèle, utilisez async let pour récupérer plusieurs résultats à la fois, ou TaskGroup quand le nombre de tasks est dynamique. Apprenez à gérer proprement l'annulation. Ça couvre les apps avec chargement de données complexe ou des fonctionnalités temps réel.

Si besoin, Les patterns avancés viennent après. Des actors personnalisés pour l'état mutable partagé, @concurrent pour des traitements gourmands en ressources CPU, une compréhension fine de Sendable. Tout ca relève de code de framework, de Swift côté serveur ou bien d'apps desktop complexes. La plupart des développeurs n'ont jamais besoin de ce niveau de complexité.

Erreurs Courantes : Les pièges à éviter

Imaginer que async = arrière‑plan

// Ceci bloque TOUJOURS le thread principal !
@MainActor
func slowFunction() async {
    let result = expensiveCalculation()  // Travail synchrone = bloquant
    data = result
}

async veut dire « peut se mettre en pause ». Le travail réel s'exécute toujours là où il s'exécute déjà. Utilise @concurrent (Swift 6.2) ou Task.detached pour un traitement gourmand en ressource CPU.

Créer trop d'actors

// Over-engineered
actor NetworkManager { }
actor CacheManager { }
actor DataManager { }

// Mieux – la plupart des choses peuvent vivre sur MainActor
@MainActor
class AppState { }

Un actor personnalisé n'est nécessaire que lorsque l'on a de l'état mutable partagé qui ne peut pas résider sur MainActor. La règle de Matt Massicotte : introduisez un actor seulement quand (1) vous avez de l'état non‑Sendable, (2) les opérations sur cet état doivent être atomiques, et (3) ces opérations ne peuvent pas s'exécuter sur un actor existant. Si vous ne pouvez le justifier avec une de ces règles, utilisez plutôt @MainActor.

Tout Rendre Sendable

Toutes les données n'ont pas besoin de franchir des frontières. Si vous vous retrouvez à mettre @unchecked Sendable de partout, prenez du recul et demandez-vous si les données doivent vraiment voyager entre différents domaines d'isolement.

Utiliser MainActor.run même quand ce n'est pas nécessaire

// Inutile
Task {
    let data = await fetchData()
    await MainActor.run {
        self.data = data
    }
}

// Mieux – rends simplement la fonction @MainActor
@MainActor
func loadData() async {
    self.data = await fetchData()
}

MainActor.run est rarement la bonne solution. Si vous avez besoin de l'isolement de MainActor, annotez la fonction avec @MainActor à la place. C'est plus clair pour l'équipe et le compilateur peut alors faire des retours plus pertinent. Voyez l'avis de Matt à ce sujet.

Bloquer le pool de threads coopératif

// NE JAMAIS FAIRE ÇA – risque de deadlock
func badIdea() async {
    let semaphore = DispatchSemaphore(value: 0)
    Task {
        await doWork()
        semaphore.signal()
    }
    semaphore.wait()  // Bloque un thread coopératif !
}

Le pool de threads coopératif de Swift a un nombre limité de threads. En bloquer un avec DispatchSemaphore, DispatchGroup.wait(), ou des appels similaires peut provoquer des deadlocks. Si vous devez brancher du code synchrone et asynchrone, utilisez async let ou restructurez-le pour qu'il reste entièrement asynchrone.

func doWork() async {

    // cette fonction se terminera quand tous les sous‑tasks auront retourné un résultat, émis une erreur, ou été annulés
    let result = try await withThrowingTaskGroup() { group in
        group.addTask {
            try await self.performAsyncOperation1()
        }
        group.addTask {
            try await self.performAsyncOperation2()
        }
        // attends et récupère les résultats des tasks ici
    }
}

func performAsyncOperation1() async throws -> Int {
    return 1
}
func performAsyncOperation2() async throws -> Int {
    return 2
}

var sum = 0
for await result in group {
    sum += result
}
// sum == 3

struct ContentView: View {

    @State private var shouldLoadImage = false

    var body: some View {
        Button("Clique !") {
            // clanger la valeur du booléen
            shouldLoadImage = !shouldLoadImage
        }
        // la Vuew gère la sous‑tâche
        // elle démarre avant que la vue soit affichée
        // et s'arrête quand la vue est cachée
        .task(id: shouldLoadImage) {
            // quand la valeur du booléen change, SwiftUI redémarre la task
            guard shouldLoadImage else { return }
            await loadImage()
        }
    }
}

Aide‑Mémoire : Référence Rapide

Pour Aller Plus Loin

Skill pour Agents IA

Vous voulez que votre assistant de code IA comprenne Swift Concurrency ? Nous fournissons un fichier SKILL.md qui regroupe ces modèles mentaux pour des agents IA comme Claude Code, Codex, Amp, OpenCode et d'autres.

Autres skills

• Swift Concurrency Agent Skill open source d'Antoine

Comment Faire

Choisissez votre agent et exécutez les commandes :

# Skill personnel (pour tous vos projets)
mkdir -p ~/.claude/skills/swift-concurrency
curl -o ~/.claude/skills/swift-concurrency/SKILL.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Skill de projet (seulement pour le projet courant)
mkdir -p .claude/skills/swift-concurrency
curl -o .claude/skills/swift-concurrency/SKILL.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Instructions globales (pour tous vos projets)
curl -o ~/.codex/AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Instructions de projet (seulement pour le projet courant)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Instructions de projet (recommandé)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

# Règles globales (pour tous vos projets)
mkdir -p ~/.config/opencode
curl -o ~/.config/opencode/AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md
# Règles de projet (seulement pour le projet courant)
curl -o AGENTS.md https://fuckingapproachableswiftconcurrency.com/SKILL.md

Le skill inclut l'analogie de l'Immeuble de Bureaux, les patterns d'isolement, le guide pour Sendable, les erreurs courantes et les tableaux de référence rapide. Votre agent utilisera automatiquement ces connaissances quand vous travaillerez avec du code Swift Concurrency.