Foundation Lab : un atelier SwiftUI pour le framework Foundation Models d'Apple
A practical lab for building, testing, and evaluating apps with Apple's Foundation Models framework.
En bref
- De quoi s’agit-il ?
- Foundation Lab est une application iOS et macOS qui rassemble prompt, outils, transcript et traces d'exécution pour le framework Foundation Models. Elle sert surtout à explorer les API sur appareil réel, pas à remplacer un banc de mesure.
- À qui s’adresse-t-il ?
- Foundation Lab convient aux développeurs Swift qui possèdent un appareil Apple Silicon sous iOS 26 ou macOS 26 et qui veulent observer le comportement réel du framework Foundation Models, transcript et appels d'outils compris. À éviter si vous cherchez une bibliothèque de production, un serveur de mesure reproductible ou un support Intel : le simulateur ne suffit pas aux exécutions de modèle.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 6 jours.
- En quel langage est-il écrit ?
- Principalement Swift, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : garder prompt, outils et traces dans le même écran
Tester un modèle sur appareil ressemble souvent à un va-et-vient entre un fichier de prompt, un onglet de console et une capture d'écran. Foundation Lab part d'un constat simple : une exécution de modèle produit plusieurs artefacts liés entre eux, et les séparer fait perdre l'information utile. Le README résume l'intention en une phrase : garder « the prompt, configuration, tools, transcript, and run evidence in one place ».
Trois destinations structurent l'application. Library regroupe 18 recettes modifiables, 14 labs guidés, trois workshops, des expériences sauvegardées et un workspace. Playground sert à éditer les instructions, configurer le modèle et les outils, diffuser la réponse en flux, saisir du texte à la voix, sauvegarder une expérience et exporter du Swift. Runs conserve l'état persisté de chaque exécution : configuration, événements du transcript, appels d'outils, temps et consommation de tokens.
Le public visé est étroit. Il faut un appareil Apple Silicon, iOS 26 ou macOS 26, Apple Intelligence activé, et Xcode 26.6 ou 27. Un développeur qui découvre le framework y trouvera un point d'entrée concret ; un développeur qui cherche un composant à intégrer dans son application se trompe de dépôt.
Comment une exécution circule dans l'application
Le dépôt sépare l'interface de la logique. FoundationLabCore contient, selon la description du README, « UI-independent requests, results, use cases, providers, and experiment models ». C'est cette couche qui porte les requêtes et leurs résultats, tandis que la cible Foundation Lab se limite à la présentation. Une recette ouverte depuis Library n'est donc pas un fichier de configuration isolé : elle alimente un Playground, qui produit une exécution, qui finit dans Runs.
Les entrées de Library annoncent leur mode d'ouverture. Une Recipe s'ouvre dans Playground et reste modifiable, exécutable et sauvegardable. Un Guided Lab utilise une interface dédiée à une API précise du framework. Un Workshop regroupe des exemples liés (schéma, langue, Xcode 27) sans ajouter de destination de premier niveau. Un Workspace ouvre un outil à part, comme Adapter Comparison.
Deux paquets externes complètent l'ensemble. FoundationModelsTools fournit les neuf recettes d'outils intégrées. FoundationModelsKit, hébergé dans un autre dépôt, apporte le transcript, la gestion du contexte, l'historique et les outils système. Ce découpage a une conséquence pratique : la mise à jour d'un de ces paquets peut changer le comportement de l'application sans qu'une nouvelle version de Foundation Lab soit publiée.
Compiler l'application et ouvrir une première recette
La prise en main tient en trois commandes, telles que le README les donne :
git clone https://github.com/rudrankriyam/Foundation-Models-Framework-Lab.git cd Foundation-Models-Framework-Lab open FoundationLab.xcodeproj
Pour vérifier la compilation sans signature de code, le README fournit deux invocations xcodebuild, l'une vers generic/platform=macOS, l'autre vers generic/platform=iOS Simulator, toutes deux avec CODE_SIGNING_ALLOWED=NO et le scheme 'Foundation Lab'. C'est la vérification la plus rapide avant d'ouvrir Xcode, et elle ne nécessite aucun appareil.
La distinction à retenir est explicite dans le README : les exécutions de modèle en direct demandent un appareil physique compatible, et les builds simulateur restent utiles pour la compilation et la validation d'interface. Autrement dit, la commande vers iOS Simulator confirme que le projet tient debout, pas que le modèle répond.
Les API introduites avec le SDK OS 27 sont conditionnées par le compilateur et par la disponibilité. Le projet se compile avec Xcode 26.6 comme avec Xcode 27, mais seuls les labs les plus récents apparaissent avec Xcode 27. Si vous restez sur Xcode 26, attendez-vous à une partie seulement du contenu décrit dans le README.
Neuf outils intégrés et la question de la confirmation
Les recettes d'outils couvrent la météo via Open-Meteo, la recherche web Search1 sans clé d'API, Contacts, Calendrier, Rappels, la localisation et la recherche de lieux, les données HealthKit autorisées, Apple Music et les métadonnées web. Toutes s'ouvrent dans Playground, où elles peuvent être combinées ou retirées.
Le point de conception intéressant concerne les outils capables de modifier les données de l'utilisateur. Le README indique qu'ils passent par un flux de confirmation propre à l'application. Pour un lecteur qui évalue le dépôt, cela veut dire que le modèle ne déclenche pas une écriture dans Calendrier ou Rappels sans validation. C'est un choix défendable, et il faut le vérifier dans le code avant de s'en servir comme modèle d'architecture, car le README ne détaille pas la forme de cette confirmation.
La couverture HealthKit mérite une lecture prudente. Le tableau de bord et le chat associés sont présentés comme fondés uniquement sur les données de santé autorisées. La formulation est celle du README ; aucune indication n'est donnée sur ce qui se passe lorsque l'autorisation est refusée en cours de session. C'est exactement le genre de cas limite qu'un lab devrait documenter, et ce n'est pas fait ici.
Sortie structurée, multilingue et RAG
Le volet sortie structurée s'appuie sur les macros @Generable et les contraintes @Guide du framework. Le README cite des schémas dynamiques, des objets imbriqués, des unions, des formulaires et l'extraction de factures. Pour un développeur qui doit faire produire du JSON à un modèle, ces exemples valent plus qu'une page de référence : ils montrent la forme attendue côté Swift.
Le multilingue est traité par des sessions dédiées et une inspection des langues prises en charge. Le RAG, lui, combine indexation de documents et recherche sémantique avec LumoKit et VecturaKit. Ces deux briques sont des dépendances externes, pas du code du dépôt. Leur version, leur licence et leur stabilité ne sont pas décrites dans le matériel fourni, et c'est une lacune pour quiconque veut évaluer la maintenance à long terme.
Les labs Xcode 27 complètent le tableau : PrivateCloudComputeLanguageModel, exécution partagée de LanguageModel, pièces jointes et références d'images, modes explicites d'appel d'outils, profils dynamiques, inspection du transcript, transformations d'historique, visualisation du budget de contexte et exécuteurs de modèle personnalisés, dont un pont vers un fournisseur vidéo. Le dépôt inclut aussi une sonde sous Tools/ImageInputProbe, décrite comme capable de mesurer la limite pratique de tampon décodé du SDK courant. C'est un outil de mesure, pas une garantie de résultat.
Adapter Comparison et la frontière avec la CLI fmas
Sur macOS, le workspace Adapter Comparison importe un paquet .fmadapter et exécute le même prompt dans deux sessions, l'une sur le modèle de base, l'autre avec l'adaptateur. Les deux flux s'affichent côte à côte, avec des mesures de time-to-first-token et de durée totale.
L'entraînement et l'export ne sont pas dans l'application. Ils restent dans la CLI compagnon fmas, installée depuis Tools/AdapterStudio via un environnement virtuel Python 3.11, avec fmas init, fmas setup, puis fmas train-adapter et fmas export. Le README renvoie à Tools/AdapterStudio pour le workflow complet. Cette séparation est cohérente : entraîner un adaptateur n'a rien à faire dans une interface SwiftUI, mais elle signifie aussi que le parcours complet traverse deux chaînes d'outils distinctes.
Autre point à noter, la CLI afm ne vit plus dans ce dépôt. Elle est publiée depuis un dépôt séparé, rudrankriyam/Foundation-Models-Framework-CLI, s'appuie sur le paquet public FoundationModelsKit et suit son propre cycle de versions. Installation via brew tap rudrankriyam/tap puis brew install afm. Si vous cherchiez un outil en ligne de commande dans Foundation Lab, il n'y est plus.
Limites, coût de maintenance et licence MIT
La contrainte la plus dure est matérielle. Exécuter un modèle en direct suppose un appareil Apple Silicon avec Apple Intelligence activé. Sur simulateur, vous validez la compilation et l'interface, rien de plus. Toute personne qui espère automatiser des exécutions de modèle dans une intégration continue sans appareil dédié sera bloquée.
La seconde contrainte est la dispersion. Le dépôt dépend de FoundationModelsKit, de FoundationModelsTools, de LumoKit et de VecturaKit, et il délègue la CLI à un autre dépôt. Le README ne documente ni les versions épinglées ni la politique de mise à jour de ces dépendances. Un changement d'API dans FoundationModelsKit se répercute sur l'application sans que son numéro de version bouge. Les trois versions publiées, 1.0.0 en juin 2026, puis 1.1.0 et 1.2.0 le lendemain, suggèrent un rythme de publication rapproché ; le matériel ne permet pas d'en dire plus sur la stabilité.
Foundation Lab n'est pas non plus un banc de mesure. Il produit des mesures diagnostiques de time-to-first-token et de durée totale dans Adapter Comparison, mais rien n'indique une méthodologie reproductible, un échantillonnage ou une agrégation statistique. Pour comparer sérieusement deux adaptateurs, il faudra construire votre propre protocole autour de ces mesures.
La licence est MIT, ce qui autorise la réutilisation, la modification et la redistribution du code, y compris dans un produit propriétaire, sous réserve de conserver l'avis de licence. Attention toutefois : cette licence couvre ce dépôt, pas nécessairement les paquets externes ni les ressources d'images. Vérifiez chaque dépendance séparément. Ce paragraphe décrit la licence telle qu'elle est déclarée, il ne constitue pas un avis juridique.
Ce qui distingue Foundation Lab d'un simple exemple de code
Un exemple de code montre une API qui fonctionne une fois. Foundation Lab conserve l'état de chaque exécution et permet de rouvrir une recette pour n'en changer qu'un paramètre. C'est la différence entre lire une documentation et manipuler un système.
La comparaison la plus utile se fait avec les exemples officiels d'Apple et avec un projet personnel minimal. Un projet minimal vous laisse seul face au câblage du transcript, de la gestion du contexte et des appels d'outils, mais il ne dépend que de vous. Foundation Lab vous donne ce câblage déjà écrit, au prix de quatre dépendances externes et d'un rythme de publication dicté par les bêtas d'Apple. Le choix dépend de ce que vous voulez apprendre : le framework, ou votre propre architecture autour de lui.
Reste une zone que le README n'éclaire pas. Aucune indication n'est donnée sur la taille du dépôt, la couverture de tests, ni sur ce qui se passe quand une exécution échoue en cours de flux. Pour un atelier, c'est acceptable. Pour un lecteur qui veut juger la robustesse, c'est une raison de lire le code de FoundationLabCore avant de se faire une opinion.
Conclusion éditoriale
Foundation Lab convient aux développeurs Swift qui possèdent un appareil Apple Silicon sous iOS 26 ou macOS 26 et qui veulent observer le comportement réel du framework Foundation Models, transcript et appels d'outils compris. À éviter si vous cherchez une bibliothèque de production, un serveur de mesure reproductible ou un support Intel : le simulateur ne suffit pas aux exécutions de modèle. Avant d'adopter, vérifiez que votre projet ouvre bien FoundationLab.xcodeproj avec Xcode 26.6 ou 27, puis lancez la commande xcodebuild sur le scheme 'Foundation Lab' avec CODE_SIGNING_ALLOWED=NO pour confirmer que la cible compile dans votre configuration.
Notes de la communauté