App Intents vs MCP: Die Frage des Routings

Zwei Protokolle, App Intents und MCP, ermöglichen es beide einem externen Agenten, die Domäne einer App zu bedienen. Sie lassen sich nicht zu einem einzigen zusammenführen. Die Frage ist, was wohin gehört und warum jedes Protokoll für seinen eigenen Aufrufer die richtige Antwort ist.

Apple hat App Intents eingeführt, um Apple Intelligence eine typisierte, deklarative Schnittstelle zur Verfügung zu stellen, mit der Drittanbieter-Apps bedient werden können, ohne deren UI zu berühren.¹ Anthropic hat das Model Context Protocol eingeführt, um jedem LLM eine typisierte, server-vermittelte Schnittstelle zur Verfügung zu stellen, mit der jedes Werkzeug bedient werden kann, ohne dessen UI zu berühren.² Die Formen sind ähnlich. Die Aufrufer sind es nicht. Beide als eine einzige Schnittstelle zu behandeln, führt zu einer Architektur, die keiner gerecht wird.

Die beiden vorherigen Beiträge dieses Clusters behandelten jedes Protokoll für sich: App Intents in App Intents Are Apple’s New API to Your App, MCP in Two Agent Ecosystems, One Shopping List. Im vorliegenden Beitrag geht es um die Frage des Routings. Wann erhält eine Funktion einen AppIntent, wann ein MCP-Tool, wann beides, und was bleibt nur innerhalb der App zugänglich?

TL;DR

• App Intents sind der einzige Weg zu Apple Intelligence, Siri, Shortcuts und dem System-Vorschlagsstapel. Das System stellt sie ab der Installation und über App-Updates bereit, wobei App-Shortcuts-Donation und -Indexierung sie in Spotlight- und Siri-Vorschlägen sichtbar machen.
• MCP-Tools sind der Weg zu jedem nicht-Apple-LLM (Claude, ChatGPT, Gemini, lokale Modelle). Der Transport erfolgt über stdio oder Streamable HTTP, mit .mcpb als Packaging-Format, das üblicherweise einen lokalen stdio-Server mitliefert; der Host lädt die Tools zu Sitzungsbeginn.
• Beide Protokolle treffen sich bei einem typisierten Schema, einer entity → action → result-Struktur und der Parameterauflösung. Sie unterscheiden sich bei Identität, Persistenz, Latenz und der Rendering-Schnittstelle.
• Die Routing-Regel: Wenn die Funktion etwas ist, das ein Benutzer Siri fragen oder aus Spotlight aufrufen könnte, dann App Intents. Wenn die Funktion etwas ist, das ein Entwickler in eine Claude Code-Sitzung oder einen externen Agentenlauf einbinden könnte, dann MCP. Die meisten Apps benötigen beides für dieselbe Domäne.

Zwei Protokolle, dieselbe Form

Beide Protokolle definieren einen Operationsvertrag zwischen einem externen Aufrufer und der Domäne einer App. Der Vertrag besteht aus drei Teilen: dem Schema (was der Aufrufer anfordern kann), dem Resolver (wie die App die Entitäten findet, die das Schema benennt) und der Aktion (was ausgeführt wird und was zurückkommt).

App Intents drücken den Vertrag in Swift aus. Die Protokolloberfläche ist AppIntent, AppEntity, AppEnum, wobei @Parameter-Makros das Schema treiben und func perform() das Ergebnis zurückgibt.³ Das Schema wird zur Compile-Zeit generiert und mit der App bei der Installation gebündelt. Apple Intelligence, Siri, Shortcuts und Spotlight lesen alle dasselbe Schema und leiten eine typisierte Anfrage durch denselben perform()-Einstiegspunkt.

MCP drückt den Vertrag in JSON-RPC über stdio oder Streamable HTTP aus. Die Protokolloberfläche besteht aus den Methoden tools/list und tools/call, wobei jedes Tool einen Namen, eine Beschreibung und ein inputSchema deklariert (wobei die Spezifikation 2025-06-18 ein optionales outputSchema für strukturierte Rückgaben hinzufügt).⁴ Ein MCP-Host (Claude Desktop, Claude Code, Cursor, die ChatGPT-Desktop-App) erkennt die Tools zu Sitzungsbeginn und ruft sie namentlich mit einer JSON-Nutzlast auf. Der Host führt das Modell aus; der Server führt das Tool aus.

Die Form ist dieselbe: Schema, Resolver, Aktion. Der Unterschied liegt darin, wer welches Stück ausführt und wo die Vertrauensgrenze verläuft. App Intents laufen innerhalb des App-Prozesses, auf dem Gerät des Benutzers, unter den Berechtigungen der App, wobei das System das Aufrufrouting vermittelt. MCP-Server laufen dort, wo der Entwickler sie ausführen lässt (lokales stdio, gehostetes HTTP, eingebettetes Bundle), wobei der Host-LLM das Aufrufrouting über eine unbegrenzte Menge von Tools vermittelt.

Wo sich die beiden Protokolle unterscheiden

Über die Oberflächenform hinaus sind vier operative Unterschiede für das Routing relevant:

Identität und Persistenz. App Intents sprechen in AppEntity-Typen, die das System speichern, präsentieren und später erneut auflösen kann. Der Wassereintrag, den ich heute über Hey Siri, log 250ml in Water speichere, übersteht Neustarts, synchronisiert sich über die iCloud-Geräte des Benutzers und kann später von anderen Intents referenziert werden (Show me yesterday’s water entries). Das System verfolgt die Entitäts-ID über alle diese Aufrufe hinweg.³ MCP ist selbst ein zustandsbehaftetes Protokoll mit Lebenszyklusverwaltung, und Streamable HTTP unterstützt Sitzungs-IDs für Verbindungskontinuität, doch dauerhafte Domänenidentität ist eine serverseitige Angelegenheit; es gibt kein protokollebenes Pendant zu AppEntity-Identifikatoren, auf die ein Host-Modell sitzungsübergreifend bauen könnte. MCP unterstützt resources für persistente Referenzdaten, aber Identität bleibt eine serverseitige Verantwortung und ist kein erstklassiger Protokollvertrag.⁴

Latenz und Akku. Der perform()-Körper des App Intent wird im Kontext der App oder einer App-Erweiterung auf dem Gerät ausgeführt. Jegliche Netzwerknutzung kommt aus dem App-eigenen Code oder aus der umgebenden Apple-Intelligence-/Siri-Schicht, nicht aus dem Intent-Vertrag selbst. Eine typisierte, geräteinterne Aktion, die ein typisiertes Ergebnis zurückgibt, ist im Normalfall schnell. MCP-Tools, selbst lokale, durchlaufen stdio-JSON-RPC-Framing mit einer separaten Prozessgrenze, und entfernte MCP-Tools verursachen HTTP-Round-Trips. Das Latenzbudget ist ein anderes. Ein log 250ml-App-Intent kann innerhalb eines Siri-Turn-Taking-Fensters abgeschlossen werden. Ein entferntes MCP-Tool könnte der Engpass einer Claude Code-Sitzung sein.

Rendering-Schnittstelle. App Intents geben Ergebnisse zurück, die Apple Intelligence in die System-UI rendert: ein Lock-Screen-Banner, eine Siri-Antwort, eine Shortcuts-Ausgabe, ein Spotlight-Ergebnis. Die App kontrolliert nicht, wie das Ergebnis dargestellt wird. MCP-Tools geben Inhaltsblöcke zurück (Text, Bilder, Audio, eingebettete Ressourcen oder strukturierte Inhalte), die das Host-Modell liest und entscheidet, wie es sie an die Oberfläche bringt. Eine Claude Code-Sitzung kann das Ergebnis dem Entwickler zurückzitieren, zusammenfassen oder es in einen Folgeaufruf einspeisen. Die Rendering-Entscheidung liegt auf der Modellebene.

Auffindbarkeit. Apple Intelligence stellt App Intents ab der Installation zur Verfügung, wobei App-Shortcuts-Donation und -Indexierung die Intents auf Basis des Benutzerverhaltens in Spotlight-Suchen und Siri-Vorschlägen sichtbar machen; App-Updates und dynamische Entitäten passen die Oberfläche im Laufe der Zeit an. Der Benutzer tippt nie einen Tool-Namen ein. MCP-Hosts lesen Tools zu Sitzungsbeginn; der Benutzer (oder der System-Prompt) entscheidet, welche Tools das Modell sehen darf. Auf der MCP-Seite ist die Entdeckung explizite Konfiguration, auf der App-Intents-Seite implizite Systeminferenz.

Die beiden Protokolle unterscheiden sich bei Identität, Latenz, Rendering und Entdeckung: vier Eigenschaften, die aus einer einzigen Wurzelunterscheidung folgen. App Intents bedienen einen System-Agenten, den der Benutzer nicht konfiguriert hat. MCP bedient einen Sitzungs-Agenten, den der Entwickler konfiguriert hat. Verschiedene Aufrufer, verschiedene Verpflichtungen.

Die Routing-Regel

Die Funktionslandkarte für eine App mit beiden Protokollen sieht so aus:

                    ┌──────────────────────────────────────────┐
                    │           App's domain capabilities       │
                    │                                            │
                    │  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
                    │  │  CRUD   │  │ Queries │  │ Actions │    │
                    │  └─────────┘  └─────────┘  └─────────┘    │
                    └────┬────────────┬────────────┬────────────┘
                         │            │            │
              ┌──────────┴──────┐    │   ┌────────┴──────────┐
              │                 │    │   │                   │
              ▼                 ▼    ▼   ▼                   ▼
       ┌────────────┐    ┌─────────────────────┐    ┌──────────────┐
       │ App Intents │    │ Both (AppIntent +   │    │  MCP tools   │
       │   only      │    │  MCP tool wrapper)  │    │    only      │
       └────────────┘    └─────────────────────┘    └──────────────┘
            │                       │                       │
       Siri / Spotlight       Cross-protocol           Claude Code,
       Shortcuts              capabilities             external agents,
       Apple Intelligence     where both callers       LLM tooling,
       proactive surfaces     should reach the         dev workflows
                              same domain

Die Routing-Regel besteht aus drei Fragen, in dieser Reihenfolge.

Ist die Funktion etwas, das der Benutzer Siri fragen oder aus Shortcuts aufrufen würde? Wenn ja, benötigt die Funktion einen App Intent. Log 250ml of water, Start a meditation, Add bananas to my list, What did I weigh yesterday sind Intents, weil der Benutzer sie laut aussprechen, in Spotlight eintippen oder in Shortcuts verketten könnte. Der App Intent ist für solche Funktionen nicht optional; nichts anderes führt Sie zur Apple-Intelligence-First-Party-Agentenoberfläche.

Ist die Funktion etwas, das ein externer Agent ansteuern können sollte? Wenn ja, benötigt die Funktion ein MCP-Tool. Add an item to the shopping list from a Claude Code session, Read Get Bananas state into a Cursor agent context, Trigger a workflow from a remote tool-using LLM sind MCP-Tools, weil der Aufrufer nicht Apple Intelligence ist; der Aufrufer ist der LLM, den der Entwickler eingebunden hat. Das MCP-Tool kann dieselbe Domain-Layer-Swift-Funktion umhüllen, die der App Intent aufruft, doch die Protokolloberfläche ist JSON-RPC über den vom Entwickler gewählten Transport.

Muss die Funktion eine einzelne Sitzung mit stabiler, systembekannter Identität überdauern? Wenn ja, ist der App-Intent-Pfad die natürliche Wahl, denn das System liefert Ihnen AppEntity-Identität, Abfrageunterstützung und Persistenzsemantik kostenlos. Wenn nein, kann das MCP-Tool einen Inhaltsblock zurückgeben, dauerhafte Identität dem Ermessen des Servers überlassen und die Kosten der Entitätsmodellierung umgehen.

Die meisten nicht-trivialen App-Funktionen fallen in die Beides-Spalte. Eine Wasser-Logging-Funktion in Water hat einen AppIntent (damit Siri Diktate aufnehmen kann) und ein MCP-Tool (damit eine Claude Code-Sitzung aus einem exportierten Log nachfüllen kann). Die beiden Wege teilen sich eine Swift-Funktion; die Funktion weiß nicht, welcher Aufrufer sie aufgerufen hat.⁵

Die Form sieht im Code so aus: eine Domänenmethode und zwei Adapter-Wrapper, die sie beide aufrufen:

// Domain layer (Swift, no protocol assumptions)
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 1: App Intent (Apple Intelligence / Siri / Shortcuts)
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)
    }
}

// Adapter 2: MCP tool (Claude Desktop / Code / external agent)
// Tool name "log_water" with inputSchema {amount_ml: number}
// 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)")

Die beiden Adapter sehen unterschiedlich aus, weil ihre Aufrufer unterschiedlich sind. Die Funktion, die sie aufrufen, ist dieselbe.

Was in der App bleibt

Eine kleine, aber wichtige Gruppe von Funktionen sollte privat in der App bleiben. Sie an eines der Protokolle zu routen, ist ein Fehler.

UI-Zustands-Funktionen. „Open the third tab”, „scroll to the bottom”, „highlight this row” sind keine Domänenoperationen. Es sind Interaktionsprimitive. App Intents unterstützen einiges davon über OpensIntent und Shortcuts, doch die Genrepassung ist schlecht; der Benutzer will normalerweise ein Ergebnis, keine Navigation. Die Unterstützung von MCP für UI-Navigation ist sogar noch schlechter: Das Modell steuert keinen Bildschirm, es steuert ein Tool.

Funktionen, die einen Menschen körperlich in der Schleife erfordern. Fotoaufnahme, biometrische Authentifizierung, sensible PII-Eingabe, jeder Ablauf, der erfordert, dass der Benutzer auf den Bildschirm schaut und tippt. Apples CameraCaptureIntent existiert für Kameraabläufe, doch die Designabsicht ist, eine Vordergrund-Aufnahmeaktivität zu starten, nicht einem Agenten Hintergrund-Kamerazugriff zu gewähren. Die ehrliche Regel für beide Protokolle: Kamera-, Biometrie- und Sensitiv-Eingabeabläufe sollten als Vordergrund-UI mit expliziter Benutzerbestätigung laufen, nicht als stille Intent- oder Tool-Aufrufe. Halten Sie diese Funktionen hinter der UI der App und lassen Sie den Agenten den Benutzer zum Bildschirm leiten, nicht durch ihn hindurch.

Lang laufende Hintergrundarbeit. App Intents enthalten ProgressReportingIntent zur Fortschrittsanzeige, und MCP enthält Fortschrittsbenachrichtigungen und Task-Primitive, doch die Rendering-Schicht keines der beiden Protokolle ist auf nachhaltigen Fortschritt in Verbraucherabläufen ausgelegt. Das Host-Modell in einer MCP-Sitzung beendet Reasoning-Ketten in der Regel weit bevor ein mehrminütiges Tool fertig wird. Bei verbraucherorientierter, lang laufender Arbeit sollten Sie die Operation über die App-eigene UI bereitstellen; lassen Sie die Protokolle the request was queued zurückgeben und auf einen Statusbildschirm verlinken.

Alles, was die Daten eines anderen Benutzers berührt. Die Vertrauensgrenze in beiden Protokollen ist der aufrufende Agent. Apple Intelligence läuft unter dem iCloud-Konto des Benutzers. MCP läuft unter den Anmeldeinformationen, die der Entwickler eingebunden hat. Operationen, die Benutzer übergreifend sind (Teilen, Mehrbenutzerkonten-Zugriff, Admin-Aktionen), sind durch keines der beiden Protokolle sicher, weil die aufrufende Identität die falsche Identität ist.

Was ich anders bauen würde

Mit dem Wissen um die obige Routing-Regel würde ich die Domänenebene einer Swift-App so entwerfen, wie ich heute APIs an der Grenze eines Dienstes entwerfe. Die Domänenmethoden nehmen typisierte Eingaben und geben typisierte Ausgaben zurück, ohne eingebackene Protokollannahmen. App Intents umhüllen Domänenmethoden dünn mit @Parameter-Schema und perform()-Klebstoff. MCP-Tools umhüllen dieselben Domänenmethoden dünn mit JSON-Schema und stdio-Framing. Beide Protokolle sind dünne Adapter; die Arbeit liegt in der Domäne.

Daraus folgen zwei Konsequenzen.

Aufruferidentität ist eine Domänenangelegenheit, keine Protokollangelegenheit. Der App-Intent-Körper erhält systemaufgelöste Parameter und läuft in einem Kontext, in dem der Benutzer den systemeigenen Intent-Aufruf-Ablauf durchlaufen hat. Der MCP-Tool-Körper erhält die Anmeldeinformationen, die der Host arrangiert hat. Beide reichen sie als expliziten caller-Parameter an die Domänenmethode durch. Die Domänenmethode erzwingt Autorisierung, Bestätigungsabfragen und alle anderen Domäneninvarianten. Keines der Protokolle darf so tun, als sei der Aufrufer der Benutzer.

Beide Adapter zeigen denselben Affordance-Satz. Die Entscheidung, welche Funktionen welchem Aufrufer offenstehen, wird in zwei Manifesten festgehalten, nicht in verstreutem Protokollcode. Eine neue Funktion hinzuzufügen sind eine Domänenmethode, zwei Adapter-Wrapper und zwei Manifesteinträge. Eine Funktion zu entfernen ist symmetrisch. Die obige Matrix wird zu einer echten Datei.

Die Frontier der Apple-Plattform für die nächsten paar Jahre liegt nicht darin, eines der Protokolle auszuwählen. Die Frontier ist, beide als orthogonale Verträge zu behandeln, die sich auf derselben Domänenebene zusammensetzen. Apple-Intelligence-Agenten haben eine Reihe von Verpflichtungen gegenüber dem Benutzer (sie laufen geräteintern, sie sprechen Siri, sie rendern durch das System). Externe LLM-Agenten haben eine andere Reihe von Verpflichtungen gegenüber dem Entwickler (sie laufen, wo auch immer, sie sprechen JSON-RPC, sie rendern durch das vom Entwickler gewählte Modell). Beide verdienen eine typisierte Schnittstelle in Ihre App. Keiner verdient es, die einzige Schnittstelle zu sein.

Wann nicht beides bauen

Das Argument schneidet in beide Richtungen. Manche Apps brauchen ein Protokoll und nicht das andere.

Reine Verbraucher-Hilfsmittel ohne Entwickler-Schnittstelle. Eine Taschenlampe. Ein Vogelstimmen-Identifizierer. Ein Augmented-Reality-Maßband. Der Benutzer möchte es vielleicht über Siri aufrufen (App Intents sind nützlich), aber kein Entwickler bindet es in einen LLM-Workflow ein (MCP wäre kosmetisch).

Reine Entwickler-Tools ohne Endbenutzer-Schnittstelle. Ein Code-Formatter-MCP-Server. Ein Repository-Search-Tool. Ein Paketversions-Inspektor. Der Benutzer ist der Entwickler in einer Claude Code-Sitzung; Siri und Apple Intelligence haben keine Rolle.

Apps, die keiner der beiden Agentenklassen gut dienen. Hochinteraktive Spiele, Echtzeit-Mehrspieler-Apps, Apps, deren Wert darin besteht, in der App und auf dem Bildschirm zu sein. Keines der beiden Protokolle passt gut; die richtige Antwort ist eine großartige App und kein Agentenvertrag.

Die Entscheidung lautet nicht eines oder beides als Standard. Die Entscheidung lautet wofür ist diese App da und wer sonst möchte ihre Domäne bedienen. Die Antwort kann keines, eines oder beide sein. Die Kosten, eines zu bauen, sind klein, wenn die Domänenebene gut geformt ist. Die Kosten, beide auf dieser Domänenebene zu bauen, sind ebenfalls klein. Die Kosten, eines nicht zu bauen, wenn der Anwendungsfall es verlangt, sind das vollständige Fehlen der Funktion auf dieser Agentenoberfläche.

Was dieses Muster für den Apple-Stack auf iOS 26+ bedeutet

Zwei Erkenntnisse.

1. Behandeln Sie App Intents und MCP als orthogonale Verträge auf derselben Domäne, nicht als konkurrierende Protokolle. Apple Intelligence, Siri, Shortcuts und Spotlight sind eine Aufruferklasse mit Verpflichtungen auf Systemebene. Claude, Cursor, ChatGPT und der Rest sind eine zweite Aufruferklasse mit Verpflichtungen auf Sitzungsebene. Beide verdienen typisierten Zugriff. Die darunter liegende Domänenebene ändert sich nicht.

2. Die Routing-Regel lautet wer aufruft, nicht was läuft. Der App Intent und das MCP-Tool können dieselbe Swift-Funktion aufrufen. Sie unterscheiden sich in den Verpflichtungen, die der Aufrufer trägt, im Rendering, das sie zurückbekommen, und in der Persistenz, die sie erwarten. Bringen Sie die Funktion in Ordnung; lassen Sie die Protokollebenen dünn sein.

Der vollständige Apple-Ökosystem-Cluster: typisierte App Intents für Apple Intelligence, MCP-Server für LLM-übergreifende Agenten, Live Activities für die Lock-Screen-Zustandsmaschine, Liquid-Glass-Muster für die visuelle Ebene und Multi-Plattform-Auslieferung für geräteübergreifende Reichweite. Der Hub befindet sich in der Apple Ecosystem Series. Für den breiteren Kontext zu iOS mit AI-Agenten siehe den iOS Agent Development guide.

FAQ

Wann sollte ich für dieselbe Funktion einen App Intent vs. ein MCP-Tool bauen?

Bauen Sie einen App Intent, wenn die Funktion Apple Intelligence, Siri, Shortcuts oder Spotlight erreichen soll. Bauen Sie ein MCP-Tool, wenn die Funktion externe LLMs erreichen soll (Claude, ChatGPT, Agenten in Claude Code oder Cursor). Für Domänenfunktionen, die beiden Aufruferklassen dienen sollen, bauen Sie beides als dünne Adapter über einer gemeinsamen Swift-Domänenmethode.

Konkurrieren App Intents und MCP-Server miteinander?

Nein. App Intents sind der Weg zu Apples First-Party-Agentenstack; MCP ist der Weg zu jedem anderen LLM. Apple Intelligence ruft keine MCP-Tools auf, und externe LLM-Agenten können App Intents nicht direkt aufrufen (sie gehen durch das System). Die beiden Protokolle bedienen verschiedene Aufruferklassen mit unterschiedlichen Vertrauensmodellen, unterschiedlichen Latenzbudgets und unterschiedlichen Rendering-Schnittstellen.

Kann eine einzelne App ihre Domäne über beide Protokolle bereitstellen?

Ja, und die meisten nicht-trivialen Apps, die volle Agentenreichweite wollen, sollten das tun. Get Bananas (behandelt im MCP-Server-Beitrag) und Water (behandelt im App-Intents-Beitrag) sind frühe Beispiele. Das Muster ist eine Domänenebene unten, mit App-Intent-Adaptern und MCP-Tool-Adaptern darüber. Beide Adapter rufen dieselben Swift-Funktionen auf.

Welchen Zustand verfolgt Apple Intelligence, den MCP nicht verfolgt?

Apple Intelligence verfolgt AppEntity-Identität über Aufrufe, Sitzungen und Neustarts hinweg. Das Entitätsmodell gibt dem System persistente Referenzen, die der Benutzer über Intents hinweg verketten kann. MCP ist selbst ein zustandsbehaftetes Protokoll mit Lebenszyklusverwaltung und Sitzungs-IDs in Streamable HTTP, doch dauerhafte Domänenidentität ist eine serverseitige Verantwortung und kein erstklassiger Protokollvertrag; das Host-Modell erhält von der Protokolloberfläche keinen AppEntity-äquivalenten Identifikator. Das resources-Konzept von MCP unterstützt persistente Referenzdaten, operiert aber auf derselben serverseitigen Ebene.

Gibt es Funktionen, die ich über keines der beiden Protokolle bereitstellen sollte?

Ja. UI-Zustands-Funktionen (open this tab, scroll to here), Funktionen, die einen Menschen körperlich in der Schleife erfordern (Kameraaufnahme, Biometrie-Authentifizierung, sensible Eingabe), lang laufende Hintergrundarbeit und Operationen, die die Daten mehrerer Benutzer überspannen, sollten alle hinter der App-UI bleiben. Beide Protokolle haben schwache Primitive für diese Fälle, und keines trägt die Vertrauenssignale, die erforderlich sind, um sicher benutzerübergreifend zu operieren.

References