Foundation Models in iOS 27: Steuerung des Tool-Callings

iOS 26 stellte einer App ein großes On-Device-Sprachmodell zur Verfügung, einen Weg zu typsicherer Ausgabe über @Generable sowie ein Tool-Protokoll, mit dem das Modell mitten in der Generierung Ihren Code aufrufen konnte¹. Das Modell entschied, wann es zu einem Tool griff, und Sie schrieben das Tool. Das Einzige, was Sie nicht tun konnten, war, das Aufrufverhalten selbst zu steuern, und das Einzige, was Sie immer tun mussten, war, jedes Tool von Hand zu schreiben — auch jene, die jede App braucht. iOS 27 schließt beide Lücken. GenerationOptions.ToolCallingMode erlaubt es Ihnen, pro Anfrage zu steuern, wie das Modell mit Tools interagiert², und das Vision-Framework liefert nun zwei fertige Tools, OCRTool und BarcodeReaderTool, die Sie an eine Sitzung anhängen, ohne den Erkennungscode selbst zu schreiben³⁴. Zusammen vervollständigen sie den agentischen Kreislauf, den das Framework begonnen hat: Das Modell entscheidet, was zu tun ist, Sie entscheiden, wie aggressiv es das tun darf, und Apple liefert die Wahrnehmungs-Tools, die die physische Welt auslesen.

Was folgt, ist die iOS-27-Schicht über der Framework-Referenz. Falls Sie LanguageModelSession, dem Tool-Protokoll oder Guided Generation noch nicht begegnet sind, beginnen Sie mit dem Foundation-Models-Framework-Erklärer und kommen Sie dann zurück.

TL;DR

• GenerationOptions.ToolCallingMode ist eine neue iOS-27-Struktur, die das Modellverhalten rund um die Tool-Nutzung beschreibt und pro Anfrage über GenerationOptions gesetzt wird². Apple dokumentiert drei Modi.
• Das Framework kann seinen Modus nach dem ersten Tool-Aufruf ändern, sodass das Modell keine Tools mehr aufruft und eine endgültige Antwort erzeugt — das begrenzt die Tool-Aktivität einer einzelnen Anfrage².
• OCRTool erkennt Text in einem Bild und gibt eine Zeichenkette mit allem zurück, was es gelesen hat. Sie aktivieren es, indem Sie Ihre LanguageModelSession mit einer OCRTool-Instanz konfigurieren³.
• BarcodeReaderTool scannt maschinenlesbare Codes und gibt ein Array von Barcode-Ergebnissen zurück, von denen jedes den decodierten Inhalt und den Symbologietyp trägt. Sie aktivieren es auf dieselbe Weise, indem Sie die Sitzung mit einer Instanz konfigurieren⁴.
• Bei beiden Vision-Tools können Sie den Standardnamen und die Standardbeschreibung überschreiben und so steuern, wie das Modell jedes Tool identifiziert und sich für seine Nutzung entscheidet³⁴.
• Alles hier ist iOS-27-Beta (und die passenden iPadOS-, macOS-, visionOS- sowie, für zwei der drei Symbole, watchOS-Betas)²³⁴.

Was sich zwischen iOS 26 und iOS 27 geändert hat

Das iOS-26-Framework behandelte das Tool-Calling an der API-Oberfläche binär. Sie übergaben einer Sitzung eine Reihe von Tools, und von da an entschied allein das Modell, ob und wie oft es sie aufrief. Für eine einzelne Abfrage funktioniert das. Heikel wird es in dem Moment, in dem Sie innerhalb einer Sitzung unterschiedliches Verhalten über mehrere Anfragen hinweg wünschen: ein Prompt, bei dem das Modell ein Tool konsultieren muss, und ein anderer, bei dem es lieber aus dem Kontext antworten und sich den Umweg sparen soll.

iOS 27 verlagert diese Entscheidung in Ihre Hände. ToolCallingMode ist ein Wert, den Sie über GenerationOptions übergeben, jenes Optionsobjekt, das bereits das Decoding steuert²⁵, und der Modus ist eine Eigenschaft der Anfrage, nicht der Sitzung. Die integrierten Vision-Tools verändern die andere Seite der Gleichung: Statt eine OCR-Pipeline oder einen Barcode-Scanner zu schreiben und in Ihre eigene Tool-Konformität zu hüllen, hängen Sie Apples Implementierung an und investieren Ihre Mühe in den Prompt.

GenerationOptions.ToolCallingMode: die Aufrufe steuern

ToolCallingMode ist eine Struktur unter GenerationOptions, verfügbar in den Betas von iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27, visionOS 27 und watchOS 27². Apples Kurzbeschreibung ist ein einziger Satz: ein Wert, mit dem Sie das Modellverhalten in Bezug auf die Tool-Nutzung beschreiben². Die Deklaration ist so schlicht wie nur möglich:

// iOS 27 beta
struct ToolCallingMode

Apples Dokumentation gibt an, dass der Tool-Calling-Modus drei Modi unterstützt². Der Diskussionstext, der jeden einzelnen benennen würde, ist in der Referenz zum Zeitpunkt des Schreibens teilweise ausgespart. Statt die Bezeichner zu erraten, beschreibe ich daher, was das Framework über das Verhalten dokumentiert — und das ist der Teil, der Ihr Design tatsächlich prägt.

Das Verhalten, das Apple ausdrücklich beschreibt: Das Framework kann den Modus nach dem ersten Tool-Aufruf ändern, was dem Modell erlaubt, eine endgültige Antwort zu erzeugen². Dieser eine Satz ist das tragende Element. Er bedeutet, dass eine Anfrage in einer Haltung starten kann, in der das Modell ein Tool aufrufen darf (oder muss), und sobald dieser erste Aufruf zurückkehrt, verschiebt das Framework den Modus, sodass das Modell nicht mehr nach Tools greift und sich auf eine Antwort festlegt. Der praktische Effekt ist eine Begrenzung der Tool-Aktivität einer einzelnen Anfrage: Sie sind nicht einem Modell ausgeliefert, das in einer Schleife immer weiter Tools aufruft, bis es das Kontextfenster erschöpft.

Sie setzen den Modus über das Optionsobjekt, das Sie ohnehin an respond(to:) übergeben:

import FoundationModels

let session = LanguageModelSession(tools: [FindContacts()])

// A request where you want to govern tool-calling behavior explicitly.
var options = GenerationOptions()
options.toolCallingMode = .someMode   // one of the three documented modes
let response = try await session.respond(
    to: "Draft a dinner invite to three of my contacts.",
    options: options
)

Die exakte Schreibweise von .someMode ergibt sich aus den drei dokumentierten Fällen; entscheidend ist der Mechanismus, und der Mechanismus besteht darin, dass das Verhalten pro Anfrage gilt und von GenerationOptions getragen wird. Dieses Objekt ist dieselbe iOS-26-Struktur, die die Decoding-Strategie regelt, die Art, wie das Modell Ausgabe-Tokens wählt, sowie die optionale Begrenzung der Antwort-Tokens, zu der Sie nur greifen, um sich gegen ausufernde Wortfülle abzusichern⁵. Der Tool-Calling-Modus ist eine neue Dimension auf einer Steuerungsfläche, die Sie bereits nutzen — kein neues Objekt, das Sie durch Ihren Code fädeln müssen.

Die Steuerung sitzt auf Anfrageebene statt auf Sitzungsebene, weil der Tool-Bedarf eine Eigenschaft der Frage ist, nicht des Gesprächs. Eine Chat-Sitzung kann eine Runde haben, die tatsächlich eine Kontaktsuche erfordert, und eine nächste Runde, die reines Umformulieren ist, das das Modell aus dem bereits Vorhandenen leisten kann. Einen Tool-Aufruf in der zweiten Runde zu erzwingen, verschwendet einen Umweg und verbrennt Tokens, die das gemeinsame Kontextfenster nicht entbehren kann⁵. Der Modus pro Anfrage lässt jede Runde ihre eigene Haltung deklarieren.

Integrierte Vision-Tools: OCRTool und BarcodeReaderTool

Die zweite Hälfte der iOS-27-Geschichte stammt aus dem Vision-Framework, das als Foundation-Models-Tools bereitgestellt wird. Apple liefert nun zwei Tools, die Sie genauso an eine LanguageModelSession anhängen wie ein eigenes — nur dass Sie keinerlei Erkennungscode schreiben.

In Session 241 präsentiert Apple BarcodeReaderTool und OCRTool als integrierte System-Tools, die die Fähigkeit eines Modells erweitern, über visuelle Informationen auf eine Weise nachzudenken, die ihm nativ nicht möglich ist.⁷

OCRTool

OCRTool erkennt Text in einem Bild. Genau das ist Apples Kurzbeschreibung, und die Diskussion ist beim Vertrag präzise: Das Tool gibt eine Zeichenkette zurück, die den gesamten aus dem Bild erkannten Text enthält³. Um es einzuschalten, konfigurieren Sie Ihre LanguageModelSession mit einer Instanz von OCRTool³. Die Deklaration:

// iOS 27 beta, Vision framework
struct OCRTool

Das Anhängen folgt derselben Form wie bei jedem Tool, denn für die Sitzung ist es nur ein weiteres Tool:

import FoundationModels
import Vision

// Configure the session with an OCRTool instance to enable it.
let session = LanguageModelSession(tools: [OCRTool()])

let response = try await session.respond(
    to: "Pull the total and the date off this receipt image and summarize them."
)

Das Modell entscheidet, wann der Prompt Text aus einem Bild benötigt, ruft OCRTool auf, erhält eine Zeichenkette mit allem, was das Tool gelesen hat, zurück und fügt diese Zeichenkette genauso in seine Antwort ein, wie es das Ergebnis eines von Ihnen geschriebenen Tools einfügen würde³. Sie schrieben weder eine Vision-Anfrage noch Verarbeitungscode. Sie hängten ein Tool an und beschrieben die Aufgabe.

Apple lässt Sie den Standardnamen und die Standardbeschreibung überschreiben, um anzupassen, wie das Modell das Tool identifiziert und nutzt³. Dieser Ansatzpunkt ist der einzige Hebel, den Sie darauf haben, wann das Modell zur OCR greift. Wenn Ihre App Belege ausliest, lenkt eine Beschreibung in Beleg-Begriffen das Modell hin zum Aufruf bei beleg-förmigen Prompts und weg von Prompts, bei denen das Bild bloß schmückend ist. Die Beschreibung ist eine Funktionsdokumentation, die das Modell liest — schreiben Sie sie also wie eine.

BarcodeReaderTool

BarcodeReaderTool scannt maschinenlesbare Codes in einem Bild⁴. Während OCRTool eine flache Zeichenkette zurückgibt, liefert das Barcode-Tool Struktur: Stößt das Modell auf ein Bild mit maschinenlesbaren Codes, kann es dieses Tool aufrufen, um sie zu decodieren, und das Tool gibt ein Array von Barcode-Ergebnissen zurück, von denen jedes den decodierten Inhalt und den Symbologietyp enthält⁴. Deklaration und Anhängen spiegeln OCRTool:

// iOS 27 beta, Vision framework
struct BarcodeReaderTool

// Configure the session with a BarcodeReaderTool instance to enable it.
let session = LanguageModelSession(tools: [BarcodeReaderTool()])

let response = try await session.respond(
    to: "Scan this label and tell me what product it is and which standard the code uses."
)

Der Symbologietyp in jedem Barcode-Ergebnis ist das Detail, das die strukturierte Rückgabe rechtfertigt⁴. Ein QR-Code, ein EAN-13-Lebensmittel-Barcode und ein PDF417 auf einem Führerschein sind allesamt maschinenlesbare Codes, und sie bedeuten für Ihre App Unterschiedliches. Weil das Tool die Symbologie neben der decodierten Nutzlast zurückgibt, können das Modell (und Ihr nachgelagerter Code) anhand der Art des Codes verzweigen, nicht nur anhand der Bytes darin. Wie bei OCRTool können Sie den Standardnamen und die Standardbeschreibung überschreiben, um zu steuern, wie das Modell das Tool identifiziert und nutzt⁴.

Beide Tools tragen dieselbe Beta-Verfügbarkeit: iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27 und visionOS 27 für beide, wobei BarcodeReaderTool zusätzlich für watchOS 27 gelistet ist³⁴.

Den Kreislauf komponieren: Wahrnehmung plus gesteuertes Aufrufen

Die beiden Funktionen sind für sich genommen interessant und gemeinsam besser, denn sie sitzen an entgegengesetzten Enden einer agentischen Anfrage. Die Vision-Tools sind Wahrnehmung, die Augen des Modells auf einem Bild. ToolCallingMode ist Steuerung, Ihre Hand darauf, wie stark sich das Modell auf diese Augen stützt.

Stellen Sie sich eine Funktion zum Wiederauffüllen der Vorratskammer vor. Der Benutzer fotografiert ein Regal. Die Sitzung hat beide Vision-Tools angehängt sowie ein eigenes Tool, ein LookUpProduct, das den Katalog der App abfragt. Eine einzige Anfrage bittet das Modell, die Artikel zu identifizieren und eine Nachbestellliste zu erstellen. Das Modell ruft BarcodeReaderTool auf, um die sichtbaren Etiketten zu decodieren, liest mit OCRTool jeden gedruckten Text für die Artikel ohne sauberen Code und ruft Ihr LookUpProduct auf, um jede decodierte Nutzlast in einen Katalogeintrag aufzulösen. Drei Tools, ein Prompt, eine stimmige Antwort.

import FoundationModels
import Vision

let session = LanguageModelSession(tools: [
    OCRTool(),
    BarcodeReaderTool(),
    LookUpProduct(),     // your own Tool conformance over the app catalog
])

var options = GenerationOptions()
options.toolCallingMode = .someMode   // govern how the model sequences the calls
let response = try await session.respond(
    to: "Identify everything on this shelf and build a reorder list.",
    options: options
)

Das ist der Kreislauf, auf den das Framework hingearbeitet hat. iOS 26 lieferte das Laufzeitmodell, Guided Generation und das Tool-Protokoll, mit dem das On-Device-Modell Ihren Code aufrufen kann, ohne dass Sie Freitext parsen¹. Der Architektur-Beitrag in diesem Cluster zog die Linie zwischen jenem Laufzeitmodell und dem Tooling-LLM, das ein Entwickler in Claude Code laufen lässt, um die App zu schreiben, und begründete eine einzige Swift-Domänenfunktion, die über drei dünne Adapter ein Foundation-Models-Tool, einen App Intent und ein MCP-Tool stützt⁶. iOS 27 fügt sich auf der Laufzeitseite dieses Bildes ein: Die integrierten Vision-Tools sind Domänenfunktionen, die Apple geschrieben hat und die Sie einhängen, LookUpProduct ist die Domänenfunktion, die Sie geschrieben haben, das Modell orchestriert sie alle, und ToolCallingMode ist die Drossel an der Orchestrierung.

Die Vertrauensgrenze verschiebt sich nicht. OCRTool und BarcodeReaderTool laufen innerhalb des App-Prozesses auf dem Gerät, gegen das Bild des Benutzers, unter derselben Sandbox- und Datenschutzhaltung wie ein selbst geschriebenes Tool. Dass Apple die Implementierung liefert, ändert, wer den Erkennungscode pflegt, nicht, wer für die Funktion verantwortlich ist. Sie besitzen weiterhin den Prompt, die Sitzung, die Verfügbarkeitsprüfung und die Entscheidung, dem Benutzer eine Kamera vorzuhalten.

Wann Sie welchen Modus und welches Tool nutzen sollten

Ein paar Regeln, die sich aus den obigen Verträgen ergeben.

Greifen Sie zu ToolCallingMode, wenn der Tool-Bedarf pro Anfrage variiert. Wenn jede Runde einer Sitzung dasselbe Tool-Verhalten braucht, ist der Standard in Ordnung und der Modus nur Rauschen. Der Modus verdient seinen Platz, wenn eine Anfrage ein Tool konsultieren muss und eine andere aus dem Kontext antworten sollte, oder wenn Sie die Modusverschiebung des Frameworks nach dem ersten Aufruf nutzen wollen, um eine Anfrage zu begrenzen, die sonst in eine Schleife geraten könnte². Setzen Sie ihn auf der Anfrage, nicht einmal für die Sitzung, denn genau dort sitzt die Steuerung².

Greifen Sie zu OCRTool, wenn die Antwort Text ist, der in einem Bild gefangen ist. Belege, Schilder, handschriftliche Notizen, Screenshots von Text. Das Tool gibt eine einzige Zeichenkette mit allem zurück, was es gelesen hat³, also passt es zu Prompts, bei denen das Modell über die Wörter nachdenken soll, nicht über das Layout. Wenn Sie Begrenzungsrahmen oder zeilenweise Konfidenzwerte brauchen, ist das eine tiefer angesetzte Vision-Anfrage, nicht dieses Tool.

Greifen Sie zu BarcodeReaderTool, wenn das Bild maschinenlesbare Codes trägt und die Art des Codes zählt. Produktetiketten, Tickets, Ausweise, Inventaretiketten. Die strukturierte Rückgabe — decodierter Inhalt plus Symbologie⁴ — ist der Grund, es einer Behandlung des Barcodes als generischen Text vorzuziehen. Verzweigen Sie anhand der Symbologie in Ihrem eigenen Tool oder Ihrer Nachverarbeitung.

Überschreiben Sie Name und Beschreibung immer dann, wenn Ihre App eine spezifische Aufgabe für ein generisches Tool hat. Beide Vision-Tools haben standardmäßig generische Identitäten, und das Modell wählt Tools teils anhand ihrer Beschreibungen³⁴. Eine App, die ausschließlich Belege ausliest, sollte das in der Beschreibung des OCR-Tools sagen, damit das Modell es nicht bei jedem Foto aufruft, das zufällig ein Wort enthält.

FAQ

Was ist GenerationOptions.ToolCallingMode in iOS 27?

Es ist eine in der iOS-27-Beta neue Struktur, die das Verhalten des Modells rund um die Tool-Nutzung für eine bestimmte Anfrage beschreibt. Sie setzen sie über die GenerationOptions, die Sie an respond(to:) übergeben, sodass das Tool-Calling-Verhalten eine Eigenschaft jeder Anfrage ist und nicht der gesamten Sitzung. Apple dokumentiert drei Modi².

Wie viele Tool-Calling-Modi dokumentiert Apple, und wie heißen sie?

Apples Dokumentation gibt an, dass der Tool-Calling-Modus drei Modi unterstützt². Der Referenztext, der jeden einzelnen Modus benennt, ist zum Zeitpunkt des Schreibens teilweise ausgespart, weshalb ich das dokumentierte Verhalten beschreibe, statt die Bezeichner zu erraten. Das Verhalten, das Apple ausdrücklich nennt: Das Framework kann den Modus nach dem ersten Tool-Aufruf ändern, sodass das Modell eine endgültige Antwort erzeugt — das begrenzt die Tool-Aktivität einer einzelnen Anfrage².

Wie aktiviere ich Apples integriertes OCR-Tool?

Konfigurieren Sie Ihre LanguageModelSession mit einer Instanz von OCRTool, genauso wie Sie jedes Tool anhängen³. Das Modell ruft es dann auf, wenn ein Prompt Text aus einem Bild benötigt, und das Tool gibt eine Zeichenkette mit dem gesamten erkannten Text zurück. OCRTool befindet sich im Vision-Framework und ist in der iOS-27-Beta verfügbar³.

Was gibt BarcodeReaderTool zurück?

Es gibt ein Array von Barcode-Ergebnissen zurück, von denen jedes den decodierten Inhalt und den Symbologietyp enthält⁴. Die Symbologie erlaubt es Ihnen, einen QR-Code von einem EAN-13 und einem PDF417 zu unterscheiden und anhand der Art des Codes zu verzweigen, nicht nur anhand seiner Nutzlast. Sie aktivieren es, indem Sie eine LanguageModelSession mit einer BarcodeReaderTool-Instanz konfigurieren⁴.

Kann ich ändern, wie das Modell entscheidet, die integrierten Vision-Tools zu nutzen?

Ja. Sowohl OCRTool als auch BarcodeReaderTool lassen Sie den Standardnamen und die Standardbeschreibung überschreiben, um anzupassen, wie das Modell das Tool identifiziert und nutzt³⁴. Die Beschreibung ist der Hebel darauf, wann das Modell zum Tool greift, also lenkt eine Formulierung in den Begriffen Ihrer App das Modell hin zu den richtigen Aufrufen.

Senden die integrierten Vision-Tools Bilder vom Gerät weg?

Nein. OCRTool und BarcodeReaderTool sind Foundation-Models-Tools, die innerhalb des App-Prozesses auf dem Gerät laufen, unter derselben Sandbox- und Datenschutzhaltung wie ein selbst geschriebenes Tool¹³⁴. Dass Apple den Erkennungscode liefert, ändert, wer ihn pflegt, nicht, wo er läuft oder wer für die Funktion verantwortlich ist.

Das vollständige Apple-Ecosystem-Cluster: der Foundation-Models-Framework-Erklärer; das On-Device-LLM; die Unterscheidung zwischen Laufzeit- und Tooling-LLM; Custom Adapters; typisierte App Intents; die neue App-Intents-Hintergrundausführung und -Synchronisierung in iOS 27; die Routing-Frage gegenüber MCP-Tools; das Vision-Framework; Core-ML-Inferenz; drei Oberflächen. Der Hub liegt bei der Apple-Ecosystem-Serie. Für breiteren Kontext zu iOS mit KI-Agenten siehe den Leitfaden zur iOS-Agent-Entwicklung.