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

Au matin du 8 février 2026, j’ai demandé à Siri d’enregistrer 8 oz d’eau depuis mon Apple Watch alors que j’avais les mains 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 plus un AppShortcutsProvider déclarant trois variantes de phrases Siri. Ce fichier est désormais la surface d’API la plus brûlante que je possède.²

Voici la partie qu’il m’a fallu un certain temps pour intérioriser. Les App Intents ne sont pas une fonctionnalité de Siri. Ce sont le contrat que les applications tierces signent avec Apple Intelligence, l’IA système qu’Apple a commencé à déployer dans iOS 18 et a continué à bâtir jusqu’à iOS 26.³ Si vous publiez une application iOS et que vous traitez toujours les App Intents comme une fonctionnalité vocale « pratique mais accessoire », vous interprétez mal ce qu’Apple a construit. Les App Intents sont l’API qui permet à l’IA d’Apple d’agir en tant que votre application pour le compte de l’utilisateur. Tout le reste (Siri, Spotlight, Shortcuts, les résumés d’Apple Intelligence, les surfaces Watch et Vision Pro) découle de ce contrat. Foundation Models, le LLM sur l’appareil livré dans iOS 26, expose un protocole Tool distinct pour l’appel d’outils intégré à l’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, que l’IA d’Apple peut appeler directement. Ce sont l’API d’utilisation d’outils d’Apple pour les applications tierces.
• Un exemple de production concret : LogWaterIntent dans Water. 80 lignes, écriture SwiftData complète, synchronisation HealthKit, conversion d’unités tenant compte de la langue, réponse de dialogue Siri structurée.
• iOS 26 a ajouté Foundation Models, le LLM sur l’appareil d’Apple. Foundation Models expose son propre protocole Tool pour l’utilisation d’outils intégrée à l’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 intents déclarés, sinon elle contourne votre application au profit d’un concurrent.
• Apple nous le dit depuis trois ans. La dénomination (App Intents, App Shortcuts, Apple Intelligence) est délibérée. 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é livré 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 de production actuelle de ce fichier dans Water fait évoluer le dialogue plus loin avec une condition objectif-atteint/quantité-restante. Le code livré le 8 février ci-dessus est celui que j’ai testé à l’évier de la cuisine.)

Trois choses ici méritent d’être nommées, 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(). Il n’y a aucune analyse de chaîne de caractères 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 afficher l’action dans l’UI de Shortcuts, dans le dialogue, et de plus en plus dans les panneaux de confirmation d’Apple Intelligence. Le résumé est lu à voix haute à l’utilisateur. Ratez-le et l’utilisateur entend une phrase disgracieuse ; réussissez-le et la surface paraît native.⁶

perform() renvoie 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 le même intent donnent à l’analyseur de langage naturel d’Apple plus de marge pour correspondre à la formulation de l’utilisateur sans que vous ayez à maintenir un dictionnaire de phrases. Le systemImageName est un nom de SF Symbols réel ; c’est ainsi que Spotlight, Shortcuts et Apple Intelligence affichent l’icône de l’action.

Apple Intelligence achemine les requêtes de l’utilisateur à travers les App Intents pour fournir des fonctionnalités d’IA sur l’appareil. Source : apple.com/apple-intelligence.

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

Les API iOS se présentent sous deux formes. Certaines concernent la façon dont votre application se dessine elle-même (UIKit, SwiftUI, Metal). D’autres concernent la façon dont votre application s’intègre au système (schémas d’URL, Universal Links, widgets). Les App Intents constituent une troisième forme : c’est la façon dont l’IA d’Apple utilise votre application. Ces surfaces widgets et Control Center sont elles-mêmes des surfaces d’App Intents, le même intent rendu à de multiples endroits, ce que je retrace dans La surface des widgets d’iOS 26.

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

• iOS 10 (2016) a introduit les SiriKit Intents (INIntent), la première fois que des applications tierces pouvaient être adressées par la voix. La surface était étroite : une liste fixe de domaines (messagerie, paiements, réservation de course) avec des schémas stricts.⁸
• iOS 12 (2018) a élargi la surface avec Siri Shortcuts : n’importe quelle application pouvait faire don d’un NSUserActivity ou d’un INIntent et espérer que Siri la suggère.
• iOS 13 (2019) a ajouté la gestion des intents au sein de l’application afin que les applications puissent répondre aux invocations de raccourcis sans passer en arrière-plan vers l’UI système de Siri.
• iOS 16 (2022) a introduit le framework App Intents : typé, déclaratif, avec @Parameter et AppShortcutsProvider. Le prédécesseur INIntent a été effectivement remplacé pour les nouveaux développements.⁹
• iOS 18 (2024) a introduit Apple Intelligence et a commencé à acheminer les requêtes Siri à travers les App Intents dans la mesure du possible. La fonctionnalité de « contexte personnel » d’Apple Intelligence lit à partir des App Entities (la version données des App Intents).¹⁰ iOS 27 va plus loin avec les App Schemas, qui permettent à Siri de raisonner sur vos entités et d’agir dessus dans des termes qu’elle comprend déjà sans aucune phrase d’entraînement, traités ici.
• iOS 26 (2025) a introduit le framework Foundation Models, le LLM sur l’appareil d’Apple. Foundation Models expose un protocole Tool distinct pour l’appel d’outils intégré à l’application. Les App Intents restent la surface inter-applications canonique pour Apple Intelligence, tandis que Tool est la surface intégrée pour les appels LLM directs. Les deux contrats fonctionnent en parallèle.⁴

Le contrat s’est étendu vers le haut de la pile à chaque version. À l’origine, le consommateur d’un App Intent était une personne tapant dans Shortcuts. Puis la voix de Siri. Puis Spotlight. Puis les résumés d’Apple Intelligence. Désormais, les surfaces système d’Apple Intelligence reposant sur un LLM les utilisent pour agir sur les requêtes des utilisateurs. La surface d’App Intent que vous livrez en 2026 est celle qu’Apple Intelligence appellera sous iOS 27, 28, 29.

Le schéma ci-dessus est ce que je veux dire lorsque j’affirme que les App Intents ne sont pas une fonctionnalité de Siri. Ce sont l’API d’utilisation d’outils structurée pour l’ensemble de la trame d’IA d’Apple. SwiftUI était l’API d’interface la plus importante parce qu’elle est devenue la seule façon d’écrire une application pour visionOS, watchOS 10+ et iOS 17+. Les App Intents suivent la même trajectoire côté IA : la surface sur laquelle Apple mise tout.

Ce qui change maintenant que Foundation Models est livré

Foundation Models est le framework livré sur chaque appareil éligible à Apple Intelligence. La limite matérielle est la même que la liste 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 : les 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 à travers les App Intents et les App Entities. Il n’existe pas d’API setSystemPrompt(...) pour les applications tierces dans la trame d’IA système. Il y a le registre des intents. Foundation Models ajoute une surface Tool parallèle intégrée à l’application pour les développeurs qui veulent leurs propres fonctionnalités de LLM sur l’appareil. Le contrat inter-applications (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 accessible 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’intent correspondant en premier. J’ai livré l’intent de Water en février 2026. Ma lecture de la direction du framework : les applications d’hydratation qui livreront l’intent en 2027 entreront sur un marché où les pondérations d’acheminement se seront déjà accumulées au profit des précurseurs. 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 précurseur sur les déclarations d’intents se cumule comme il l’a fait pour d’autres API stratégiques de la plateforme Apple (catégories HealthKit, résultats enrichis Spotlight, jetons Live Activities).

La personnalisation d’Apple Intelligence lit à partir des App Entities, pas seulement des intents. Une 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 recherche dans chaque AppEntity correspondant à Book dans toutes les applications installées. Si votre application possède une liste de lecture et aucune BookEntity 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 est de plus en plus importante. Apple Intelligence compose les résultats d’intents en réponses plus longues à travers Siri, Spotlight et la Watch. Un perform() qui se contente de renvoyer un succès sans dialogue structuré est plus difficile à composer par le système 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 journaux de production dans Water me révèlent trois choses que j’aurais dû faire plus tôt.

Livrez plus d’intents que vous ne pensez en avoir besoin. J’en ai livré un. J’aurais dû en livrer quatre : LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent. Chacun correspond à une phrase Siri que les utilisateurs essaient réellement (« combien d’eau ai-je bu aujourd’hui » acheminée vers l’IA générique d’Apple plutôt que vers les données de mon application). Chaque intent manquant est une requête qu’Apple Intelligence contourne pour m’éviter.

La chaîne de dialogue n’est pas le corps d’un e-mail. J’avais ProvidesDialog dès le départ, mais mon dialogue initial était de la prose. L’utilisateur qui l’entend via CarPlay ou des AirPods a besoin d’une structure courte, concrète et factuelle : « 8 oz enregistrées. 32 oz restantes. » La surface Watch en particulier tronque agressivement. Un dialogue conversationnel est une moins bonne expérience utilisateur qu’un dialogue factuel et assuré. J’ai réécrit le mien à la semaine 4.²

Les App Entities comptent plus que je ne le pensais. J’ai un modèle SwiftData WaterEntry. Je devrais aussi déclarer une WaterEntryEntity: AppEntity ainsi que sa WaterEntryQuery: EntityQuery associée, afin qu’Apple Intelligence puisse répondre à « montre-moi quand j’ai bu de l’eau hier ». Le pont 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 colle de récupération SwiftData. Pour rendre les entrées individuellement repérables dans Spotlight (afin que les utilisateurs cherchant « water » tombent sur la bonne entrée), faites conformer l’entité à IndexedEntity et faites don des mises à jour d’index lors des écritures. C’est ce que le pipeline Spotlight d’Apple attend au-delà de la simple exposition d’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, plus un champ lastModified pour la synchronisation iCloud Drive.¹³ L’envelopper en ShoppingItemEntity: AppEntity et livrer quelques intents (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 de 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 livrée : le modèle SwiftData est la donnée, les App Intents sont le contrat d’Apple, MCP est le contrat d’Anthropic, les deux surfaces opèrent sur la même source de vérité.

Quand ne pas livrer d’App Intent

Le refus fait partie de la conception.

Si votre application est purement axée sur la consommation (lecture des photos de l’utilisateur, affichage d’actualités, lecture audio) sans état utilisateur modifiable, les App Intents peuvent n’avoir rien à exposer. Le framework d’Apple prend en charge OpenIntent (se contenter d’ouvrir l’application sur un contexte) mais si la seule action utile est « ouvrir l’application », l’intent n’est qu’une surcharge. N’en livrez pas pour le simple plaisir d’en avoir un.

Si l’action dépend d’affordances d’interface difficiles à abstraire (un outil de canevas complexe à plusieurs étapes, une application d’édition 3D), le parameterSummary requis par l’intent dégénérera en un pseudo-langage-naturel vague que personne ne prononce vraiment. La phrase Siri « édite ma photo avec l’outil de flou à l’intensité 7 » est techniquement possible mais aucun humain ne la prononcera. La surface de l’intent est une taxe 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. « Enregistre 8 oz d’eau » est cette phrase. « Applique un flou gaussien avec sigma 2,4 au calque 3 » ne l’est pas. Si les actions de votre application se concentrent sur le second schéma, les intents ne sont pas votre levier de conversion.

Le mot de la fin

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 d’Apple Intelligence à travers eux. La WWDC 2025 a ajouté Foundation Models à côté, comme une surface distincte d’appel d’outils intégrée à l’application, laissant les App Intents comme le contrat inter-applications 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é à livrer si on a 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 d’Apple Intelligence aujourd’hui), les applications sans intents déclarés risquent de se retrouver hors du graphe d’acheminement. La surface du précurseur, d’après mon expérience de l’observation des autres paris de plateforme d’Apple, se cumule.

Water a LogWaterIntent livré depuis onze semaines. La quantité de code qui livre un App Intent est assez petite pour tenir dans un seul fichier. Le coût de ne pas le livrer croît à chaque version d’Apple Intelligence.

Si vous livrez une application iOS en 2026 et que vous n’avez pas déclaré au moins un App Intent, votre feuille de route comporte un élément manquant. Ajoutez-le.

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. Il 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 renvoie un résultat structuré. Siri, Spotlight, Shortcuts et Apple Intelligence d’Apple peuvent l’appeler. Foundation Models (le LLM sur l’appareil d’Apple) utilise un protocole Tool distinct pour les appels d’outils directs intégrés à l’application.

En quoi les App Intents diffèrent-ils de l’ancien INIntent ?

Les App Intents (introduits dans iOS 16, 2022) ont remplacé INIntent comme framework d’intents 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 à typage sûr 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 aucun nouveau travail de fonctionnalité.

Ai-je besoin d’iOS 26 pour livrer 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 sous 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 simples fonctionnent jusqu’à iOS 16 ; ceux reposant sur 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 un intent. WaterEntry devenant un type interrogeable est une entité. Apple Intelligence utilise les deux : les intents 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 de Foundation Models ?

Foundation Models expose son propre protocole Tool pour les appels d’outils LLM directs intégrés à l’application. Les App Intents restent la surface inter-applications canonique qu’Apple Intelligence, Siri et Spotlight appellent. Même direction (utilisation d’outils typée et déclarative) ; deux contrats parallèles. Une application qui veut être accessible par les surfaces d’IA système livre des App Intents ; une application qui veut appeler son propre LLM sur l’appareil avec des outils personnalisés livre des conformités Tool. De nombreuses applications livreront les deux.

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

Plus dans la série Écosystème Apple

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

• Deux écosystèmes d’agents, une seule liste de courses : comment Get Bananas expose les mêmes données à Apple Intelligence (App Intents) et à Claude Desktop (MCP) à travers un seul fichier JSON dans iCloud Drive.
• Liquid Glass dans SwiftUI : trois patterns issus de la livraison de Return : des patterns de production pour la couche visuelle d’iOS 26.
• Cinq plateformes Apple, trois fichiers partagés : la stratégie de livraison multiplateforme, quand partager le code et quand bifurquer les cibles.
• HealthKit + SwiftUI sous iOS 26 : la couche source de données des flux d’autorisation, des types d’échantillons, et le piège qui verrouille les utilisateurs hors de votre application.

Ou rendez-vous directement sur le hub complet : Série Écosystème Apple. Pour le contexte plus large d’iOS avec des agents d’IA, consultez le guide de développement d’agents iOS.

Références