Use Apple Intelligence On-Device Models in SwiftUI

What Apple Intelligence actually gives an app

Apple Intelligence is not one API but several, and knowing which you need saves a lot of confusion. The headline one for developers is the Foundation Models framework, which lets your app call an on-device language model directly for text generation and structured output. Alongside it, Writing Tools appear automatically in standard text views, Image Playground and Genmoji expose image generation (Image Playground returns square images around 1,024 by 1,024 pixels), and App Intents let Siri and the system invoke your app’s actions. So “using the Apple Intelligence API” usually means one specific thing: calling the on-device model from your own UI.

The appeal of that model is what it does not need: no API key, no network, no per-token bill, and no data leaving the device. The constraint is its size, which shapes everything you build with it.

Calling the on-device model with Foundation Models

In practice you check availability, open a session, and ask. SystemLanguageModel tells you whether the model is available on this device, in this region, with Apple Intelligence enabled, and your UI must handle the case where it is not rather than assuming it is there. When it is, you create a session, send a prompt, and receive a response you can stream into the view as it generates, which keeps a SwiftUI screen responsive instead of frozen while the model thinks.

The availability check is the part people skip and should not. The model is gated by device, by region, and by a user setting, so a real app treats “model unavailable” as a normal state with a graceful fallback, not an error.

Structured output is the useful part

A raw text blob is hard to build on, so the framework’s best feature is guided generation: you describe a Swift type you want back, and the model fills it in. Instead of parsing prose for a title, a summary, and three tags, you ask for a struct with those fields and get them typed. This is what makes the on-device model genuinely useful in an app, summarizing a note into structured fields, extracting entities, categorizing input, because you can wire the result straight into your UI with no fragile string parsing.

Lean on this. The difference between a demo and a feature is usually whether the output is structured enough to trust in code.

The honest limits of an on-device model

The on-device model is small by design, and pretending otherwise is the fastest way to ship a bad feature. It is excellent at focused language tasks on text you give it, summarizing, rewriting, tagging, extracting, and weak at broad world knowledge, long documents, and anything needing current facts, where a large cloud model is a different tool. It can also be unavailable, on older hardware or with Apple Intelligence off, so design for absence. Used for what it is good at, on-device and private, it is a strong addition; stretched to imitate a frontier model, it disappoints. The companion AI surfaces are worth seeing too, like an Apple Intelligence Siri overlay, and the cross-framework angle in Siri Shortcuts and App Intents from React Native.

Building the UI from a template

The screen around the model, an input, a generate action, a streaming result, and the loading, empty, unavailable, and error states, is the same in every Apple Intelligence feature, so it is worth starting from. A free VP0 design ships that generation UI with its states as a SwiftUI file with a machine-readable source page, so pasting the link into Claude Code or Cursor gives the agent the screen to wire the Foundation Models session behind. For comparison shopping on models, the best LLM for vibe coding covers the cloud side.

Common mistakes using the Apple Intelligence API

The frequent ones come from ignoring availability and size. Assuming the model is always present crashes or dead-ends on unsupported devices, so check availability and provide a fallback. Asking the on-device model for broad world knowledge or current facts produces confident, wrong answers. Parsing prose instead of using guided generation makes the feature fragile. Blocking the UI while the model generates, rather than streaming, feels frozen. And shipping a generated result without a user review step, for anything that matters, trusts a small model too far.

Key takeaways: Apple Intelligence in SwiftUI

• It is several APIs. Foundation Models for the on-device LLM, plus Writing Tools, Image Playground, and App Intents.
• Check availability first. The model is gated by device, region, and a user setting; absence is a normal state.
• Use guided generation. Ask for a typed Swift struct, not prose, so the output is safe to use in code.
• Respect the model’s size. Great for focused text tasks on device, wrong for broad knowledge or current facts.
• Start from a generation template. A free VP0 SwiftUI design gives an agent the screen and states to wire the session behind.

Frequently asked questions

How do I use Apple Intelligence in a SwiftUI app? Use the Foundation Models framework to call the on-device language model: check SystemLanguageModel availability, open a session, send a prompt, and stream the response into your view. Prefer guided generation, describing a Swift type you want back so the model fills typed fields instead of prose, which is far easier to build on. Handle the case where the model is unavailable as a normal state, and reach for App Intents, Writing Tools, or Image Playground when those fit better. A free generation template gives you the screen and states to start from.

What is the safest way to build this with Claude Code or Cursor? Give the agent a generation-screen template and let it wire the Foundation Models session, while you keep the availability check and the fallback explicit. A free VP0 SwiftUI design has a machine-readable source page with the input, the generate action, the streaming result, and the loading, unavailable, and error states, so Claude Code or Cursor builds against a real screen. That avoids the common result where an AI tool assumes the model is always present and parses prose instead of using guided generation.

Can VP0 provide a free SwiftUI template for an AI generation screen? Yes. VP0 has free generation designs in SwiftUI with the input, the generate action, the streaming result, and the loading, empty, unavailable, and error states already built, each exposing an AI-readable source page. Because the screen exists, your agent connects it to a Foundation Models session instead of reinventing the generation UI and the state handling that usually trip up hand-built AI features.

Is the Apple Intelligence on-device model as capable as ChatGPT? No, and building as if it were is a mistake. The on-device model is small and tuned for focused language tasks on text you provide, summarizing, rewriting, tagging, and extracting, with the benefits of being private, free, and offline. It is not built for broad world knowledge, long documents, or current facts, where a large cloud model is the right tool. Use the on-device model for what it does well, and reach for the cloud when the task genuinely needs a frontier model.

What common errors happen when vibe coding an Apple Intelligence feature? Assuming the model is always available, asking it for broad knowledge or current facts, and parsing prose instead of using guided generation are the frequent ones. Blocking the UI while it generates feels frozen, and shipping a generated result with no review step trusts a small model too far for anything important. Check availability with a fallback, keep tasks focused, request typed output, and stream the response.