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üchenhahn waren. Das Wasser wurde protokolliert. Der Watch-Dialog meldete 32 oz verbleibend. Ich hatte keinen Bildschirm berührt.¹

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

Hier ist der Teil, den zu verinnerlichen mir eine Weile dauerte. App Intents sind keine Siri-Funktion. Sie sind der Vertrag, den Drittanbieter-Apps mit Apple Intelligence eingehen, jenen System-AI-Oberflächen, die Apple in iOS 18 einzuführen begann und bis iOS 26 weiter ausbaute.³ Wenn Sie eine iOS-App ausliefern und App Intents immer noch als „nettes Extra” einer Sprachfunktion behandeln, lesen Sie falsch, was Apple gebaut hat. App Intents sind die API, die es Apples KI ermöglicht, als Ihre App im Auftrag des Benutzers zu handeln. Alles andere (Siri, Spotlight, Shortcuts, Apple Intelligence-Zusammenfassungen, die Watch- und Vision-Pro-Oberflächen) ist diesem Vertrag nachgelagert. Foundation Models, das LLM auf dem Gerät, das mit iOS 26 ausgeliefert wurde, bietet ein separates Tool-Protokoll für In-App-Tool-Aufrufe; 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 reales Produktionsbeispiel: LogWaterIntent in Water. 80 Zeilen, vollständiger SwiftData-Schreibvorgang, HealthKit-Sync, gebietsspezifische Einheitenumrechnung, strukturierte Siri-Dialogantwort.
• iOS 26 fügte Foundation Models hinzu, Apples LLM auf dem Gerät. Foundation Models bietet ein eigenes Tool-Protokoll für In-App-Tool-Aufrufe; App Intents bleiben die kanonische Oberfläche, die Siri / Spotlight / Apple Intelligence app-übergreifend aufrufen. Dieselbe Richtung, zwei parallele Verträge.
• Eine App ohne App Intents ist 2026 für Apple Intelligence unsichtbar. Das KI-Gewebe leitet entweder durch Ihre deklarierten Intents oder es leitet um Ihre App herum zu einem Mitbewerber.
• Apple sagt uns das seit drei Jahren. Die Benennung (App Intents, App Shortcuts, Apple Intelligence) ist Absicht. Der Vertrag wandert mit jeder WWDC eine Ebene höher im Stack.

Referenzbild des App-Intents-Frameworks aus der Apple Developer-Dokumentation.⁵

Was ein App Intent eigentlich 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 führt den Dialog mit einer Bedingung „Ziel erreicht / verbleibende Menge” weiter aus. Der oben gezeigte Auslieferungscode vom 8. Februar ist derjenige, den ich am Küchenhahn 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 kein String-Parsing statt. Das Typsystem ist das Schema.⁵

parameterSummary ist die Reflexion des Parameters in natürlicher Sprache. Apple verwendet sie, um die Aktion in der Shortcuts-Oberfläche, im Dialog und zunehmend in den Bestätigungspanels von Apple Intelligence darzustellen. Die Zusammenfassung wird dem Benutzer laut vorgelesen. Machen Sie sie falsch, hört der Benutzer einen hässlichen Satz; machen Sie sie richtig, 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/Misserfolg zurück, sondern auch einen Dialog-String, den der Benutzer hört. Apple erwartet zunehmend ProvidesDialog, ProvidesView oder ReturnsValue, damit das Ergebnis sich in Siri, Spotlight, die Watch und (in iOS 26) in die Antwortkette von Apple Intelligence komponiert.⁷

Der AppShortcutsProvider-Block am Ende ist das, was die Siri-Phrasen registriert. Das Token \(.applicationName) ist die Stelle, an der Siri „Water” automatisch einfügt. Drei Phrasenvarianten mit demselben Intent geben Apples NL-Parser mehr Spielraum, um die Formulierung des Benutzers zu treffen, ohne dass Sie ein Phrasen-Dictionary pflegen müssen. systemImageName ist ein echter SF-Symbols-Name; so rendern Spotlight, Shortcuts und Apple Intelligence das Aktionssymbol.

Apple Intelligence leitet Benutzeranfragen über App Intents weiter, um KI-Funktionen auf dem Gerät bereitzustellen. Quelle: apple.com/apple-intelligence.

Warum dies die wichtigste iOS-API seit SwiftUI ist

iOS-APIs gibt es in zwei Ausprägungen. Manche betreffen, wie sich Ihre App selbst zeichnet (UIKit, SwiftUI, Metal). Manche betreffen, wie Ihre App mit dem System integriert wird (URL-Schemata, Universal Links, Widgets). App Intents sind eine dritte Form: Sie sind die Art, wie Apples KI Ihre App nutzt.

Die Entwicklung lohnt sich nachzuzeichnen.

• 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, Fahrtenbuchung) mit strikten Schemata.⁸
• iOS 12 (2018) erweiterte die Oberfläche mit Siri Shortcuts: Jede App konnte eine NSUserActivity oder einen INIntent spenden und hoffen, dass Siri diese vorschlug.
• iOS 13 (2019) fügte In-App-Intent-Handhabung hinzu, sodass Apps auf Shortcut-Aufrufe reagieren konnten, ohne in die System-Siri-Oberfläche im Hintergrund 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 Entwicklungen praktisch abgelöst.⁹
• iOS 18 (2024) führte Apple Intelligence ein und begann, Siri-Anfragen wo immer 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 Framework Foundation Models ein, Apples LLM auf dem Gerät. Foundation Models bietet ein separates Tool-Protokoll für In-App-Tool-Aufrufe. 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 wurde mit jedem Release weiter oben im Stack ausgeweitet. Ursprünglich war der Konsument eines App Intent eine Person, die Shortcuts antippte. Dann Siri-Sprache. Dann Spotlight. Dann Apple-Intelligence-Zusammenfassungen. Nun nutzen die LLM-gestützten System-Oberflä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 meine ich, wenn ich sage, dass App Intents keine Siri-Funktion sind. Sie sind die API für strukturierte Tool-Nutzung des gesamten Apple-KI-Gewebes. 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 ä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. Bemerkenswert abwesend: Basis-iPhone 15 / 15 Plus.⁴¹²

Die Implikation: Wenn Apples System-Oberflächen (Siri, Spotlight, Apple Intelligence) Ihre App überhaupt aufrufen, rufen sie sie über App Intents und App Entities auf. Es gibt keine setSystemPrompt(...)-API für Drittanbieter-Apps im System-KI-Gewebe. Es gibt das Intent-Register. Foundation Models fügt eine parallele In-App-Tool-Oberfläche für Entwickler hinzu, die ihre eigenen LLM-Funktionen auf dem Gerät wünschen. 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, die den passenden Intent deklariert haben. Ich lieferte Waters Intent im Februar 2026 aus. Mein Eindruck zur Richtung des Frameworks: Hydrationsapps, die den Intent 2027 ausliefern, betreten einen Markt, in dem sich die Routing-Gewichte bereits zugunsten der frühen Akteure aufgebaut haben. Dieselbe Logik gilt für Einkaufslisten, Trainings-Logging, Kalendereinträge, Foto-Suchen. Ich erwarte, dass der First-Mover-Vorteil bei Intent-Deklarationen sich kumuliert — so wie bei anderen Apple-Plattform-Wetten-APIs (HealthKit-Kategorien, Spotlight Rich Results, Live-Activities-Tokens).

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

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

Was ich anders bauen würde

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

Liefern Sie mehr Intents aus, als Sie zu brauchen glauben. Ich habe einen ausgeliefert. Ich hätte vier ausliefern sollen: LogWaterIntent, CheckTodaysProgressIntent, AdjustGoalIntent, ShowHistoryIntent. Jeder bildet eine Siri-Phrase ab, die Benutzer tatsächlich versuchen („how much water have I had today” wurde an Apples generische KI geleitet statt an die Daten meiner App). Jeder fehlende Intent ist eine Anfrage, die Apple Intelligence um mich herumleitet.

Der Dialog-String 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, faktenführende Struktur: „8 oz logged. 32 oz to go.” Insbesondere die Watch-Oberfläche kürzt aggressiv. Konversationeller Dialog ist eine schlechtere Benutzererfahrung als faktenfester 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: „Zeig 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())")
    }
    @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-Klebstoff. Um Einträge in Spotlight einzeln auffindbar zu machen (sodass Benutzer, die nach „water” suchen, beim richtigen Eintrag landen), lassen Sie die Entität IndexedEntity entsprechen und spenden Index-Updates beim Schreiben. Das erwartet Apples Spotlight-Pipeline jenseits der bloßen AppEntity-Exponierung.

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 einem lastModified-Feld für iCloud-Drive-Sync.¹³ Es als ShoppingItemEntity: AppEntity zu verpacken und ein paar Intents (AddShoppingItem, CheckOffItem, ShowList) auszuliefern, würde Apple Intelligence dieselbe Persistenzschicht zugänglich machen, die Get Bananas bereits Claude Desktop über seinen .mcpb-MCP-Server zugänglich macht.¹⁴ 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 sind die Daten, App Intents sind Apples Vertrag, MCP ist Anthropics Vertrag, beide Oberflächen operieren auf derselben Quelle der Wahrheit.

Wann Sie keinen App Intent ausliefern sollten

Verzicht ist Teil des Designs.

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

Wenn die Aktion von UI-Elementen abhängt, die schwer zu abstrahieren sind (ein komplexes mehrstufiges Canvas-Tool, eine 3D-Bearbeitungs-App), wird die erforderliche parameterSummary des Intent zu einer vagen Pseudo-Natursprache verkommen, 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 Gegenleistung.

Die richtige Regel: Ein App Intent verdient sich seinen Platz, wenn es einen Satz gibt, den ein Benutzer natürlich sagen würde, 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 die Aktionen Ihrer App sich um das zweite Muster gruppieren, sind Intents nicht Ihr Konversionshebel.

Das abschließende Fazit

Drei Jahre lang signalisiert Apple, dass das System-KI-Gewebe von iOS über App Intents läuft. WWDC 2024 fügte Apple-Intelligence-Routing über sie hinzu. WWDC 2025 fügte Foundation Models daneben als separate In-App-Tool-Aufruf-Oberfläche hinzu und beließ App Intents als app-übergreifenden Vertrag, 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 eingehen.

Die meisten iOS-Apps behandeln App Intents immer noch wie Siri Shortcuts: ein Feature, das man ausliefert, wenn man Zeit hat. Mein Eindruck ist, dass diese Einordnung schlecht altern wird. Da sich die System-Oberflächen von Apple Intelligence ausweiten (heute bereits durch 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 kumuliert sich, nach meiner Erfahrung mit anderen Plattform-Wetten von Apple.

Water hat LogWaterIntent seit elf Wochen ausgeliefert. Die Code-Menge, die einen App Intent ausliefert, ist klein genug, um in eine einzige Datei zu passen. Die Kosten, 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 Ihrer Roadmap eine Position. Fügen Sie sie 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 zugänglich macht. Sie deklariert Parameter über @Parameter, eine natürlichsprachige Zusammenfassung über parameterSummary und einen asynchronen perform()-Rumpf, der die Arbeit erledigt und ein strukturiertes Ergebnis zurückgibt. Apples Siri, Spotlight, Shortcuts und Apple Intelligence können sie aufrufen. Foundation Models (Apples LLM auf dem Gerät) 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 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 jedoch keine neuen Funktionsarbeiten.

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 hinzu, aber die App-Intent-Deklarationen selbst funktionieren auf iOS 16+. Der obige Beispielcode verwendet SwiftData (iOS 17+), sodass das Deployment-Target davon abhängt, was Ihr perform()-Rumpf 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, die Ihre App kennt (Substantiv). LogWaterIntent ist ein Intent. WaterEntry, das zu einem abfragbaren Typ wird, ist eine Entity. Apple Intelligence verwendet beides: Intents, um Aktionen auszuführen, Entitäten, um Daten in Antworten abzurufen und zu referenzieren.

Wie verhalten sich App Intents zum Tool-Aufruf von Foundation Models?

Foundation Models bietet ein eigenes Tool-Protokoll für direkte In-App-LLM-Tool-Aufrufe. App Intents bleiben die kanonische app-übergreifende Oberfläche, die Apple Intelligence, Siri und Spotlight aufrufen. Dieselbe Richtung (typisierte, deklarative Tool-Nutzung); zwei parallele Verträge. Eine App, die für System-KI-Oberflächen erreichbar sein möchte, liefert App Intents aus; eine App, die ihr eigenes LLM auf dem Gerät mit benutzerdefinierten Tools aufrufen möchte, liefert Tool-Konformitäten aus. Viele Apps werden beides ausliefern.

App Intents sind kein Feature. 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 anderswohin geleitet. Vor elf Wochen habe ich einen in Water ausgeliefert. Der Kumulationseffekt 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 Apple Intelligence (App Intents) und Claude Desktop (MCP) durch eine JSON-Datei in iCloud Drive dieselben Daten zugänglich macht.
• 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 Code geteilt und wann Targets getrennt werden sollten.
• HealthKit + SwiftUI on iOS 26: die Datenquellenschicht von Autorisierungs-Flows, Sample-Typen und der Falle, die Benutzer aus Ihrer App aussperrt.

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

Referenzen