La performance de SwiftData est un problème de stockage

Le group lab SwiftData de la WWDC 2026 était animé par les personnes qui possèdent les couches situées sous le framework, dont l’ingénieur qui maintient SQLite sur les plateformes d’Apple et le responsable de Core Data et de SwiftData. Le fil conducteur de leurs réponses était une correction utile à la façon dont la plupart des développeurs abordent la performance : une fois que SwiftData est dans votre application, la chose coûteuse est l’I/O, pas votre code Swift, et les gains viennent du fait de lire moins et de comprendre le moteur de stockage plutôt que d’ajouter de la concurrence. L’essentiel de ce qui suit s’appuie sur la documentation d’Apple et celle de SQLite ; lorsqu’une affirmation relève du raisonnement d’ingénierie du lab plutôt que d’un fait documenté, elle est signalée comme telle.

Le SwiftData Group Lab de la WWDC 2026.

En bref

• Le store SQLite de SwiftData utilise le write-ahead logging (WAL) par défaut, ce qui signifie que plusieurs lecteurs s’exécutent en concurrence avec un unique rédacteur. Ce n’est pas un verrou lecteur/rédacteur, une distinction que les développeurs se trompent régulièrement, selon le lab.²³
• Lire sans matérialiser les objets : fetchCount(_:) renvoie un nombre de correspondances et fetchIdentifiers(_:) renvoie [PersistentIdentifier], l’un et l’autre sans hydrater les modèles. Associez-les à l’observation de l’historique pour décider si un rafraîchissement est même nécessaire.⁴⁵
• Les objets @Model ne sont pas Sendable et il ne faut pas les y forcer. Pour franchir une frontière d’acteur, transmettez le PersistentIdentifier (qui est Sendable) ainsi que les valeurs extraites, puis refaites la récupération sur le contexte de destination.⁶
• SwiftData n’a aucun équivalent aux requêtes d’agrégation poussées en SQL de Core Data (sum, average, min, max). La porte de sortie est la coexistence : faites tourner une stack Core Data sur le même fichier de store et laissez-la calculer l’agrégat.⁸
• Le message de performance du lab : profilez pour découvrir pourquoi SwiftUI a refait une récupération avant de supposer que la base de données est lente, car une sur-invalidation des vues ressemble à un problème d’I/O alors qu’elle n’en est pas un.¹¹⁰

WAL : lecteurs concurrents, un seul rédacteur, pas un verrou

La correction la plus utile du lab concerne la concurrence au niveau de la couche de stockage. SwiftData repose sur le store SQLite de Core Data, et ce store utilise par défaut le write-ahead logging depuis iOS 7.³ Sous WAL, comme le formule la documentation de SQLite, « WAL provides more concurrency as readers do not block writers and a writer does not block readers. Reading and writing can proceed concurrently. »² Il y a toujours exactement un rédacteur à la fois, mais le modèle mental d’un mutex qui sérialise tous les accès à la base de données est faux : vos lectures n’ont pas à attendre derrière l’écriture.

Le cadrage du lab, paraphrasé depuis l’enregistrement, était que les gens traitent la règle de l’unique rédacteur comme un verrou lecteur/rédacteur et conçoivent leur architecture autour d’une contrainte qui n’existe pas.¹ Le modèle exact est celui du WAL : concevoir pour de nombreuses lectures concurrentes et une écriture sérialisée, pas pour une exclusion globale.

Lire moins : compter et identifier sans hydrater

Si l’I/O est le coût, le geste à plus fort levier consiste à cesser de charger les objets dont vous n’avez pas besoin. SwiftData offre deux primitives pour cela, toutes deux vérifiées dans l’API :

fetchCount(_:) sur ModelContext prend un FetchDescriptor et renvoie le nombre de modèles correspondants sous forme d’Int sans en instancier aucun.⁴ Lorsque vous avez besoin d’un compte pour un badge ou un en-tête de section, c’est strictement moins coûteux que de récupérer les objets et d’appeler .count.

fetchIdentifiers(_:) renvoie [PersistentIdentifier] pour un descripteur, là encore sans matérialiser les modèles, et une surcharge fetchIdentifiers(_:batchSize:) traite le travail par lots.⁵ L’usage suggéré par le lab, paraphrasé, l’associe à l’observation de l’historique : lorsqu’un changement survient, récupérez les identifiants concernés et comparez-les à ce que votre vue affiche réellement avant de décider de recharger quoi que ce soit.¹ Les API d’historique et d’observation elles-mêmes sont traitées dans Observation et historique de SwiftData sous iOS 27 ; fetchIdentifiers est la lecture légère qui les rend efficaces. Le type d’observation à privilégier en dehors de SwiftUI est ResultsObserver, l’observateur fondé sur Swift Observation introduit pour les versions 2027, qui prend en charge les mêmes primitives que @Query, dont le sectionnement par key-path via sectionBy:.⁹

La frontière Sendable est réelle, et le graphe de modèles ne la franchit pas

Les modèles SwiftData sont des types référence câblés dans un graphe à l’intérieur de leur contexte, et ils ne sont pas Sendable. Le lab a été catégorique sur le fait qu’on ne peut pas raisonnablement les y forcer, car le graphe n’est pas thread-safe et l’hydrater partiellement sur un autre acteur mène à des ennuis.¹ Le pattern pris en charge utilise PersistentIdentifier, qui est Sendable, Hashable et Codable, comme identité que vous déplacez à travers les frontières.⁶ Extrayez les valeurs dont vous avez besoin dans une struct, attachez le PersistentIdentifier, transmettez-le à l’autre acteur, puis refaites la récupération du modèle sur le contexte de destination si vous avez besoin de l’objet vivant.

Une précision à conserver : Apple note qu’un PersistentIdentifier décodé et un identifiant créé par le store par défaut ne sont pas toujours considérés comme équivalents ; traitez donc l’identifiant comme un handle stable inter-contexte plutôt que de supposer qu’une copie décodée équivaut à un objet vivant.⁶

La même discipline « identité, pas graphe » se retrouve entre processus. Lorsque vous déplacez un store dans un app group pour le partager avec un widget ou une extension, la configuration par défaut copie pour vous le store existant dans le conteneur de l’app group ; avec une URL de store personnalisée, vous gérez vous-même l’emplacement.⁷ Dans les deux cas, les processus se coordonnent via le store et ses identifiants, et non en se transmettant des objets vivants.

Le déficit d’agrégation, et la porte de sortie Core Data

Une vraie limite nommée par le lab : SwiftData n’a aucun équivalent aux requêtes d’agrégation fondées sur NSExpression de Core Data, celles qui poussent sum, average, min et max dans SQLite afin que la base de données les calcule sans charger de lignes.⁸ Dans SwiftData, il faudrait récupérer les lignes et les réduire en mémoire, ce qui anéantit l’intérêt sur une grande table. Pour min ou max, vous pouvez récupérer avec un descripteur de tri et une limite de récupération à un ; pour de véritables agrégats, le lab a pointé vers la coexistence.

La coexistence, telle qu’Apple l’a cadrée à la WWDC 2023, ce sont « two completely separate persistent stacks, one Core Data stack and one SwiftData stack, talking to the same persistent store. »⁸ Les deux stacks pointent vers la même URL de store, et comme SwiftData active automatiquement le suivi de l’historique persistant, le côté Core Data doit lui aussi activer NSPersistentHistoryTrackingKey, sans quoi le store s’ouvre en lecture seule.⁸ Une fois cela en place, vous pouvez exécuter l’agrégat poussé en SQL via Core Data contre le fichier même que possède SwiftData. C’est davantage de machinerie que la plupart des applications n’en ont besoin, mais c’est le chemin documenté lorsque vous avez réellement besoin d’une agrégation côté base de données.

Profilez l’invalidation, pas seulement la base de données

Le conseil de performance le plus pratique du lab, paraphrasé, était que le coût d’I/O apparent d’une application SwiftData est souvent un problème d’invalidation SwiftUI déguisé : une vue qui s’invalide trop souvent refait des récupérations, et un profileur affiche ces récupérations comme du temps de base de données alors que la vraie faute est que la vue n’aurait pas dû se rafraîchir du tout.¹ Le correctif est la même discipline d’isolation des vues qui aide tout problème de performance SwiftUI, traitée dans Performance et interopérabilité SwiftUI : découpez les grandes vues en plus petites, dotées de dépendances plus étroites, et transmettez vers le bas les modèles déjà récupérés afin que la requête ne se relance pas.

L’outillage soutient cette lecture. Instruments fournit un template SwiftUI qui regroupe l’instrument SwiftUI aux côtés des instruments Hangs et Hitches, un template File Activity dont l’instrument Reads and Writes montre le trafic disque réel (sur appareil uniquement, pas le simulateur), et le template Core Data avec son instrument Data Persistence qui rapporte les faults, les fetches et les saves.¹⁰ Faire tourner ensemble les vues SwiftUI et persistance vous indique si une récupération était une vraie lecture ou une lecture redondante déclenchée par une sur-invalidation.

Une mise en garde soulevée par le lab à propos du benchmarking, paraphrasée : il y a des caches à tous les niveaux, le cache de pages de SQLite, le cache de fichiers de l’OS et le contrôleur de stockage, de sorte qu’une exécution « rapide » peut être un cache hit plutôt qu’une amélioration réelle. Mesurez face à un jeu de données réalistement grand et utilisez l’instrument File Activity pour confirmer qu’une I/O réelle a bien eu lieu.¹

À propos de l’ajout de concurrence

L’opinion la plus tranchée du lab, et la partie à traiter comme du raisonnement d’ingénierie plutôt que comme un fait documenté, était une mise en garde contre le réflexe de recourir à la concurrence comme correctif de performance. Les ingénieurs ont décrit le connection pooling de SwiftData comme délibérément borné et ont soutenu qu’au-delà d’un petit nombre d’opérations concurrentes vous atteignez le plafond du matériel de stockage, de sorte que davantage de contextes offre des rendements décroissants au prix de plus de mémoire et de plus d’I/O.¹ Apple ne documente aucune limite de concurrence précise ; ne retenez donc de chiffre ferme de personne, y compris de ce billet. La conclusion défendable est directionnelle : sur un appareil à stockage flash, accumuler des rédacteurs concurrents n’est pas un moyen fiable d’aller plus vite, et le modèle WAL vous offre déjà gratuitement des lectures concurrentes.

Ce qu’il faut en retenir

Le lab recadre la performance de SwiftData autour du moteur de stockage. Les leviers vérifiés sont concrets : appuyez-vous sur les lectures concurrentes du WAL au lieu de craindre un verrou, utilisez fetchCount et fetchIdentifiers pour éviter d’hydrater des objets, déplacez PersistentIdentifier entre acteurs plutôt que le graphe de modèles, et recourez à la coexistence Core Data lorsque vous avez besoin d’un vrai agrégat. La discipline de profilage consiste à confirmer qu’un coût d’I/O est réel avant d’optimiser la base de données, car le coupable est souvent une vue qui s’est rafraîchie alors qu’elle n’aurait pas dû.

FAQ

SwiftData verrouille-t-il la base de données pendant les écritures ?

Pas au sens d’un verrou lecteur/rédacteur. Le store utilise le write-ahead logging de SQLite, qui permet à plusieurs lecteurs de s’exécuter en concurrence avec un unique rédacteur ; les lectures ne bloquent pas le rédacteur et le rédacteur ne bloque pas les lectures.²³ Il y a un rédacteur à la fois, mais les lectures progressent à ses côtés.

Comment compter ou vérifier des enregistrements sans les charger ?

Utilisez ModelContext.fetchCount(_:) pour un nombre de correspondances et ModelContext.fetchIdentifiers(_:) pour des valeurs [PersistentIdentifier], ni l’un ni l’autre ne matérialisant les objets modèles.⁴⁵ Combinez fetchIdentifiers avec l’observation de l’historique pour déterminer si un changement affecte réellement ce que votre vue montre avant de recharger.

Comment transmettre un objet SwiftData à un autre acteur ?

Vous ne transmettez pas l’objet. Les types @Model ne sont pas Sendable. Transmettez le PersistentIdentifier (qui est Sendable) ainsi que les valeurs extraites, puis refaites la récupération sur le contexte de destination.⁶ Évitez de faire franchir la frontière au graphe de modèles vivant.

SwiftData peut-il faire sum/average/min/max dans la base de données ?

Non. SwiftData n’a aucun équivalent aux agrégats NSExpression poussés en SQL de Core Data.⁸ Pour min/max, récupérez avec un tri et une limite de récupération à un ; pour de vrais agrégats, faites tourner une stack Core Data contre le même fichier de store (coexistence), ce qui requiert d’aligner l’URL de store et d’activer le suivi de l’historique persistant côté Core Data.⁸

La voie SwiftData de ce blog couvre la discipline de schéma et de migration dans discipline de schéma et le guide des migrations, et les API d’observation et d’historique d’iOS 27 dans observation et historique. Ce billet ajoute la couche de performance et de stockage. Le hub complet de la série est la série Apple Ecosystem.

References