Foundation Models Unavailable? 2026 Troubleshooting Guide

Apple's availability API names three unavailable reasons: deviceNotEligible, appleIntelligenceNotEnabled, and modelNotReady (Apple's availability definitions). This week, read SystemLanguageModel availability first, branch on the reason, then handle generation errors separately. A successful build or simulator run does not verify model operation on a supported target device.

This guide is for independent developers adding Apple Foundation Models to an iOS app and debugging unavailable-model reports.
It also helps macOS developers account for different system versions and model states.
Small teams preparing release tests can use the checklist to verify fallback behavior.

Last updated November 1, 2026. We checked the guidance against Apple's Foundation Models and availability documentation, its Apple Intelligence support information, and the API error references linked below.

Do not treat “AI failed” as one diagnosis. First determine whether the model was unavailable before a session or whether a generation call failed after the app attempted to use it. These are different checkpoints, with different evidence and recovery paths. Apple's Foundation Models usage guide describes checking model availability and preparing a fallback.

Capture the context before changing code or asking someone to retry. Record the device model, OS version, app build, relevant user setting, the full availability value, and the action that triggered the failure. If a generation request began, record its error type and whether the failure can be reproduced with the same input. Avoid collecting private user content unless it is necessary and consented to; a redacted test prompt may be enough to reproduce a code path.

That evidence matters because a device eligibility result, a disabled system feature, an unready model, and an asset error are not interchangeable. A report that only says “the model is broken” cannot tell the team whether to adjust the UI, wait, investigate a request, or verify support requirements.

These branches follow the documented availability reasons and generation-stage errors; they are not a promise that every failure will map to one particular UI message. Check Apple's availability enum and unavailable-reason definitions against the API used by your app.

When availability reports deviceNotEligible, treat it as a device eligibility problem, not an app configuration error. Apple's support information says Apple Intelligence use depends on supported devices and software requirements; consult the current Apple Intelligence device and system requirements rather than relying on an old compatibility list or assumptions based on a device name.

Keep two questions separate:

• Can the app install and run on this OS version?
• Can this device use the Foundation Models capability under its current system conditions?

The app's minimum deployment target answers the first question. It does not establish that the model is available on every device that can run the app. Likewise, raising or lowering the deployment target does not make an ineligible device eligible. Apple's unavailable-reason documentation defines deviceNotEligible as a distinct availability outcome; use it to choose the product path rather than repeatedly retrying the same request.

For an ineligible device, preserve the feature's underlying purpose where possible. If the model drafts a description, offer the user a manual editor. If it summarizes content, keep the source content accessible and explain that the summary option is unavailable. Do not present a disabled control with no explanation, and do not make a model-dependent feature the only route through an essential task unless that limitation is deliberate and clearly communicated.

Also avoid implying that the user can fix an eligibility condition by changing an app preference. The app should reflect the returned state, explain the boundary in plain language, and keep any available non-model function intact.

If availability indicates appleIntelligenceNotEnabled, do not tell the user that the device is unsupported. The returned reason points to a settings state, so the app should explain what the user can choose to do next. The user may decide to enable the system feature, defer that choice, or continue using the app without Foundation Models.

The app cannot enable Apple Intelligence on the user's behalf. It should not silently redirect the user into system settings or block unrelated app functions while waiting for a change. Provide a clear, optional instruction where appropriate, then re-check availability when the user returns or explicitly tries the model feature again.

This separation prevents a costly product mistake: treating a settings choice as a compatibility failure. It also avoids presenting model access as mandatory when the rest of the app can work without it. Apple's generative AI design guidance is useful when deciding how to communicate AI behavior, user control, and limitations without overstating what the feature can do.

Implementation note: Do not cache “available” as a permanent entitlement. Re-read availability at the point where the user is about to use the model, and still handle errors from the actual request.

modelNotReady means the model is not ready at the availability check. Apple documents it as a distinct unavailable reason. That supports a temporary-state response, but it does not justify promising that a particular wait period will resolve it.

Keep the behavior bounded:

• Tell the user that the model is not ready and leave the rest of the app usable.
• Offer a retry action or a later retry triggered by a meaningful user action.
• Re-check availability before starting another model operation.
• If the state remains unchanged, stop prompting and keep the fallback path available.

Avoid a tight loop that continuously polls or resubmits work. It can create confusing UI, waste resources, and obscure the original state without giving the user a better outcome. The retry policy should be controlled by the app and should not imply that the user needs to restart the device or reinstall the app.

There is another important distinction: modelNotReady is an availability result, while an asset error during generation happens after the app has tried to use the model. Logging and UI should preserve that distinction. Otherwise, a team may spend time changing an availability screen when the reproducible failure is actually in the session request.

An availability check is useful evidence at one point in the flow. It is not a guarantee that a later session or generation call will succeed. If availability reports that the model can be used but the app still fails, inspect the session creation and the exact generation call. Record the error case, the operation, the app build, the target OS, and a reproducible input.

For asset failures, use the error type that applies to the API and SDK combination you support. Apple's documentation describes assetsUnavailable as a Foundation Models error and also documents a generation-error form for LanguageModelSession. The generation error reference also calls out API and Xcode migration considerations. Do not assume that one spelling or handling path applies across every deployment target.

A practical investigation separates framework state from app code:

• Does the failure occur before a session is created, or during a session operation?
• Is the same error returned with a small, repeatable test input?
• Does the app handle the thrown error, or does it leave the interface waiting?
• Does the code path behave differently under the SDK and OS combinations you support?
• Does the fallback remain usable after the failure, including when the user retries?

When using Xcode 27, confirm the declarations available in the SDK and the availability annotations relevant to your deployment targets. A project compiling with a newer toolchain does not prove that every runtime path is supported on every OS you ship. Review the LanguageModelSession API reference and the generation-error documentation when adjusting session or error handling.

Release safeguard: Log enough to distinguish an availability result from a thrown generation error, but do not put private prompts or user-generated content into production logs by default.

A fallback is part of the feature, not a placeholder to add after the first failure report. Review each state in a test plan and confirm what the user can still do. The checklist below focuses on behavior and evidence, not on a particular device list; verify eligibility against Apple's current support information for the actual target device.

• [ ] Model available: Confirm the app reaches the intended session and generation path, displays the result correctly, and can recover from an unsuccessful request.
• [ ] Device ineligible: Confirm the model-dependent control explains the limitation and the relevant non-model task remains available.
• [ ] Apple Intelligence not enabled: Confirm the app presents an optional, understandable settings prompt without claiming the device is unsupported or enabling the system feature itself.
• [ ] Model not ready: Confirm the temporary state offers a reasonable next action, avoids endless retries, and does not block unrelated functionality.
• [ ] Generation error: Confirm the error is recorded in a useful, privacy-conscious way and that the user can use the fallback instead of seeing a permanent spinner.
• [ ] Target OS and SDK combinations: Review API availability and error handling for the deployment versions you support, rather than relying only on the developer machine's current environment.
• [ ] Real target-device run: Verify model behavior on a supported physical device. Keep that result separate from project compilation, code review, and simulator behavior.

A remote Mac can help inspect code, build a project, and review whether the app handles documented branches. But none of those checks, by themselves, prove that Foundation Models ran successfully on a supported iPhone or Mac. We do not report target-device model acceptance without verifiable test evidence from that device. Keep the release record explicit: what was built, what was run, where it was run, and which model state was observed.

If the issue is a build or code-path problem, a remote Mac may be useful as a macOS development environment. If your team is weighing that option, you can review JEXCLOUD's Mac access options; an external build environment can reduce dependence on a local Mac, but it does not remove the need for target-device acceptance.

What should the app do when deviceNotEligible appears?

Treat it as a device eligibility result. Keep the app's core workflow usable without the model, and verify current support requirements rather than repeatedly asking the user to restart or retry. Also keep device eligibility separate from the app's minimum deployment target: one does not establish the other.

Why can the model still be unavailable when Apple Intelligence is enabled?

An enabled setting does not guarantee that the current availability check will return available. Read the specific SystemLanguageModel result, record the device and OS context, and investigate the reason it reports. Do not infer a framework defect from the system setting alone.

Should the app retry modelNotReady?

A later retry can be appropriate, but avoid continuous polling or automatic repeated requests. Tell the user the model is not ready, preserve a useful alternative, and check availability again before trying. If it remains unavailable, stop retrying and let the user continue without the model.

What should happen after assetsUnavailable during generation?

Handle it as a generation-stage failure, not as though the earlier availability check had returned modelNotReady. Check the error API that applies to your SDK and deployment targets, record the failure safely, and give the user a retry or fallback path without repeating the same failing call in a loop.

If you already have a local Mac tied up with builds, or rely on a non-macOS environment that cannot run macOS-only Xcode tooling, a remote Mac can provide a separate place to inspect and build the project without purchasing another machine. That option still has limits: it cannot make an ineligible device eligible, change the user's Apple Intelligence setting, or replace runtime acceptance on a supported target device. For temporary build work or a separate test environment, compare those tradeoffs with JEXCLOUD's available Mac plans; for continuous heavy use or tests requiring physical device access, choose the setup that gives your team that access directly.

• Check how AI feature availability varies across supported iPhone model tiers
• Separate simulator checks from real-device validation in an iOS testing plan
• Plan CI builds alongside the device testing they cannot replace