App Intents sind Apples neue API zu Ihrer App

Am Morgen des 8. Februar 2026 bat ich Siri, 8 oz Wasser von meiner Apple Watch zu protokollieren, während meine Hände unter dem Küchenwasserhahn waren. Das Wasser wurde protokolliert. Der Watch-Dialog meldete 32 oz verbleibend. Ich hatte keinen Bildschirm berührt.¹

Elf Wochen zuvor hatte ich eine einzelne Swift-Datei zu Water hinzugefügt, meiner Hydratations-Tracking-iOS-App: LogWaterIntent.swift, 80 Zeilen AppIntent plus ein AppShortcutsProvider, der drei Siri-Phrasen-Varianten deklariert. Diese Datei ist mittlerweile die wichtigste API-Oberfläche, die ich besitze.²

Hier ist der Teil, den ich erst nach einer Weile verinnerlicht habe. App Intents sind keine Siri-Funktion. Sie sind der Vertrag, den Drittanbieter-Apps mit Apple Intelligence schließen, jenen System-KI-Oberflächen, die Apple in iOS 18 einzuführen begann und durch iOS 26 weiter ausbaute.³ Wenn Sie eine iOS-App veröffentlichen und App Intents immer noch als „nice to have”-Sprachfunktion behandeln, dann verkennen Sie, was Apple gebaut hat. App Intents sind die API, die es Apples KI ermöglicht, als Ihre App im Auftrag des Benutzers zu agieren. Alles andere (Siri, Spotlight, Shortcuts, Apple Intelligence-Zusammenfassungen, die Watch- und Vision Pro-Oberflächen) ist diesem Vertrag nachgelagert. Foundation Models, das in iOS 26 eingeführte On-Device-LLM, stellt ein separates Tool-Protokoll für In-App-Tool-Aufrufe bereit; es läuft parallel zu App Intents und nicht durch sie hindurch.

TL;DR

• App Intents deklarieren auf typisierte, strukturierte Weise, was Ihre App tun kann, sodass Apples KI sie direkt aufrufen kann. Sie sind Apples Tool-Use-API für Drittanbieter-Apps.
• Ein echtes Produktionsbeispiel: LogWaterIntent in Water. 80 Zeilen, vollständiger SwiftData-Schreibvorgang, HealthKit-Sync, gebietsschemabewusste Einheitenkonvertierung, strukturierte Siri-Dialogantwort.
• iOS 26 brachte Foundation Models, Apples On-Device-LLM. Foundation Models stellt ein eigenes Tool-Protokoll für In-App-Tool-Use bereit; App Intents bleiben die kanonische Oberfläche, die Siri / Spotlight / Apple Intelligence app-übergreifend aufrufen. Gleiche Richtung, zwei parallele Verträge.
• Eine App ohne App Intents ist 2026 für Apple Intelligence unsichtbar. Das KI-Geflecht leitet entweder über Ihre deklarierten Intents oder umgeht Ihre App und wendet sich an einen Konkurrenten.
• Apple kommuniziert uns das seit drei Jahren. Die Namensgebung (App Intents, App Shortcuts, Apple Intelligence) ist Absicht. Der Vertrag steigt mit jeder WWDC eine Stack-Ebene höher.

Was ein App Intent tatsächlich ist

Der vollständige Quellcode von LogWaterIntent, wie er in Commit e398c58 am 8. Februar 2026 ausgeliefert wurde:²

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"
        )
    }
}

(Die aktuelle Produktionsversion dieser Datei in Water entwickelt den Dialog mit einer Konditional-Logik für „Ziel erreicht / verbleibende Menge” weiter. Der oben gezeigte Code vom 8. Februar ist derjenige, den ich am Küchenwasserhahn getestet habe.)

Drei Dinge sind hier erwähnenswert, weil die meisten „App Intents-Tutorials” sie übergehen.

Der @Parameter ist das Schema. Apples KI sieht amount: Int mit einem Standardwert von 8. Wenn Siri „log 12 oz of water” parst, erzeugt sie LogWaterIntent(amount: 12) und ruft perform() auf. Auf meiner Seite findet kein String-Parsing statt. Das Typsystem ist das Schema.⁵

parameterSummary ist die natürlichsprachliche Reflexion des Parameters. Apple verwendet sie, um die Aktion in der Shortcuts-UI, im Dialog und zunehmend in den Bestätigungsbereichen von Apple Intelligence darzustellen. Die Summary wird dem Benutzer vorgelesen. Falsch formuliert, hört der Benutzer einen hässlichen Satz; richtig formuliert, fühlt sich die Oberfläche nativ an.⁶

perform() gibt IntentResult & ProvidesDialog zurück. Das ist die strukturierte Rückgabe: Die KI-Oberfläche erhält nicht nur Erfolg/Fehlschlag zurück, sondern auch eine Dialog-Zeichenkette, die der Benutzer hört. Apple erwartet zunehmend ProvidesDialog, ProvidesView oder ReturnsValue, damit sich das Ergebnis in Siri, Spotlight, die Watch und (in iOS 26) in die Antwortkette von Apple Intelligence einfügt.⁷

Der AppShortcutsProvider-Block am Ende registriert die Siri-Phrasen. Das \(.applicationName)-Token ist die Stelle, an der Siri automatisch „Water” einsetzt. Drei Phrasen-Varianten mit demselben Intent geben Apples NL-Parser mehr Spielraum, um Benutzerformulierungen zu erkennen, ohne dass Sie ein Phrasen-Wörterbuch pflegen müssen. Der systemImageName ist ein echter SF-Symbols-Name; so rendern Spotlight, Shortcuts und Apple Intelligence das Symbol der Aktion.

Warum dies die wichtigste iOS-API seit SwiftUI ist

iOS-APIs gibt es in zwei Formen. Manche bestimmen, wie Ihre App sich zeichnet (UIKit, SwiftUI, Metal). Andere bestimmen, wie Ihre App sich in das System integriert (URL-Schemata, Universal Links, Widgets). App Intents sind eine dritte Form: Sie bestimmen, wie Apples KI Ihre App nutzt.

Die Entwicklung lohnt sich nachzuvollziehen.

• iOS 10 (2016) führte SiriKit Intents (INIntent) ein, das erste Mal, dass Drittanbieter-Apps per Sprache angesprochen werden konnten. Die Oberfläche war eng: eine feste Liste von Domänen (Messaging, Zahlungen, Mitfahrgelegenheiten) mit strengen Schemata.⁸
• iOS 12 (2018) erweiterte die Oberfläche mit Siri Shortcuts: jede App konnte ein NSUserActivity oder INIntent spenden und hoffen, dass Siri es vorschlug.
• iOS 13 (2019) ergänzte die In-App-Intent-Verarbeitung, sodass Apps auf Shortcut-Aufrufe reagieren konnten, ohne in die System-Siri-UI gehen zu müssen.
• iOS 16 (2022) führte das App Intents-Framework ein: typisiert, deklarativ, mit @Parameter und AppShortcutsProvider. Der Vorgänger INIntent war für neue Entwicklungen faktisch abgelöst.⁹
• iOS 18 (2024) führte Apple Intelligence ein und begann, Siri-Anfragen wo möglich über App Intents zu leiten. Die „Personal Context”-Funktion von Apple Intelligence liest aus App Entities (der Datenversion von App Intents).¹⁰
• iOS 26 (2025) führte das Foundation Models-Framework ein, Apples On-Device-LLM. Foundation Models stellt ein separates Tool-Protokoll für In-App-Tool-Aufrufe bereit. App Intents bleiben die kanonische app-übergreifende Oberfläche für Apple Intelligence, während Tool die In-App-Oberfläche für direkte LLM-Aufrufe ist. Die beiden Verträge laufen parallel.⁴

Der Vertrag ist mit jedem Release in der Stack-Ebene weiter nach oben gerückt. Ursprünglich war der Konsument eines App Intent eine Person, die in Shortcuts tippte. Dann Siri-Sprache. Dann Spotlight. Dann Apple Intelligence-Zusammenfassungen. Jetzt nutzen die LLM-gestützten Systemoberflächen von Apple Intelligence sie, um auf Benutzeranfragen zu reagieren. Die App-Intent-Oberfläche, die Sie 2026 ausliefern, ist diejenige, die Apple Intelligence auf iOS 27, 28, 29 aufrufen wird.

Das obige Muster ist es, was ich meine, wenn ich sage, App Intents seien keine Siri-Funktion. Sie sind die API für strukturierten Tool-Use im gesamten KI-Geflecht von Apple. SwiftUI war die wichtigste UI-API, weil es zur einzigen Möglichkeit wurde, eine App für visionOS, watchOS 10+ und iOS 17+ zu schreiben. App Intents zeichnen denselben Bogen auf der KI-Seite nach: die Oberfläche, auf die Apple alle seine Wetten setzt.

Was sich nun ändert, da Foundation Models ausgeliefert wurde

Foundation Models ist das Framework, das auf jedem für Apple Intelligence geeigneten Gerät ausgeliefert wird. Die Hardware-Grenze entspricht der Apple Intelligence-Liste: iPhone 15 Pro und 15 Pro Max (A17 Pro), iPhone 16-Serie, iPhone 17-Serie, iPhone Air, iPhone 17e, iPad Pro mit M1 oder neuer, iPad Air mit M1 oder neuer, iPad mini mit A17 Pro, Vision Pro mit M2 oder neuer und Mac mit M1 oder neuer. Auffällig fehlend: das Basis-iPhone 15 / 15 Plus.⁴¹²

Die Implikation: Wenn Apples Systemoberflächen (Siri, Spotlight, Apple Intelligence) Ihre App überhaupt aufrufen, dann tun sie es über App Intents und App Entities. Es gibt keine setSystemPrompt(...)-API für Drittanbieter-Apps im System-KI-Geflecht. Es gibt das Intent-Register. Foundation Models fügt eine parallele In-App-Tool-Oberfläche für Entwickler hinzu, die ihre eigenen On-Device-LLM-Funktionen wollen. Der app-übergreifende Vertrag (derjenige, den Apple Intelligence und Siri verwenden, um Ihre App zu finden) läuft über App Intents.

Drei konkrete Konsequenzen für App-Entwickler:

Eine App ohne relevanten App Intent ist über einen Siri-Sprachbefehl in ihrer Kategorie nicht erreichbar. Apple Intelligence leitet Phrasen wie „Hey Siri, log my water” zuerst an Apps weiter, die den passenden Intent deklariert haben. Ich habe Waters Intent im Februar 2026 ausgeliefert. Mein Eindruck der Framework-Richtung: Hydratations-Apps, die den Intent 2027 ausliefern, betreten einen Markt, in dem sich die Routing-Gewichte bereits zu Gunsten der Vorreiter angesammelt haben. Dieselbe Logik gilt für Einkaufslisten, Workout-Tracking, Kalendereinträge, Foto-Suchen. Ich erwarte, dass sich der First-Mover-Vorteil bei Intent-Deklarationen kumuliert, so wie bei anderen Apple-Plattform-Wetten-APIs (HealthKit-Kategorien, Spotlight-Rich-Results, Live Activities-Tokens).

Die Apple Intelligence-Personalisierung liest aus App Entities, nicht nur aus Intents. Eine AppEntity deklariert „Diese App enthält Daten dieser Form.” Wenn der Benutzer fragt „Was war das letzte Buch, das ich zu meiner Leseliste hinzugefügt habe?”, durchsucht Apple Intelligence jede AppEntity, die mit Book übereinstimmt, in jeder installierten App. Wenn Ihre App eine Leseliste hat und keine BookEntity deklariert ist, sind Ihre Daten für Apples KI-Oberflächen unsichtbar. Apple Intelligence kann Ihre Daten weder abrufen noch referenzieren.¹¹

Die Rückgabeform IntentResult & ProvidesDialog wird zunehmend wichtig. Apple Intelligence komponiert Intent-Ergebnisse zu längeren Antworten in Siri, Spotlight und der Watch. Ein perform(), das nur Erfolg ohne strukturierten Dialog zurückgibt, ist für das System schwerer zu einer kohärenten Antwort zu komponieren. ProvidesDialog und ProvidesView sind keine optionale Höflichkeit; sie sind die Art und Weise, wie Ihre Aktion zu einem Zitat in der KI-Oberfläche des Benutzers wird.

Was ich anders bauen würde

Elf Wochen Produktionsprotokolle in Water sagen mir drei Dinge, die ich früher hätte tun sollen.

Liefern Sie mehr Intents aus, als Sie für nötig halten. Ich habe einen ausgeliefert. Ich hätte vier ausliefern sollen: LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent. Jeder davon entspricht einer Siri-Phrase, die Benutzer tatsächlich versuchen („wie viel Wasser habe ich heute getrunken” wurde an Apples generische KI geleitet statt an die Daten meiner App). Jeder fehlende Intent ist eine Anfrage, die Apple Intelligence an mir vorbeileitet.

Die Dialog-Zeichenkette ist nicht der Text einer E-Mail. Ich hatte ProvidesDialog von Anfang an, aber mein früher Dialog war Prosa. Der Benutzer, der ihn über CarPlay oder AirPods hört, braucht eine kurze, konkrete, faktengeführte Struktur: „8 oz protokolliert. 32 oz verbleibend.” Insbesondere die Watch-Oberfläche kürzt aggressiv. Konversationeller Dialog ist eine schlechtere Benutzererfahrung als selbstbewusst-faktischer Dialog. Ich habe meinen in Woche 4 umgeschrieben.²

App Entities sind wichtiger, als ich dachte. Ich habe ein WaterEntry-SwiftData-Modell. Ich sollte zudem eine WaterEntryEntity: AppEntity plus deren Begleiter WaterEntryQuery: EntityQuery deklarieren, damit Apple Intelligence beantworten kann „Zeige mir, wann ich gestern Wasser getrunken habe.” Die minimale Brücke:¹¹

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
    }
}

Zwei kleine Swift-Typen plus die SwiftData-Fetch-Verbindung. Damit einzelne Einträge in Spotlight individuell auffindbar werden (sodass Benutzer, die nach „water” suchen, beim richtigen Eintrag landen), lassen Sie die Entity zu IndexedEntity konformieren und spenden Sie bei Schreibvorgängen Index-Updates. Das erwartet Apples Spotlight-Pipeline über die bloße AppEntity-Bereitstellung hinaus.

Dieselbe Form gilt auch für andere meiner Apps. Get Bananas, meine Einkaufslisten-App, hat bereits ein SwiftData-@Model ShoppingItem mit @Attribute(.unique) var id: UUID, name, amount, section, isChecked plus einem lastModified-Feld für iCloud Drive-Sync.¹³ Wenn man es als ShoppingItemEntity: AppEntity umhüllt und einige Intents (AddShoppingItem, CheckOffItem, ShowList) ausliefert, würde dies dieselbe Persistenzschicht für Apple Intelligence offenlegen, die Get Bananas bereits Claude Desktop über seinen .mcpb-MCP-Server bereitstellt.¹⁴ Zwei LLM-Ökosysteme, zwei verschiedene Verträge, dieselbe Einkaufsliste. Das ist die These der parallelen Verträge in einer einzigen ausgelieferten App: Das SwiftData-Modell ist die Daten, App Intents sind Apples Vertrag, MCP ist Anthropics Vertrag, beide Oberflächen operieren auf derselben Datenquelle.

Wann Sie keinen App Intent ausliefern sollten

Verzicht ist Teil des Designs.

Wenn Ihre App rein konsumgetrieben ist (Anzeigen der Fotos des Benutzers, Anzeigen von Nachrichten, Wiedergabe von Audio) ohne veränderbaren Benutzerzustand, haben App Intents möglicherweise nichts zu bieten. Apples Framework unterstützt OpenIntent (öffnen Sie einfach die App in einem Kontext), aber wenn die einzige sinnvolle Aktion „App öffnen” ist, ist der Intent Overhead. Liefern Sie keinen aus, nur um einen zu haben.

Wenn die Aktion von UI-Affordanzen abhängt, die schwer zu abstrahieren sind (ein komplexes mehrstufiges Canvas-Werkzeug, eine 3D-Bearbeitungs-App), wird die erforderliche parameterSummary des Intents zu vager Pseudo-Natürlichsprache verkommen, die niemand tatsächlich sagt. Die Siri-Phrase „bearbeite mein Foto mit dem Weichzeichner-Werkzeug bei Stärke 7” ist technisch möglich, aber kein Mensch wird sie aussprechen. Die Oberfläche des Intents ist eine Steuer ohne Gegenwert.

Die richtige Regel: Ein App Intent verdient seinen Platz, wenn es einen Satz gibt, den ein Benutzer natürlicherweise sagen würde, der die Aktion auslöst. „Log 8 oz of water” ist dieser Satz. „Wende einen Gauß’schen Weichzeichner mit Sigma 2,4 auf Ebene 3 an” ist es nicht. Wenn die Aktionen Ihrer App sich um das zweite Muster gruppieren, sind Intents nicht Ihr Konvertierungshebel.

Das Fazit

Seit drei Jahren signalisiert Apple, dass das System-KI-Geflecht von iOS über App Intents läuft. Die WWDC 2024 brachte das Apple Intelligence-Routing über sie. Die WWDC 2025 brachte Foundation Models daneben als separate In-App-Tool-Aufruf-Oberfläche und ließ App Intents als app-übergreifenden Vertrag bestehen, den Siri / Spotlight / Apple Intelligence weiterhin nutzen. Jedes Signal weist in dieselbe Richtung: der typisierte, deklarative App Intent ist der Vertrag, den Drittanbieter-Apps nun mit dem System schließen.

Die meisten iOS-Apps behandeln App Intents immer noch als Siri Shortcuts: eine Funktion, die man ausliefert, wenn man Zeit hat. Mein Eindruck ist, dass diese Sichtweise schlecht altern wird. Während sich die Systemoberflächen von Apple Intelligence ausdehnen (heute bereits über Siri, Spotlight, Shortcuts und Apple Intelligence-Zusammenfassungen), werden Apps ohne deklarierte Intents wahrscheinlich außerhalb des Routing-Graphen landen. Die First-Mover-Oberfläche kumuliert sich, soweit ich das bei anderen Plattform-Wetten von Apple beobachten konnte.

Water hat seit elf Wochen LogWaterIntent ausgeliefert. Die Menge an Code, die einen App Intent ausliefert, ist klein genug, um in eine einzige Datei zu passen. Die Kosten dafür, ihn nicht auszuliefern, wachsen mit jedem Apple Intelligence-Release.

Wenn Sie 2026 eine iOS-App ausliefern und nicht mindestens einen App Intent deklariert haben, fehlt in Ihrer Roadmap ein Posten. Fügen Sie ihn hinzu.

FAQ

Was ist ein App Intent in der iOS-Entwicklung?

Ein App Intent ist eine typisierte, deklarative Swift-Struktur, die eine der Aktionen Ihrer App den System-KI-Oberflächen von Apple zur Verfügung stellt. Er deklariert Parameter über @Parameter, eine natürlichsprachliche Zusammenfassung über parameterSummary und einen asynchronen perform()-Body, der die Arbeit erledigt und ein strukturiertes Ergebnis zurückgibt. Apples Siri, Spotlight, Shortcuts und Apple Intelligence können ihn aufrufen. Foundation Models (Apples On-Device-LLM) verwendet ein separates Tool-Protokoll für direkte In-App-Tool-Aufrufe.

Wie unterscheidet sich App Intents vom älteren INIntent?

App Intents (eingeführt mit iOS 16, 2022) ersetzten INIntent als Apples primäres Intent-Framework. Das neuere Framework ist vollständig Swift-nativ, verwendet Property Wrapper wie @Parameter, unterstützt typsichere Entity-Abfragen über AppEntity und ist die Oberfläche, die Siri, Spotlight, Shortcuts und Apple Intelligence aufrufen. Das ältere INIntent wird zwar noch unterstützt, erhält aber keine neuen Funktionsentwicklungen.

Brauche ich iOS 26, um einen App Intent auszuliefern?

Nein. App Intents sind ab iOS 16 verfügbar. iOS 26 fügt das Foundation Models-Framework daneben hinzu, aber die App Intent-Deklarationen selbst funktionieren ab iOS 16. Der obige Beispielcode verwendet SwiftData (iOS 17+), sodass das Deployment-Ziel davon abhängt, was Ihr perform()-Body importiert. Reine App Intents funktionieren bis zurück zu iOS 16; SwiftData-gestützte benötigen iOS 17.

Was ist der Unterschied zwischen einem App Intent und einer App Entity?

Ein App Intent ist eine Aktion (Verb). Eine App Entity sind die Daten, die Ihre App kennt (Substantiv). LogWaterIntent ist ein Intent. Wenn WaterEntry zu einem abfragbaren Typ wird, ist es eine Entity. Apple Intelligence verwendet beide: Intents, um Aktionen auszuführen, Entities, um Daten in Antworten abzurufen und zu referenzieren.

Wie verhalten sich App Intents zum Tool Calling von Foundation Models?

Foundation Models stellt sein eigenes Tool-Protokoll für direkte In-App-LLM-Tool-Aufrufe bereit. App Intents bleiben die kanonische app-übergreifende Oberfläche, die Apple Intelligence, Siri und Spotlight aufrufen. Gleiche Richtung (typisierter, deklarativer Tool-Use); zwei parallele Verträge. Eine App, die von System-KI-Oberflächen erreichbar sein möchte, liefert App Intents aus; eine App, die ihr eigenes On-Device-LLM mit benutzerdefinierten Tools aufrufen möchte, liefert Tool-Konformanzen aus. Viele Apps werden beides ausliefern.

App Intents sind keine Funktion. Sie sind der Vertrag. Die App, die den Intent zuerst ausliefert, bekommt die Oberfläche; die App, die ihn später ausliefert, findet die Oberfläche bereits anderweitig geroutet vor. Vor elf Wochen habe ich einen in Water ausgeliefert. Die Kumulierung hat bereits begonnen.

Quellen