Foundation Models Use Cases: General vs Content Tagging

Apple’s SystemLanguageModel docs start with the base model, then use cases, then adapters. SystemLanguageModel.default is the base model; SystemLanguageModel.UseCase documents general and contentTagging; custom adapters are the developer-trained path covered separately.¹²³

The earlier post on the Tool protocol covered how to make the default model do useful work. The question this post answers is the next one: when does the default with prompting and tools suffice, and when does Apple’s .contentTagging use case earn its slot? The custom-adapter path is a separate post; the developer-managed lifecycle has too much surface area to share with the decision rubric.

TL;DR

• SystemLanguageModel.UseCase is a struct with two static properties: .general and .contentTagging.³ No other use cases are documented.
• .general is the default. Reach for it first. Prompting, instructions, guided generation, and tool calling all live on top of .general; specialization is the last lever to pull.
• .contentTagging belongs to Apple’s content-tagging guide: identify topics, actions, objects, and emotions in input text, then fall back to .general when Apple’s stated boundaries do not fit.⁵
• The third rail (custom adapters, the Adapter type, the entitlement, the toolkit) is where the operational complexity lives. Different post.

What SystemLanguageModel Actually Is

Apple describes SystemLanguageModel as the on-device language model for text generation tasks, with default as the base model. Availability is runtime state: device eligibility, Apple Intelligence settings, and model readiness all matter before an app shows model-backed UI.¹

Apple’s documentation lists the model platforms (iOS, iPadOS, Mac Catalyst, macOS, visionOS, all 26.0+) and two current model versions: one for OS releases 26.0–26.3 and another for 26.4. Apple updates the on-device model in routine OS updates.¹

Availability is checked at runtime. SystemLanguageModel.availability is an Availability enum with the following cases as documented in Apple’s sample code:¹

struct GenerativeView: View {
    private var model = SystemLanguageModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Show your intelligence UI.
        case .unavailable(.deviceNotEligible):
            // Show an alternative UI.
        case .unavailable(.appleIntelligenceNotEnabled):
            // Ask the person to turn on Apple Intelligence.
        case .unavailable(.modelNotReady):
            // The model isn't ready because it's downloading or because
            // of other system reasons.
        case .unavailable(let other):
            // The model is unavailable for an unknown reason.
        }
    }
}

isAvailable is a convenience getter that returns true only when the system is entirely ready.¹ Always check before you call.

The First Rail: Prompt The General Model

Apple’s general guide says the on-device model supports text generation and understanding for the tasks below, including Generate tags from text.⁴

Apple’s avoid list is separate: basic math, code creation, and logical reasoning.⁴

Note that “generate tags from text” appears in the good-at table for the general model. That’s important context for the specialization decision below.

The general rail is where Apple documents prompts, instructions, guided generation, tool calling, and generation options.⁴

The context window is 4,096 tokens for the system model.⁴ Apple notes that a token corresponds to three or four characters in languages like English, Spanish, or German, and one token per character in languages like Japanese, Chinese, or Korean. The instructions, prompts, and outputs all count toward the limit. When a session exceeds it, the framework throws LanguageModelSession.GenerationError.exceededContextWindowSize(_:).⁴

The Second Rail: .contentTagging

SystemLanguageModel.UseCase is documented as a struct (not an enum) with two static properties:³

static let general: SystemLanguageModel.UseCase
static let contentTagging: SystemLanguageModel.UseCase

There are no other documented cases. If a writeup names a third use case, the writeup is making it up.

.contentTagging is a different shape from .general. Apple’s guide describes the contentTagging model as one that “identifies topics, actions, objects, and emotions in input text” and produces tags as “one to a few lowercase words.”⁵ The model is built to evaluate input rather than respond conversationally: “It isn’t a typical language model that responds to a query from a person: instead, it evaluates and groups the input you provide.”⁵

Loading the model with .contentTagging:

let model = SystemLanguageModel(useCase: .contentTagging)
let session = LanguageModelSession(
    model: model,
    instructions: """
        Provide the two tags that are most significant in the context of topics.
        """
)

The documented convenience initializer is init(useCase:guardrails:).¹ Apple’s sample code calls it without the guardrails argument, which suggests guardrails carries a default value at the call site.

The contentTagging model integrates with Generable, so you can define a Swift type that captures the shape of tags you want:

@Generable
struct ContentTaggingResult {
    @Guide(
        description: "Most important actions in the input text.",
        .maximumCount(2)
    )
    let actions: [String]

    @Guide(
        description: "Most important emotions in the input text.",
        .maximumCount(3)
    )
    let emotions: [String]

    @Guide(
        description: "Most important objects in the input text.",
        .maximumCount(5)
    )
    let objects: [String]

    @Guide(
        description: "Most important topics in the input text.",
        .maximumCount(2)
    )
    let topics: [String]
}

let response = try await session.respond(
    to: prompt,
    generating: ContentTaggingResult.self
)

Apple’s behavioral note: “For very short input queries, topic and emotion tagging instructions provide the best results. Actions or object lists will be too specific, and may repeat the words in the query.”⁵ The contentTagging model also “respects the output format you want, even in the absence of instructions”, so the Generable shape carries more weight than a verbose system prompt would.

The Decision Tree (Apple’s Own Words)

Apple gives the decision rule directly. Use .general for tags outside actions, objects, emotions, or topics; for hashtags; for tool-calling tag flows; and for constraints beyond maximumCount.⁵

The four exact sentences from Apple’s contentTagging guide:⁵

1. “If you’re tagging content that’s not an action, object, emotion, or topic, use general instead.”
2. “Use the general model to generate content like hashtags for social media posts.”
3. “If you adopt the tool calling API, and want to generate tags, use general and pass the Tool output to the content tagging model.”
4. “If you have a complex set of constraints on tagging that are more complicated than the maximum count support of the tagging model, use general instead.”

Pick .contentTagging only when the task is text tagging into Apple’s four documented categories and the output constraints fit maximumCount. If neither .general nor .contentTagging fits, leave the custom-adapter decision to the adapter lifecycle post.⁵

What Apple Has Not Published

Apple documents .contentTagging as an adapted content-tagging model, but does not publish the adaptation mechanism, benchmark deltas, or additional UseCase static properties. Treat anything beyond general and contentTagging as unverified until developer.apple.com documents it.³⁵

Apple’s own framing on versioning: “Apple will periodically update SystemLanguageModel in routine OS updates to improve the on-device model’s abilities and performance.”¹ Treat the surface as versioned.

Takeaways

1. Two documented use cases. Apple’s UseCase page documents general and contentTagging; do not assume a third value.³
2. Default to .general. Prompting + tools + guided generation handles most use cases the on-device model is designed for. Specialization is the last lever, not the first.
3. Pick .contentTagging only when Apple’s documented shape fits. Topics, actions, objects, emotions. One-to-a-few-word lowercase tags. maximumCount-level constraints. Anything more, fall back.
4. Read Apple’s “use general instead” rules. They’re four concrete sentences in the contentTagging guide.⁵ Each one is a real boundary.
5. The custom-adapter path is a separate decision. Different surface area, different lifecycle, different post.

The full Apple Ecosystem cluster: the on-device LLM and Tool protocol for the framework’s primitives; the agentic workflow split between in-app and developer-tooling LLMs; App Intents vs MCP for the routing question across all three. The hub is at the Apple Ecosystem Series. For broader iOS-with-AI-agents context, see the iOS Agent Development guide.

FAQ

How many SystemLanguageModel.UseCase values are there?

Two static properties as currently documented: .general and .contentTagging.³ If you see a third value referenced in a tutorial or an LLM-generated answer, verify it against developer.apple.com before adopting it.

When should I use .contentTagging instead of just prompting .general?

Use .contentTagging when the task is identifying topics, actions, objects, or emotions in input text and returning short lowercase tags. Apple’s guide lists four scenarios where .general is the right answer instead: tagging that doesn’t fit those four categories, hashtag generation, tag pipelines that route through tool calls, and tagging constraints richer than maximumCount.⁵

Does the contentTagging model accept arbitrary instructions like the general model does?

It accepts instructions, but the model’s design is to evaluate input rather than respond to user-style queries. Apple’s guide notes that the contentTagging model “respects the output format you want, even in the absence of instructions”, so a @Generable shape with @Guide annotations carries the constraint, not a long prompt.⁵

What’s the context window for the on-device model?

4,096 tokens for the system model.⁴ Token-to-character ratio is roughly three to four characters per token in English/Spanish/German and one token per character in Japanese/Chinese/Korean.⁴ The framework throws LanguageModelSession.GenerationError.exceededContextWindowSize(_:) when the session exceeds the limit.⁴

Why does Apple’s sample code call SystemLanguageModel(useCase:) without guardrails:?

Apple documents init(useCase:guardrails:) and publishes content-tagging sample code that calls SystemLanguageModel(useCase: .contentTagging). I did not verify the defaulted guardrails parameter by compiling against the iOS 26 SDK.¹⁵

References