Model-backed features need both an API availability check and a runtime readiness decision. A deployment guard alone does not establish that a model is usable on the current device.

SDK guard → Runtime readiness → Model session → Useful fallback
  1. 1SDK guard
  2. 2Runtime readiness
  3. 3Model session
  4. 4Useful fallback

Work through the example

Define the non-AI path first. Keep tool arguments validated and distinguish generated output from app-owned facts.

Start with a disposable branch and synthetic data. Write the expected outcome before changing the implementation, then keep the first failing result. This prevents a later repair from quietly redefining the task. The procedure below is grounded in the repository reference; its examples must still be checked against your project and installed toolchain.

Implementation reference

The following focused section is adapted from the maintained project guide. It preserves the source’s examples and limitations.

10. Availability

Two versions are in play. Do not collapse them.

// Baseline framework + on-device model.
@available(iOS 26.0, macOS 26.0, *)

// PCC model, Dynamic Profiles, image attachments, custom LanguageModel providers.
@available(iOS 27.0, *)

func makeSession() -> LanguageModelSession? {
    if #available(iOS 27.0, *) {
        return LanguageModelSession(profile: CookingProfile(state: state))
    } else if #available(iOS 26.0, *) {
        return LanguageModelSession(instructions: fallbackInstructions)
    } else {
        return nil          // feature hidden entirely below iOS 26
    }
}

An app supporting iOS 17+ (this skill's baseline) must treat every Foundation Models feature as additive. The non-AI path is the product; the AI path is an enhancement.

Acceptance and failure review

Checkpoint What to inspect If it does not match
SDK guard Confirm the input and environment Preserve the failure and return to this step
Runtime readiness Inspect the intermediate artifact Preserve the failure and return to this step
Model session Run the focused check Preserve the failure and return to this step
Useful fallback Record the observed result Preserve the failure and return to this step

Ask the agent to explain the smallest change that resolves the observed mismatch. Keep unrelated refactors out of the repair. A change that makes a warning disappear is not enough if the behavior or ownership contract has changed. Re-run the same acceptance check so the before and after results are comparable.

Evidence and limits

A simulator or static sample cannot establish every supported physical-device model configuration.

This is an educational guide. Its presence in the series does not certify a completed client-specific lab. The series evidence record separates executed checks from exercises and blocked environments.

Inspect the source used in this lesson.

What to do next

Next: Notifications, background tasks and the permissions agents forget