@StateObject : ce que c'est, création et gestion d'ObservableObject

Qu'est-ce que @StateObject dans SwiftUI

@StateObject est un property wrapper introduit dans iOS 14 qui permet à une View de créer et de posséder une instance d'une classe conforme au protocole ObservableObject. Contrairement à @State qui fonctionne avec des types valeur (structs), @StateObject est conçu pour les types référence — des classes qui peuvent notifier SwiftUI des modifications de leurs propriétés.

Lorsqu'une View utilise @StateObject var viewModel: MyViewModel, SwiftUI crée automatiquement une instance de MyViewModel lors de la première apparition de la View et la stocke dans un stockage spécial du framework. À chaque mise à jour de la View (par exemple, lorsque l'état parent change), SwiftUI ne recrée pas l'objet — il utilise l'instance existante jusqu'à ce que la View soit supprimée de la hiérarchie.

Selon Apple WWDC Session 10137 (2024), @StateObject résout le problème de perte de données qui existait dans iOS 13 lors de la reconstruction des Views, forçant les développeurs à créer ObservableObject dans la View parente et à le passer via l'initialiseur. Cela entraînait une duplication de code et le risque de recréer accidentellement l'objet.

import SwiftUI

class CounterViewModel: ObservableObject {
    @Published var count: Int = 0
    
    func increment() {
        count += 1
    }
}

struct CounterView: View {
    @StateObject var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment", action: viewModel.increment)
        }
    }
}

Comment fonctionne @StateObject

Le mécanisme de @StateObject est basé sur l'intégration de SwiftUI avec le framework Combine. Lorsqu'un ObservableObject marque ses propriétés avec l'attribut @Published, SwiftUI s'abonne automatiquement aux changements via le publisher intégré au protocole ObservableObject. Lorsqu'une propriété publiée change, l'objet envoie un signal via le publisher objectWillChange, ce qui déclenche un redessin de toutes les Views qui observent cet objet.

SwiftUI stocke l'instance d'ObservableObject dans un stockage spécial lié à une instance spécifique de View. Ce stockage est créé une fois lors du premier rendu et existe jusqu'à ce que la View soit détruite. C'est pourquoi @StateObject garantit la stabilité de la référence — SwiftUI gère la mémoire automatiquement, sans dépendre de l'initialiseur de la View.

Selon objc.io — Thinking in SwiftUI (2025), l'implémentation interne de @StateObject utilise un mécanisme similaire à @State mais pour les types référence : SwiftUI crée une enveloppe (boxing) autour de l'objet et gère son cycle de vie via son propre allocateur, optimisé pour les reconstructions fréquentes de la hiérarchie des Views.

Cycle de vie de @StateObject

• Création — lorsque la View apparaît pour la première fois à l'écran, SwiftUI appelle l'initialiseur de l'objet et stocke la référence.
• Reconstruction — lorsque la View parente est mise à jour, l'objet n'est pas recréé ; l'instance existante est utilisée.
• Destruction — lorsque la View quitte l'écran et est supprimée de la hiérarchie, SwiftUI appelle le deinit de l'objet.

@StateObject vs @ObservedObject : différences clés

La principale différence entre @StateObject et @ObservedObject réside dans la propriété de l'objet. @StateObject crée et stocke l'objet — il en est le propriétaire. @ObservedObject observe seulement l'objet qui a été créé ailleurs et passé via l'initialiseur ou une propriété.

La règle est simple : si la View crée l'ObservableObject — utilisez @StateObject. Si la View reçoit seulement un objet déjà créé du parent — utilisez @ObservedObject. Violer cette règle entraîne soit une perte de données (si @ObservedObject est utilisé pour la propriété), soit une création excessive d'objets (si @StateObject est utilisé pour l'observation).

Quand utiliser @StateObject

@StateObject doit être utilisé dans les Views qui sont la source de vérité pour un ensemble spécifique de données. Les scénarios typiques incluent les écrans avec leur propre view model, les écrans racines des piles de navigation et les présentations modales gérant leur propre état.

• Écran avec view model — chaque écran qui gère ses propres données et logique doit créer son view model via @StateObject.
• View racine — dans une hiérarchie NavigationStack ou TabView, l'élément racine crée les données, et les éléments enfants les reçoivent via @ObservedObject.
• Fenêtres modales — .sheet et .fullScreenCover nécessitent souvent leur propre @StateObject pour gérer un formulaire ou un processus.
• Liste modifiable — chaque ligne de liste contenant un formulaire d'édition doit avoir son propre @StateObject.

struct ProfileView: View {
    @StateObject var viewModel = ProfileViewModel()
    
    var body: some View {
        NavigationStack {
            Form {
                TextField("Name", text: $viewModel.name)
                TextField("Email", text: $viewModel.email)
                Button("Save") {
                    viewModel.saveProfile()
                }
            }
            .navigationTitle("Profile")
        }
    }
}

Initialiser @StateObject avec des paramètres

Initialiser @StateObject avec des paramètres nécessite une syntaxe spéciale, car SwiftUI gère lui-même la création de l'objet. Vous ne pouvez pas simplement passer des paramètres à l'initialiseur — vous devez utiliser une closure échappée ou une méthode d'usine séparée.

Selon Swift by Sundell (2024), l'approche la plus propre est d'utiliser une méthode d'usine ou une closure que SwiftUI appellera lors de la première création de l'objet. Une approche alternative consiste à initialiser l'ObservableObject dans la View parente et à le passer via @StateObject en utilisant l'initialiseur standard.

class UserViewModel: ObservableObject {
    @Published var user: User
    
    init(user: User) {
        self.user = user
    }
}

struct UserDetailView: View {
    @StateObject var viewModel: UserViewModel
    
    init(user: User) {
        _viewModel = StateObject(wrappedValue: UserViewModel(user: user))
    }
    
    var body: some View {
        Text(viewModel.user.name)
    }
}

Il est important de se rappeler que l'initialiseur de View avec @StateObject doit utiliser un underscore avant le nom de la propriété (_viewModel) pour accéder au property wrapper lui-même, et non à sa valeur. C'est un modèle Swift standard pour travailler avec les property wrappers dans les initialiseurs.

Erreurs courantes avec @StateObject

L'erreur la plus courante est d'utiliser @ObservedObject au lieu de @StateObject pour une View qui devrait posséder l'objet. Dans ce cas, chaque fois que le parent est reconstruit, l'objet sera recréé, entraînant la perte de toutes les données accumulées. Cette erreur est particulièrement insidieuse dans les hiérarchies complexes avec NavigationStack ou TabView.

• Perte de données lors de la navigation — si un écran enfant utilise @ObservedObject pour son propre view model, les données seront réinitialisées lors du retour en arrière et de la réouverture.
• Fuite de mémoire — créer @StateObject dans une View parente qui n'est jamais supprimée peut entraîner une accumulation d'objets si chaque écran enfant crée également @StateObject sans contrôle.
• Duplication d'objets — passer un seul ObservableObject à plusieurs @StateObject dans différentes Views crée plusieurs instances indépendantes qui ne se synchronisent pas entre elles.

Pour éviter ces problèmes, suivez une règle simple : un @StateObject par source de vérité. Si les données doivent être partagées entre plusieurs écrans — créez @StateObject une fois dans la View racine et passez-le via @ObservedObject ou @EnvironmentObject aux éléments enfants.

// ❌ Wrong: @ObservedObject for owning an object
struct BadView: View {
    @ObservedObject var vm = ViewModel() // will be recreated on each update!
}

// ✅ Correct: @StateObject for owning
struct GoodView: View {
    @StateObject var vm = ViewModel() // created once for View lifetime
}