App Intents sind Apples neue API zu Ihrer App

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

Elf Wochen zuvor hatte ich Water, meiner iOS-App zur Trinkmengenverfolgung, eine einzige Swift-Datei hinzugefügt: LogWaterIntent.swift, 80 Zeilen AppIntent plus einen AppShortcutsProvider, der drei Siri-Phrasenvarianten deklariert. Diese Datei ist heute die heißeste API-Oberfläche, die ich besitze.²

Hier ist der Teil, den zu verinnerlichen mich eine Weile gekostet hat. App Intents sind keine Siri-Funktion. Sie sind der Vertrag, den Drittanbieter-Apps mit Apple Intelligence schließen, der System-KI-Oberfläche, die Apple in iOS 18 einzuführen begann und bis iOS 26 weiter ausbaute.³ Wenn Sie eine iOS-App veröffentlichen und App Intents immer noch als „Nice to have”-Sprachfunktion behandeln, missverstehen Sie, was Apple gebaut hat. App Intents sind die API, mit der Apples KI als Ihre App im Auftrag des Benutzers handeln kann. Alles andere (Siri, Spotlight, Shortcuts, Apple-Intelligence-Zusammenfassungen, die Watch- und Vision-Pro-Oberflächen) ist diesem Vertrag nachgelagert. Foundation Models, das geräteinterne LLM, das in iOS 26 ausgeliefert wurde, stellt ein separates Tool-Protokoll für In-App-Tool-Calling bereit; es läuft parallel zu App Intents, 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-Synchronisierung, sprachgebietsabhängige Einheitenkonvertierung, strukturierte Siri-Dialogantwort.
• iOS 26 führte Foundation Models ein, Apples geräteinternes 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 durch Ihre deklarierten Intents oder es leitet an Ihrer App vorbei zu einem Wettbewerber.
• Apple sagt uns das seit drei Jahren. Die Benennung (App Intents, App Shortcuts, Apple Intelligence) ist Absicht. Der Vertrag rückt mit jeder WWDC eine Ebene im Stack nach oben.

App-Intents-Framework-Referenzbild aus der Apple-Developer-Dokumentation.⁵

Was ein App Intent tatsächlich ist

Der vollständige Quellcode von LogWaterIntent, so 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 Bedingung für Ziel-erreicht/Restmenge weiter. Der oben gezeigte Auslieferungscode vom 8. Februar ist derjenige, den ich am Küchenwasserhahn getestet habe.)

Drei Dinge sind hier benennenswert, 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 keine String-Verarbeitung statt. Das Typsystem ist das Schema.⁵

parameterSummary ist die natürlichsprachliche Spiegelung des Parameters. Apple verwendet sie, um die Aktion in der Shortcuts-UI, im Dialog und zunehmend in den Bestätigungspanels von Apple Intelligence darzustellen. Die Zusammenfassung wird dem Benutzer vorgelesen. Machen Sie sie falsch, hört der Benutzer einen hässlichen Satz; machen Sie sie richtig, wirkt die Oberfläche nativ.⁶

perform() gibt IntentResult & ProvidesDialog zurück. Das ist die strukturierte Rückgabe: Die KI-Oberfläche erhält nicht nur Erfolg/Misserfolg zurück, sondern einen Dialog-String, den 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 unten ist das, was die Siri-Phrasen registriert. Das \(.applicationName)-Token ist die Stelle, an der Siri automatisch „Water” einfügt. Drei Phrasenvarianten mit demselben Intent geben Apples NL-Parser mehr Spielraum, um die Formulierung des Benutzers zu treffen, ohne dass Sie ein Phrasenwörterbuch pflegen müssen. Der systemImageName ist ein echter SF-Symbols-Name; so rendern Spotlight, Shortcuts und Apple Intelligence das Symbol der Aktion.

Apple Intelligence leitet Benutzeranfragen durch App Intents, um geräteinterne KI-Funktionen bereitzustellen. Quelle: apple.com/apple-intelligence.

Warum dies die wichtigste iOS-API seit SwiftUI ist

iOS-APIs treten in zwei Formen auf. Manche bestimmen, wie sich Ihre App selbst zeichnet (UIKit, SwiftUI, Metal). Manche bestimmen, wie sich Ihre App ins System integriert (URL-Schemata, Universal Links, widgets). App Intents sind eine dritte Form: Sie bestimmen, wie Apples KI Ihre App nutzt. Jene Widget- und Control-Center-Oberflächen sind selbst App-Intents-Oberflächen, dasselbe Intent an vielen Stellen gerendert, was ich in The iOS 26 Widget Surface nachzeichne.

Die Entwicklung lohnt eine Nachverfolgung.

• 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, Fahrtbuchung) mit strengen Schemata.⁸
• iOS 12 (2018) erweiterte die Oberfläche mit Siri Shortcuts: Jede App konnte eine NSUserActivity oder ein INIntent spenden und hoffen, dass Siri es vorschlägt.
• iOS 13 (2019) fügte die In-App-Intent-Verarbeitung hinzu, sodass Apps auf Shortcut-Aufrufe reagieren konnten, ohne in die System-Siri-UI zu wechseln.
• iOS 16 (2022) führte das App-Intents-Framework ein: typisiert, deklarativ, mit @Parameter und AppShortcutsProvider. Der Vorgänger INIntent wurde für neue Entwicklung praktisch abgelöst.⁹
• iOS 18 (2024) führte Apple Intelligence ein und begann, Siri-Anfragen wo immer möglich durch App Intents zu leiten. Die Funktion „persönlicher Kontext” von Apple Intelligence liest aus App Entities (der Datenversion von App Intents).¹⁰ iOS 27 treibt dies mit App Schemas weiter, die es Siri erlauben, über Ihre Entitäten zu schlussfolgern und in Begriffen, die sie bereits versteht, ohne jegliche Trainingsphrasen darauf zu handeln, hier behandelt.
• iOS 26 (2025) führte das Foundation Models-Framework ein, Apples geräteinternes LLM. Foundation Models stellt ein separates Tool-Protokoll für In-App-Tool-Calling 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 erstreckt sich mit jedem Release weiter den Stack hinauf. Ursprünglich war der Konsument eines App Intent eine Person, die auf Shortcuts tippte. Dann Siri per Sprache. Dann Spotlight. Dann Apple-Intelligence-Zusammenfassungen. Jetzt nutzen die LLM-gestützten Systemoberflächen von Apple Intelligence sie, um auf Benutzeranfragen zu handeln. Die App-Intent-Oberfläche, die Sie 2026 ausliefern, ist diejenige, die Apple Intelligence in iOS 27, 28, 29 aufrufen wird.

Das obige Muster ist gemeint, wenn ich sage, dass App Intents keine Siri-Funktion sind. Sie sind die API für strukturierten Tool-Use für das gesamte KI-Geflecht von Apple. SwiftUI war die wichtigste UI-API, weil es die einzige Möglichkeit wurde, eine App für visionOS, watchOS 10+ und iOS 17+ zu schreiben. App Intents folgen auf der KI-Seite demselben Bogen: die Oberfläche, auf die Apple all seine Wetten setzt.

Was sich ändert, jetzt da Foundation Models ausgeliefert ist

Foundation Models ist das Framework, das auf jedem Apple-Intelligence-fähigen Gerät ausgeliefert wird. Die Hardware-Grenze ist dieselbe Apple-Intelligence-Liste: iPhone 15 Pro und 15 Pro Max (A17 Pro), die iPhone-16-Reihe, die iPhone-17-Reihe, 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 abwesend: das Basis-iPhone-15 / 15 Plus.⁴¹²

Die Implikation: Wenn Apples Systemoberflächen (Siri, Spotlight, Apple Intelligence) Ihre App überhaupt aufrufen, rufen sie sie durch App Intents und App Entities auf. Es gibt im System-KI-Geflecht keine setSystemPrompt(...)-API für Drittanbieter-Apps. Es gibt die Intent-Registrierung. Foundation Models fügt eine parallele In-App-Tool-Oberfläche für Entwickler hinzu, die eigene geräteinterne LLM-Funktionen wollen. Der app-übergreifende Vertrag (derjenige, den Apple Intelligence und Siri nutzen, um Ihre App zu finden) läuft durch App Intents.

Drei konkrete Konsequenzen für App-Entwickler:

Eine App ohne ein relevantes App Intent ist über einen Siri-Sprachbefehl in ihrer Kategorie nicht erreichbar. Apple Intelligence leitet Phrasen wie „Hey Siri, log my water” zu den Apps, die das passende Intent zuerst deklariert haben. Ich habe Waters Intent im Februar 2026 ausgeliefert. Meine Lesart der Framework-Richtung: Trinkmengen-Apps, die das Intent 2027 ausliefern, betreten einen Markt, in dem sich die Routing-Gewichtungen bereits zugunsten der frühen Akteure angesammelt haben. Dieselbe Logik gilt für Einkaufslisten, Workout-Protokollierung, Kalendereinträge, Fotosuchen. Ich erwarte, dass sich der First-Mover-Vorteil bei Intent-Deklarationen verstärkt, so wie es bei anderen Plattform-Wett-APIs von Apple der Fall war (HealthKit-Kategorien, Spotlight-Rich-Results, Live-Activities-Token).

Die Personalisierung von Apple Intelligence liest aus App Entities, nicht nur aus Intents. Ein AppEntity deklariert „diese App hat Daten dieser Form”. Wenn der Benutzer fragt „what was the last book I added to my reading list”, durchsucht Apple Intelligence jedes AppEntity, das zu Book passt, über jede installierte App hinweg. Hat Ihre App eine Leseliste, aber kein deklariertes BookEntity, 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 wichtiger. Apple Intelligence setzt Intent-Ergebnisse über Siri, Spotlight und die Watch hinweg zu längeren Antworten zusammen. Ein perform(), das nur Erfolg ohne strukturierten Dialog zurückgibt, lässt sich vom System schwerer zu einer kohärenten Antwort zusammensetzen. ProvidesDialog und ProvidesView sind keine optionale Höflichkeit; sie sind die Art, wie Ihre Aktion zu einer Zitatquelle 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 glauben zu brauchen. Ich habe eines ausgeliefert. Ich hätte vier ausliefern sollen: LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent. Jedes davon entspricht einer Siri-Phrase, die Benutzer tatsächlich ausprobieren („how much water have I had today”, die an Apples generische KI statt an die Daten meiner App geleitet wird). Jedes fehlende Intent ist eine Anfrage, die Apple Intelligence an mir vorbeileitet.

Der Dialog-String ist nicht der Textkörper 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, faktenführende Struktur: „8 oz logged. 32 oz to go.” Insbesondere die Watch-Oberfläche kürzt aggressiv. Konversationsdialog ist eine schlechtere Benutzererfahrung als selbstbewusster Faktendialog. Ich habe meinen in Woche 4 neu geschrieben.²

App Entities sind wichtiger, als ich dachte. Ich habe ein WaterEntry-SwiftData-Modell. Ich sollte außerdem ein WaterEntryEntity: AppEntity plus die zugehörige WaterEntryQuery: EntityQuery deklarieren, damit Apple Intelligence „show me when I drank water yesterday” beantworten kann. Die minimale Überbrückung:¹¹

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

Zwei kleine Swift-Typen plus der SwiftData-Fetch-Kleber. Um Einträge einzeln in Spotlight auffindbar zu machen (damit Benutzer, die nach „water” suchen, beim richtigen Eintrag landen), lassen Sie die Entität IndexedEntity konformieren und spenden bei Schreibvorgängen Index-Updates. Das ist es, was Apples Spotlight-Pipeline über die bloße AppEntity-Bereitstellung hinaus erwartet.

Dieselbe Form gilt anderswo in meinen Apps. Get Bananas, meine Einkaufslisten-App, hat bereits ein SwiftData-@Model ShoppingItem mit @Attribute(.unique) var id: UUID, name, amount, section, isChecked plus ein lastModified-Feld für die iCloud-Drive-Synchronisierung.¹³ Es als ShoppingItemEntity: AppEntity zu kapseln und ein paar Intents auszuliefern (AddShoppingItem, CheckOffItem, ShowList) würde Apple Intelligence dieselbe Persistenzschicht offenlegen, die Get Bananas Claude Desktop bereits über seinen .mcpb-MCP-Server offenlegt.¹⁴ Zwei LLM-Ökosysteme, zwei verschiedene Verträge, dieselbe Einkaufsliste. Das ist die These der parallelen Verträge als einzelne ausgelieferte App: Das SwiftData-Modell sind die Daten, App Intents sind Apples Vertrag, MCP ist Anthropics Vertrag, beide Oberflächen operieren auf derselben Quelle der Wahrheit.

Wann man kein App Intent ausliefern sollte

Verzicht ist Teil des Designs.

Wenn Ihre App rein konsumgetrieben ist (die Fotos des Benutzers lesen, Nachrichten anzeigen, Audio abspielen) ohne veränderlichen Benutzerzustand, haben App Intents womöglich nichts offenzulegen. Apples Framework unterstützt OpenIntent (einfach die App in einem Kontext öffnen), aber wenn die einzige nützliche Aktion „App öffnen” ist, ist das Intent Overhead. Liefern Sie keines aus, nur um eines zu haben.

Wenn die Aktion von UI-Affordanzen abhängt, die sich schwer abstrahieren lassen (ein komplexes mehrstufiges Canvas-Werkzeug, eine 3D-Bearbeitungs-App), degeneriert die erforderliche parameterSummary des Intent zu vager Pseudo-Natürlichsprache, die niemand tatsächlich sagt. Die Siri-Phrase „edit my photo with the blur tool at strength 7” ist technisch möglich, aber kein Mensch wird sie aussprechen. Die Oberfläche des Intent ist eine Steuer ohne Gegenwert.

Die richtige Regel: Ein App Intent verdient seinen Platz, wenn es einen Satz gibt, den ein Benutzer natürlich sagen würde und der die Aktion auslöst. „Log 8 oz of water” ist dieser Satz. „Apply Gaussian blur with sigma 2.4 to layer 3” ist es nicht. Wenn sich die Aktionen Ihrer App auf das zweite Muster konzentrieren, sind Intents nicht Ihr Konversionshebel.

Das abschließende Fazit

Seit drei Jahren signalisiert Apple, dass das System-KI-Geflecht von iOS durch App Intents läuft. Die WWDC 2024 fügte das Apple-Intelligence-Routing durch sie hinzu. Die WWDC 2025 fügte Foundation Models daneben als separate In-App-Tool-Calling-Oberfläche hinzu und beließ App Intents als den app-übergreifenden Vertrag, den Siri / Spotlight / Apple Intelligence weiterhin nutzen. Jedes Signal weist in dieselbe Richtung: Das typisierte, deklarative App Intent ist der Vertrag, den Drittanbieter-Apps jetzt 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. Meine Lesart ist, dass diese Rahmung schlecht altern wird. Während sich die Systemoberflächen von Apple Intelligence ausdehnen (heute bereits über Siri, Spotlight, Shortcuts und Apple-Intelligence-Zusammenfassungen), werden sich Apps ohne deklarierte Intents wahrscheinlich außerhalb des Routing-Graphen wiederfinden. Die First-Mover-Oberfläche verstärkt sich nach meiner Erfahrung beim Beobachten von Apples anderen Plattform-Wetten.

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

Wenn Sie 2026 eine iOS-App ausliefern und nicht mindestens ein 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 offenlegt. Es deklariert Parameter über @Parameter, eine natürlichsprachliche Zusammenfassung über parameterSummary und einen asynchronen perform()-Körper, der die Arbeit erledigt und ein strukturiertes Ergebnis zurückgibt. Apples Siri, Spotlight, Shortcuts und Apple Intelligence können es aufrufen. Foundation Models (Apples geräteinternes LLM) verwendet ein separates Tool-Protokoll für direkte In-App-Tool-Calls.

Wie unterscheidet sich App Intents vom älteren INIntent?

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

Brauche ich iOS 26, um ein App Intent auszuliefern?

Nein. App Intents sind ab iOS 16 verfügbar. iOS 26 fügt daneben das Foundation-Models-Framework hinzu, aber die App-Intent-Deklarationen selbst funktionieren ab iOS 16+. Der obige Beispielcode verwendet SwiftData (iOS 17+), sodass das Deployment Target davon abhängt, was Ihr perform()-Körper importiert. Reine App Intents funktionieren bis iOS 16 zurück; 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, von denen Ihre App weiß (Substantiv). LogWaterIntent ist ein Intent. WaterEntry, das zu einem abfragbaren Typ wird, ist eine Entität. Apple Intelligence nutzt beide: Intents, um Aktionen auszuführen, Entitäten, um Daten in Antworten abzurufen und zu referenzieren.

Wie hängen App Intents mit dem Tool-Calling von Foundation Models zusammen?

Foundation Models stellt ein eigenes Tool-Protokoll für direkte In-App-LLM-Tool-Calls 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 will, liefert App Intents aus; eine App, die ihr eigenes geräteinternes LLM mit eigenen Tools aufrufen will, liefert Tool-Konformitäten aus. Viele Apps werden beides ausliefern.

App Intents sind keine Funktion. Sie sind der Vertrag. Die App, die das Intent zuerst ausliefert, bekommt die Oberfläche; die App, die es später ausliefert, findet die Oberfläche bereits anderweitig geroutet vor. Vor elf Wochen habe ich eines in Water ausgeliefert. Der Verstärkungseffekt hat bereits begonnen.

Mehr aus der Apple-Ecosystem-Serie

Dieser Essay ist der Einstiegspunkt. Die anderen vier decken den Rest des Architektur-Stacks ab:

• Two Agent Ecosystems, One Shopping List: wie Get Bananas dieselben Daten Apple Intelligence (App Intents) und Claude Desktop (MCP) über eine JSON-Datei in iCloud Drive offenlegt.
• Liquid Glass in SwiftUI: Three Patterns From Shipping Return: Produktionsmuster für die visuelle Schicht von iOS 26.
• Five Apple Platforms, Three Shared Files: die plattformübergreifende Auslieferungsstrategie, wann man Code teilt und wann man Targets forkt.
• HealthKit + SwiftUI on iOS 26: die Datenquellenschicht aus Autorisierungsabläufen, Sample-Typen und der Falle, die Benutzer aus Ihrer App aussperrt.

Oder springen Sie direkt zum vollständigen Hub: Apple Ecosystem Series. Für den breiteren Kontext von iOS mit KI-Agenten siehe den iOS Agent Development guide.

Referenzen