Was tun, wenn Foundation Models nicht verfügbar sind? Leitfaden zur Fehlerbehebung 2026

Apple bildet die Modellverfügbarkeit in SystemLanguageModel als verfügbaren oder nicht verfügbaren Zustand mit einem möglichen Grund ab (Apple-Referenz zu Availability). Wenn Foundation Models nicht verfügbar sind, prüfen Sie daher zuerst genau diesen Status und behandeln Sie anschließend Geräteberechtigung, Apple-Intelligence-Einstellungen, Modellbereitschaft und Fehler beim Generieren getrennt. Ein erfolgreicher Build oder ein Lauf im Simulator ersetzt keine Abnahme auf dem tatsächlichen Zielgerät.

Zuletzt geprüft am 01.11.2026 anhand der Apple-Dokumentation zu Foundation Models, Availability und Generierungsfehlern.

Dieser Leitfaden richtet sich an unabhängige Entwicklerinnen und Entwickler, die Apple Foundation Models in eine iOS-App integrieren und eine Nichtverfügbarkeit untersuchen.
Er hilft auch Teams, die eine macOS-App für unterschiedliche Systemversionen und Modellzustände warten.
Für kleine Test- und Veröffentlichungsteams zeigt er, wie sich Fallbacks und die Grenze zwischen Build-Prüfung und Geräteabnahme nachvollziehbar festhalten lassen.

Bevor Sie Einstellungen ändern oder Code umbauen, klären Sie, in welcher Phase der Fehler auftritt. „Die KI funktioniert nicht“ reicht als Diagnose nicht: Ein Modell kann schon vor dem Erstellen einer Sitzung als nicht verfügbar gemeldet werden, oder erst eine konkrete Generierungsanfrage kann fehlschlagen. Diese Fälle haben unterschiedliche Ursachen und verlangen unterschiedliche Reaktionen.

Apple empfiehlt, die Verfügbarkeit über SystemLanguageModel zu prüfen und bei Nichtverfügbarkeit einen Fallback vorzusehen. Die Anleitung zum Generieren von Inhalten mit Foundation Models beschreibt die Nutzung des Frameworks; die Definition der Availability-Zustände erläutert, wie eine App den Status einordnen kann.

Halten Sie für jeden Fehlerfall fest:

• Systemversion und Gerätetyp, auf dem der Fehler auftritt.
• Den von SystemLanguageModel gelieferten Availability-Zustand samt Grund.
• Ob Apple Intelligence in den Systemeinstellungen aktiviert ist, soweit dies für die Diagnose relevant und vom Nutzer mitgeteilt wurde.
• Die auslösende Aktion, den Anfrageablauf und den Zeitpunkt relativ zur Sitzungserstellung.
• Den vollständigen Fehler aus dem Generierungsaufruf sowie den sichtbaren Zustand der App.

Vermeiden Sie es, aus einem einzelnen Fehlschlag sofort einen Defekt des Frameworks abzuleiten. Ebenso wenig beweist eine frühere Availability-Prüfung, dass ein späterer Generierungsaufruf unter allen Umständen erfolgreich sein wird. Die Zustandsabfrage ist eine Entscheidungshilfe für den aktuellen Ablauf, keine Erfolgsgarantie für jede folgende Operation.

Die folgenden Fälle sollten in Code, Protokollierung und Nutzerführung getrennt bleiben. Die Statusnamen und Fehlerformen sind technische Kennungen aus den Apple-APIs; ihre konkrete Verfügbarkeit und Behandlung müssen Sie gegen die Dokumentation für die jeweilige Zielsystemversion prüfen.

Die Tabelle ist eine Diagnosehilfe, kein Ersatz für die API-Referenz. Insbesondere dürfen Sie aus einem Status keine pauschale Aussage über alle Geräte oder Systemversionen ableiten. Apples Support-Seite kann sich ändern; veröffentlichen Sie deshalb keine konkrete Kompatibilitätsliste, ohne sie vor der Veröffentlichung gegen die aktuelle offizielle Information zu prüfen.

deviceNotEligible ist keine Aufforderung, den Nutzer zu wiederholten Neustarts oder zum erneuten Anfordern des Modells zu bewegen. Der Status betrifft die Voraussetzungen des aktuellen Geräts. Apple weist in seinen Informationen zu Apple Intelligence auf Geräte- und Systemanforderungen hin; verwenden Sie diese Quelle, wenn Sie in der App oder Dokumentation erklären, welche Umgebungen unterstützt werden.

Prüfen Sie die Geräteberechtigung getrennt von der Mindestversion, die Ihre App im Store oder in der Projektkonfiguration voraussetzt. Eine App kann eine bestimmte Betriebssystemversion verlangen und trotzdem auf einem Gerät laufen, auf dem die Modellfunktion nicht verfügbar ist. Umgekehrt belegt ein erfolgreiches Kompilieren mit einem aktuellen SDK nicht, dass jedes Gerät, auf dem die App installiert werden kann, das Modell ausführen kann.

Für die Produktentscheidung empfiehlt sich eine Abgrenzung nach Funktion:

• Ist die generative Ausgabe ein Zusatz, lassen Sie den übrigen App-Ablauf ohne sie fortsetzen.
• Ist sie für eine Teilaufgabe nötig, erklären Sie, welche Eingabe oder welcher Schritt eingeschränkt ist, und ermöglichen Sie einen alternativen Arbeitsweg.
• Ist die Modellfunktion tatsächlich zwingend, kommunizieren Sie die Einschränkung vor dem Start der betreffenden Aufgabe, nicht erst nach einer leeren oder fehlgeschlagenen Ausgabe.

Apple beschreibt in den Designhinweisen für generative KI die Bedeutung einer nachvollziehbaren Nutzererfahrung. Für Ihre Implementierung heißt das: Versprechen Sie keine generierte Antwort, bevor der Status geprüft ist, und lassen Sie eine Nichtverfügbarkeit nicht wie einen erfolgreichen, aber inhaltsleeren Abschluss aussehen.

Ein Hinweis, dass Apple Intelligence nicht aktiviert ist, muss von einer Gerätebeschränkung unterscheidbar sein. Die App darf erklären, dass eine optionale Funktion dadurch nicht bereitsteht; sie sollte daraus aber nicht ableiten, dass das Gerät generell inkompatibel ist. Ebenso kann die App die Systemeinstellung nicht stellvertretend für den Nutzer aktivieren.

Gestalten Sie den Hinweis so, dass er drei Fragen beantwortet: Welche konkrete Funktion fehlt? Welche Aktion kann der Nutzer selbst in den Systemeinstellungen prüfen? Was lässt sich in der App ohne Aktivierung weiterhin erledigen? Diese Angaben sollten den tatsächlichen Funktionsumfang widerspiegeln und nicht suggerieren, dass die Aktivierung allein jeden späteren Fehler ausschließt.

Wenn Ihre App eine Einstellungsanleitung einblendet, formulieren Sie diese als optionalen Weg und führen Sie den Hauptablauf nicht in eine Sackgasse. Vermeiden Sie außerdem, sensible Nutzereingaben zu protokollieren, wenn zur Fehlerdiagnose Availability-Grund und Fehlerklasse ausreichen. Bei Diagnoseprotokollen für Nutzerberichte sollten Zweck, Umfang, Speicherdauer und Weitergabe nachvollziehbar sein; prüfen Sie die Verarbeitung zudem anhand Ihrer Datenschutzpflichten und der DSGVO.

modelNotReady ist als Availability-Grund von Fehlern zu unterscheiden, die erst beim Generieren auftreten. Die Apple-Dokumentation ordnet diesen Zustand der Verfügbarkeit des Modells zu. Ihre App sollte deshalb keine Endlosschleife starten, die ohne Nutzerwissen immer wieder dieselbe Anfrage stellt.

Ein robuster Ablauf kann so aussehen:

1. Availability unmittelbar vor dem Funktionsaufruf erfassen und den Status im Ablaufprotokoll notieren.
2. Bei modelNotReady eine verständliche, vorübergehende Einschränkung anzeigen, statt die Anfrage als erfolgreich oder endgültig fehlgeschlagen auszugeben.
3. Den Nutzer entscheiden lassen, ob er später erneut versucht, und dabei ungespeicherte Eingaben möglichst erhalten.
4. Vor einem späteren Versuch den Availability-Status erneut prüfen, anstatt blind denselben Aufruf zu wiederholen.
5. Wenn die Funktion nicht warten kann, den alternativen App-Ablauf anbieten und klarstellen, welche Leistung ohne Modell verfügbar bleibt.

Das Wiederholen ist also eine mögliche Produktentscheidung, aber kein Beweis dafür, dass das Modell nach einer bestimmten Wartezeit bereit sein wird. Vermeiden Sie feste Versprechen, die Apple für Ihren konkreten Fall nicht dokumentiert. Bei einer fortlaufenden Störung sollte der Nutzer die Kernfunktion weiterhin erreichen können, ohne fortwährend auf eine generative Antwort zu warten.

Ein verfügbar gemeldetes Modell und ein erfolgreicher Generierungsaufruf sind zwei verschiedene Prüfpunkte. Wenn Availability zunächst positiv ist, aber eine Sitzung oder ein Generierungsaufruf fehlschlägt, untersuchen Sie den späteren Fehler und nicht nur den vorherigen Status. Apple dokumentiert assetsUnavailable als Fehler während der Generierung; die Referenz zum neuen Fehler und die Dokumentation zur älteren Fehlerform in LanguageModelSession sollten Sie passend zu Ihrer Zielsystemversion heranziehen.

Erfassen Sie für einen reproduzierbaren Bericht die Eingabe in datenschutzgerechter Form, den Sitzungsschritt, den Fehlernamen und die Systemversion. Nutzen Sie Testeingaben, die keine persönlichen oder vertraulichen Nutzerdaten enthalten. Prüfen Sie außerdem, ob die App den Fehler selbst erzeugt: etwa durch eine falsche Zustandsannahme, eine nicht erwartete Abbruchbedingung oder eine UI, die ein Ergebnis anzeigt, obwohl der Generierungsaufruf nicht erfolgreich war.

Die Fehlerdokumentation kann je nach API- und Systemversion unterschiedliche Formen betreffen. Apples Übersicht zu Generierungsfehlern und der Xcode-Migration ist deshalb neben der Dokumentation zu LanguageModelSession zu prüfen. Übernehmen Sie keine Fehlerbehandlung aus einem Beispiel, ohne deren Verfügbarkeit für Ihre Zielsysteme zu kontrollieren. Ein gemeinsamer Fehlerpfad darf nach außen eine einheitliche Meldung zeigen, sollte intern aber Availability-Fehler und Fehler beim Generieren auseinanderhalten.

Die Prüfung ist erst abgeschlossen, wenn die App nicht nur bei verfügbarer Modellfunktion, sondern auch in den Fehlerfällen verständlich bleibt. Legen Sie dafür Testfälle für Availability und Generierung getrennt an. Wenn Sie mit Xcode 27 arbeiten, dokumentieren Sie die Werkzeugversion für die Reproduzierbarkeit; leiten Sie aus dieser Versionsangabe jedoch keine Aussage über die Geräteberechtigung oder Modellverfügbarkeit ab.

Arbeiten Sie die folgende Liste pro unterstütztem Zielsystem und den tatsächlich verfügbaren Testgeräten ab:

• [ ] Der verfügbare Zustand führt in den erwarteten Funktionsablauf; die Oberfläche wartet nicht fälschlich auf eine weitere Verfügbarkeitsprüfung.
• [ ] deviceNotEligible zeigt eine passende Erklärung und lässt die Kernfunktion ohne Modell weiterlaufen.
• [ ] Ein ausgeschaltetes Apple Intelligence wird nicht als allgemeine Geräteinkompatibilität beschriftet.
• [ ] modelNotReady führt nicht zu wiederholten, unkontrollierten Anfragen; Eingaben und ein späterer Versuch bleiben nachvollziehbar.
• [ ] Ein Fehler beim Generieren, darunter assetsUnavailable, wird unabhängig von der vorangegangenen Availability behandelt.
• [ ] Für jeden Fehlerfall ist festgehalten, welche Funktion eingeschränkt ist und welcher alternative Ablauf angeboten wird.
• [ ] Protokolle enthalten die zur Diagnose nötigen Status- und Fehlerinformationen, aber nicht mehr Nutzereingaben als erforderlich.
• [ ] Der Test wurde auf einem geeigneten tatsächlichen Zielgerät ausgeführt; Build-Erfolg, Simulatorlauf und Geräteabnahme sind getrennt dokumentiert.

Diese Abnahme verhindert eine häufige Fehlinterpretation: Ein sauberer Build beweist, dass Quellcode und Werkzeugkette den jeweiligen Build-Schritt durchlaufen haben; ein Simulator kann bestimmte App-Abläufe prüfen. Keines von beidem beweist für sich, dass Foundation Models auf einem unterstützten iPhone oder Mac unter den konkreten Systemeinstellungen des späteren Nutzers verfügbar ist. Berichten Sie ein Geräteergebnis nur, wenn ein entsprechender Test auf dem Zielgerät tatsächlich durchgeführt und nachvollziehbar protokolliert wurde.

Wenn ein Fehler auf den Projektaufbau, eine API-Verwendung oder den Build-Pfad zurückgeht, kann eine separate Mac-Umgebung bei der Codeprüfung und beim Erstellen des Projekts helfen. Das ist jedoch keine Geräteprüfung und ersetzt nicht die Ausführung auf unterstützter Hardware. Falls Sie dafür eine zusätzliche macOS-Umgebung benötigen, können Sie zunächst die Informationen zu JEXCLOUD prüfen. Ob eine solche Umgebung für Ihren Ablauf passt, hängt davon ab, ob Sie einen reproduzierbaren Build oder tatsächliche Modelltests auf Zielgeräten benötigen.

Die folgenden Antworten fassen die wichtigsten Entscheidungen zusammen; für konkrete Zustandsnamen und Fehlerbehandlung gilt weiterhin die Dokumentation der verwendeten API und Zielsystemversion.

Wie sollte eine App auf deviceNotEligible reagieren?

Behandeln Sie deviceNotEligible als Hinweis darauf, dass das aktuelle Gerät die Voraussetzungen für die Modellnutzung nicht erfüllt. Wiederholte Neustarts oder erneute Modellanforderungen beheben diese Gerätebedingung nicht. Zeigen Sie stattdessen eine verständliche Erklärung und lassen Sie die Kernfunktion der App ohne generative Ausgabe weiter nutzbar. Prüfen Sie die aktuelle Geräte- und Systemunterstützung in Apples Informationen, bevor Sie konkrete Kompatibilitätsangaben veröffentlichen.

Was lässt sich prüfen, wenn Apple Intelligence eingeschaltet ist, das Modell aber fehlt?

Erfassen Sie zunächst den konkreten Availability-Grund und prüfen Sie, ob die App tatsächlich auf dem Gerät und der Systemversion ausgeführt wird, die Sie untersuchen möchten. Eine aktivierte Systemeinstellung beweist nicht, dass das Modell in jedem Moment bereitsteht. Unterscheiden Sie eine noch nicht abgeschlossene Bereitschaft von einem Fehler beim Generieren und protokollieren Sie den Fehler, statt die Systemeinstellung innerhalb der App automatisch ändern zu wollen.

Kann die App bei modelNotReady automatisch erneut anfragen?

Ein erneuter Versuch kann sinnvoll sein, wenn die App den vorübergehenden Zustand begrenzt behandelt und eine alternative Aktion anbietet. Vermeiden Sie eine automatische Dauerschleife: Sie kann wiederholt fehlschlagen und den eigentlichen Zustand für Nutzende verschleiern. Geben Sie eine bewusste Möglichkeit zum späteren Wiederholen, bewahren Sie nach Möglichkeit den bisherigen Arbeitsstand und prüfen Sie den Availability-Status vor einem neuen Generierungsversuch erneut.

Was ist bei assetsUnavailable während der Generierung zu tun?

Ordnen Sie assetsUnavailable der Generierungsphase zu, wenn die Sitzung bereits erstellt wurde und die Anfrage erst beim Ausführen fehlschlägt. Behandeln Sie diesen Fehler getrennt von modelNotReady, das als Grund für eine nicht verfügbare Modellbereitschaft auftreten kann. Prüfen Sie die für die Zielsystemversion dokumentierte Fehlerform, protokollieren Sie den reproduzierbaren Ablauf und bieten Sie einen kontrollierten Wiederholungsversuch oder einen Fallback an.

Wenn Ihr aktueller Entwicklungsrechner keinen verlässlichen macOS-Build ermöglicht, bleiben lokale Vorbereitung, eine zusätzliche Mac-Build-Umgebung und ein späterer Test auf dem realen Zielgerät unterschiedliche Optionen. Ein eigener Mac ist bei dauerhaftem, regelmäßigem Einsatz möglicherweise die passendere Wahl; eine zusätzliche Umgebung lohnt sich eher, wenn Sie vorübergehend an Build- und Codepfaden arbeiten. Sie beseitigt weder die Kosten für Geräteabnahme noch die Abhängigkeit von den tatsächlichen Einstellungen und Voraussetzungen des Zielgeräts.

Eine Remote-Mac-Umgebung kann Ihnen helfen, einen macOS-abhängigen Projektpfad zu prüfen, während Ihr Team den separaten Gerätetest organisiert. Sie sollten sie nicht als Nachweis dafür behandeln, dass Foundation Models auf einem bestimmten iPhone verfügbar ist. Wenn Sie für Build-Prüfung oder Codepfad-Reproduktion eine solche Umgebung benötigen, können Sie die passende Möglichkeit über JEXCLOUD zur Mac-Miete ansehen; die Freigabe Ihrer App sollte dennoch erst nach dokumentierter Abnahme auf den tatsächlichen Zielgeräten erfolgen.

• Die WWDC-Zusammenfassung ordnet das Foundation Models Framework und die Geräte- und Regionsgrenzen der Apple-KI ein.
• Welche iPhone-Modelle KI-Funktionen unterstützen und worauf Entwickler beim Testen achten sollten, zeigt der iOS-27-Upgrade-Leitfaden.
• Als Ausweichlösung für lokale Inferenz: So lassen sich Sprachmodelle auf Apple-Silicon-Hardware betreiben.