App Intents mit Siri AI verbinden? Entwickler-Tutorial 2026

„App Intents“ ist kein einzelner Siri-Schalter. Die Integration betrifft mehrere unterschiedliche Fragen: Welche Inhalte kann ein System auffinden? Welche Aktionen kann eine App anbieten? Welcher Kontext steht beim Aufruf zur Verfügung? Und welche Daten sollen zwischen Apps weitergegeben werden? Werden diese Aufgaben vermischt, entstehen Implementierungen, die zwar kompiliert werden, aber die eigentliche Nutzersituation nicht abdecken.

Die App-Intents-Übersicht von Apple beschreibt das Framework als Schnittstelle, über die Apps Aktionen und Inhalte für Systemfunktionen bereitstellen können. Für die Architekturentscheidung genügt es jedoch nicht, irgendeinen Intent anzulegen. Ein Intent für „Eintrag speichern“ ersetzt kein Modell, mit dem die App einen konkreten gespeicherten Eintrag identifizieren kann. Umgekehrt macht eine Entity zwar Inhalte beschreibbar, führt aber nicht automatisch eine gewünschte Änderung aus.

Prüfen Sie deshalb zuerst, was der Nutzer tatsächlich erreichen will:

• Soll Siri einen bestimmten Inhalt finden oder darüber Auskunft geben?
• Soll eine klar definierte App-Aktion ausgeführt werden?
• Bezieht sich die Anfrage auf etwas, das gerade auf dem Bildschirm zu sehen ist?
• Muss ein Inhalt an eine andere App übergeben oder von ihr übernommen werden?

Diese Unterscheidung ist auch für die Suche relevant: Wer App Intents für Siri AI einsetzt, sollte zwischen Inhaltssuche, Aktionsaufruf und Kontextweitergabe unterscheiden, statt alle drei Erwartungen in einen einzigen Intent zu packen.

Wenn Siri einen Inhalt aus der App finden soll, muss dieser Inhalt als identifizierbares Datenobjekt beschrieben werden können. Eine App Entity sollte deshalb auf ein echtes Produktobjekt verweisen, das der Nutzer kennt: etwa ein Projekt, eine Notiz oder einen Termin. Der Anzeigename, weitere sichtbare Informationen und die interne Identität müssen dabei zusammenpassen. Ein generischer Titel wie „Element 42“ hilft wenig, wenn Nutzer nach einem Projektnamen suchen.

Legen Sie vor dem Schreiben der Entity eine kleine Liste tatsächlicher Suchformulierungen an. Notieren Sie, welche Attribute die App braucht, um passende Objekte voneinander zu unterscheiden. Prüfen Sie anschließend, ob diese Attribute in Ihrem Datenmodell vorhanden, verständlich und ausreichend stabil sind. Ein Name kann als Such- oder Anzeigeinformation nützlich sein; eine interne Datenbank-ID kann dagegen der Zuordnung dienen, ohne dass sie als Nutzerbegriff taugt.

Apples Anleitung zu App Entities in Spotlight ist relevant, wenn Inhalte im Voraus für die Suche bereitgestellt werden können. Daraus folgt keine allgemeine Pflicht, jede Entity auf diese Weise zu indizieren. Prüfen Sie, ob die Inhalte dauerhaft genug sind, ob eine Vorab-Indexierung zur Aktualisierungslogik passt und ob sich die gewünschten Suchanfragen damit sinnvoll abbilden lassen. Bei kurzlebigen oder häufig wechselnden Daten ist zu klären, ob eine andere Abfrage zur Laufzeit die passendere Architektur ist. Die konkrete API-Verfügbarkeit muss mit der Dokumentation für die Zielversion abgeglichen werden.

Die entscheidende Abnahmefrage lautet nicht nur „Wurde die Entity gefunden?“, sondern: Kann die App das richtige Objekt eindeutig zurückgeben, wenn Nutzer nach den Begriffen suchen, die sie im Alltag tatsächlich verwenden? Prüfen Sie auch ähnliche Namen, fehlende Treffer und Änderungen am Inhalt. Eine veröffentlichte Entity ist kein Versprechen, dass Siri bei jeder Formulierung genau das erwartete Objekt oder eine bestimmte Antwort liefert.

App Entities beschreiben Inhalte, mit denen die App arbeitet. App Intents machen konkrete Aktionen verfügbar. App Schemas können passende, von Apple definierte Handlungsmuster nutzen, damit Funktionen in einem von Siri oder anderen Systemfunktionen verstandenen Rahmen angeboten werden. Sie sind daher keine alternative Bezeichnung für Entities und nicht für jede App-Aktion automatisch geeigneter als ein eigener Intent.

Bevor eine vorhandene Aktion neu geschrieben wird, vergleichen Sie ihren Zweck mit den dokumentierten Möglichkeiten der App Schemas. Apple beschreibt in der Dokumentation zum Auffinden von Aktionen und Inhalten mit App Schemas, wie diese Schemas einzuordnen sind. Das WWDC26-Video zu App Schemas ergänzt Beispiele; Beispiele aus einer Präsentation sind jedoch nicht mit einer Zusage gleichzusetzen, dass jede Funktion in jeder Zielversion oder in jedem Siri-Kontext verfügbar ist.

Wenn die Funktion nicht sinnvoll zu einem dokumentierten Schema passt, kann ein eigener App Intent die bessere Beschreibung sein. Beschreiben Sie ihn ausgehend vom Nutzerziel, nicht von der internen Implementierung: Welche Eingabe ist wirklich erforderlich? Welches Ergebnis wird zurückgegeben? Was passiert bei einem unbekannten Inhalt, fehlender Berechtigung oder einer nicht erreichbaren Datenquelle? Diese Fragen verhindern, dass ein oberflächlich erfolgreicher Aufruf als vollständig behandelt wird, obwohl ein relevanter Fehlerfall ungeklärt bleibt.

Damit Siri eine Frage zu App-Inhalten sinnvoll bearbeiten kann, müssen Inhaltssuche und Aktionsausführung getrennt überprüft werden. Ein App Intent, der eine Aktion anbietet, sagt für sich genommen nicht aus, welche Inhalte die App kennt oder wie ein bestimmter Datensatz gefunden wird. Umgekehrt beweist eine auffindbare Entity nicht, dass Siri eine passende Aktion ausführen kann.

Bilden Sie eine Prüfung für jeden Inhaltstyp, der gefunden werden soll:

1. Wählen Sie ein reales Beispielobjekt aus der App.
2. Prüfen Sie, welche Suchbegriffe ein Nutzer dafür tatsächlich verwenden würde.
3. Ordnen Sie die Begriffe den verfügbaren Namen und Attributen der Entity zu.
4. Stellen Sie fest, ob die Inhalte vorab verfügbar gemacht werden können oder dynamisch abgefragt werden müssen.
5. Testen Sie eindeutige, ähnliche und nicht vorhandene Treffer.

Ein Beispiel: Eine Aufgaben-App soll eine benannte Aufgabe auffindbar machen. Das Testobjekt braucht eine Nutzer-identifizierbare Bezeichnung und eine belastbare Zuordnung zum gespeicherten Datensatz. Eine Abfrage mit einem ähnlichen Titel darf nicht stillschweigend eine andere Aufgabe auswählen. Wird keine passende Entity zurückgegeben, sollte das Ergebnis kontrolliert und nachvollziehbar sein, statt eine beliebige Aktion auf einem falschen Objekt auszuführen.

Verknüpfen Sie die Prüfung mit den Fragen, die Ihre Nutzer wirklich stellen. Wenn die App etwa „Projekt Atlas“ kennt, ist zu testen, ob diese Bezeichnung zum richtigen Projekt führt und ob relevante Suchattribute berücksichtigt werden. Die zuvor genannte Apple-Anleitung zur Indexierung von Entities in Spotlight hilft bei der technischen Beurteilung eines Indexierungswegs. Aus erfolgreicher Indexierung lässt sich jedoch keine garantierte Antwortqualität für Siri ableiten. Erheben Sie deshalb als Abnahmekriterium, welches Objekt die App bereitstellt, nicht eine bestimmte Formulierung der Systemantwort.

Leiten Sie einen Intent aus einer klaren Handlung ab. „Aufgabe als erledigt markieren“ ist ein überprüfbares Ziel; „App verwalten“ ist dafür zu unbestimmt. Legen Sie fest, welche Entity betroffen ist, welche Parameter der Nutzer liefern muss und welche Zustandsänderung tatsächlich erwartet wird. Prüfen Sie dabei auch, ob der Vorgang wiederholbar ist oder bei mehrfacher Ausführung einen unerwünschten Zustand erzeugt.

Für Aktionen mit Nebenwirkungen gelten besonders strenge Anforderungen. Beim Löschen, Versenden oder Ändern von Daten muss die App klären, ob eine Bestätigung notwendig ist und wie sie bei unklarer Auswahl oder fehlender Berechtigung reagiert. Eine Aktion darf einen mehrdeutigen Datensatz nicht allein deshalb auswählen, weil ein Systemaufruf einen Parameter geliefert hat. Legen Sie auch fest, welche Information an den Nutzer zurückgegeben wird, wenn die Aktion nicht abgeschlossen werden kann.

App Intents und App Schemas haben unterschiedliche Rollen: Der Intent beschreibt eine konkrete Funktion der App; ein Schema kommt in Betracht, wenn die Funktion und die Zielplattform zu einem von Apple vorgesehenen Muster passen. Prüfen Sie dafür die bereits verlinkte App-Schema-Dokumentation. Entscheiden Sie erst danach, ob ein vorhandener Intent angepasst, ein Schema verwendet oder die Aktion nicht für den Siri-Aufruf angeboten werden sollte.

Eine belastbare Aktionsprüfung enthält mindestens den normalen Erfolgsweg, ungültige oder fehlende Eingaben, eine nicht gefundene Entity sowie eine nicht autorisierte oder fehlgeschlagene Änderung. Notieren Sie für jeden Fall, ob die App einen Zustand verändert und was sie als Ergebnis zurückmeldet. So wird nicht nur getestet, ob die Methode aufgerufen wurde, sondern ob die App auf den Aufruf verlässlich reagiert.

Ein Nutzer kann sich auf ein Element beziehen, das gerade in einer Ansicht zu sehen ist. Das ist eine andere Anforderung als die allgemeine Suche nach Inhalten in der App. Die App sollte deshalb unterscheiden, ob ein Inhalt ohnehin suchbar ist oder ob ein aktueller Bildschirm beziehungsweise eine Nutzeraktivität zusätzliche Hinweise für die Interpretation liefert.

Apple beschreibt kontextuelle Hinweise für Apple Intelligence und Siri als eigenen Integrationsbereich. Nutzen Sie diese Möglichkeit nur, wenn die Ansicht tatsächlich zusätzliche Information über die gemeinte Auswahl bereitstellt. Bei einer Liste mit mehreren Einträgen muss die Prüfung beispielsweise feststellen, ob die App das ausgewählte Element korrekt zuordnet, auch wenn ein anderer Eintrag ähnlich benannt ist oder sich die Ansicht zwischenzeitlich geändert hat.

Ein sachgerechter Test besteht darin, eine Aktion auf das aktuell ausgewählte Objekt zu beziehen und anschließend zu prüfen, ob genau dieses Objekt verarbeitet wird. Prüfen Sie außerdem, was geschieht, wenn keine eindeutige Auswahl vorliegt oder die Auswahl nicht mehr existiert. Kontextuelle Hinweise sind keine Erlaubnis, beliebige Daten aus einer App-Oberfläche als verfügbar zu behandeln; sie müssen zur vorgesehenen Funktion und zu den geltenden Datenschutz- und Berechtigungsgrenzen passen.

Nicht jede Bildschirmreferenz verlangt eine übertragbare Datenrepräsentation. Apple dokumentiert IntentValueRepresentation als eigenen Mechanismus für die Repräsentation von Werten. Bewerten Sie Transferable erst, wenn ein konkreter Anwendungsfall das Übergeben von Inhalten zwischen Apps verlangt. Für eine Aktion, die lediglich auf einen internen Datensatz verweist, kann eine entsprechend modellierte Entity genügen.

Wenn ein Inhalt eine App verlässt, reicht es nicht, nur den Export zu beschreiben. Legen Sie getrennt fest, welche Informationen die abgebende App bereitstellt, wie der Empfänger sie interpretiert und welche Handlung anschließend erfolgen soll. Ein technisch übergebener Wert ist nicht automatisch sinnvoll, vollständig oder für den Empfänger zulässig.

Beginnen Sie mit einem kleinen, repräsentativen Datensatz. Prüfen Sie, ob die enthaltenen Felder für den vorgesehenen Zweck nötig sind, ob sensible Informationen ausgeschlossen bleiben und ob der Empfänger den Datentyp erwartungsgemäß verarbeiten kann. Dokumentieren Sie, was geschieht, wenn ein erforderliches Feld fehlt, der Empfänger den Inhalt nicht unterstützt oder der Nutzer die Weitergabe nicht autorisiert. Die App sollte einen verständlichen Rückweg anbieten, statt den Fehler als erfolgreiche Übertragung zu behandeln.

Die Apple-Dokumentation zu IntentValueRepresentation ist eine passende Referenz, wenn Werte für App-Intent-Szenarien repräsentiert werden sollen. Die Zusammenarbeit mit Siri oder Systemfunktionen ist dabei von einer direkten, app-eigenen Auslösung der Aktion einer anderen App zu unterscheiden. Planen Sie keine automatische Kontrolle über eine fremde App ein, nur weil ein Inhalt systemseitig übergeben werden kann. Die Zuständigkeit für Interpretation und Folgeaktion muss an der jeweiligen Schnittstelle klar bleiben.

Ein erfolgreicher Build belegt, dass der Code unter den geprüften Bedingungen erstellt werden konnte. Er belegt nicht automatisch, dass die App die Entity korrekt zurückliefert, eine Aktion sicher ausführt oder dass das tatsächliche Siri-Erlebnis auf dem vorgesehenen Gerät wie erwartet funktioniert. Apple bietet dafür getrennte Unterlagen zur Verifikation einer App-Intents-Implementierung und zum Testen des App-Intents-Codes. Nutzen Sie die dort beschriebenen Prüfwege passend zu Ihrer Implementierung und Plattformversion.

Arbeiten Sie die Abnahme in getrennten Ebenen ab:

• Fachlogik: Prüfen Sie Entity-Zuordnung, Suchattribute, Parameter, Ergebnis und Fehlerbehandlung unabhängig von der konkreten Siri-Antwort.
• Implementierung: Verwenden Sie die von Apple dokumentierten Verifikations- und Testmöglichkeiten für App Intents. Halten Sie fest, welche Eingabe geprüft wurde und ob der erwartete Zustand entstand.
• Systemintegration: Testen Sie den vorgesehenen Einstieg über die jeweilige Systemfunktion und prüfen Sie Berechtigungen, App-Zustand sowie verfügbare Inhalte.
• Zielgerät: Prüfen Sie die tatsächliche Nutzung auf dem vorgesehenen Gerät und mit der vorgesehenen Systemversion. Erfassen Sie Abweichungen zwischen Code-Test und End-to-End-Erlebnis, statt sie durch einen erfolgreichen Build zu ersetzen.

Für die Build-Umgebung sind die aktuellen Xcode-Systemanforderungen maßgeblich. API-Verfügbarkeit, unterstützte Systeme und Testverhalten müssen anhand der Dokumentation für die konkret eingesetzte Version überprüft werden. Ein Build auf einem Remote Mac kann belegen, dass die betreffende Konfiguration erfolgreich kompiliert. Er ersetzt aber keinen Test der Siri-Interaktion auf dem Zielgerät und keine Prüfung der Nutzerberechtigungen.

Vor einer Freigabe sollte das Team die Ergebnisse so dokumentieren, dass ein Fehler reproduzierbar bleibt: verwendete System- und Xcode-Version, Testobjekt, Anfrage beziehungsweise Eingabe, erwartetes Ergebnis und tatsächlich beobachtetes Verhalten. Ein Video oder ein Testprotokoll kann bei der Fehlersuche helfen; es ist jedoch kein Beleg dafür, dass sich dieselbe Antwort in allen Situationen oder auf anderen Systemversionen wiederholt.

• [ ] Für jeden auffindbaren Inhaltstyp ist eine konkrete App Entity mit nachvollziehbarer Identität vorgesehen.
• [ ] Anzeigenamen und Suchattribute entsprechen Begriffen, die Nutzer für den Inhalt verwenden.
• [ ] Die App hat begründet, ob Vorab-Indexierung zu Aktualität und Lebensdauer der Daten passt.
• [ ] Jeder App Intent beschreibt eine konkrete Nutzerhandlung und nicht nur einen internen Methodenaufruf.
• [ ] Parameter, Ergebnis und Fehlerfälle sind für jede Aktion dokumentiert.
• [ ] Änderungen und andere Aktionen mit Nebenwirkungen berücksichtigen Mehrdeutigkeit, Berechtigungen und erforderliche Bestätigung.
• [ ] App Schemas werden nur eingesetzt, wenn dokumentiertes Schema und tatsächliche Funktion zusammenpassen.
• [ ] Bildschirmkontext wird nur für einen nachweisbaren Kontextbedarf ergänzt.
• [ ] Transferable oder eine andere Inhaltsrepräsentation wird nur für einen echten Übergabefall vorgesehen.
• [ ] Absender und Empfänger sind für jeden Übergabefall getrennt geprüft, einschließlich fehlender Daten und Ablehnung.
• [ ] Code-Tests, Systemintegration und Siri-Erlebnis auf dem Zielgerät sind als getrennte Ergebnisse festgehalten.
• [ ] Ein erfolgreicher Remote-Build wird nicht als Ersatz für die End-to-End-Abnahme behandelt.

Für die Planung des Entwicklungsarbeitsplatzes ist außerdem die Trennung zwischen Codeerstellung und Geräteprüfung wichtig. Eine lokale Mac-Umgebung kann direkte Geräteverbindungen und wiederholte manuelle Tests erleichtern, bindet aber Kapital und benötigt ausreichend Speicherplatz. Ein allgemeines Cloud-System ohne macOS kann den Xcode-Build nicht übernehmen; ein Remote Mac benötigt seinerseits eine passende Verbindung zur Zielgeräteprüfung. Prüfen Sie deshalb vor der Wahl, ob das Team überwiegend baut, auf einem Gerät testet oder beides regelmäßig am selben Arbeitsplatz tun muss.

Wenn die App-Intents-Logik steht, aber ein macOS-Build-System für wiederholte Builds oder zusätzliche Tests fehlt, kann ein gemieteter Mac eine flexible Ergänzung zum vorhandenen Rechner sein. Er beseitigt jedoch weder die Notwendigkeit eines passenden Zielgeräts noch die Arbeit an Berechtigungen, Testfällen und tatsächlicher Siri-Erfahrung. Informationen zum Angebot finden Sie bei NUKCLOUD; vor einer Entscheidung sollten Anforderungen an Zugriff, Laufzeit und Standort mit dem konkreten Einsatz abgeglichen werden. Für Teams, die einen Standort prüfen möchten, ist auch die Bestellseite für die Region US East verfügbar.