Créer une fonction IA privée en Swift avec Foundation Models, SwiftUI et App Intents

Le framework Foundation Models d'Apple permet d'intégrer des fonctions de modèle de langage dans une application Swift native, tandis qu'App Intents expose les actions utiles aux expériences système. Ce guide propose une architecture orientée production avec SwiftUI, sortie structurée, confidentialité, tests, accessibilité et solutions de repli mesurables.

Ce qu'Apple a fait évoluer pour les développeurs

À la WWDC26, Apple a présenté de nouvelles capacités de Foundation Models concernant les modèles, la vision, la gestion du contexte, la recherche sémantique, les évaluations et les traitements côté serveur. Consultez la session officielle Apple avant l'adoption, car les noms et disponibilités des API peuvent évoluer.

1. Définir un résultat utilisateur précis

Ne commencez pas par un chatbot générique. Choisissez une tâche mesurable : résumer des notes de version, classer des retours, extraire des champs structurés ou produire un brouillon contrôlé par l'utilisateur.

2. Construire la couche modèle SwiftUI

import FoundationModelsimport Observation @MainActor@Observablefinal class ReleaseNotesModel {    private let session = LanguageModelSession()    var summary = ""     func summarize(_ notes: String) async throws {        let response = try await session.respond(            to: "Summarize these release notes for an iOS developer: \(notes)"        )        summary = response.content    }}

3. Connecter les actions avec App Intents

App Intents décrit les actions et les entités de manière structurée afin que les expériences système compatibles puissent les découvrir. Commencez par la documentation officielle App Intents et conservez des paramètres clairs.

4. Tester le comportement plutôt que la formulation

La formulation générée peut changer alors que l'exigence produit reste stable. Testez les faits obligatoires, le contenu interdit, les contraintes structurées, l'annulation, l'indisponibilité du modèle et la solution manuelle.

import Testing@testable import DeveloperAssistant @Test("Generated summaries keep the essential migration warning")func summaryContainsMigrationWarning() async throws {    let result = try await fixtureSummary()    #expect(result.localizedCaseInsensitiveContains("migration"))}

5. Traiter la disponibilité comme un état produit

Une fonctionnalité fondée sur un modèle ne doit pas se résumer à un indicateur activé ou désactivé. Construisez une machine à états explicite pour les modes disponible, temporairement indisponible, restreint, en téléchargement, en échec et solution de repli. SwiftUI peut ainsi expliquer la situation au lieu d’afficher une attente sans fin.

import FoundationModels enum AssistantAvailability {    case ready    case unavailable(reason: String)} func assistantAvailability() -> AssistantAvailability {    let model = SystemLanguageModel.default     switch model.availability {    case .available:        return .ready    case .unavailable(let reason):        return .unavailable(reason: String(describing: reason))    }}

• Afficher la raison de l’indisponibilité avec des termes compréhensibles.
• Conserver la navigation, les données et le flux manuel utilisables sans le modèle.
• Revérifier la disponibilité lorsque l’application redevient active.
• Mesurer les états agrégés sans collecter les requêtes ou contenus privés.

6. Préférer les sorties structurées au parsing fragile

Le texte libre convient aux brouillons, mais la logique produit doit consommer des valeurs contraintes dès que possible. Apple documente ces flux dans son guide Foundation Models . Définissez un contrat réduit, validez chaque champ et rejetez les valeurs contraires aux règles métier.

Pour un assistant de notes de version, le contrat peut contenir un résumé, les plateformes concernées, l’urgence de migration, les actions requises et les sources. L’interface affiche alors des sections prévisibles et localise les libellés indépendamment de la génération.

7. Encadrer strictement les outils

Les outils peuvent relier le modèle au calendrier, à une base locale, au réseau ou à des actions de l’application. Considérez les arguments proposés comme des entrées non fiables. Validez types et plages, appliquez les autorisations hors du modèle et exigez une confirmation pour les achats, suppressions, publications, messages ou changements de compte.

• Exposer uniquement les outils nécessaires à la tâche en cours.
• Retourner des résultats courts et typés plutôt que des dossiers privés complets.
• Séparer les outils en lecture seule de ceux qui modifient des données.
• Journaliser le nom de l’outil, la latence et la catégorie d’erreur.
• Ne jamais placer de clé API, jeton ou politique interne dans une requête.

8. Rendre App Intents utile en dehors de l’application

App Intents peut exposer une capacité ciblée aux expériences système compatibles. Suivez le guide de création d’un premier App Intent , localisez titres et descriptions, simplifiez les paramètres et retournez un résultat utile même sans l’interface complète.

import AppIntents struct SummarizeReleaseNotesIntent: AppIntent {    static let title: LocalizedStringResource = "Summarize Release Notes"    static let description = IntentDescription(        "Creates a concise draft while preserving migration warnings."    )     @Parameter(title: "Release notes")    var notes: String     func perform() async throws -> some IntentResult & ReturnsValue<String> {        let summary = try await ReleaseNotesService.shared.summarize(notes)        return .result(value: summary)    }}

L’intent ne doit pas dupliquer l’orchestration du modèle. Placez requêtes, validation, persistance et télémétrie dans un service réutilisable par SwiftUI, App Intents et les tests afin d’éviter des comportements contradictoires.

9. Construire un jeu d’évaluation avant d’ajuster les requêtes

Le jeu d’évaluation doit représenter les entrées réelles : textes courts ou longs, langues mélangées, contexte manquant, données sensibles et instructions adverses. Enregistrez les faits attendus et les affirmations inacceptables plutôt qu’un paragraphe de référence unique.

struct EvaluationCase: Codable {    let id: String    let input: String    let requiredFacts: [String]    let prohibitedClaims: [String]} func score(_ output: String, against test: EvaluationCase) -> Double {    let required = test.requiredFacts.filter(output.localizedCaseInsensitiveContains)    let violations = test.prohibitedClaims.filter(output.localizedCaseInsensitiveContains)    let recall = Double(required.count) / Double(max(test.requiredFacts.count, 1))    return max(0, recall - Double(violations.count) * 0.25)}

• Conserver un jeu de régression figé pour chaque version publiée.
• Ajouter les échecs réels après suppression des données personnelles.
• Comparer la voie IA à la solution manuelle, pas seulement à l’ancienne requête.
• Mesurer la latence médiane et extrême, les annulations et la réussite du repli.

10. Intégrer confidentialité et sécurité dans le flux de données

Dessinez le trajet complet des données : saisie, mémoire, stockage local, session du modèle, outils, analytics, rapports de panne, serveur et suppression. Classez chaque champ et décidez ce qui ne doit jamais quitter l’appareil. Une promesse de confidentialité n’est crédible que si l’architecture et les journaux l’imposent.

11. Intégrer l’accessibilité à chaque état généré

Le contenu généré doit rester utilisable avec Dynamic Type, VoiceOver, contraste renforcé, réduction des animations, clavier et contrôle de sélection. Annoncez les changements utiles, stabilisez le focus à l’arrivée du résultat et identifiez clairement un brouillon généré.

• Employer des titres sémantiques et des libellés d’accessibilité concis.
• Permettre la pause des médias, animations et mises à jour automatiques.
• Fournir alternatives textuelles et transcriptions pour chaque média.
• Tester les chaînes françaises et anglaises aux tailles d’accessibilité.
• Conserver la sélection et le focus après régénération ou rejet.

12. Localiser le comportement, pas seulement les libellés

Les versions française et anglaise exigent des cas d’évaluation distincts : noms, dates, unités, ponctuation, terminologie et résumé acceptable diffèrent. Rendez la langue explicite et ne traduisez jamais silencieusement un contenu privé par un service non annoncé.

1 / 2

Ressources Apple Developer officielles utilisées pour valider le parcours technique.

13. Définir un budget de performance et d’énergie

Mesurez démarrage à froid, délai avant le premier résultat utile, durée totale, pression mémoire, annulation et impact batterie sur le plus ancien appareil pris en charge. Annulez le travail lorsque la vue disparaît et ne mettez en cache que les contenus pouvant être conservés.

14. Observer les échecs sans enregistrer les contenus privés

Les tableaux de bord doivent indiquer la disponibilité, la version exécutée, le résultat de la validation, l’acceptation par l’utilisateur et la réussite de la solution de repli. Utilisez des catégories d’erreur expurgées plutôt que les requêtes et réponses brutes.

• Taux de disponibilité par système, appareil, langue et région.
• Taux d’échec de validation et de nouvelle tentative par version.
• Latences P50, P95 et P99 avec le taux d’annulation.
• Taux de réussite du repli et taux de correction signalée.
• Sessions sans panne et alertes mémoire autour des opérations.

15. Checklist de mise en production

Ressources officielles pour poursuivre

Commencez par la documentation Foundation Models .

Consultez la documentation App Intents .

Utilisez la documentation Swift Testing .

Si une application exige un autre fournisseur de modèle, consultez la session Apple sur l’intégration des fournisseurs et expliquez clairement le nouveau trajet des données.

Verdict final