Annoncé à la WWDC 2019 (iOS 13+), SwiftUI est le framework UI moderne d'Apple, inspiré de React, Flutter et Jetpack Compose. Là où UIKit (impératif, MVC, depuis 2007) demande de manipuler chaque vue et son cycle de vie manuellement, SwiftUI décrit l'état souhaité de l'UI à un instant T : le framework s'occupe du diffing et redessine uniquement ce qui change.

Une View SwiftUI est une struct (value type immuable) conforme au protocole View, exposant une propriété calculée body. Le compilateur Swift utilise un result builder (@ViewBuilder) pour assembler les sous-vues en arbre statique typé, vérifié à la compilation.

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack(spacing: 12) {
            Text("Bonjour, \(name)")
                .font(.largeTitle)
                .foregroundStyle(.blue)
            Image(systemName: "hand.wave.fill")
                .imageScale(.large)
        }
        .padding()
    }
}

Les modifiers (.font, .padding, .background...) retournent une nouvelle View. L'ordre compte : .padding().background(Color.red) n'est pas équivalent à .background(Color.red).padding().

SwiftUI redessine une View lorsque sa source de vérité change. Cette source est encapsulée dans des property wrappers spécifiques selon la portée et la propriété :

iOS 17 introduit la macro @Observable (framework Observation) qui remplace ObservableObject + @Published par un mécanisme plus performant basé sur le tracking automatique. Désormais :

@Observable class UserViewModel {
    var user: User?
    var isLoading = false

    func load() async {
        isLoading = true
        defer { isLoading = false }
        user = try? await API.fetchCurrentUser()
    }
}

struct ProfileView: View {
    @State private var vm = UserViewModel()  // plus de @StateObject !

    var body: some View {
        Group {
            if vm.isLoading { ProgressView() }
            else if let user = vm.user { Text(user.name) }
        }
        .task { await vm.load() }
    }
}

Depuis iOS 16, NavigationStack remplace le NavigationView déprécié. Il gère une pile de destinations typées via NavigationPath, ce qui permet la deep linking et la restauration d'état.

struct ContentView: View {
    @State private var path = NavigationPath()

    var body: some View {
        NavigationStack(path: $path) {
            List(0..<10) { i in
                NavigationLink("Item \(i)", value: i)
            }
            .navigationTitle("Accueil")
            .navigationDestination(for: Int.self) { value in
                DetailView(index: value)
            }
        }
    }
}

Pour les écrans modaux, on utilise .sheet(isPresented:) (modal carte iOS 13+), .fullScreenCover (plein écran sans drag dismiss), .alert et .confirmationDialog pour les confirmations natives système.

Animer en SwiftUI consiste à modifier un état dans un bloc withAnimation { }. Le framework interpole automatiquement les valeurs animables (opacity, scale, offset, color, cornerRadius...) entre les deux états.

struct LikeButton: View {
    @State private var liked = false

    var body: some View {
        Image(systemName: liked ? "heart.fill" : "heart")
            .foregroundStyle(liked ? .red : .gray)
            .scaleEffect(liked ? 1.3 : 1.0)
            .animation(.spring(response: 0.4, dampingFraction: 0.6), value: liked)
            .onTapGesture { liked.toggle() }
    }
}

Pour les transitions plus avancées (effet "hero" entre deux écrans), matchedGeometryEffect identifie une vue par un id et un namespace partagé : SwiftUI interpole position, taille et forme automatiquement entre les états.

Le passage de @ObservableObject au macro @Observable (iOS 17+) est l'évolution la plus importante de SwiftUI depuis sa naissance. Sous le capot, @Observable applique du tracking par observation granulaire au niveau propriété : SwiftUI ne réinvalide une vue que si la propriété spécifique lue dans body change. Avec l'ancien @Published, toute modification de n'importe quelle propriété déclenchait une réinvalidation de toutes les vues observant l'objet. Le gain de performances est mesurable : sur des écrans complexes (200+ vues), on observe 30 à 60 % de moins de recalculs de body.

La règle d'or : @State pour la propriété d'une vue, @Bindable pour passer un objet observable mutable à une sous-vue, @Environment(\.modelContext) ou similaire pour les services injectés via l'environnement. Le triplet @StateObject/@ObservedObject/@EnvironmentObject reste valide pour la compatibilité descendante mais devient legacy. Une migration partielle est possible : vous pouvez avoir des @Observable et des ObservableObject cohabitant dans la même app.

Sous-section 1 — Custom ViewModifiers et le pattern ViewBuilder

Tout modifier en SwiftUI est en réalité une fonction qui prend une View et retourne une autre View. Pour créer le vôtre, on conforme un type à ViewModifier et on implémente body(content:). L'astuce est d'envelopper l'usage dans une extension View pour bénéficier d'une API fluide. Le bénéfice n'est pas qu'esthétique : un modifier custom est cacheable par le compilateur car il a une identité de type stable, ce qui permet à SwiftUI de mémoriser la sortie. Cela contraste avec un wrapper @ViewBuilder ad-hoc qui doit être reconstruit.

Le @ViewBuilder lui-même mérite attention : c'est un result builder qui transforme une séquence de View en TupleView. Sa limitation officielle est 10 vues (mais on peut combiner avec Group pour contourner). Plus subtil : un if/else dans un @ViewBuilder produit un _ConditionalContent, ce qui change l'identité de la vue selon la branche. SwiftUI détruit puis recrée l'état (@State) à chaque bascule, ce qui peut causer des regressions visuelles. Pour préserver l'état, utiliser un modifier conditionnel : view.opacity(condition ? 1 : 0) au lieu de if condition { view }.

Sous-section 2 — Drag & drop, Transferable et interopérabilité

Le protocole Transferable (iOS 16+) unifie tout transfert de données : drag & drop, copy-paste, partage ShareLink. On implémente static var transferRepresentation: some TransferRepresentation avec un DataRepresentation, FileRepresentation, ou CodableRepresentation. Le runtime sélectionne le format optimal selon le destinataire : si vous draggez un type vers Finder, c'est le FileRepresentation qui est utilisé ; vers une autre app SwiftUI, c'est la version Codable typée.

Combiner .draggable et .dropDestination permet de construire une UI de réordonnancement quasi gratuite. Sur iPad multitâche, .draggable permet le drag inter-app sans code supplémentaire. Le piège : sur iOS, contrairement à macOS, un drag long-press d'un seul élément n'est pas le geste natif. Il faut typiquement initier le drag depuis une zone tactile dédiée ou utiliser EditMode.