App Intents vs MCP: Die Routing-Frage

Genre: frontier-essay. Der Beitrag benennt eine Routing-Regel für agentische Apple-Entwicklung. Zwei Protokolle (App Intents und MCP) erlauben es beide einem externen Agenten, die Domain einer App zu bedienen. Sie fallen nicht in eines zusammen. Die Frage ist, was wohin gehört und warum jedes Protokoll für seinen jeweiligen Aufrufer die richtige Antwort ist.

Apple hat App Intents ausgeliefert, um Apple Intelligence eine typisierte, deklarative Oberfläche zu geben, mit der Drittanbieter-Apps bedient werden können, ohne deren UI anzufassen.¹ Anthropic hat das Model Context Protocol ausgeliefert, um jedem LLM eine typisierte, server-vermittelte Oberfläche zu geben, mit der jedes Werkzeug bedient werden kann, ohne dessen UI anzufassen.² Die Formen ähneln sich. Die Aufrufer nicht. Beide als eine einzige Oberfläche zu behandeln, erzeugt eine Architektur, die keinen von beiden zufriedenstellt.

Die beiden vorherigen Beiträge in diesem Cluster 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. Der vorliegende Beitrag widmet sich der Routing-Frage. Wann erhält eine Funktion einen AppIntent, wann ein MCP-Tool, wann beides, und was bleibt nur innerhalb der App verfügbar?

TL;DR

• App Intents sind der einzige Pfad zu Apple Intelligence, Siri, Shortcuts und dem System-Vorschlags-Stack. Das System stellt sie ab der Installation und über App-Updates bereit, wobei App Shortcuts Donation und Indexierung sie in Spotlight- und Siri-Vorschläge einspeisen.
• MCP-Tools sind der Pfad zu jedem nicht-Apple-LLM (Claude, ChatGPT, Gemini, lokale Modelle). Der Transport erfolgt über stdio oder Streamable HTTP, wobei .mcpb ein Paketformat ist, das üblicherweise einen lokalen stdio-Server mitliefert; der Host lädt die Tools zum Sitzungsbeginn.
• Beide Protokolle laufen auf ein typisiertes Schema, eine entity → action → result-Form und Parameter-Auflösung hinaus. Sie unterscheiden sich in Identität, Persistenz, Latenz und Rendering-Oberfläche.
• Die Routing-Regel: Wenn die Funktion etwas ist, das ein Benutzer Siri fragen oder aus Spotlight aufrufen könnte, gehört sie zu App Intents. Wenn die Funktion etwas ist, das ein Entwickler in eine Claude Code-Sitzung oder einen Agentenlauf einbinden könnte, gehört sie zu MCP. Die meisten Apps brauchen beides für dieselbe Domain.

Zwei Protokolle, dieselbe Form

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

App Intents formulieren den Vertrag in Swift. Die Protokoll-Oberfläche besteht aus AppIntent, AppEntity, AppEnum, wobei @Parameter-Makros das Schema treiben und func perform() das Ergebnis zurückgibt.³ Das Schema wird zur Compile-Zeit generiert und bei der Installation in die App gepackt. Apple Intelligence, Siri, Shortcuts und Spotlight lesen alle dasselbe Schema und routen eine typisierte Anfrage über denselben perform()-Einstiegspunkt.

MCP formuliert den Vertrag in JSON-RPC über stdio oder Streamable HTTP. Die Protokoll-Oberfläche besteht aus den Methoden tools/list und tools/call, wobei jedes Tool einen Namen, eine Beschreibung und ein inputSchema deklariert (die 2025-06-18-Spezifikation ergänzt ein optionales outputSchema für strukturierte Rückgaben).⁴ Ein MCP-Host (Claude Desktop, Claude Code, Cursor, die ChatGPT-Desktop-App) entdeckt Tools beim Sitzungsstart und ruft sie über ihren Namen mit einer JSON-Payload 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 laufen lässt (lokales stdio, gehostetes HTTP, eingebettetes Bundle), wobei der Host-LLM das Aufrufrouting über eine unbegrenzte Menge von Tools vermittelt.

Wo die beiden Protokolle uneins sind

Über die oberflächliche Form hinaus gibt es vier operationelle Unterschiede, die für das Routing entscheidend sind:

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, überlebt Neustarts, synchronisiert über NSUbiquitousKeyValueStore 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 Lifecycle-Management, und Streamable HTTP unterstützt Sitzungs-IDs für Verbindungskontinuität, aber dauerhafte Domain-Identität ist eine server-eigene Angelegenheit; es gibt kein protokoll-seitiges Pendant zu AppEntity-Bezeichnern, auf das ein Host-Modell sitzungsübergreifend bauen könnte. MCP unterstützt resources für persistente Referenzdaten, aber die Identität bleibt eine serverseitige Verantwortung statt eines erstklassigen Protokollvertrags.⁴

Latenz und Akku. Der perform()-Rumpf des App Intents wird im App- oder App-Extension-Kontext auf dem Gerät ausgeführt. Jegliche Netzwerknutzung kommt aus dem Code der App selbst oder aus der umgebenden Apple-Intelligence-/Siri-Schicht, nicht aus dem Intent-Vertrag selbst. Eine typisierte, geräteseitige 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 zum Engpass einer Claude Code-Sitzung werden.

Rendering-Oberfläche. 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 über deren Darstellung es entscheidet. Eine Claude Code-Sitzung könnte das Ergebnis dem Entwickler zurückzitieren, es zusammenfassen oder es in einen Folgeaufruf einspeisen. Die Rendering-Entscheidung liegt auf der Modellebene.

Auffindbarkeit. Apple Intelligence stellt App Intents ab der Installation bereit, wobei App Shortcuts Donation und Indexierung die Intents in Spotlight-Suchen und Siri-Vorschläge einspeisen, basierend auf dem Benutzerverhalten; 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 beim Sitzungsstart; der Benutzer (oder der System-Prompt) entscheidet, welche Tools das Modell sehen kann. Die Entdeckung ist auf der MCP-Seite explizite Konfiguration und auf der App-Intents-Seite implizite Systeminferenz.

Die beiden Protokolle sind sich uneins über 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. Unterschiedliche Aufrufer, unterschiedliche 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? Falls ja, braucht 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 tippen oder in Shortcuts verketten könnte. Der App Intent ist für solche Funktionen nicht optional; nichts anderes bringt Sie auf Apples erstanbieterseitige Agenten-Oberfläche.

Ist die Funktion etwas, das ein externer Agent ansteuern können soll? Falls ja, braucht 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 derjenige LLM, den der Entwickler verdrahtet hat. Das MCP-Tool kann dieselbe Domain-Schicht-Swift-Funktion umhüllen, die der App Intent aufruft, aber 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? Falls ja, ist der App-Intent-Pfad die natürliche Wahl, weil das System Ihnen AppEntity-Identität, Abfragesupport und Persistenzsemantik kostenlos liefert. Falls nein, kann das MCP-Tool einen Inhaltsblock zurückgeben, dauerhafte Identität dem Server überlassen und die Kosten der Entitätsmodellierung sparen.

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

Die Form sieht im Code aus wie eine Domain-Methode und zwei Adapter-Wrapper, die beide diese 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 Menge von Funktionen sollte privat zur App bleiben. Sie an eines der beiden Protokolle zu routen, ist ein Fehler.

UI-Zustands-Funktionen. „Open the third tab”, „scroll to the bottom”, „highlight this row” sind keine Domain-Operationen. Sie sind Interaktionsprimitive. App Intents unterstützen einen Teil davon über OpensIntent und Shortcuts, aber die Genre-Passung ist schlecht; der Benutzer will normalerweise ein Ergebnis, keine Navigation. Die MCP-Unterstützung für UI-Navigation ist sogar noch schlechter: Das Modell steuert keinen Bildschirm, es steuert ein Tool.

Funktionen, die den Körper einer Person in der Schleife erfordern. Fotoaufnahme, biometrische Authentifizierung, Eingabe sensibler PII, jeder Ablauf, der erfordert, dass der Benutzer auf den Bildschirm schaut und tippt. Apples CameraCaptureIntent existiert für Kamera-Abläufe, aber die Designabsicht ist es, eine Vordergrund-Aufnahmeaktivität zu starten, nicht einem Agenten Hintergrundzugriff auf die Kamera zu gewähren. Die ehrliche Regel für beide Protokolle: Kamera-, biometrische und Sensitive-Eingabe-Ablä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 routen, nicht durch ihn.

Lang laufende Hintergrundarbeit. App Intents enthalten ProgressReportingIntent zum Anzeigen von Fortschritt, und MCP enthält Fortschrittsbenachrichtigungen und Task-Primitive, aber die Rendering-Schicht keines der beiden Protokolle ist für anhaltenden Fortschritt in Verbraucher-Abläufen gebaut. Das Host-Modell in einer MCP-Sitzung lässt Reasoning-Ketten in der Regel ablaufen, lange bevor ein mehrminütiges Tool fertig ist. Für verbraucherorientierte lang laufende Arbeit sollten Sie die Operation über die eigene UI der App freigeben; 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 Anmeldedaten, die der Entwickler verdrahtet hat. Operationen, die mehrere Benutzer umspannen (Teilen, Mehrkonten-Zugriff, Admin-Aktionen), sind über keines der Protokolle sicher, weil die aufrufende Identität die falsche Identität ist.

Was ich anders bauen würde

In Kenntnis der obigen Routing-Regel würde ich die Domain-Schicht in einer Swift-App so entwerfen, wie ich heute APIs an der Grenze eines Dienstes entwerfe. Die Domain-Methoden nehmen typisierte Eingaben und geben typisierte Ausgaben zurück, ohne eingebackene Protokollannahmen. App Intents wickeln Domain-Methoden dünn mit @Parameter-Schema und perform()-Glue ein. MCP-Tools wickeln dieselben Domain-Methoden dünn mit JSON-Schema und stdio-Framing ein. Beide Protokolle sind dünne Adapter; die Arbeit liegt in der Domain.

Daraus folgen zwei Konsequenzen.

Aufrufer-Identität ist eine Domain-Angelegenheit, keine Protokoll-Angelegenheit. Der App-Intent-Rumpf erhält systemaufgelöste Parameter und läuft in einem Kontext, in dem der Benutzer den System-Intent-Aufrufablauf durchlaufen hat. Der MCP-Tool-Rumpf erhält die Anmeldedaten, die der Host arrangiert hat. Beide reichen sie als expliziten caller-Parameter an die Domain-Methode durch. Die Domain-Methode setzt Autorisierung, Bestätigungsaufforderungen und alle anderen Domain-Invarianten durch. Keines der beiden Protokolle darf vorgeben, der Aufrufer sei der Benutzer.

Beide Adapter geben dieselbe Affordance-Menge frei. Die Entscheidung, welche Funktionen welchem Aufrufer freigegeben werden, wird in zwei Manifesten festgehalten, nicht in verstreutem Protokollcode. Eine neue Funktion hinzuzufügen bedeutet eine Domain-Methode, zwei Adapter-Wrapper, 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 Jahre besteht nicht darin, ein Protokoll auszuwählen. Die Frontier besteht darin, beide als orthogonale Verträge zu behandeln, die sich in derselben Domain-Schicht zusammensetzen. Apple-Intelligence-Agenten haben einen Satz von Verpflichtungen gegenüber dem Benutzer (sie laufen geräteseitig, sie sprechen Siri, sie rendern über das System). Externe LLM-Agenten haben einen anderen Satz von Verpflichtungen gegenüber dem Entwickler (sie laufen irgendwo, sie sprechen JSON-RPC, sie rendern über das Modell, das der Entwickler ausgewählt hat). Beide verdienen eine typisierte Oberfläche in Ihre App. Keiner verdient es, die einzige Oberfläche zu sein.

Wann nicht beides bauen

Das Argument gilt in beide Richtungen. Manche Apps brauchen das eine Protokoll und nicht das andere.

Reine Verbraucher-Utilities ohne Entwickler-Oberfläche. Eine Taschenlampe. Ein Vogelstimmen-Identifikator. Ein AR-Maßband. Der Benutzer möchte es vielleicht über Siri aufrufen (App Intents sind nützlich), aber kein Entwickler verdrahtet es in einen LLM-Workflow (MCP wäre kosmetisch).

Reine Entwicklerwerkzeuge ohne Endbenutzer-Oberfläche. Ein Code-Formatter-MCP-Server. Ein Repository-Such-Tool. Ein Paket-Versions-Inspector. Der Benutzer ist der Entwickler in einer Claude Code-Sitzung; Siri und Apple Intelligence haben keine Rolle.

Apps, die keine der beiden Agentenklassen gut bedienen. Hochinteraktive Spiele, Echtzeit-Multiplayer-Apps, Apps, deren Wert darin liegt, 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 beide standardmäßig. Die Entscheidung lautet wofür ist diese App da und wer sonst möchte vielleicht ihre Domain bedienen. Die Antwort kann keines, eines oder beide lauten. Die Kosten, eines zu bauen, sind gering, wenn die Domain-Schicht gut geformt ist. Die Kosten, beide auf dieser Domain-Schicht zu bauen, sind ebenfalls gering. Die Kosten, eines nicht zu bauen, wenn der Anwendungsfall es verlangt, sind das vollständige Fehlen der Funktion auf dieser Agenten-Oberflä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 Domain, 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 Domain-Schicht darunter ändert sich nicht.

2. Die Routing-Regel lautet wer ruft auf, 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, dem Rendering, das er zurückbekommt, und der Persistenz, die er erwartet. Bringen Sie die Funktion in Ordnung; lassen Sie die Protokollschichten dünn sein.

Der vollständige Apple-Ecosystem-Cluster: typisierte App Intents für Apple Intelligence, MCP-Server für protokollübergreifende Agenten, Live Activities für die Lock-Screen-Zustandsmaschine, Liquid-Glass-Muster für die visuelle Schicht und Multi-Plattform-Auslieferung für geräteübergreifende Reichweite. Der Hub befindet sich unter der Apple Ecosystem Series. Für den breiteren iOS-mit-KI-Agenten-Kontext 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 Domain-Funktionen, die beide Aufruferklassen bedienen sollen, bauen Sie beide als dünne Adapter über einer gemeinsamen Swift-Domain-Methode.

Konkurrieren App Intents und MCP-Server miteinander?

Nein. App Intents sind der Pfad zu Apples erstanbieterseitigem Agenten-Stack; MCP ist der Pfad 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 unterschiedliche Aufruferklassen mit unterschiedlichen Vertrauensmodellen, unterschiedlichen Latenzbudgets und unterschiedlichen Rendering-Oberflächen.

Kann eine einzelne App ihre Domain über beide Protokolle freigeben?

Ja, und die meisten nicht-trivialen Apps, die volle Agentenreichweite wollen, sollten dies tun. Get Bananas (behandelt im MCP-Server-Beitrag) und Water (behandelt im App-Intents-Beitrag) sind frühe Beispiele. Das Muster besteht aus einer Domain-Schicht darunter, 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 Lifecycle-Management und Sitzungs-IDs in Streamable HTTP, aber dauerhafte Domain-Identität ist eine serverseitige Verantwortung statt eines erstklassigen Protokollvertrags; das Host-Modell erhält über die Protokolloberfläche keinen AppEntity-äquivalenten Bezeichner. Das resources-Konzept von MCP unterstützt persistente Referenzdaten, operiert aber auf derselben server-eigenen Schicht.

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

Ja. UI-Zustands-Funktionen (öffne diesen Tab, scrolle hierhin), Funktionen, die den Körper einer Person in der Schleife erfordern (Kameraaufnahme, biometrische Authentifizierung, sensible Eingabe), lang laufende Hintergrundarbeit und Operationen, die Daten mehrerer Benutzer umspannen, sollten alle hinter der UI der App bleiben. Beide Protokolle haben schwache Primitive für diese, und keines trägt die Vertrauenssignale, die erforderlich sind, um sicher über Benutzer hinweg zu operieren.

Quellen