Les App Intents sont la nouvelle API d'Apple vers votre application

Le matin du 8 février 2026, j’ai demandé à Siri d’enregistrer 8 oz d’eau depuis mon Apple Watch alors que mes mains étaient sous l’évier de la cuisine. L’eau a été enregistrée. La boîte de dialogue de la montre indiquait 32 oz restantes. Je n’avais touché aucun écran.¹

Onze semaines plus tôt, j’avais ajouté un seul fichier Swift à Water, mon application iOS de suivi d’hydratation : LogWaterIntent.swift, 80 lignes d’AppIntent ainsi qu’un AppShortcutsProvider déclarant trois variantes de phrases Siri. Ce fichier est désormais la surface API la plus active que je possède.²

Voici la partie qu’il m’a fallu un certain temps à intégrer. Les App Intents ne sont pas une fonctionnalité Siri. Ce sont le contrat que les applications tierces signent avec Apple Intelligence, les surfaces d’IA système qu’Apple a commencé à déployer dans iOS 18 et qu’elle a continué à construire jusqu’à iOS 26.³ Si vous publiez une application iOS et que vous traitez encore les App Intents comme une fonctionnalité vocale « bonne à avoir », vous interprétez mal ce qu’Apple a construit. Les App Intents sont la API qui permet à l’IA d’Apple d’agir en tant que votre application au nom de l’utilisateur. Tout le reste (Siri, Spotlight, Shortcuts, les résumés Apple Intelligence, les surfaces Watch et Vision Pro) découle de ce contrat. Foundation Models, le LLM embarqué qui est arrivé avec iOS 26, expose un protocole Tool distinct pour l’appel d’outils intra-application ; il fonctionne en parallèle des App Intents plutôt qu’à travers eux.

TL;DR

• Les App Intents déclarent ce que votre application peut faire de manière typée et structurée qu’Apple’s IA peut appeler directement. Ils sont la API d’utilisation d’outils d’Apple pour les applications tierces.
• Un exemple de production réel : LogWaterIntent dans Water. 80 lignes, écriture SwiftData complète, synchronisation HealthKit, conversion d’unités sensible à la locale, réponse de dialogue Siri structurée.
• iOS 26 a ajouté Foundation Models, le LLM embarqué d’Apple. Foundation Models expose son propre protocole Tool pour l’utilisation d’outils intra-application ; les App Intents restent la surface canonique que Siri / Spotlight / Apple Intelligence appellent à travers les applications. Même direction, deux contrats parallèles.
• Une application sans App Intents en 2026 est invisible pour Apple Intelligence. La trame d’IA passe par vos intentions déclarées, ou bien elle contourne votre application au profit d’un concurrent.
• Apple nous le dit depuis trois ans. La nomenclature (App Intents, App Shortcuts, Apple Intelligence) est intentionnelle. Le contrat monte d’un niveau dans la pile à chaque WWDC.

Image de référence du framework App Intents tirée de la documentation Apple Developer.⁵

Ce qu’est réellement un App Intent

Le code source complet de LogWaterIntent tel qu’il a été déployé dans le commit e398c58 le 8 février 2026 :²

import AppIntents
import SwiftData

struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    static var description: IntentDescription = "Log a glass of water to your daily intake"

    @Parameter(title: "Amount", default: 8)
    var amount: Int

    static var parameterSummary: some ParameterSummary {
        Summary("Log \(\.$amount) oz of water")
    }

    func perform() async throws -> some IntentResult & ProvidesDialog {
        let container = try ModelContainer(for: WaterEntry.self, DailyLog.self, UserSettings.self)
        let context = ModelContext(container)

        let settingsDescriptor = FetchDescriptor<UserSettings>(
            predicate: #Predicate { $0.id == "user-settings" }
        )
        let settings = try context.fetch(settingsDescriptor).first ?? UserSettings()

        let amountMl: Double
        if settings.unitSystem == .imperial {
            amountMl = Double(amount) * 29.5735
        } else {
            amountMl = Double(amount)
        }

        let todayKey = DailyLog.todayKey()
        let logDescriptor = FetchDescriptor<DailyLog>(
            predicate: #Predicate { $0.dateKey == todayKey }
        )
        let log: DailyLog
        if let existing = try context.fetch(logDescriptor).first {
            log = existing
        } else {
            log = DailyLog(date: .now, goalAmount: settings.dailyGoal)
            context.insert(log)
        }

        let entry = WaterEntry(amount: amountMl)
        log.entries.append(entry)
        try context.save()

        if settings.healthKitEnabled {
            try? await HealthKitService.shared.logWater(amount: amountMl, date: entry.timestamp)
        }

        let unit = settings.unitSystem == .imperial ? "oz" : "mL"
        let totalDisplay = settings.formatAmount(log.totalAmount)
        return .result(dialog: "Logged \(amount) \(unit). Today's total: \(totalDisplay)")
    }
}

struct WaterShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: LogWaterIntent(),
            phrases: [
                "Log water in \(.applicationName)",
                "Add water in \(.applicationName)",
                "Drink water in \(.applicationName)",
            ],
            shortTitle: "Log Water",
            systemImageName: "drop.fill"
        )
    }
}

(La version actuelle de production de ce fichier dans Water itère le dialogue plus loin avec une condition objectif-atteint/quantité-restante. Le code expédié le 8 février ci-dessus est celui que j’ai testé devant l’évier de la cuisine.)

Trois éléments ici méritent d’être nommés, parce que la plupart des « tutoriels App Intents » les survolent.

Le @Parameter est le schéma. L’IA d’Apple voit amount: Int avec une valeur par défaut de 8. Lorsque Siri analyse « log 12 oz of water », elle produit LogWaterIntent(amount: 12) et appelle perform(). Aucun parsing de chaîne de mon côté. Le système de types est le schéma.⁵

parameterSummary est le reflet en langage naturel du paramètre. Apple l’utilise pour rendre l’action dans l’interface Shortcuts, dans les dialogues, et de plus en plus dans les panneaux de confirmation d’Apple Intelligence. Le résumé est lu à voix haute à l’utilisateur. Mal écrit, l’utilisateur entend une phrase moche ; bien écrit, la surface paraît native.⁶

perform() retourne IntentResult & ProvidesDialog. C’est le retour structuré : la surface d’IA récupère non seulement un succès/échec mais aussi une chaîne de dialogue que l’utilisateur entend. Apple attend de plus en plus ProvidesDialog, ProvidesView ou ReturnsValue afin que le résultat se compose dans Siri, Spotlight, la Watch et (dans iOS 26) la chaîne de réponse d’Apple Intelligence.⁷

Le bloc AppShortcutsProvider en bas est ce qui enregistre les phrases Siri. Le jeton \(.applicationName) est l’endroit où Siri insère « Water » automatiquement. Trois variantes de phrases avec la même intention donnent à l’analyseur NL d’Apple plus de marge pour reconnaître la formulation de l’utilisateur sans que vous mainteniez un dictionnaire de phrases. Le systemImageName est un véritable nom SF Symbols ; c’est ainsi que Spotlight, Shortcuts et Apple Intelligence rendent l’icône de l’action.

Apple Intelligence achemine les requêtes utilisateur via les App Intents pour proposer des fonctionnalités d’IA embarquées. Source : apple.com/apple-intelligence.

Pourquoi c’est la API iOS la plus importante depuis SwiftUI

Les APIs d’iOS prennent deux formes. Certaines concernent la manière dont votre application se dessine elle-même (UIKit, SwiftUI, Metal). D’autres concernent la manière dont votre application s’intègre au système (schémas d’URL, Universal Links, Widgets). Les App Intents sont une troisième forme : ils sont la manière dont l’IA d’Apple utilise votre application.

La progression mérite d’être retracée.

• iOS 10 (2016) a introduit les SiriKit Intents (INIntent), la première fois où les applications tierces pouvaient être adressées par la voix. La surface était étroite : une liste fixe de domaines (messagerie, paiements, réservation de courses) avec des schémas stricts.⁸
• iOS 12 (2018) a élargi la surface avec Siri Shortcuts : n’importe quelle application pouvait donner une NSUserActivity ou un INIntent et espérer que Siri la suggère.
• iOS 13 (2019) a ajouté la gestion intra-application des intentions afin que les applications puissent répondre aux invocations de raccourcis sans passer par l’interface Siri système.
• iOS 16 (2022) a introduit le framework App Intents : typé, déclaratif, avec @Parameter et AppShortcutsProvider. Le prédécesseur INIntent a été effectivement supplanté pour les nouveaux développements.⁹
• iOS 18 (2024) a introduit Apple Intelligence et a commencé à acheminer les requêtes Siri via les App Intents partout où c’était possible. La fonctionnalité « contexte personnel » d’Apple Intelligence lit depuis les App Entities (la version « données » des App Intents).¹⁰
• iOS 26 (2025) a introduit le framework Foundation Models, le LLM embarqué d’Apple. Foundation Models expose un protocole Tool distinct pour l’appel d’outils intra-application. Les App Intents restent la surface canonique inter-application pour Apple Intelligence, tandis que Tool est la surface intra-application pour les appels LLM directs. Les deux contrats fonctionnent en parallèle.⁴

Le contrat n’a cessé de s’étendre vers le haut de la pile à chaque version. À l’origine, le consommateur d’un App Intent était une personne touchant Shortcuts. Puis la voix Siri. Puis Spotlight. Puis les résumés Apple Intelligence. Maintenant, les surfaces système d’Apple Intelligence soutenues par LLM les utilisent pour agir sur les requêtes utilisateur. La surface App Intent que vous expédiez en 2026 est celle qu’Apple Intelligence appellera dans iOS 27, 28, 29.

Le schéma ci-dessus est ce que je veux dire quand je dis que les App Intents ne sont pas une fonctionnalité Siri. Ils sont la API d’utilisation d’outils structurés pour toute la trame d’IA Apple. SwiftUI a été la API d’interface utilisateur la plus importante parce qu’elle est devenue la seule manière d’écrire une application pour visionOS, watchOS 10+ et iOS 17+. Les App Intents suivent la même trajectoire côté IA : la surface où Apple place tous ses paris.

Ce qui change maintenant que Foundation Models est arrivé

Foundation Models est le framework qui s’expédie sur tout appareil éligible à Apple Intelligence. Le seuil matériel est la même liste qu’Apple Intelligence : iPhone 15 Pro et 15 Pro Max (A17 Pro), gamme iPhone 16, gamme iPhone 17, iPhone Air, iPhone 17e, iPad Pro avec M1 ou ultérieur, iPad Air avec M1 ou ultérieur, iPad mini avec A17 Pro, Vision Pro avec M2 ou ultérieur, et Mac avec M1 ou ultérieur. Notablement absents : iPhone 15 / 15 Plus de base.⁴¹²

L’implication : si les surfaces système d’Apple (Siri, Spotlight, Apple Intelligence) appellent votre application, elles l’appellent via les App Intents et les App Entities. Il n’existe pas de API setSystemPrompt(...) pour les applications tierces dans la trame d’IA système. Il y a le registre d’intentions. Foundation Models ajoute une surface Tool parallèle intra-application pour les développeurs qui veulent leurs propres fonctionnalités LLM embarquées. Le contrat inter-application (celui qu’Apple Intelligence et Siri utilisent pour trouver votre application) passe par les App Intents.

Trois conséquences concrètes pour les développeurs d’applications :

Une application sans App Intent pertinent n’est pas joignable depuis une commande vocale Siri dans sa catégorie. Apple Intelligence achemine des phrases comme « Hey Siri, log my water » vers les applications qui ont déclaré l’intention correspondante en premier. J’ai déployé l’intention de Water en février 2026. Ma lecture de la direction du framework : les applications d’hydratation qui déploieront l’intention en 2027 entreront dans un marché où les pondérations de routage se sont déjà accumulées en faveur des premiers à se positionner. La même logique s’applique aux listes de courses, à l’enregistrement d’entraînements, aux entrées de calendrier, aux recherches de photos. Je m’attends à ce que l’avantage du premier à se positionner sur les déclarations d’intention se cumule comme cela a été le cas pour d’autres APIs de pari plateforme Apple (catégories HealthKit, résultats riches Spotlight, jetons Live Activities).

La personnalisation Apple Intelligence lit depuis les App Entities, pas seulement depuis les intentions. Un AppEntity déclare « cette application possède des données de cette forme ». Lorsque l’utilisateur demande « quel est le dernier livre que j’ai ajouté à ma liste de lecture », Apple Intelligence parcourt chaque AppEntity correspondant à Book à travers chaque application installée. Si votre application possède une liste de lecture et qu’aucune BookEntity n’est déclarée, vos données sont invisibles pour les surfaces d’IA d’Apple. Apple Intelligence ne peut ni récupérer ni référencer vos données.¹¹

La forme de retour IntentResult & ProvidesDialog prend de plus en plus d’importance. Apple Intelligence compose les résultats d’intentions dans des réponses plus longues à travers Siri, Spotlight et la Watch. Un perform() qui retourne simplement un succès sans dialogue structuré est plus difficile pour le système à composer en une réponse cohérente. ProvidesDialog et ProvidesView ne sont pas une politesse facultative ; c’est ainsi que votre action devient une citation dans la surface d’IA de l’utilisateur.

Ce que je construirais différemment

Onze semaines de logs de production dans Water me disent trois choses que j’aurais dû faire plus tôt.

Expédiez plus d’intentions que vous ne pensez en avoir besoin. J’en ai expédié une. J’aurais dû en expédier quatre : LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent. Chacune correspond à une phrase Siri que les utilisateurs essaient effectivement (« how much water have I had today » acheminée vers l’IA générique d’Apple plutôt que vers les données de mon application). Chaque intention manquée est une requête qu’Apple Intelligence contourne.

La chaîne de dialogue n’est pas le corps d’un e-mail. J’avais ProvidesDialog dès le début, mais mon dialogue précoce était de la prose. L’utilisateur qui l’entend via CarPlay ou des AirPods a besoin d’une structure courte, concrète, axée sur les faits : « 8 oz logged. 32 oz to go. » La surface Watch en particulier tronque agressivement. Un dialogue conversationnel offre une expérience utilisateur pire qu’un dialogue assuré et factuel. J’ai réécrit le mien lors de la 4e semaine.²

Les App Entities comptent plus que je ne le pensais. J’ai un modèle SwiftData WaterEntry. Je devrais aussi déclarer un WaterEntryEntity: AppEntity ainsi que son compagnon WaterEntryQuery: EntityQuery pour qu’Apple Intelligence puisse répondre à « show me when I drank water yesterday ». Le pontage minimal :¹¹

struct WaterEntryEntity: AppEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Water Entry"
    static var defaultQuery = WaterEntryQuery()
    var id: UUID
    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(title: "\(amount) oz at \(timestamp.formatted())")
    }
    @Property(title: "Amount") var amount: Int
    @Property(title: "Timestamp") var timestamp: Date
}

struct WaterEntryQuery: EntityQuery {
    func entities(for identifiers: [UUID]) async throws -> [WaterEntryEntity] {
        // Fetch matching entries from SwiftData
    }
    func suggestedEntities() async throws -> [WaterEntryEntity] {
        // Recent entries Apple Intelligence can suggest
    }
}

Deux petits types Swift plus la glue de fetch SwiftData. Pour rendre les entrées individuellement remontables dans Spotlight (afin que les utilisateurs cherchant « water » tombent sur la bonne entrée), conformez l’entité à IndexedEntity et donnez les mises à jour d’index lors des écritures. C’est ce que le pipeline Spotlight d’Apple attend au-delà d’une simple exposition AppEntity.

La même forme s’applique ailleurs dans mes applications. Get Bananas, mon application de liste de courses, possède déjà un @Model ShoppingItem SwiftData avec @Attribute(.unique) var id: UUID, name, amount, section, isChecked, ainsi qu’un champ lastModified pour la synchronisation iCloud Drive.¹³ L’envelopper en tant que ShoppingItemEntity: AppEntity et expédier quelques intentions (AddShoppingItem, CheckOffItem, ShowList) exposerait à Apple Intelligence la même couche de persistance que Get Bananas expose déjà à Claude Desktop via son serveur MCP .mcpb.¹⁴ Deux écosystèmes LLM, deux contrats différents, la même liste de courses. C’est la thèse des contrats parallèles incarnée dans une seule application expédiée : le modèle SwiftData est la donnée, les App Intents sont le contrat d’Apple, MCP est le contrat de Anthropic, les deux surfaces opèrent sur la même source de vérité.

Quand ne pas expédier d’App Intent

Le refus fait partie de la conception.

Si votre application est purement orientée consommation (lire les photos de l’utilisateur, afficher des informations, lire de l’audio) sans état utilisateur mutable, les App Intents peuvent n’avoir rien à exposer. Le framework d’Apple prend en charge OpenIntent (ouvrir simplement l’application sur un contexte), mais si la seule action utile est « ouvrir l’application », l’intention est une charge inutile. Ne l’expédiez pas pour le simple fait d’en avoir une.

Si l’action dépend d’affordances d’interface utilisateur difficiles à abstraire (un outil de canevas multi-étapes complexe, une application d’édition 3D), le parameterSummary requis de l’intention dégénérera en pseudo-langage naturel vague que personne ne dit réellement. La phrase Siri « edit my photo with the blur tool at strength 7 » est techniquement possible, mais aucun humain ne la prononcera. La surface de l’intention est un impôt sans contrepartie.

La bonne règle : un App Intent justifie sa présence quand il existe une phrase qu’un utilisateur dirait naturellement et qui déclenche l’action. « Log 8 oz of water » est cette phrase. « Apply Gaussian blur with sigma 2.4 to layer 3 » ne l’est pas. Si les actions de votre application se regroupent autour du second motif, les intentions ne sont pas votre levier de conversion.

La conclusion

Depuis trois ans, Apple signale que la trame d’IA système d’iOS passe par les App Intents. La WWDC 2024 a ajouté l’acheminement Apple Intelligence à travers eux. La WWDC 2025 a ajouté Foundation Models à côté en tant que surface d’appel d’outils intra-application distincte, laissant les App Intents comme contrat inter-application que Siri / Spotlight / Apple Intelligence continuent d’utiliser. Tous les signaux pointent dans la même direction : l’App Intent typé et déclaratif est le contrat que les applications tierces signent désormais avec le système.

La plupart des applications iOS traitent encore les App Intents comme des Siri Shortcuts : une fonctionnalité à expédier si vous avez le temps. Ma lecture est que ce cadrage va mal vieillir. À mesure que les surfaces système d’Apple Intelligence s’étendent (déjà à travers Siri, Spotlight, Shortcuts et les résumés Apple Intelligence aujourd’hui), les applications sans intentions déclarées risquent de se retrouver hors du graphe de routage. La surface du premier à se positionner, d’après mon expérience à observer les autres paris plateforme d’Apple, se cumule.

Water dispose de LogWaterIntent depuis onze semaines. La quantité de code nécessaire pour expédier un App Intent est suffisamment réduite pour tenir dans un seul fichier. Le coût de ne pas l’expédier croît à chaque sortie d’Apple Intelligence.

Si vous expédiez une application iOS en 2026 et que vous n’avez pas déclaré au moins un App Intent, votre feuille de route comporte une ligne manquante. Ajoutez-la.

FAQ

Qu’est-ce qu’un App Intent dans le développement iOS ?

Un App Intent est une structure Swift typée et déclarative qui expose l’une des actions de votre application aux surfaces d’IA système d’Apple. Elle déclare des paramètres via @Parameter, un résumé en langage naturel via parameterSummary, et un corps perform() asynchrone qui effectue le travail et retourne un résultat structuré. Siri, Spotlight, Shortcuts et Apple Intelligence d’Apple peuvent l’appeler. Foundation Models (le LLM embarqué d’Apple) utilise un protocole Tool distinct pour les appels d’outils intra-application directs.

En quoi App Intents diffère-t-il de l’ancien INIntent ?

App Intents (introduit avec iOS 16, en 2022) a remplacé INIntent comme framework d’intentions principal d’Apple. Le framework plus récent est entièrement natif Swift, utilise des property wrappers comme @Parameter, prend en charge des requêtes d’entités typées via AppEntity, et constitue la surface que Siri, Spotlight, Shortcuts et Apple Intelligence appellent. L’ancien INIntent est toujours pris en charge mais ne reçoit plus de nouveau travail de fonctionnalité.

Faut-il iOS 26 pour expédier un App Intent ?

Non. Les App Intents sont disponibles à partir d’iOS 16. iOS 26 ajoute le framework Foundation Models à côté, mais les déclarations d’App Intent elles-mêmes fonctionnent sur iOS 16+. L’exemple de code ci-dessus utilise SwiftData (iOS 17+) donc la cible de déploiement dépend de ce que votre corps perform() importe. Les App Intents nus fonctionnent jusqu’à iOS 16 ; ceux soutenus par SwiftData nécessitent iOS 17.

Quelle est la différence entre un App Intent et une App Entity ?

Un App Intent est une action (verbe). Une App Entity est la donnée que votre application connaît (nom). LogWaterIntent est une intention. WaterEntry devenant un type interrogeable est une entité. Apple Intelligence utilise les deux : les intentions pour effectuer des actions, les entités pour récupérer et référencer des données dans les réponses.

Comment les App Intents se rapportent-ils à l’appel d’outils Foundation Models ?

Foundation Models expose son propre protocole Tool pour les appels d’outils LLM intra-application directs. Les App Intents restent la surface canonique inter-application qu’appellent Apple Intelligence, Siri et Spotlight. Même direction (utilisation d’outils typés et déclaratifs) ; deux contrats parallèles. Une application qui veut être joignable par les surfaces d’IA système expédie des App Intents ; une application qui veut appeler son propre LLM embarqué avec des outils personnalisés expédie des conformités Tool. Beaucoup d’applications expédieront les deux.

Les App Intents ne sont pas une fonctionnalité. Ils sont le contrat. L’application qui expédie l’intention en premier obtient la surface ; l’application qui l’expédie plus tard trouve la surface déjà acheminée ailleurs. Il y a onze semaines, j’en ai expédié une dans Water. Le cumul a déjà commencé.

Plus dans la série Apple Ecosystem

Cet essai est le point d’entrée. Les quatre autres couvrent le reste de la pile d’architecture :

• Two Agent Ecosystems, One Shopping List : comment Get Bananas expose les mêmes données à Apple Intelligence (App Intents) et à Claude Desktop (MCP) via un seul fichier JSON dans iCloud Drive.
• Liquid Glass in SwiftUI: Three Patterns From Shipping Return : motifs de production pour la couche visuelle d’iOS 26.
• Five Apple Platforms, Three Shared Files : la stratégie d’expédition multi-plateforme, quand partager le code et quand bifurquer les cibles.
• HealthKit + SwiftUI on iOS 26 : la couche source de données des flux d’autorisation, types d’échantillons et le piège qui exclut les utilisateurs de votre application.

Ou rendez-vous au hub complet : Apple Ecosystem Series. Pour le contexte plus large iOS-avec-agents-IA, consultez le guide iOS Agent Development.

Références