Apple Foundation Models: Erste SwiftUI-Funktion erstellen – Einsteiger-Tutorial 2026

Beginnen Sie mit einer einzelnen Texteingabe, einer Anfrage an Apple Foundation Models und einer sichtbaren Antwort; bauen Sie für Ihre erste SwiftUI-Funktion noch keinen Agenten und keine Werkzeugaufrufe. Prüfen Sie zuerst, ob Entwicklungsumgebung und Zielgerät passen, denn ein erfolgreicher Build bestätigt nicht, dass das Modell zur Laufzeit verfügbar ist.

Dieser Ablauf passt zu Ihnen, wenn Sie gerade SwiftUI lernen und eine einfache KI-Textfunktion in ein Übungsprojekt einbauen möchten.
Er richtet sich auch an Programmieranfänger, die bereits eine kleine Seite erstellen können, aber noch keine Foundation-Models-Anfrage gestellt haben.
Wenn Sie dafür einen Remote-Mac nutzen möchten, prüfen Sie vorab die konkrete zugewiesene Umgebung.

Zuletzt geprüft am 25.09.2026; technische Angaben mit den Foundation-Models-Dokumenten von Apple und den aktuellen Xcode-Systemanforderungen abgeglichen.

Meilenstein: Oberfläche zuerst statt Modellfunktion

Legen Sie vor dem Programmieren fest, was Ihre erste Übung leisten soll: Sie tippen eine Frage ein, starten eine Anfrage und sehen entweder die Antwort oder eine verständliche Meldung. Diese Grenze hält das Projekt überschaubar. Bilder, eigene Werkzeuge und ein Agent mit mehreren Arbeitsschritten sind für diesen ersten Test nicht nötig.

Stellen Sie sich die Oberfläche wie ein Arbeitsblatt vor: Das Eingabefeld ist Ihre Frage, die Schaltfläche gibt den Arbeitsauftrag ab, und der Antwortbereich zeigt das Ergebnis. In SwiftUI verwaltet @State Werte, die sich während der Nutzung ändern. Ändert sich der Zustand, kann SwiftUI die betroffenen Teile der Oberfläche neu darstellen. Apples Erklärung zu SwiftUI-State und zustandsabhängiger Darstellung beschreibt dieses Grundprinzip.

Planen Sie diese sichtbaren Zustände ein, bevor Sie die Modellanfrage anschließen:

• Noch keine Anfrage: Das Feld ist bereit; der Antwortbereich bleibt neutral.
• Anfrage läuft: Die Schaltfläche ist vorübergehend deaktiviert oder zeigt einen Ladehinweis.
• Ergebnis oder Fehler: Die Antwort erscheint, oder Sie sehen einen konkreten Hinweis, was nicht funktioniert hat.

Für die erste Zwischenabnahme reicht ein Platzhaltertext. Tippen Sie etwas ein und prüfen Sie, ob der Text angezeigt wird. Lösen Sie anschließend beim Antippen der Schaltfläche eine sichtbare Änderung aus. Verwenden Sie die Platzhalterantwort nicht als Beleg dafür, dass das Modell bereits ausgeführt wurde.

Hinweis: Halten Sie den ersten Prompt frei von persönlichen, vertraulichen oder schulisch geschützten Daten. Bei einem Remote-Rechner wird Ihre Eingabe an den entfernten Host übertragen; beachten Sie deshalb auch die Regeln Ihrer Hochschule und die Zugriffskontrolle der Umgebung.

Meilenstein: Entwicklungswerkzeuge und Laufzeit getrennt prüfen

Xcode, das Zielbetriebssystem und die Modellverfügbarkeit sind unterschiedliche Prüfpunkte. Die Xcode-Systemanforderungen geben Auskunft über die unterstützten Entwicklerumgebungen. Sie ersetzen aber nicht die Prüfung, ob Foundation Models auf dem Gerät, auf dem Ihre App läuft, verfügbar ist. Prüfen Sie deshalb die konkrete Xcode-Version, das ausgewählte SDK und das Laufzeitziel anhand der offiziellen Xcode-Systemanforderungen.

Die Framework-Dokumentation stellt Foundation Models als Schnittstelle zum Systemmodell dar. Für die Praxis zählt jedoch nicht nur, ob Ihr Projekt die Schnittstelle kennt: SystemLanguageModel.default liefert auch einen Verfügbarkeitsstatus. Apple beschreibt diese Abfrage in der Dokumentation zu SystemLanguageModel. Prüfen Sie den Status auf dem Gerät, das Sie später für Ihre Abnahme verwenden wollen.

Die Namen Xcode 27 und ein aktuelles SDK reichen allein nicht als Kompatibilitätsnachweis. Vergleichen Sie die tatsächlich installierte Version mit Apples Anforderungen und prüfen Sie anschließend das Gerät. Wenn Ihre Schule einen Remote-Mac bereitstellt oder Sie einen mieten, klären Sie vor dem Start, welche Umgebung Ihnen zugewiesen wird und ob Sie dort die benötigten Einstellungen kontrollieren können. Eine allgemeine Aussage über alle Remote-Macs wäre keine verlässliche Abnahmegrundlage.

Meilenstein: Erste Anfrage mit einer Session senden

Sobald die Oberfläche und die grundlegenden Bedingungen geprüft sind, ergänzen Sie den Modellaufruf. Das Framework wird über FoundationModels eingebunden. Eine LanguageModelSession können Sie sich wie ein Gesprächsprotokoll für zusammengehörige Modellanfragen vorstellen; der Prompt ist die konkrete Aufgabenstellung, die Sie dem Modell geben. Die Apple-Dokumentation zu LanguageModelSession erläutert den Sitzungsansatz.

Für den ersten Versuch benötigen Sie nur die Eingabe des Nutzers und eine Textantwort. Der Ablauf sieht in vereinfachter Form so aus:

import FoundationModels

let session = LanguageModelSession()
let response = try await session.respond(to: prompt)
let answer = response.content

Die Methode respond(to:) ist asynchron: Ihre Oberfläche sollte während der Anfrage erkennbar reagieren und darf nicht so wirken, als sei die Antwort bereits fertig. Die genaue Signatur und die verfügbaren Optionen finden Sie in Apples Dokumentation zu respond(to:options:).

Setzen Sie den Ablauf in Ihrer SwiftUI-Seite in diese Reihenfolge um:

1. Eingabe speichern: Binden Sie das Textfeld an einen Zustand, etwa prompt.
2. Leere Eingaben abfangen: Starten Sie keine Anfrage, wenn das Feld keinen sinnvollen Text enthält.
3. Ladezustand setzen: Aktualisieren Sie den Status, bevor Sie den asynchronen Aufruf beginnen.
4. Session verwenden: Erzeugen Sie eine Sitzung und senden Sie den Text an respond(to:).
5. Antwort darstellen: Übernehmen Sie response.content in einen Zustand, den die Oberfläche anzeigt.
6. Fehler behandeln: Beenden Sie den Ladezustand auch dann, wenn der Aufruf scheitert, und zeigen Sie einen verständlichen Hinweis.

Für das erste Projekt sollten Sie bei dieser einfachen Textanfrage bleiben. Fügen Sie nicht gleichzeitig Bilder, dynamische Generierungseinstellungen oder Werkzeugaufrufe hinzu: Wenn die Antwort ausbleibt, wäre sonst unklar, welcher Teil den Fehler verursacht. Das Ziel dieses Meilensteins ist eine überprüfbare Verbindung zwischen Schaltfläche, Anfrage und angezeigtem Text.

Meilenstein: Verfügbarkeit statt endloser Ladeanzeige

Die Verfügbarkeit müssen Sie vor dem Aufruf behandeln und nicht erst dann, wenn keine Antwort kommt. Apple unterscheidet bei SystemLanguageModel mehrere Gründe für einen nicht verfügbaren Zustand. Dazu gehören ein nicht geeignetes Gerät, deaktiviertes Apple Intelligence und ein noch nicht bereites Modell; die genauen Bezeichnungen und Bedeutungen stehen in Apples Dokumentation zu den Gründen für einen nicht verfügbaren SystemLanguageModel-Zustand.

Der Zustand der App und der Zustand des Modells sind nicht dasselbe. Ihre Seite kann korrekt reagieren, während das Modell nicht verfügbar ist. Eine klar beschriftete Fehlermeldung ist deshalb ein brauchbares Ergebnis für den Oberflächentest, aber keine erfolgreiche Modellabnahme.

Achtung: Verwechseln Sie eine Beispielantwort, eine leere Ausgabe und eine echte Modellantwort nicht miteinander. Zeigen Sie im Zweifel einen Status an, der für Sie und Ihre Lehrkraft klar zwischen Platzhalter, Fehler und tatsächlich empfangenem Text unterscheidet.

Meilenstein: Abnahme mit einer echten Anfrage

Testen Sie die Verbindung mit einer einfachen, unkritischen Frage, etwa einer Bitte um eine kurze Erklärung eines allgemeinen Programmierbegriffs. Beurteilen Sie nicht nur, ob der Bildschirm „irgendetwas“ anzeigt. Halten Sie fest, welcher Teil der Übung tatsächlich funktioniert:

• Oberfläche: Lassen sich Text eingeben und Schaltfläche bedienen?
• Anfrage: Wird der asynchrone Aufruf gestartet und endet der Ladezustand?
• Verfügbarkeit: Meldet das Laufzeitgerät, dass das Systemmodell verwendet werden kann?
• Ergebnis: Erscheint der vom Aufruf gelieferte Text, oder wird ein Fehler nachvollziehbar angezeigt?

Diese Trennung hilft bei der Fehlersuche. Wenn die Oberfläche funktioniert, die Verfügbarkeit aber negativ ist, müssen Sie nicht sofort den SwiftUI-Code umbauen. Wenn die Verfügbarkeit positiv ist, aber kein Ergebnis erscheint, kontrollieren Sie den Fehlerpfad und die Aktualisierung des Antwortzustands. Apple dokumentiert Framework, Modellstatus und Sitzung getrennt; nutzen Sie diese Dokumente als Referenz, statt aus einem erfolgreichen Build auf eine erfolgreiche Ausführung zu schließen.

Wenn Sie Ihr Projekt nicht auf dem eigenen Rechner testen können, trennen Sie Lernziel und Abnahmeziel. Die Gestaltung des SwiftUI-Bildschirms lässt sich mit einem Platzhalter üben. Für die echte Modellabnahme benötigen Sie jedoch eine Umgebung, auf der Sie die Laufzeitbedingungen überprüfen können. Hinweise dazu, wie Sie eine Mac-Umgebung für einen Apple-Entwicklungskurs prüfen, helfen Ihnen, vorab die nötigen Fragen zu stellen. Prüfen Sie außerdem die Konditionen für eine Mac-Miete, bevor Sie eine Umgebung für Ihre Übung einplanen.

Häufige Fragen

Einbindung in SwiftUI

Fügen Sie das FoundationModels-Framework in Ihr Projekt ein, prüfen Sie SystemLanguageModel.default.availability und erzeugen Sie erst bei verfügbarer Laufzeit eine LanguageModelSession. Übergeben Sie den Eingabetext mit respond(to:) und stellen Sie response.content dar. Behandeln Sie Fehler sichtbar, statt eine leere Antwort als Erfolg auszugeben.

Prüfung vor dem ersten Modellaufruf

Kontrollieren Sie getrennt, ob Xcode und das ausgewählte SDK die APIs unterstützen, ob das Zielbetriebssystem passt und ob das konkrete Gerät das Modell bereitstellt. Prüfen Sie außerdem Apple Intelligence und den Modellstatus. Ein Build ist nur ein Nachweis für erfolgreiches Kompilieren, nicht für eine verfügbare Laufzeit.

Weiterarbeit bei fehlendem Modell

Sie können die SwiftUI-Oberfläche mit einer festen Beispielantwort oder einer Statusmeldung weiterentwickeln. Kennzeichnen Sie Platzhalter ausdrücklich und testen Sie Eingabe, Schaltfläche, Ladeanzeige und Ausgabe getrennt. Den echten Systemaufruf nehmen Sie erst ab, wenn ein geeignetes Gerät die Modellverfügbarkeit bestätigt.

Remote-Mac für das Projekt

Ein Remote-Mac kann für die Entwicklung hilfreich sein, garantiert aber nicht automatisch Zugriff auf das Systemmodell. Entscheidend sind die tatsächlich zugewiesene Umgebung und deren Laufzeitbedingungen. Fragen Sie vorab, ob Sie Betriebssystem, Modellstatus und erforderliche Einstellungen prüfen können. Andernfalls können Sie die Oberfläche üben, aber keine echte Antwort verlässlich abnehmen.

Wenn Sie heute nur einen Windows-Rechner oder eine nicht kompatible Umgebung nutzen, bleiben Ihnen für den vollständigen Test zwei Nachteile: Ein Platzhalter prüft keine echte Modellantwort, und ein zeitlich begrenzter Zugriff auf einen fremden Rechner lässt sich nicht immer passend zu Ihrem Lernrhythmus planen. Ein Remote-Mac kann diese Hürden verringern, sofern die konkret zugewiesene Umgebung die nötigen Bedingungen erfüllt; er ist keine pauschale Kompatibilitätszusage. Wenn Sie den Versuch auf einem Mac durchführen möchten, können Sie bei VMSPIN die verfügbare Mietumgebung prüfen und vorab bestätigen, dass sie zu Ihrem Kursziel passt.