Drei Oberflächen: Mensch, Apple Intelligence, Agent

Jede bedeutsame Funktion in einer iOS-App unter iOS 26+ steht heute bis zu drei Oberflächen gegenüber, von denen aus sie aufgerufen werden kann. Dieselbe Swift-Funktion, die ein Glas Wasser protokolliert, kann durch einen Menschen ausgelöst werden, der auf eine Schaltfläche tippt, durch Apple Intelligence, das eine Siri-Anfrage weiterleitet, oder durch einen externen Agenten (Claude Code, Cursor, ChatGPT), der ein MCP-Tool aufruft. Drei verschiedene Aufrufer, drei verschiedene Pflichten, drei verschiedene Darstellungsoberflächen. Die Funktion ist dieselbe; die Oberflächen sind es nicht.

Viele Architekturfehler bei iOS entstehen dadurch, dass für eine Oberfläche entworfen wird und die Funktion dann in die anderen hineingezwängt wird. UI-Abläufe sickern in Siri-Antworten ein; Agent-Tools, die für einen Entwickler korrekt sind, werden für Endbenutzer zur Gefahr; On-Device-LLM-Funktionen setzen Cloud-tauglichen Kontext voraus. Der Cluster hat diese Oberflächen in einzelnen Beiträgen kartiert. Der vorliegende Beitrag ist die Synthese: die drei Oberflächen, ihre Unterschiede, die Routing-Regel und wie die Domänenschicht einer App aussehen muss, um alle drei zu bedienen, ohne eine zu kompromittieren.

Das mentale Modell: Wählen Sie eine Domänenfunktion aus. Fragen Sie, welche der drei Oberflächen sie aufrufen können sollte. Fragen Sie, welche es können. Fragen Sie, was jede Oberfläche von der Funktion benötigt und was die Funktion zurückschuldet. Die Antworten formen die Architektur.

TL;DR

• Drei Oberflächen: Mensch (SwiftUI-Views, Tippen, Gesten, Bildschirm), Apple Intelligence (App Intents, Siri, Shortcuts, Spotlight), Agent (MCP-Server, externe LLM-Hosts).
• Jede Oberfläche hat unterschiedliche Pflichten: Vertrauenshaltung, Latenzbudget, Darstellungsort, Persistenzsemantik, Fehlerbehandlung, Anforderungen an die Barrierefreiheit.
• Die richtige Architektur ist eine Domänenschicht unterhalb der Oberflächen. Jede Oberfläche ist ein dünner Adapter über denselben Swift-Funktionen; die Funktion erhält ein typisiertes Caller-Argument, sodass sie auf oberflächenübergreifende Regeln (Ratenbegrenzungen, Audit, Bestätigungen) verzweigen kann, ohne die Protokolldetails der Oberfläche zu kennen.
• Nicht jede Funktion bedient alle drei. Die Entscheidung welche Oberfläche ist die Designentscheidung. Funktionen vor Oberflächen zu verbergen, die sie nicht haben sollten, ist genauso eine Produktentscheidung wie sie den Oberflächen verfügbar zu machen, die sie haben sollten.

Oberfläche eins: Mensch

Die menschliche Oberfläche ist der Bildschirm. Der Benutzer schaut auf die App, tippt, scrollt, zieht, wischt, tippt Text. Das Framework ist SwiftUI (oder UIKit oder für einige Workloads RealityKit auf visionOS). Die Darstellung erfolgt auf dem Gerät des Benutzers, im App-Prozess, gemäß dem vom Benutzer gewählten Farbschema, der dynamischen Schriftgröße und den Einstellungen für die Barrierefreiheit.¹

Was die menschliche Oberfläche von einer Funktion benötigt:

• Eine visuelle Affordanz. Eine Schaltfläche, eine Listenzeile, eine Wischgeste, ein Kontextmenü. Die Funktion muss über die Navigation der App auffindbar sein und konsistent mit dem Rest der UI gestaltet sein.
• Echtzeit-Rückmeldung. Jede Interaktion benötigt eine sofort sichtbare Reaktion. Eine Schaltfläche, die einen lang laufenden Vorgang auslöst, muss einen Fortschrittsindikator, einen aktivierten/deaktivierten Zustand, eine Animation zeigen.
• Barrierefreiheit. VoiceOver-Beschriftungen, Unterstützung für Dynamic Type, Farbkontrast, Alternativen zur Motoriksteuerung. Die menschliche Oberfläche stellt die anspruchsvollsten Anforderungen an die Barrierefreiheit, weil der Benutzer direkt mit der Darstellung interagiert.
• Sichtbarkeit von Fehlern. Fehler landen in der Ansicht des Benutzers. Ein fehlgeschlagenes Speichern zeigt eine Warnmeldung; eine Netzwerkzeitüberschreitung zeigt einen Wiederholversuch; eine Berechtigungsverweigerung zeigt einen Link zu den Einstellungen.

Was die menschliche Oberfläche der Funktion zurückschuldet:

• Eindeutige Benutzerabsicht. Der Benutzer hat auf eine bestimmte Schaltfläche getippt; die Funktion weiß genau, was angefordert wurde. Es gibt keine Inferenzschicht.
• Enges Latenzbudget. Ein Tippen, das mehr als ein paar hundert Millisekunden braucht, um sichtbar zu reagieren, fühlt sich kaputt an. Die Funktion muss entweder schnell sein oder so gestaltet werden, dass sie sofort Fortschritt anzeigt.
• Keine externe Autorität. Der Benutzer ist in der App; der Benutzer ist der Agent im weitesten Sinne (der Mensch ist derjenige, der die Aktion antreibt). Kein Drittanbieter-LLM, kein Systemagent, nur die Hände des Benutzers.

Die menschliche Oberfläche besteht von den dreien am längsten. Jedes iOS-Framework, jedes Designmuster und jede Regel zur Barrierefreiheit, die die Plattform seit iOS 7 angesammelt hat, dient dieser Oberfläche. Die anderen beiden Oberflächen sind so neu, dass sich die Muster noch setzen.

Oberfläche zwei: Apple Intelligence

Die Apple-Intelligence-Oberfläche ist der Systemagent. Siri, Shortcuts, Spotlight, der Stack der Systemvorschläge. Der Benutzer spricht, tippt in Spotlight oder verkettet eine Aktion in Shortcuts; das System leitet die Anfrage durch das App-Intents-Framework, findet einen AppIntent, der passt, löst die Parameter auf und führt den perform()-Rumpf des Intents aus. Das Framework ist App Intents.²

Was die Apple-Intelligence-Oberfläche von einer Funktion benötigt:

• Ein typisiertes Schema. AppIntent-Typen deklarieren @Parameter-Eigenschaften; AppEntity-Typen liefern persistente Identität für Dinge, über die das System sprechen kann; AppEnum-Typen benennen geschlossene Mengen von Optionen. Das System liest das Schema zur Installationszeit.
• Identität, die den App-Prozess überdauert. Ein Wassereintrag, den der Benutzer gestern über Siri protokolliert hat, sollte heute über Siri referenzierbar sein. Das AppEntity-Modell gibt dem System eine stabile Möglichkeit, sitzungsübergreifend über Objekte zu sprechen.
• Stille Fehlerbehandlung. Fehler landen nicht in der Ansicht eines Benutzers; sie landen in einer Siri-Antwort, einer Shortcuts-Ausgabe oder einem Spotlight-Ergebnis. Das vom System erwartete Fehlerformat ist strukturiert (Apples AppIntentError plus LocalizedError-konforme Throws), nicht visuell.
• Idempotenz bei Wiederholungen. Das System kann einen Intent während einer Shortcut-Kette oder nach einem Teilfehler erneut aufrufen. Funktionen, die den Zustand verändern, müssen unter wiederholten Aufrufen sicher sein oder eine klare „Bereits erledigt”-Semantik vermitteln.

Was die Apple-Intelligence-Oberfläche der Funktion zurückschuldet:

• Die tatsächliche Identität des Benutzers. Das System weiß, wer der Benutzer ist, hat ihn über das OS authentifiziert und führt den Intent in seinem Kontext aus. Die Funktion muss die Identität nicht über das hinaus verifizieren, was das OS bereitstellt.
• Darstellung auf Systemebene. Das Ergebnis, das der Intent zurückgibt, wird vom System in das passende Chrome formatiert (Banner auf dem Sperrbildschirm, Siri-Antwortkarte, Shortcuts-Ausgabe). Die App steuert nicht, wie die Antwort dargestellt wird.
• Auffindbarkeit, ohne dass Ihr Code läuft. App Intents können aufgerufen werden, wenn Ihre App nicht läuft. Das System liest das Schema und stellt die Funktion proaktiv zur Verfügung.

Die Vertrauenshaltung: Apple Intelligence ist Apples Erstanbieter-Agent. Der Benutzer hat ihn nicht konfiguriert; das System hat es getan. Der Benutzer vertraut dem OS; das OS vertraut dem App-Intents-Schema, das Ihre App durch das Review ausgeliefert hat. Die Vertrauenskette ist OS → App. App Intents unterstützen requestConfirmation(...) und Vordergrundmodus-Bestätigungen, sodass Funktionen, die ein „Sind Sie sicher?” benötigen, technisch dort leben können; die Produktentscheidung, nicht die Plattformbeschränkung, ist, ob risikoreiche Bestätigungen in einen Siri-Turn gehören oder auf den eigenen Bildschirm der App. Alles Unwiderrufliche (Kontolöschung, destruktive Massenbearbeitungen, Bezahlung) ist in der Regel auf der menschlichen Oberfläche sicherer, auch wenn App Intents eine Bestätigung anfordern können.³

Oberfläche drei: Agent

Die Agent-Oberfläche ist jedes andere LLM-gestützte System, das die Domäne der App bedienen möchte. Claude Desktop, Claude Code, Cursor, die ChatGPT-Desktop-App, Codex CLI, benutzerdefinierte Agent-Harnesses. Das Framework ist das Model Context Protocol: Ein MCP-Server stellt die Domäne der App über JSON-RPC-tools/call-Methoden bereit; der Host-LLM entdeckt die Tools beim Sitzungsstart und ruft sie namentlich mit einer JSON-Nutzlast auf.⁴

Was die Agent-Oberfläche von einer Funktion benötigt:

• Einen JSON-RPC-Vertrag. Tool-Name, Beschreibung, inputSchema, optional outputSchema. Der Agent liest die Beschreibung, um zu entscheiden, ob er aufruft; er folgt dem Schema, um die Argumente zu formatieren.
• Eine nützliche Beschreibung. Das Modell entscheidet anhand seiner Beschreibung, wann das Tool zu verwenden ist. Behandeln Sie die Beschreibung wie einen Docstring, von dem Sie erwarten, dass ein anderer Entwickler (das Modell) ihn liest. Vage Beschreibungen führen zu falscher Tool-Auswahl.
• Fehler in zwei Formen. Tool-Ausführungsfehler werden als Inhaltsblock plus isError: true im vom Modell gelesenen Tool-Ergebnis zurückgegeben. Fehler auf Protokollebene (fehlerhafte Anfrage, fehlendes Tool, Transportfehler) werden als standardmäßige JSON-RPC-error-Antworten zurückgegeben, die der Host behandelt. Der Tool-Autor besitzt die ersten; das Protokoll besitzt die zweiten.
• Zustandslose oder explizit zustandsbehaftete Semantik. MCP ist auf der Protokollebene zustandsbehaftet (Sitzungslebenszyklus, Sitzungs-IDs in Streamable HTTP), aber dauerhafte Domänenidentität ist eine serverseitige Verantwortung, keine Garantie auf Protokollebene. Wenn derselbe Bezeichner sitzungsübergreifend dasselbe bedeuten soll, muss der Server dies durchsetzen.

Was die Agent-Oberfläche der Funktion zurückschuldet:

• Die Authentifizierung des Hosts, nicht des Benutzers. Das Vertrauen kommt von demjenigen, der den MCP-Server bereitgestellt hat. Lokales Stdio des Entwicklers: die eigenen Dateisystemberechtigungen des Entwicklers. Internet-erreichbares HTTP: was auch immer für eine Authentifizierung der Server durchsetzt. Die Funktion muss davon ausgehen, dass die Identitätsbehauptung das ist, was der Server ihr gegeben hat.
• Toleranz für variable Latenz. Der Host kann länger warten als die menschliche Oberfläche oder die Apple-Intelligence-Oberfläche. Ein Tool-Aufruf, der dreißig Sekunden dauert, ist auf der Agent-Oberfläche akzeptabel und auf den anderen inakzeptabel.
• Keine Darstellungsoberfläche. Das Ergebnis ist Text oder strukturierte Daten, die das Modell interpretiert. Kein Chrome, keine UI, keine Systemformatierung.

Die Vertrauenshaltung: Der MCP-Server ist der Vertrag des Entwicklers darüber, wer ihn aufrufen darf. Zwei Bereitstellungen desselben Servers (lokales Stdio für die Entwicklung, Internet-HTTP für Endbenutzer) haben sehr unterschiedliche Vertrauenshaltungen und benötigen sehr unterschiedliche Sicherungen. Das Protokoll ist dasselbe; die Bereitstellung ist die Architektur. Im Detail behandelt in App Intents vs MCP: Die Routing-Frage und Wenn das LLM in Ihrer App vs. in Ihrem Tooling lebt.⁵

Die sechs Achsen, in denen sich die Oberflächen unterscheiden

Die drei Oberflächen in eine Vergleichstabelle zu ziehen, macht die Architekturentscheidungen konkret:

Die Unterschiede setzen sich zusammen. Eine für die menschliche Oberfläche entworfene Funktion setzt enge Latenz, reiche Darstellung und app-verwaltete Fehler voraus. Sie durch Apple Intelligence zu zwängen, verliert die Kontrolle über die Darstellung und fügt OS-vermittelte Identität hinzu. Sie durch die Agent-Oberfläche zu zwängen, verliert die Darstellung vollständig und verschiebt die Vertrauensgrenze auf denjenigen, der den Server bereitgestellt hat. Die Funktion muss neu geformt werden, nicht nur neu verpackt.

Die Architekturregel: Domänenschicht unterhalb der Oberflächen

Das Muster, das über die drei Oberflächen hinweg überlebt, ist eine Domänenschicht unter ihnen. Die Domänenschicht besteht aus einfachen Swift-Funktionen: typisierte Eingaben, typisierte Ausgaben, keine Protokollannahmen. Jede Oberfläche ist ein dünner Adapter über der Domäne. Dieselbe logWater(amount:caller:)-Funktion liegt der SwiftUI-Schaltfläche, dem perform() des App Intents und dem Handler des MCP-Tools zugrunde.

Die Skizze (echte Produktion würde WaterEntry für die Rückgabe des App Intents an AppEntity anpassen, domain als Abhängigkeit injizieren statt als Top-Level-Referenz und das erforderliche static var title am Intent hinzufügen):

// Domain layer (the actual capability)
func logWater(amount: Measurement<UnitVolume>, at: Date, caller: Caller) throws -> WaterEntry {
    try guards.requireWritePermission(caller)
    let entry = WaterEntry(amount: amount, timestamp: at)
    try store.insert(entry)
    return entry
}

// Adapter A: human surface (SwiftUI button)
Button("Log 250ml") {
    Task {
        let entry = try await domain.logWater(
            amount: .init(value: 250, unit: .milliliters),
            at: .now,
            caller: .human
        )
        // Update view state, show confirmation animation, etc.
    }
}

// Adapter B: Apple Intelligence surface (AppIntent)
struct LogWaterIntent: AppIntent {
    static var title: LocalizedStringResource = "Log Water"
    @Parameter(title: "Amount") var amount: Measurement<UnitVolume>
    func perform() async throws -> some IntentResult & ReturnsValue<WaterEntry> {
        let entry = try domain.logWater(amount: amount, at: .now, caller: .siri)
        return .result(value: entry)  // WaterEntry conforms to AppEntity
    }
}

// Adapter C: agent surface (MCP tool handler)
let entry = try domain.logWater(
    amount: .init(value: ml, unit: .milliliters),
    at: .now,
    caller: .mcp(host: hostName)
)
return .text("Logged \(entry.amount) at \(entry.timestamp)")

Drei Aufrufer. Eine Domänenfunktion. Die Domänenfunktion erhält einen Caller-Parameter, sodass sie unterschiedliche Regeln pro Oberfläche durchsetzen kann (Ratenbegrenzungen, Audit-Protokollierung, Bestätigungspflichten), ohne dass jede Oberfläche sie neu implementieren muss. Die Adapter sind dumm; die Domäne ist klug.

Die Form verallgemeinert das Dual-Adapter-Muster aus App Intents vs MCP; das Hinzufügen der menschlichen Oberfläche als dritte Aufruferklasse ist die natürliche Erweiterung. Das On-Device-LLM Foundation Models, wenn es innerhalb der App verwendet wird, sitzt auf der menschlichen Oberfläche (der Benutzer hat eine In-App-Funktion aufgerufen, die zufällig das Modell aufruft); das Runtime-LLM ist keine vierte Oberfläche, es ist eine Möglichkeit, Funktionen auszuführen, die bereits zur menschlichen Oberfläche gehören.⁶

Nicht jede Funktion bedient alle drei Oberflächen

Gleiche Verfügbarkeit ist nicht das Ziel. Verschiedene Funktionen gehören auf verschiedene Oberflächen.

Funktionen, die in der Regel die Anwesenheit eines Menschen im Vordergrund erfordern sollten. Fotoaufnahme, biometrische Authentifizierung, Eingabe sensibler PII, Bezahlbestätigung, Kontolöschung. Der Mensch muss auf den Bildschirm schauen, muss zustimmen, muss sich authentifizieren. Apple Intelligence kann die App technisch in den Vordergrund holen und eine Bestätigung anfordern; die Agent-Oberfläche hat keine entsprechende Anwesenheitsgarantie. Die Produktentscheidung lautet, dass diese Funktionen als Vordergrund-UI mit expliziter, bewusster Aktion ausgeführt werden sollten, nicht als stiller Siri- oder Hintergrund-Tool-Aufruf.

Funktionen, die auf den Oberflächen Mensch + Apple Intelligence leben sollten. Die meisten benutzerorientierten Aktionen. Wasser protokollieren, eine Meditation starten, einen Eintrag zur Liste hinzufügen, zeige mir die Einträge meines Dienstags. Der Benutzer könnte auf eine Schaltfläche tippen oder „Hey Siri” sagen. Beide Oberflächen sind gültig; beide sollten dieselbe Domänenfunktion erreichen.

Funktionen, die auf allen drei Oberflächen leben sollten. Prozessübergreifende Integrationen. Eine Einkaufsliste, die zwischen dem iPhone des Benutzers und einer Claude Code-Sitzung geteilt wird, die Rezepte importiert. Die menschliche Oberfläche besitzt den täglichen Gebrauch; die Apple-Intelligence-Oberfläche besitzt die Reichweite über Siri/Spotlight; die Agent-Oberfläche besitzt den entwickler- oder benutzergetriebenen externen Workflow.

Funktionen, die nur auf der Agent-Oberfläche leben sollten. Entwickler- oder Admin-Massenimporte ohne Endbenutzer-Review-Flow, Integrationen mit externen Systemen, agent-orchestrierte Workflows, die keinen Siri- oder In-App-Ausdruck haben. Massenimport von 500 historischen Einträgen aus einer CSV des Entwicklers während eines einmaligen Backfills. Endbenutzer-Dateiimporte haben oft einen menschlichen Oberflächen-Flow (Shortcuts können Dateien übergeben; ein In-App-Importer kann den Fortschritt zerlegen); der reine Agent-Fall ist der Workflow, der wirklich keinen Platz in einer der anderen beiden Oberflächen hat.

Die Entscheidung ist das Design. Die Auflistung der Oberflächen, die eine Funktion nicht bedient, ist genauso wichtig wie die Auflistung derjenigen, die sie bedient.

Was ich anders bauen würde

Zwei Muster, die die Apps des Clusters entweder ausliefern oder sich wünschen, sie hätten sie ausgeliefert.

Machen Sie Caller zu einem erstklassigen Typ in der Domänenschicht. Jede öffentliche Domänenfunktion erhält ein Caller-Argument. Der Typ kodiert, welche Oberfläche den Aufruf ausgelöst hat (.human, .siri, .mcp(host:)). Die Domänenlogik verzweigt darauf für Bestätigungsaufforderungen, Ratenbegrenzungen, Audit-Protokollierung und Tore für sensible Aktionen. Die Alternative (jede Oberfläche implementiert die Regeln neu) driftet; die zentralisierte Version bleibt konsistent.

Behandeln Sie die Oberflächenabdeckung als explizite Checkliste. Beim Hinzufügen einer Funktion listet das Designdokument auf, welche der drei Oberflächen sie verfügbar machen sollten und welche sie ablehnen sollten. Die Ablehnungsliste ist kein Standardwert; sie ist eine bewusste Entscheidung. Abgelehnt: Apple-Intelligence-Oberfläche, weil die Funktion einen Nachweis der Benutzeraufmerksamkeit erfordert, den Siri nicht liefern kann. Die Begründung wird festgehalten; das Audit erfasst spätere Drift.

Was das Muster für Apps bedeutet, die unter iOS 26+ ausgeliefert werden

Drei Erkenntnisse.

1. Drei Oberflächen, drei Vertrauenshaltungen. Mensch, Apple Intelligence, Agent. Jede hat Pflichten, die die anderen nicht haben. Für eine zu entwerfen und in andere zu zwängen, erzeugt schlechte Architektur auf jeder Oberfläche.

2. Domäne unten; Adapter oben. Eine Swift-Funktion pro Funktion; dünne Adapter pro Oberfläche; die Funktion erhält einen Caller-Parameter, sodass sie oberflächenspezifische Regeln an einer Stelle durchsetzen kann.

3. Nicht jede Funktion bedient alle drei. Eine Funktion vor den Oberflächen zu verbergen, die sie nicht haben sollten, ist genauso eine Designentscheidung wie sie verfügbar zu machen. Die Ablehnungsliste verdient ihren Platz.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents für die Apple-Intelligence-Oberfläche; MCP-Server für die Agent-Oberfläche; die Routing-Frage zwischen ihnen; Foundation Models für On-Device-LLM-Funktionen innerhalb der menschlichen Oberfläche; die Unterscheidung zwischen Runtime- vs. Tooling-LLM; Live Activities für die Zustandsmaschine des iOS-Sperrbildschirms; der watchOS-Runtime-Vertrag auf der Apple Watch; SwiftUI-Internas für das Substrat der menschlichen Oberfläche; RealityKits räumliches mentales Modell für visionOS-Szenen; SwiftData-Schemadisziplin für oberflächenübergreifende Persistenz; Liquid-Glass-Muster für die menschliche visuelle Schicht; Multi-Plattform-Auslieferung für geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für umfassenderen Kontext zu iOS mit LLM-Agenten siehe den iOS Agent Development Guide.

FAQ

Was sind die drei Oberflächen einer iOS-App?

Die menschliche Oberfläche (SwiftUI-Views, Tippen, Gesten, Bildschirm), die Apple-Intelligence-Oberfläche (App Intents, Siri, Shortcuts, Spotlight) und die Agent-Oberfläche (MCP-Server, die externen LLM-Hosts wie Claude Code, Cursor, ChatGPT bereitgestellt werden). Jede hat ihre eigene Aufruferidentität, ihr eigenes Latenzbudget, ihren eigenen Darstellungsort, ihre eigene Persistenzsemantik und Vertrauenshaltung. Eine Funktion, die mehr als eine Oberfläche bedienen möchte, sollte auf einer Domänenschicht unterhalb dünner Adapter pro Oberfläche sitzen.

Sollte jede Funktion auf allen drei Oberflächen verfügbar gemacht werden?

Nein. Einige Funktionen sind korrekterweise auf eine oder zwei Oberflächen beschränkt. Fotoaufnahme, biometrische Authentifizierung und Bestätigungen sensibler Aktionen sind in der Regel als Vordergrund-Flows der menschlichen Oberfläche am besten aufgehoben, weil die Vertrauenssignale (Benutzeraufmerksamkeit, bewusste Aktion) dort am zuverlässigsten vorhanden sind. Entwicklergetriebene Massenoperationen gehören allein auf die Agent-Oberfläche, wenn kein Endbenutzer-Review-Flow existiert. Die Designentscheidung ist, welche Oberflächen eine Funktion bedient und welche sie ablehnt.

Was ist der Unterschied zwischen den Oberflächen Apple Intelligence und Agent?

Apple Intelligence ist Apples Erstanbieter-Agent: Der Benutzer ruft Siri, Shortcuts oder Spotlight auf; das System leitet über App Intents weiter. Das Vertrauen kommt vom OS. Die Agent-Oberfläche ist jeder andere LLM-Host: Entwickler verwenden Claude Code oder Cursor, Endbenutzer verwenden Claude Desktop oder ChatGPT. Das Vertrauen kommt von demjenigen, der den MCP-Server bereitgestellt hat. App Intents sind die Protokolloberfläche für den ersten; MCP ist die Protokolloberfläche für den zweiten.

Wo passt das On-Device-LLM Foundation Models hin?

In die menschliche Oberfläche. Wenn der Benutzer eine In-App-Funktion aufruft, die Foundation Models aufruft, ist das Runtime-LLM die Implementierung einer Funktion der menschlichen Oberfläche, keine vierte Oberfläche. Das Runtime-LLM hat keinen eigenen Siri- oder externen Host-Aufrufer. Foundation-Models-Tools sind die Art und Weise, wie das On-Device-Modell den Domänenzustand der App liest/schreibt; der Benutzer ist derjenige, der den Aufruf antreibt.

Wie vereinfacht das Domänenschicht-Muster den Code mit mehreren Oberflächen?

Durch Zentralisierung der Regeln. Eine Swift-Funktion erhält ein Caller-Argument und setzt oberflächenspezifisches Verhalten (Bestätigungsaufforderungen, Ratenbegrenzungen, Audit-Protokollierung) an einer Stelle durch. Jede Oberfläche ist ein dünner Adapter (SwiftUI-Bindung, AppIntent.perform, MCP-Handler), der das Protokoll der Oberfläche in die Domänenfunktion übersetzt. Drift zwischen Oberflächen wird unmöglich, weil es eine einzige Quelle der Wahrheit gibt.

Quellen