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 plus un AppShortcutsProvider déclarant trois variantes de phrases Siri. Ce fichier est désormais la API la plus brûlante que je possède.²

Voici la partie qu’il m’a fallu un certain temps à intérioriser. Les App Intents ne sont pas une fonctionnalité Siri. Ils 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 a continué à construire jusqu’à iOS 26.³ Si vous publiez une application iOS et que vous traitez encore les App Intents comme une fonctionnalité vocale « agréable à avoir », vous lisez 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 pour le compte de l’utilisateur. Tout le reste (Siri, Spotlight, Shortcuts, les résumés Apple Intelligence, les surfaces Watch et Vision Pro) est en aval de ce contrat. Foundation Models, le LLM on-device livré dans iOS 26, expose un protocole Tool distinct pour l’appel d’outils intégrés à 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 d’une manière typée et structurée qu’Apple’s AI peut appeler directement. Ils sont la API d’utilisation d’outils d’Apple pour les applications tierces.
• Un véritable exemple de production : LogWaterIntent dans Water. 80 lignes, écriture SwiftData complète, synchronisation HealthKit, conversion d’unités tenant compte de la locale, réponse de dialogue Siri structurée.
• iOS 26 a ajouté Foundation Models, le LLM on-device d’Apple. Foundation Models expose son propre protocole Tool pour l’utilisation d’outils intégrés à 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. Le tissu d’IA passe par vos intents déclarés ou contourne votre application pour aller chez 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.

Ce qu’est réellement un App Intent

La source complète de LogWaterIntent telle qu’elle a été livrée 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 itère le dialogue plus loin avec une condition d’objectif atteint/quantité restante. Le code livré le 8 février ci-dessus est celui que j’ai testé devant l’évier de la cuisine.)

Trois choses ici méritent d’être nommées car 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 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’interface 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. Mal le rédiger et l’utilisateur entend une phrase laide ; bien le rédiger et la surface paraît native.⁶

perform() retourne IntentResult & ProvidesDialog. C’est le retour structuré : la surface d’IA reçoit non seulement un succès/échec mais aussi une chaîne de dialogue que l’utilisateur entend. Apple s’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 NL d’Apple plus de marge pour faire correspondre la formulation de l’utilisateur sans que vous ne mainteniez un dictionnaire de phrases. Le systemImageName est un véritable nom SF Symbols ; c’est ainsi que Spotlight, Shortcuts et Apple Intelligence affichent l’icône de l’action.

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

Les APIs 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 sont une troisième forme : ils sont la façon 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 que 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 : toute application pouvait faire don d’une NSUserActivity ou d’un INIntent et espérer que Siri la suggère.
• iOS 13 (2019) a ajouté la gestion des intents dans l’application afin que les applications puissent répondre aux invocations de raccourcis sans passer en arrière-plan vers 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 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 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 on-device d’Apple. Foundation Models expose un protocole Tool distinct pour l’appel d’outils intégrés à l’application. Les App Intents restent la surface canonique inter-applications pour Apple Intelligence, tandis que Tool est la surface intégrée pour les appels directs au LLM. 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 tapotant sur Shortcuts. Puis la voix Siri. Puis Spotlight. Puis les résumés Apple Intelligence. Maintenant, les surfaces système soutenues par le LLM d’Apple Intelligence les utilisent pour agir sur les requêtes de l’utilisateur. La surface App Intent que vous publiez en 2026 est celle qu’Apple Intelligence appellera sur iOS 27, 28, 29.

Le motif ci-dessus est ce que je veux dire lorsque j’affirme que les App Intents ne sont pas une fonctionnalité Siri. Ils sont la API d’utilisation d’outils structurée pour l’ensemble du tissu d’IA d’Apple. SwiftUI a été la API d’UI la plus importante car elle est devenue la seule façon d’écrire une application pour visionOS, watchOS 10+ et iOS 17+. Les App Intents suivent le même arc côté IA : la surface où Apple place tous ses paris.

Ce qui change maintenant que Foundation Models a été livré

Foundation Models est le framework qui est livré sur tous les appareils éligibles à 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. Notamment 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 à travers les App Intents et les App Entities. Il n’existe pas de API setSystemPrompt(...) pour les applications tierces dans le tissu d’IA système. Il y a le registre d’intents. Foundation Models ajoute une surface Tool parallèle dans l’application pour les développeurs qui veulent leurs propres fonctionnalités LLM on-device. 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 d’abord des phrases comme « Hey Siri, log my water » vers les applications qui ont déclaré l’intent correspondant. 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 de routage se sont déjà accumulées en faveur des premiers arrivants. 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 arrivant sur les déclarations d’intents s’amplifie comme cela a été le cas pour d’autres APIs phares de la plateforme Apple (catégories HealthKit, résultats riches Spotlight, jetons Live Activities).

La personnalisation Apple Intelligence lit depuis les App Entities, pas seulement les intents. 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 cherche chaque AppEntity correspondant à Book à travers chaque application installée. Si votre application possède une liste de lecture et qu’aucun BookEntity n’est déclaré, 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’intent en réponses plus longues à travers Siri, Spotlight et la Watch. Un perform() qui retourne juste 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 optionnelle ; 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.

Livrez plus d’intents que vous ne le pensez nécessaire. 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 manqué est une requête qu’Apple Intelligence contourne à mes dépens.

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 AirPods a besoin d’une structure courte, concrète, axée sur les faits : « 8 oz enregistrées. 32 oz restantes. » La surface Watch en particulier tronque agressivement. Le dialogue conversationnel offre une moins bonne expérience utilisateur que le dialogue factuel et confiant. 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 un WaterEntryEntity: AppEntity plus son compagnon WaterEntryQuery: EntityQuery pour qu’Apple Intelligence puisse répondre à « montre-moi quand j’ai bu de l’eau hier ». 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())")
    }
    var amount: Int
    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 le code de récupération SwiftData. Pour rendre les entrées individuellement accessibles dans Spotlight (afin que les utilisateurs cherchant « water » atterrissent sur la bonne entrée), conformez 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 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 LLM, deux contrats différents, la même liste de courses. C’est la thèse des contrats parallèles 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 de Anthropic, les deux surfaces opèrent sur la même source de vérité.

Quand ne pas livrer un 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 mutable, les App Intents peuvent n’avoir rien à exposer. Le framework d’Apple prend en charge OpenIntent (juste ouvrir l’application sur un contexte) mais si la seule action utile est « ouvrir l’application », l’intent est de la surcharge. N’en livrez pas un pour le simple fait d’en avoir un.

Si l’action dépend d’éléments d’interface difficiles à abstraire (un outil de canevas multi-étapes complexe, une application d’édition 3D), le parameterSummary requis par l’intent va dégénérer en un pseudo-langage naturel vague que personne ne dit réellement. 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 gagne sa place 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 sur le second motif, les intents ne sont pas votre levier de conversion.

La conclusion

Depuis trois ans, Apple signale que le tissu d’IA système d’iOS passe par les App Intents. La WWDC 2024 a ajouté le routage Apple Intelligence à travers eux. La WWDC 2025 a ajouté Foundation Models à côté en tant que surface distincte d’appel d’outils intégrée à l’application, laissant les App Intents comme 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 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 intents déclarés vont probablement se retrouver hors du graphe de routage. La surface du premier arrivant, d’après mon expérience à observer les autres paris de plateforme d’Apple, s’amplifie.

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

Si vous publiez une application iOS en 2026 et que vous n’avez pas déclaré au moins un App Intent, votre feuille de route a 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. 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 on-device d’Apple) utilise un protocole Tool distinct pour les appels d’outils directs intégrés à l’application.

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

App Intents (introduit dans iOS 16, 2022) a remplacé INIntent comme framework d’intent 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 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 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 un App Entity ?

Un App Intent est une action (verbe). Un App Entity est les données 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 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 canonique inter-applications 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 joignable par les surfaces d’IA système livre des App Intents ; une application qui veut appeler son propre LLM on-device avec des outils personnalisés livre des conformités à Tool. De nombreuses applications livreront les deux.

Les App Intents ne sont pas une fonctionnalité. Ils 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. L’amplification a déjà commencé.

Références