Comprendre Core Data et SwiftData en Swift : stocker des données simplement sur iOS

Comprendre Core Data et SwiftData en Swift : comment les apps iOS stockent leurs données

Quand tu utilises une application iPhone, tu t’attends à ce que certaines choses restent :

tes notes,
tes favoris,
ton profil,
tes paramètres,
ton historique.

Ce n’est pas “magique” : l’app doit enregistrer ces informations quelque part dans le téléphone. Sur iOS, deux technologies principales sont utilisées pour cela côté Apple : Core Data (la plus ancienne) et SwiftData (la nouvelle, pensée pour SwiftUI).

Ce guide t’explique, sans jargon technique :

à quoi servent Core Data et SwiftData,
comment ils s’intègrent dans une app,
leurs forces et leurs faiblesses,
comment ça se traduit dans le code (sans entrer dans les détails compliqués).

1. Le problème à résoudre : garder des données sur l’appareil

Une app a besoin de deux grands types de données :

Les données distantes : venant d’un serveur (ex : ton fil Instagram).
Les données locales : stockées directement sur le téléphone (ex : notes hors-ligne).

Core Data et SwiftData servent à gérer ces données locales :

les sauvegarder,
les retrouver,
les modifier,
les supprimer.

On peut les comparer à une petite base de données embarquée dans l’app.

2. Core Data : la solution historique d’Apple

Core Data existe depuis longtemps sur iOS et macOS. C’est un framework (ensemble d’outils) fourni par Apple pour :

modéliser des objets (Notes, Utilisateur, Tâche...),
les stocker sur le disque,
les retrouver facilement avec des requêtes (chercher une note par titre par exemple).

2.1 Comment penser Core Data sans technique

Imagine un carnet structuré dans lequel :

tu décides des types d’objets (Contacts, Notes, Tâches),
tu définis les champs (pour une Note : titre, contenu, date, etc.),
tu peux ensuite créer, modifier, supprimer des entrées.

Core Data te permet de définir ce “modèle” et ensuite de manipuler les données en suivant ce modèle.

2.2 Exemple concret de modèle Core Data (conceptuel)

Prenons une app de notes. Avec Core Data, on définit une entité Note avec :

title : texte (le titre de la note)
content : texte (le contenu)
createdAt : date (la date de création)

Derrière, Core Data générera du code pour représenter ces Notes dans l’app.

2.3 Exemple simple (code illustratif, sans entrer dans la configuration)


// Modèle Core Data généré (version simplifiée)
class Note: NSManagedObject {
    @NSManaged var title: String
    @NSManaged var content: String
    @NSManaged var createdAt: Date
}

Pour créer une note, le développeur doit :

récupérer un contexte Core Data (un objet spécial),
créer une Note,
remplir ses champs,
enregistrer (save) le contexte.

Tout cela fonctionne très bien, mais demande pas mal de “plomberie” (code répétitif).

2.4 Forces de Core Data

Très mature : utilisé depuis des années dans des milliers d’apps.
Optimisé : gère bien de grandes quantités de données.
Intégré dans l’écosystème Apple : fonctionne avec UIKit, AppKit, etc.

2.5 Faiblesses de Core Data

Syntaxe parfois verbeuse et technique.
Intégration moins naturelle avec SwiftUI.
Beaucoup de choses à configurer (modèles, contextes, etc.).

C’est pour simplifier tout ça qu’Apple a introduit SwiftData.

3. SwiftData : la version moderne et “SwiftUI-friendly”

SwiftData est une nouvelle API introduite par Apple pour simplifier le stockage de données en Swift, en particulier avec SwiftUI.

L’idée : “Et si on utilisait simplement des structs/classes Swift modernes pour représenter les données, et qu’on les stockait automatiquement ?”

3.1 Modèles déclarés en Swift pur

Avec SwiftData, on déclare nos modèles avec le langage Swift lui-même, en utilisant des annotations comme @Model.

Exemple de modèle “Note” en SwiftData :


import SwiftData

@Model
class Note {
    var title: String
    var content: String
    var createdAt: Date

    init(title: String, content: String, createdAt: Date = .now) {
        self.title = title
        this.content = content
        self.createdAt = createdAt
    }
}

Ce qu’on voit :

La classe Note est une classe Swift “normale”.
L’annotation @Model indique à SwiftData qu’elle doit être persistée (stockée).
Pas besoin d’interface graphique séparée pour le modèle (comme avec Core Data).

3.2 Intégration directe avec SwiftUI

SwiftData fournit des mécanismes très simples pour :

récupérer une “base” (modelContainer),
faire des requêtes depuis une vue SwiftUI,
réagir automatiquement aux changements de données.

Exemple d’écran SwiftUI affichant une liste de notes :


import SwiftUI
import SwiftData

struct NotesListView: View {

    @Environment(\.modelContext) private var context

    @Query(sort: \Note.createdAt, order: .reverse)
    private var notes: [Note]

    var body: some View {
        NavigationView {
            List {
                ForEach(notes) { note in
                    VStack(alignment: .leading) {
                        Text(note.title)
                            .font(.headline)
                        Text(note.content)
                            .font(.subheadline)
                            .lineLimit(2)
                    }
                }
            }
            .navigationTitle("Mes notes")
            .toolbar {
                Button(action: addSampleNote) {
                    Image(systemName: "plus")
                }
            }
        }
    }

    private func addSampleNote() {
        let newNote = Note(title: "Nouvelle note", content: "Contenu de test")
        context.insert(newNote)
        try? context.save()
    }
}

Même si tu ne lis pas le code dans le détail, tu peux comprendre la logique :

@Query récupère la liste des Note depuis SwiftData.
List affiche ces notes.
Le bouton “+” crée une nouvelle note et l’enregistre.

SwiftData se charge de synchroniser automatiquement les données et la vue.

4. Comparer Core Data et SwiftData sans jargon

4.1 Analogie simple

On peut voir :

Core Data comme un système puissant, mais un peu ancien, qui demande plus de réglages manuels.
SwiftData comme sa version moderne, pensée pour le langage Swift d’aujourd’hui et pour SwiftUI.

4.2 Tableau comparatif (conceptuel)

Définition des modèles :
- Core Data : via un éditeur de modèle (fichier .xcdatamodel), génération de classes, etc.
- SwiftData : via des classes/structs Swift annotées avec @Model.
Intégration UI :
- Core Data : intégré historiquement avec UIKit ; utilisable avec SwiftUI mais moins fluide.
- SwiftData : intégré nativement avec SwiftUI (@Query, @Environment(\.modelContext)).
Simplicité :
- Core Data : plus de concepts, plus de “plomberie”.
- SwiftData : approche plus directe, proche du code Swift normal.
Maturité :
- Core Data : très mature, très éprouvé.
- SwiftData : plus récent, en évolution.

5. Scénarios concrets : quand utiliser quoi ?

5.1 App existante en UIKit / Obj-C

Si l’app est ancienne, utilise UIKit, et peut-être du code Objective-C, il est logique de rester sur Core Data, déjà largement utilisé et documenté.

5.2 Nouvelle app SwiftUI moderne

Si tu démarres une nouvelle app en SwiftUI, avec une base de code moderne, SwiftData est un excellent choix : moins de configuration, plus de lisibilité.

5.3 Projet qui doit tourner sur des OS plus anciens

SwiftData étant plus récent, si tu dois supporter des versions d’iOS anciennes, Core Data reste parfois nécessaire.

6. Comment cela se connecte au reste de l’architecture

Dans une architecture d’app bien structurée (MVVM, MVI, Clean Architecture…), Core Data ou SwiftData se situent plutôt dans la couche “données” :

la couche “Data” sait comment parler à Core Data / SwiftData et au serveur,
la couche “Domaine / Logique” formule des besoins (“donne-moi toutes les notes récentes”),
la “Vue” affiche ce qui lui est fourni, sans savoir comment c’est stocké.

Pour un non technique, l’idée importante est :

Core Data / SwiftData = la mémoire structurée locale de l’app,
on peut la combiner avec des architectures modernes pour garder un code clair et fiable.

7. Forces et faiblesses globales

7.1 Core Data

Forces :

Très utilisé, très documenté.
Optimisé pour des données complexes, relations, etc.
Fonctionne sur de nombreux OS Apple et versions.

Faiblesses :

Courbe d’apprentissage plus raide.
Intégration SwiftUI moins naturelle.
Configuration parfois verbeuse (modèles, contextes, etc.).

7.2 SwiftData