Foundation Models недоступны? Руководство по диагностике 2026

В API Apple состояние модели отражается через SystemLanguageModel.availability, а причина недоступности имеет отдельное значение; сначала прочитайте это состояние, а уже затем меняйте интерфейс или повторяйте запрос (описание availability). Если модель недоступна из-за ограничений устройства, предложите функцию без генерации; если не включена Apple Intelligence — покажите добровольную подсказку; если модель ещё не готова — разрешите поздний повтор. Ошибки, возникшие уже во время генерации, диагностируйте отдельно. Прохождение сборки или запуск в симуляторе не подтверждают работу модели на целевом устройстве.

Эта инструкция предназначена разработчикам iOS-приложений, которые подключают Apple Foundation Models и получают отказ вместо результата.
Она также пригодится разработчикам macOS-приложений, которым нужно различать системные состояния и ошибки генерации.
Тестировщики и небольшие команды найдут здесь порядок проверки запасного сценария перед выпуском.

Последняя проверка: 1 ноября 2026 года; выводы сверены с руководством Apple по Foundation Models, документацией API availability и описаниями ошибок. Поведение конкретных API следует повторно сверить с документацией для целевой версии системы перед выпуском.

Слов «AI не работает» недостаточно для диагностики: они не показывают, на каком этапе возникло препятствие. В приложении важно разделить как минимум два наблюдаемых случая:

• availability уже сообщает, что модель недоступна;
• модель считается доступной, но запрос, сессия или получение результата завершаются ошибкой.

Это разные точки отказа, поэтому у них должны быть разные сообщения, журналирование и действия пользователя. Apple рекомендует проверять доступность модели до использования и готовить запасной вариант, если она недоступна.

До изменений в коде соберите минимальный набор диагностических сведений. Запишите версию системы, тип устройства, состояние системных настроек, значение availability, точное действие пользователя и этап, на котором появилась ошибка. Для генерации дополнительно сохраните тип ошибки и безопасный для журналирования пример входных данных. Не помещайте в диагностику личный текст пользователя без необходимости: для воспроизведения обычно достаточно обезличенного минимального примера.

Значение availability — это результат проверки в конкретном контексте, а не обещание, что последующий вызов непременно завершится. Между проверкой и запросом может обнаружиться отдельная ошибка в сессии или при доступе к ресурсам. Поэтому фиксируйте оба результата, а не только состояние, показанное при открытии экрана. В документации Apple отдельно описаны состояния доступности и типы ошибок сессии.

Сначала проверьте, что сама ветка кода обрабатывает полученное состояние. Если интерфейс сообщает «модель недоступна» без указания причины, разработчику и пользователю трудно отличить неподходящее устройство от выключенной системной функции или временной неготовности. А если приложение сразу повторяет запрос, оно может маскировать настоящий источник проблемы и создавать видимость зависания.

В SystemLanguageModel причины недоступности представлены отдельными состояниями. В частности, документация описывает deviceNotEligible, состояние, связанное с выключенной Apple Intelligence, и modelNotReady; трактуйте их по значению, а не объединяйте в одну общую ошибку (перечень причин недоступности).

Ниже — схема выбора поведения. Она помогает отделить действие пользователя от того, что приложение изменить не может.

Эта схема не заменяет проверку актуальных требований Apple: поддерживаемость зависит от устройства и поддержки Apple Intelligence. Сверяйте характеристики конкретного устройства с актуальной страницей требований Apple Intelligence, а не с минимальным deployment target вашего проекта. Минимальная версия системы в настройках сборки задаёт, где приложение может быть установлено; она сама по себе не доказывает, что на каждом таком устройстве доступна модель.

Если получен deviceNotEligible

Такое состояние следует трактовать как ограничение текущего устройства или среды, а не как повод бесконечно перезапускать приложение. Предложите действие, которое остаётся полезным без генерации: например, сохранить введённые данные, продолжить обычный сценарий или объяснить, что функция на этом устройстве не активна. Не обещайте, что повторная загрузка ресурсов, изменение настроек приложения или перезагрузка изменят eligibility, если для этого нет подтверждённого основания.

В пользовательском интерфейсе избегайте формулировок, которые перекладывают ответственность на пользователя. Если устройство не соответствует условиям, фраза «включите Apple Intelligence» будет неверной подсказкой. Объясните ограничение нейтрально и оставьте приложению полноценный путь без модели. Так команда не смешивает качество продукта с доступностью системной функции.

Если Apple Intelligence выключена

Этот случай отличается от неподходящего устройства: система сообщает о состоянии, которое может измениться в настройках пользователя. Приложение может объяснить, почему для конкретной функции требуется Apple Intelligence, и предложить перейти к системным настройкам самостоятельно, но не должно заявлять, что оно включит системную функцию за пользователя.

Подсказка должна быть необязательной. Основной экран и ключевые данные не должны исчезать только потому, что пользователь решил не включать функцию или отложил изменение настройки. В рекомендациях Apple по генеративным функциям акцент сделан на ясных ожиданиях и контроле пользователя (руководство по проектированию генеративного ИИ). Это особенно важно, если генерация дополняет уже существующий сценарий, а не является единственным способом выполнить задачу.

Если modelNotReady

Состояние готовности модели — не то же самое, что отказ из-за несовместимости. Apple описывает modelNotReady как отдельную причину недоступности (справка по modelNotReady). В интерфейсе представьте это как временное состояние: сообщите, что функция пока не готова, сохраните введённый материал и предложите вернуться позднее.

Повтор должен иметь понятные границы. Не запускайте непрерывный polling и не создавайте цепочку повторных запросов после каждого отказа: это не гарантирует готовность модели и затрудняет выявление систематической ошибки. Дайте пользователю возможность явно повторить действие позднее, а до этого оставьте альтернативный путь. При повторе заново проверьте состояние, вместо того чтобы считать прежний результат вечной истиной.

Важно: modelNotReady в availability и assetsUnavailable в генерации принадлежат разным этапам. Если записывать их под одним сообщением «модель загружается», журнал перестаёт показывать, где именно прервался сценарий.

Если availability указывает на доступность, но приложение не получает результат, не возвращайтесь автоматически к проверке настроек как к единственному объяснению. Проверьте создание LanguageModelSession, конфигурацию запроса, обработку завершения и точный тип ошибки. Руководство Apple описывает работу с сессиями и генерацией, а справочник API перечисляет ошибки вызова (типы ошибок LanguageModelSession).

Для каждого воспроизведения записывайте раздельно:

• состояние availability непосредственно перед запросом;
• точку вызова — создание сессии, отправку запроса или обработку результата;
• конкретный тип ошибки, а не только локализованный текст сообщения;
• безопасный пример входа и ожидаемое поведение;
• параметры целевой системы, устройства и конфигурации сборки.

Такой журнал помогает отделить ошибку интеграции от проблемы доступности. Например, если одно и то же действие стабильно доходит до генерации, а затем падает с определённым типом ошибки, простая подсказка включить Apple Intelligence не соответствует наблюдаемому факту. Если же приложение использует неподдерживаемый для целевой версии API или обрабатывает только часть вариантов ошибки, исправлять нужно совместимость и ветвление кода.

Особое внимание уделите assetsUnavailable. В документации Apple описана ошибка активов на этапе генерации (новое описание assetsUnavailable). Для более ранних вариантов API и систем может быть актуален отдельный вариант ошибки (описание ошибки в LanguageModelSession). Не выбирайте тип только по тому, что сборка прошла в вашей текущей среде: сопоставьте API с целевой версией и проверьте, что обработчик компилируется и правильно маршрутизирует ошибку для каждого поддерживаемого варианта.

Документация ошибок Foundation Models содержит пояснения по типам и миграции API для разных системных условий. Поэтому при изменении deployment target или обновлении Xcode 27 проверяйте не только успешную компиляцию, но и доступность используемых API для конфигурации проекта. Сам факт, что проект собирается, не подтверждает ни правильность обработки состояния, ни выполнение модели на пользовательском устройстве.

Резервный путь — не просто обработчик исключения, который выводит сообщение об ошибке. Он определяет, что пользователь может сделать, пока модель недоступна. До выпуска проверьте, сохраняются ли данные, можно ли завершить основной сценарий и не обещает ли интерфейс результат, который приложение не сможет получить.

Используйте проверочный список для каждого релизного сценария:

• [ ] При доступной модели пользователь может вызвать генерацию и получить ожидаемый результат.
• [ ] При deviceNotEligible приложение не предлагает бессмысленное включение системной функции или бесконечные повторы.
• [ ] При выключенной Apple Intelligence пользователь видит нейтральное объяснение и может отказаться от настройки.
• [ ] При modelNotReady состояние выглядит временным, введённые данные не теряются, а повтор не запускается бесконечно.
• [ ] При assetsUnavailable интерфейс и журналирование отражают ошибку этапа генерации, а не ошибочно сообщают о неподдерживаемом устройстве.
• [ ] При ошибке сессии пользователь получает предусмотренное продолжение, а команда может найти тип ошибки в диагностике.
• [ ] При отсутствии генерации ключевая функция приложения остаётся доступной в заявленных границах.

Для проверки используйте реальные сценарии, которые соответствуют условиям вашего приложения. Нельзя считать, что разработчик сможет принудительно получить каждое системное состояние обычным нажатием кнопки. Если нужное состояние невозможно воспроизвести в конкретной среде, проверьте обработчик на уровне кода и явно отметьте границу такого теста, вместо того чтобы выдавать его за полноценное испытание на устройстве.

Разделяйте виды проверки. Сборка подтверждает, что проект компилируется в выбранной конфигурации; тестирование интерфейса может подтвердить реакцию на подставленный результат; симулятор помогает проверить некоторые программные пути. Ни один из этих результатов сам по себе не доказывает, что Apple Foundation Models доступна и успешно выполняет запрос на поддерживаемом реальном iPhone. Для этого нужна проверка на устройстве, которое соответствует действующим условиям Apple, с фиксацией фактического состояния и результата.

Если для проверки кода нужен macOS/Xcode, удалённый Mac может помочь собрать проект и просмотреть ветки обработки, когда собственного Mac нет под рукой. При выборе временной среды можно посмотреть обзор вариантов удалённого Mac и отдельно оценить условия заказа Mac. Но такая сборка остаётся проверкой проекта и окружения разработки: она не заменяет запуск Foundation Models на целевом поддерживаемом устройстве. Мы не считаем удалённую сборку доказательством устройства, на котором модель реально работала.

Что означает deviceNotEligible?

Это состояние сообщает, что текущая среда не подходит для использования модели. Не требуйте от пользователя многократно перезапускать приложение или повторно загружать модель: сначала оставьте ему работающий сценарий без генерации. Проверяйте требования к устройству по актуальной информации Apple отдельно от минимальной версии системы, которую задаёт конфигурация приложения.

Почему модель недоступна, хотя Apple Intelligence включена?

Включённая настройка не гарантирует успех последующей генерации. Перечитайте availability и сохраните состояние вместе с данными о системе, устройстве и действии пользователя. Если модель доступна, а запрос завершается ошибкой, проверяйте сессию и тип ошибки отдельно; не предлагайте снова включить функцию без подтверждения, что причина именно в настройках.

Можно ли повторить запрос при modelNotReady?

Поздний повтор допустим, но не должен превращаться в бесконечный автоматический цикл. Покажите временное состояние, сохраните введённые данные и дайте пользователю возможность повторить действие позже. Перед новым запросом снова прочитайте availability; прежнее состояние не следует считать гарантией готовности модели к следующей попытке.

Как обработать assetsUnavailable во время генерации?

Сначала зафиксируйте тип ошибки и этап вызова: assetsUnavailable при генерации не тождественен modelNotReady в availability. Предусмотрите ограниченный повтор или путь без генерации и сверьте применяемый API с целевой системой. Для разных вариантов API документация Apple описывает отдельные типы и переходы, поэтому обработчик нужно проверять в контексте конфигурации проекта.

Если сейчас команда полагается только на локальную среду без подходящего Mac, возможны ограничения доступа к Xcode; если проверка заканчивается успешной сборкой или симулятором, остаётся непроверенным запуск модели на целевом устройстве; если покупать Mac исключительно для разовой сборки, появляется постоянная стоимость оборудования ради задачи, которая может быть временной. Удалённый Mac от JEXCLOUD может быть удобен для работы с проектом, сборки и повторной проверки кода без покупки отдельного компьютера. Но если приложению необходима непрерывная нагрузка или физические интерфейсы, собственный Mac может лучше соответствовать рабочему режиму; а модель всё равно следует отдельно проверять на реальном поддерживаемом устройстве. Для временной потребности можно оценить варианты аренды Mac у JEXCLOUD, не подменяя этой проверкой устройство пользователя.

• Foundation Models Framework на WWDC 2026: новые возможности и агентные примитивы
• Доступность Apple Intelligence и ограничения по моделям iPhone в iOS 27