Comment créer une première fonctionnalité SwiftUI avec Apple Foundation Models ? Tutoriel débutant 2026

Repère de départ : la documentation Apple distingue trois causes d’indisponibilité du modèle, dont un appareil non éligible et Apple Intelligence désactivé ; vous pouvez les traiter séparément au lieu de confondre une compilation réussie avec un appel fonctionnel (détails des raisons d’indisponibilité). Pour votre première fonctionnalité SwiftUI avec Apple Foundation Models, limitez-vous à une zone de saisie, une action et une réponse, puis vérifiez l’environnement avant de lancer une requête réelle. Gardez les agents et les outils pour un exercice ultérieur.

Cette progression s’adresse à vous si vous commencez SwiftUI et souhaitez ajouter une réponse générée à un petit projet.
Elle convient aussi si vous savez créer une page, mais ne savez pas encore démarrer une session de modèle.
Si vous comptez travailler sur un Mac distant faute de Mac local compatible, vérifiez les capacités de l’environnement attribué avant de prévoir la validation finale.

Dernière vérification : 25 septembre 2026, à partir de la documentation Apple Developer consacrée à Foundation Models, à la disponibilité de SystemLanguageModel, aux sessions et aux exigences de Xcode. Les conditions et les API pouvant évoluer, contrôlez les pages officielles au moment de votre exercice.

Avant la première ligne : séparer compilation et disponibilité

Un projet peut compiler sans que l’appareil utilisé puisse effectuer une génération. Ce sont deux étapes différentes : Xcode doit accepter le projet et les API employées ; ensuite, l’appareil et sa configuration doivent permettre l’utilisation du modèle. L’une ne prouve pas l’autre.

Commencez par consulter les exigences système de Xcode pour vérifier si votre version de l’outil est prise en charge par le système installé sur votre Mac. Le nom Xcode 27 dans un intitulé de cours ou une recherche ne suffit pas à valider cette compatibilité : fiez-vous à la page officielle et à la version effectivement disponible dans votre environnement. Évitez de supposer qu’un projet qui s’ouvre sur un appareil donné fonctionnera de la même manière sur tous les autres.

Vérifiez ensuite que le projet cible les plateformes et versions système indiquées dans la documentation Apple de Foundation Models. Les conditions exactes de prise en charge doivent être vérifiées là, au moment du travail ; cet article ne garantit ni que tous les Mac Apple silicon conviennent, ni qu’un simulateur puisse réaliser une génération.

Peut-on préparer l’exercice sans Mac local compatible ? Oui, vous pouvez construire et tester l’interface SwiftUI avec des réponses temporaires, puis chercher un environnement Mac compatible pour vérifier l’appel réel. Si vous envisagez un Mac distant, demandez d’abord quelles versions du système et de Xcode sont fournies, et si l’accès aux fonctions requises est possible. Le simple accès à macOS ne prouve pas que le modèle sera disponible.

Le premier choix pédagogique est donc simple : si vous n’avez pas encore confirmé l’environnement, écrivez l’interface et son état de secours d’abord ; réservez la validation du modèle à un appareil dont la compatibilité a été contrôlée.

Premier jalon : afficher une page sans modèle

Commencez par une page qui comporte trois éléments visibles : un champ de saisie, un bouton et une zone de réponse. Ce périmètre est volontairement réduit : vous apprenez le trajet d’une donnée dans l’interface sans ajouter de logique de conversation, d’image ou d’outil.

En SwiftUI, une valeur d’état peut représenter le texte saisi ou la réponse affichée. Quand cette valeur change, l’interface peut se mettre à jour. La documentation Apple sur State décrit ce lien entre l’état et les vues. Pour un débutant, imaginez une fiche de cours : le champ est votre question, la variable d’état est la copie conservée par l’application, et la zone de réponse est l’endroit où vous reportez le résultat.

Créez d’abord une réponse fixe, sans connecter Apple Foundation Models. Saisissez quelques mots dans le champ, puis faites changer le texte affiché lorsque vous appuyez sur le bouton. Vous aurez ainsi vérifié que la page réagit avant d’introduire des erreurs possibles liées à l’environnement ou au modèle.

À ce stade, l’acceptation est concrète : le texte entré reste visible, l’action déclenche un changement perceptible et la zone de réponse ne reste pas vide sans explication. Si cette étape échoue, corrigez l’interface avant d’ajouter un appel asynchrone ; sinon, vous risqueriez de chercher une panne de modèle alors que le bouton n’est simplement pas relié à l’action attendue.

À retenir : gardez une réponse de démonstration clairement étiquetée comme telle. Elle sert à tester l’écran, mais ne doit jamais être présentée comme une réponse produite par le modèle.

Deuxième jalon : envoyer une première requête texte

Le cadre de base d’Apple Foundation Models comprend un modèle système et une session de conversation. Une session est comparable au cahier d’un exercice en cours : elle reçoit votre demande et peut servir de contexte aux échanges associés. Le prompt — autrement dit la consigne transmise au modèle — est la question que vous souhaitez lui faire traiter.

La documentation Apple présente SystemLanguageModel pour accéder au modèle système et LanguageModelSession pour créer une session. Pour une première tentative, le chemin à tester est volontairement direct : créer une session, transmettre une consigne avec respond(to:), puis afficher le contenu de la réponse. La référence de respond(to:) donne la signature et les détails de l’appel à contrôler dans votre version de l’API.

Voici le cœur d’une action asynchrone, à intégrer dans une vue qui met à jour son état. Il ne remplace pas les contrôles d’éligibilité présentés ensuite :

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: "Explique en une phrase ce qu'est une variable.")
let texteGenere = response.content

Dans une app SwiftUI, l’appel doit être déclenché depuis une tâche asynchrone, car la génération ne se déroule pas nécessairement immédiatement. Pendant l’attente, désactivez le bouton ou affichez un état de chargement ; à la fin, placez response.content dans la valeur d’état liée à votre zone de réponse. En cas d’erreur, remplacez le chargement par un message utile. Le code exact autour de la vue dépend de la structure de votre projet, mais le principe reste le même : la saisie déclenche l’action, l’action effectue la requête, puis l’état actualise l’écran.

Comment appeler le modèle dans une app SwiftUI ? Depuis une action asynchrone, créez une LanguageModelSession, transmettez un texte avec respond(to:) et affichez le contenu renvoyé dans l’état de la vue. Commencez par une demande courte et sans données personnelles ; vous saurez ainsi distinguer un problème d’interface d’un problème de compatibilité.

Ne complexifiez pas cette première étape avec un agent, un appel d’outil, une image ou des réglages avancés. Ces ajouts créent d’autres comportements à tester et n’aident pas à répondre à la question initiale : l’écran sait-il envoyer une demande et montrer le résultat ?

Troisième jalon : traiter l’indisponibilité au lieu d’attendre indéfiniment

Avant d’envoyer une requête, lisez l’état de disponibilité exposé par le modèle système. Apple documente cette vérification avec SystemLanguageModel.default.availability ; consultez la documentation de disponibilité au moment de coder, car les noms d’API et les conditions peuvent changer.

La logique générale se présente ainsi :

import FoundationModels

let model = SystemLanguageModel.default

switch model.availability {
case .available:
    // Lancer la requête texte
case .unavailable(let reason):
    // Afficher une explication adaptée à reason
}

La documentation officielle répertorie des raisons d’indisponibilité telles que deviceNotEligible, appleIntelligenceNotEnabled et modelNotReady (énumération des raisons). Ne réduisez pas tous ces cas à un message générique « erreur ». Ils ne désignent pas le même problème et n’appellent pas la même suite d’actions :

• Si l’appareil n’est pas éligible, vous ne pouvez pas rendre l’appel possible en modifiant uniquement la vue. Continuez les exercices avec une réponse de démonstration et cherchez un appareil qui répond aux conditions officielles.
• Si Apple Intelligence est désactivé, indiquez à l’utilisateur qu’il doit vérifier les réglages système concernés. Ne prétendez pas que le bouton a produit une réponse.
• Si le modèle n’est pas prêt, évitez de laisser l’écran bloqué en chargement. Affichez un message compréhensible et permettez une nouvelle tentative plus tard, selon le comportement décrit par Apple.

Le modèle est indisponible : l’exercice peut-il continuer ? Oui. Vous pouvez terminer la mise en page, tester les changements d’état et vérifier l’affichage d’un message de repli. En revanche, notez séparément que la génération réelle n’a pas été validée. Un état d’erreur propre est une partie fonctionnelle de l’exercice ; une réponse fixe n’est pas une preuve d’appel réussi.

Contrôle de cohérence : n’affichez « réponse générée » qu’après réception effective du résultat. Si le modèle n’est pas disponible ou si l’appel échoue, remplacez le chargement par une explication et conservez la possibilité de réessayer.

Quatrième jalon : vérifier chaque résultat sur l’appareil cible

Faites une courte vérification avec une question sans données sensibles, par exemple une demande de définition. Observez le parcours entier : saisie, action, état de chargement, vérification de disponibilité, résultat ou message d’échec. Une capture de la page seule ne suffit pas à démontrer que le modèle a répondu ; gardez une trace de ce qui a réellement été testé.

Séparez les observations en trois catégories. Premièrement, la page s’affiche et réagit. Deuxièmement, l’application atteint le chemin d’appel sans rester bloquée. Troisièmement, le modèle est disponible et produit effectivement un résultat sur l’appareil visé. Cette distinction évite de déclarer un exercice « terminé » parce que la compilation est réussie alors que la requête n’a jamais abouti.

Faut-il valider sur simulateur ou sur appareil réel ? Utilisez le simulateur pour vérifier l’interface lorsque cela convient à votre projet, mais ne déduisez pas de cette vérification que la génération est prise en charge. Pour certifier un appel réel, contrôlez la disponibilité sur l’environnement qui exécutera la fonction et suivez les consignes Apple concernant la plateforme et le modèle.

Si vous êtes sur un Mac distant, recommencez ces contrôles après avoir ouvert votre session de travail : l’environnement réellement attribué, ses versions système et Xcode, puis l’état du modèle. Ne généralisez pas le résultat d’une machine à toutes les autres instances distantes. Pour comparer les conditions d’accès et les formules disponibles, vous pouvez consulter les offres Mac à distance ; vérifiez ensuite que l’environnement envisagé répond aux exigences de votre cours avant de compter sur lui.

Tableau de décision : ce que votre environnement permet de conclure

Tableau de progression : garder une preuve pour chaque jalon

Pour votre séance de travail, avancez dans cet ordre : d’abord la page et sa réponse de test, ensuite la vérification de compatibilité, puis la requête avec son traitement d’erreur. Vous pourrez ainsi remettre une interface fonctionnelle même si l’accès au modèle doit attendre, sans confondre l’état de l’exercice avec l’état de l’appareil.

Si votre ordinateur actuel empêche l’installation de l’environnement requis, Windows ou un poste scolaire verrouillé peuvent compliquer la validation de Xcode et de l’appel système ; une machine distante, elle, peut varier selon ses versions et ses capacités réelles. Ces solutions ne garantissent donc pas à elles seules un test complet. Pour un exercice ponctuel, vérifiez d’abord si un Mac distant satisfait les exigences avant de vous engager ; les conditions des environnements Mac accessibles à distance peuvent vous aider à examiner cette option. Si votre cours exige un environnement local durable ou des périphériques physiques précis, un Mac que vous contrôlez directement peut être plus approprié.