Direct answer
Apple Foundation Models on macOS should be evaluated at runtime, not assumed from the framework name or a successful build. Apple documents SystemLanguageModel as the on-device text model used by Apple Intelligence, while availability can depend on device eligibility, region, system settings, model readiness, and the requested locale. The framework exposes availability and locale-support checks; apps should use them to choose a clear ready, unavailable, or retry state. A feature can also have a server route through Private Cloud Compute or another provider, so “uses Foundation Models” alone is not proof that a particular request stayed on the Mac. Start by recording the precise Mac and OS build, app configuration, region, selected model path, and requested language. Then run a fixed task with network disabled where that is an intended product promise, and preserve errors and fallback. This page publishes no Mac compatibility matrix or speed result; it provides a checklist for measuring an exact configuration.
Scenario: shipping a local summarizer for Mac notes
A developer adds a short note-summary action to a Mac app and wants it to work without sending note text to a server. The framework compiles on the development Mac, but a user may have a different device eligibility state, region, language setting, or model readiness state.
Decision
Check model availability and locale support at runtime, explicitly choose the local system model route, and define a useful state if the system is unavailable. Test the task with private synthetic fixtures and network disabled; treat any cloud fallback as a separate route that needs its own disclosure and consent.
Expected outcome
The app can tell the user whether the local task is ready, unavailable, or retryable. The published support statement is tied to tested OS, device state, region, locale, and task—not to API compilation alone.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Mac, macOS, and region configuration
- SystemLanguageModel availability and locale result
- Offline task, fallback, and failure evidence
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Pin the operating-system and device context. Record the exact macOS build, Mac model family, region and language settings, app version, and Xcode/SDK used to build. Do not copy a successful result from one Mac to every Mac or imply that an API introduction date defines the complete supported-device set. Use Apple’s current availability documentation as the source for runtime checks.
- Check SystemLanguageModel availability at runtime. Before presenting a local action as ready, read the SystemLanguageModel availability state and handle each documented unavailable reason. Distinguish a device that is not eligible, a feature that is not enabled, and a model that is not ready. A type compiling into the app proves only that the app was built against an SDK; it does not prove inference can start on the user’s current system.
- Verify the requested locale, not only the system locale. Use the framework’s locale-support APIs or supported-language list for the exact language the task requests. App-specific language settings can differ from the Mac’s primary language. Treat fallback between similar locales as documented behavior to test, not as proof that every dialect or translation direction produces acceptable results.
- Make local and remote routing explicit. Trace whether the task uses SystemLanguageModel, Private Cloud Compute, or a third-party provider. If privacy or offline operation is a requirement, do not silently change routes when the local model is unavailable. Present the local unavailable state or request consent before any separately disclosed remote path.
- Evaluate task quality with a fixed acceptance set. Use private synthetic notes and a versioned expected-property set. Check omissions, invented details, formatting, unsupported-language errors, cancellations, and recovery. A model availability check only proves the framework says it can accept requests; it does not establish that the chosen task meets the application’s quality or safety needs.
- Repeat offline and publish a bounded support statement. On the exact target configuration, disable network access and execute the full user task from input through visible output. Record setup dependencies, all failures, and whether an alternate route was attempted. State which Mac/OS/region/locale/task combination was tested and what remains unknown; avoid a universal “works on Mac” or speed claim without evidence.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Device, macOS build, region, language settings, SDK, and app version are recorded.
- Runtime model availability and requested-locale support are checked and handled separately.
- Local SystemLanguageModel routing is distinguishable from Private Cloud Compute or other providers.
- Task quality and offline completion are tested on the exact configuration, including unavailable and failure states.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Framework API compiles | Build-time availability in the chosen SDK | Confirms API access at build time, not runtime model readiness. |
| System model available | Runtime availability state for this device and region | Shows whether the system is ready for a request; still does not prove task quality. |
| Locale supported | supportsLocale or supportedLanguages result for the requested locale | Applies to the language check; output quality still needs evaluation. |
| Task verified offline | Fixed acceptance set completed with network disabled and route recorded | Supports a bounded local-task statement for this configuration only. |
Failure patterns to prevent
- Treating API presence as model readiness
- Assuming one supported locale or Mac generalizes
- Hiding Private Cloud Compute or provider routing
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- Apple SystemLanguageModel availability and locale support
- Cove benchmark method
- Apple SystemLanguageModel availability and on-device model overview
- Apple Foundation Models language and locale support
- Apple Foundation Models availability property
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Does Apple Foundation Models automatically mean my Mac request stays on-device?
Not solely from the framework name. Apple documents SystemLanguageModel as the on-device model, and separately documents Private Cloud Compute and other provider paths. Trace the route for the exact request and make any remote fallback explicit; test offline if local execution is a requirement.
Why can a Foundation Models app build but show the model as unavailable?
Build-time API availability and runtime model readiness are different. Apple’s runtime availability state can reflect device eligibility, Apple Intelligence settings, region, or a model that is not ready. Handle those states in the app rather than treating compilation as proof of runtime access.
How do I check whether a language is supported?
Use Apple’s documented locale-support checks or supported-language list for the exact locale requested by the user. Also test the actual task and output. A locale check is evidence about framework language support, not a measured quality result for every prompt or translation direction.
Can a test on one Mac prove support for all Macs?
No. The result is scoped to the recorded device state, macOS version, region, locale, app configuration, and task. Availability may change with operating-system releases and settings, so test representative target configurations and report the supported boundary precisely.