SwiftData : En savoir plus sur l’héritage et la migration des schémas

Bonjour, je suis Rishi Verma, ingénieur au sein de l’équipe SwiftData. Je vous souhaite la bienvenue dans « SwiftData: Dive into inheritance and schema migration ». SwiftData a été introduit dans iOS 17 et permet de modéliser et de conserver les données de l’app en Swift sur toutes les plates-formes Apple. Il permet d’écrire un code rapide, efficace et sûr en exploitant les fonctionnalités modernes du langage Swift. Cette vidéo continue avec une introduction à l’héritage de classe et explique quand l’héritage est le bon choix. Avec l’adoption de l’héritage et l’évolution du schéma, nous allons aborder les stratégies de migration utilisées pour préserver les données, puis nous verrons plusieurs façons d’adapter les requêtes SwiftData pour une performance optimale. Enfin, nous allons observer les changements apportés aux modèles, localement ou à distance. Depuis quelques versions, nous utilisons une app bien connue, SampleTrips. Il s’agit d’une app développée avec SwiftUI pour suivre tous les voyages que j’ai prévus. Pour utiliser SwiftData avec les modèles de cette app, il suffit d’importer le framework et d’annoter chaque modèle avec la macro Model.

Dans la définition de l’app, nous ajoutons le modificateur modelContainer sur le WindowGroup, ce qui informe toute la hiérarchie des vues du modèle Trip. Avec le modelContainer configuré, je peux maintenant mettre à jour ma vue pour utiliser la macro Query. Supprimons ces données statiques et remplissons plutôt la vue en utilisant la macro Query, qui générera le code pour récupérer les voyages depuis le modelContainer.

C’est tout ! L’app enregistre tous les voyages que je crée et s’intègre parfaitement à mes vues SwiftUI. SwiftData offre une gestion simplifiée de la persistance, mais aussi la modélisation et la migration de votre schéma, la gestion des graphes, la synchronisation avec CloudKit, etc. Dernière nouveauté de SwiftData : la prise en charge de l’héritage de classe. Nouveauté d’iOS 26 : la possibilité de créer un graphe de modèles exploitant l’héritage. L’héritage de classe est un outil puissant. Voyons dans quels cas c’est l’outil le plus adapté. L’héritage est adapté aux modèles hiérarchiques aux caractéristiques communes. Le modèle Trip contient les propriétés destination, startDate et endDate, essentielles pour savoir où et quand partir. Ainsi, toute sous-classe de Trip héritera automatiquement de ces propriétés et des comportements partagés définis dans Trip. Le modèle Trip couvre un vaste domaine. Nous faisons toutes sortes de voyages au cours de notre vie. Une nouvelle sous-classe de Trip doit représenter un sous-domaine naturel du modèle Trip.

Dans notre app SampleTrips, la plupart des voyages relèvent de deux sous-domaines naturels : personnels et professionnels. Avec ces 2 nouveaux modèles exprimant les sous-domaines naturels d’un voyage, je peux ajouter des propriétés et comportements spécifiques à chacun. Pour les voyages personnels, je vais ajouter une énumération indiquant la raison du voyage. Pour les voyages professionnels, je vais ajouter une propriété perdiem pour suivre mes dépenses lors de mon prochain déplacement. Faisons cela dans l’app SampleTrips pour une expérience plus riche. Voici notre classe Trip avec les propriétés à partager avec ses sous-classes. Ajoutons 2 sous-classes à notre app Trips : une pour les voyages professionnels et une pour les voyages personnels. Je dois aussi les annoter avec @available sur iOS 26 pour correspondre à la prise en charge de l’héritage dans SwiftData. Ajoutons maintenant les propriétés spécifiques au sous-domaine à nos sous-classes. Je peux ajouter un perdiem au BusinessTrip et définir sa valeur initiale. Et pour PersonalTrip, on ajoute une énumération Reason pour indiquer la raison du voyage. Ah oui, dernière étape : mettre à jour notre schéma pour inclure les nouvelles sous-classes. Ajoutons BusinessTrip et PersonalTrip au modificateur modelContainer, et c’est parti ! L’app SampleTrips est prête à exploiter les nouveaux voyages personnels en bleu et professionnels en vert, sans code supplémentaire. L’héritage de classe est un outil puissant, mais il ne convient pas à tous les cas. Voyons quand il est pertinent d’utiliser l’héritage.

Dans certains cas, l’héritage est la solution idéale. Si vos modèles reflètent naturellement une hiérarchie avec des caractéristiques communes à étendre, l’héritage peut être un bon choix, car vos types forment alors une relation de type « est un ».

En utilisant des modèles hérités, on sait qu’un voyage personnel est un Trip. Ainsi, lorsqu’on travaille avec le type Trip, comme dans la requête affichée ici, on peut s’attendre à retrouver tous les types de voyages : personnels, professionnels, ou de la classe Trip elle-même. Nos voyages sont représentés par des avions, avec les mêmes couleurs que notre UI, qui volent du modelContainer vers le modelContext à l’origine de la requête. Cependant, l’héritage ne doit pas être exploité pour partager des caractéristiques communes entre les modèles. Si l’on créait une sous-classe pour tous les modèles ayant une propriété name, on aurait une hiérarchie contenant de nombreux sous-domaines ne partageant qu’une seule propriété, tandis que toutes les autres caractéristiques resteraient propres à chaque sous-domaine. Comme ces sous-domaines ne forment pas une hiérarchie naturelle, il vaut mieux les représenter par une conformité à un protocole. La conformité à un protocole permet à des domaines distincts de partager des comportements sans caractéristiques superflues. L’héritage peut aussi être utile selon la façon dont vous interrogez ou récupérez vos modèles.

Il y a plusieurs façons d’interroger des données, ici on utilise la macro Query pour récupérer tous les voyages depuis le modelContainer et alimenter nos vues. C’est un exemple de recherche en profondeur.

Si l’on utilise uniquement des recherches en profondeur, en ne récupérant que des objets de type Trip, il vaut mieux représenter PersonalTrip ou BusinessTrip comme une propriété de Trip plutôt que comme une sous-classe. Mais, si vos requêtes ciblent uniquement les types de sous-classes finales, on parle alors de recherche en surface. Il est alors préférable d’aplatir nos modèles, puisque le type Trip n’est jamais interrogé ni utilisé directement. Si vous combinez recherches en profondeur et en surface, l’héritage est utile pour afficher tous les voyages ou un sous-type comme PersonalTrips selon le contexte. Voyons comment mettre à jour notre app Trips pour n’afficher que les voyages personnels ou professionnels.

Utilisons un contrôle segmenté pour afficher tous les voyages ou filtrer par sous-classe.

Le segment sélectionné permet de définir un prédicat qui filtre les types via le mot-clé « is ». Par exemple, ici je vérifie s’il s’agit d’un PersonalTrip. On fournit ensuite le prédicat et on trie par startDate pour initialiser notre Query. Voyons le résultat dans l’app. On commence par la vue des voyages qui affiche tous mes Trips. Je peux ensuite filtrer l’affichage par sous-classe spécifique. Trop fort ! Voilà comment tirer parti de l’héritage de classe dans iOS 26. Mais, je n’ai pas encore terminé. Nous avons apporté des modifications importantes à notre schéma, il faut donc réfléchir à leurs conséquences pour l’app et à la manière de migrer nos données. L’app SampleTrips a connu plusieurs évolutions au cours des dernières versions. Prenons un moment pour créer des schémas versionnés et un plan de migration, pour que l’app conserve les données de l’utilisateur lors de la mise à jour de SampleTrips.

Tout a commencé dans notre première vidéo avec SwiftData sur iOS 17, illustré par l’exemple des voyages. Dans ces vidéos d’introduction, nous avons appris à rendre le nom d’un voyage unique et à renommer une propriété pour conserver les données lors d’une migration.

Pour iOS 17, nous avons créé un schéma versionné en 2.0, avec un modèle Trip modifié : nom unique et dates de début et de fin renommées.

Puis, nous avons ajouté une étape de migration personnalisée pour dédupliquer les voyages existants. Ici, nous avons utilisé la fonction fetch de ModelContext pour récupérer tous les voyages et les dédupliquer.

Dans iOS 18, nous avons utilisé les macros index et unique, tout en indiquant quelles propriétés conserver lors d’une suppression.

Cela nous permet d’identifier nos modèles après leur suppression du magasin de données.

Dans notre schéma versionné pour iOS 18, on le marque en version 3 et on y consigne les modifications du modèle Trip. Nouvelle utilisation des macros unique et index pour garantir la déduplication des données et optimiser les recherches et requêtes. Nous avons aussi annoté ces propriétés avec preserved value on deletion pour pouvoir identifier un voyage supprimé lors de l’utilisation de l’historique persistant.

Nous avons aussi ajouté une étape de migration personnalisée pour dédupliquer les voyages entre les versions 2 et 3. Dans iOS 26, nous ajoutons la version 4 avec des sous-classes et une étape de migration légère. Dans notre schéma actuel, on le marque en version 4 et on y inclut tous les modèles, y compris les nouvelles sous-classes. Et puisque nos sous-classes sont annotées pour iOS 26 ou version ultérieure, notre schéma de version l’est aussi. Nous devons ajouter une étape de migration légère de la version 3 à la version 4, avec la même disponibilité qu’auparavant. Une fois notre dernier schéma de version et l’étape de migration définis, nous pouvons les regrouper dans un plan de migration, qui précise l’ordre des versions et des étapes à exécuter. Le plan de migration du schéma consiste en un tableau de schémas listés dans l’ordre de leur publication. Lorsque iOS 26 est disponible, on ajoute le nouveau schéma avec les sous-classes, ainsi qu’un tableau d’étapes de migration permettant de passer d’une version à l’autre. Et voilà comment construire un plan de migration de schéma. Maintenant que notre schéma de version et son plan de migration sont prêts, l’étape suivante consiste à les utiliser lors de la création du modelContainer pour SampleTrips. Revenons à notre modificateur modelContainer et mettons-le à jour pour qu’il utilise un conteneur avec un plan de migration de schéma. On commence par ajouter une nouvelle propriété container à l’app, dans laquelle on construit notre schéma versionné (version 4) et on fournit le plan de migration à l’initialiseur de ModelContainer. On met à jour le modelContainer pour utiliser ce nouveau conteneur compatible avec la migration. Ainsi, les mises à jour de SampleTrips tirant parti de l’héritage peuvent migrer facilement à travers les versions précédentes, tout en préservant les données utilisateur. Maintenant que la migration est en place, il est temps d’optimiser les requêtes et récupérations utilisées pour alimenter nos vues et étapes de migration. Nous avons mis à jour la requête avec le segment choisi via un prédicat. Mais dans une autre vidéo, nous avions aussi une barre de recherche. Réintégrons-la et passons directement à la gestion du texte saisi par l’utilisateur.

Nous commençons par construire un prédicat avec le searchText fourni. On commence par vérifier si le texte est vide. Sinon, on crée un prédicat composé pour vérifier si le nom ou la destination du voyage contient le texte saisi. Puis, nous construisons un prédicat composé avec le prédicat de recherche et le prédicat de classe. Enfin, on met à jour l’initialiseur de notre Query pour utiliser le nouveau prédicat composé. Avec cette mise à jour, je peux utiliser la barre de recherche pour filtrer les voyages, puis affiner encore avec le contrôle segmenté. Le filtrage et le tri ne sont que quelques moyens de personnaliser les requêtes et récupérations. Voyons d’autres façons de personnaliser les extractions SwiftData. Voici notre étape de migration personnalisée de la version 1 à la 2. Nous allons utiliser le bloc willMigrate pour récupérer tous les Trips. Cependant, dans ma logique de déduplication, je n’accède qu’à une seule propriété : name, car c’est la propriété unique en version 2, utilisée pour éviter les doublons. Puisque name est la seule propriété utilisée, je peux mettre à jour le fetchDescriptor avec propertiesToFetch pour ne récupérer que name, ce qui évite de charger inutilement d’autres données lors de la migration. De plus, si l’on sait qu’une relation sera parcourue, ici, je prévois de réassigner un hébergement en cas de doublon, on peut aussi optimiser en utilisant relationshipsToPrefetch. Ajoutons ici la relation livingAccommodation.

Maintenant que nous utilisons le préchargement des propriétés, nous pouvons optimiser le code du widget existant dans SampleTrips pour le rendre plus performant. Dans le widget SampleTrips, une requête récupère le voyage le plus récent. Mais on peut l’optimiser pour ne récupérer qu’une seule valeur. Actuellement, le widget utilise uniquement le 1er résultat de la récupération. On peut rendre cela plus efficace en définissant une fetch limit.

En définissant une fetch limit, le widget récupère uniquement le premier voyage correspondant au prédicat, sans se soucier d’un grand nombre de vacances planifiées. Maintenant que nos requêtes et récupérations sont optimisées, voyons comment savoir quand le modèle a changé. Tous les modèles persistants sont Observable, ce qui permet d’utiliser withObservationTracking pour réagir aux modifications des propriétés qui nous intéressent. Pour observer les changements des dates de début et de fin d’un voyage, on peut ajouter une fonction datesChangedAlert qui déclenche une alerte lorsque l’utilisateur modifie ces dates.

On peut observer de nombreuses modifications locales apportées à nos PersistentModels, ce qui est très utile pour suivre les changements effectués en local. Pour en savoir plus sur les nouveautés d’Observable, regardez « What’s New in Swift ». Seules les modifications effectuées sur vos modèles dans le processus en cours sont Observable. Celles provenant d’un autre processus (comme un widget, une extension ou un autre modelContainer de votre app) ne le sont pas. Les modifications locales ou internes à l’app surviennent lorsque plusieurs modelContext partagent le même modelContainer. Ces modelContext détectent mutuellement leurs modifications, et les Query les appliquent automatiquement. En revanche, si vous utilisez les API de récupération (fetch) du modelContext, les modifications d’un autre modelContext ne seront visibles qu’après un nouveau fetch.

Une action externe peut aussi modifier vos données : un widget qui enregistre des infos ou une autre app écrivant dans le conteneur partagé de votre App Group. Ces modifications mettront automatiquement à jour la vue alimentée par la Query. Mais, les récupérations manuelles devront être relancées pour voir les changements. Une récupération peut être coûteuse, surtout si rien d’important pour le traitement du modèle n’a changé.

Heureusement, SwiftData conserve un historique des modifications. On peut savoir quels modèles ont été modifiés, quand, par qui, et même quelles propriétés ont été mises à jour. Nous utilisons aussi preservedValueOnDeletion sur plusieurs propriétés de Trip, ce qui permet à l’historique de conserver une trace lors d’une suppression, afin d’identifier le voyage supprimé. Pour en savoir plus, regardez « Track Model Changes with SwiftData History » de la WWDC24.

Utilisons l’historique persistant pour savoir si un nouveau fetch est nécessaire. La première étape consiste à récupérer le dernier jeton d’historique du conteneur. Il sert de repère indiquant jusqu’où nous avons lu la base de données pour la dernière fois. Comme un marque-page indiquant où nous nous sommes arrêtés dans notre livre préféré. On lance une récupération avec un descripteur pour la transaction d’historique par défaut. Cependant, si l’historique persistant est volumineux, on risque de récupérer beaucoup de données juste pour obtenir le dernier jeton. iOS 26 apporte une nouveauté : la possibilité de récupérer l’historique en le triant avec sortBy. Nous pouvons spécifier n’importe quelle propriété de la transaction, comme author ou transactionIdentifier, pour trier le résultat de l’historique. Adoptons le nouveau tri en utilisant transactionIdentifier en ordre inverse, pour obtenir les transactions les plus récentes en 1er. Ensuite, comme seule la 1ère transaction (la plus récente) nous intéresse, limitons le résultat à 1. C’est tout ce qu’il faut pour récupérer efficacement le dernier jeton d’historique et le stocker. Gardons ce jeton pour plus tard, pour de prochaines récupérations d’historique. Désormais, à chaque changement, par exemple, une mise à jour par le widget, une entrée s’ajoute à l’historique. L’app vérifie alors si des modifications depuis le dernier jeton sont pertinentes. Avec un jeton stocké, nous pouvons créer un prédicat pour récupérer uniquement l’historique postérieur à ce jeton. Pour ne récupérer que les changements pertinents, on définit les entités dont on veut suivre les modifications. Ici, on souhaite uniquement savoir si un voyage ou son hébergement a été modifié, par exemple si le widget a confirmé notre lieu de séjour. On utilise les noms des entités dans le prédicat de changements pour filtrer l’historique selon les types souhaités. Enfin, en combinant le prédicat du jeton et celui des changements, on crée un prédicat composé. Ainsi, lors de la récupération de l’historique, on obtient uniquement les entrées postérieures à notre jeton et concernant les entités qui nous intéressent. Avec une récupération d’historique optimisée, on peut éviter un nouveau fetch s’il n’y a pas de changements pertinents. Heureusement, l’historique de SwiftData facilite cette tâche. Ainsi, nous savons comment observer les modifications locales et distantes de nos modèles et données. J’espère que cette vidéo vous aidera à exploiter SwiftData pour vos besoins de persistance. En construisant votre graphe de modèles, pensez à l’héritage et à ses impacts sur la migration au fur et à mesure de son évolution. Pour récupérer vos données, créez des récupérateurs et des requêtes plus riches et performants. Savoir quand vos données changent est précieux. L’observation et l’historique persistant vous facilitent la tâche. C’est tout pour moi. Je vous souhaite un excellent voyage.