From Shared Model to App-Specific Capability

Apple’s Foundation Models framework addresses a practical problem: how can a shared on-device foundation model become useful inside many different apps without pretending to be a universal chatbot? This chapter examines the controls around that model—typed generation, tools, sessions, streaming, and low-rank adapters—and distinguishes the kinds of specialization each one provides. The result is a clearer boundary between asking a model to say something, constraining what it may return, connecting it to an external operation, and changing how its weights respond to a task.

Interfaces make a compact model useful without making it omniscient

A raw language-model response is a sequence of tokens. An app usually needs something more specific: a date and location, a list of entities, a rewritten paragraph, a decision that selects one of a few actions, or a call to a service with named arguments. If the app receives only text, it must infer whether the output has the expected shape and then parse it. Every extra parsing step creates a new failure surface.

Apple’s guided generation approach changes the contract. A developer describes a Swift structure or enumeration with the @Generable macro. The framework translates that developer-defined type into a standardized response format, supplies the format to the model, and uses constrained decoding to keep the generated result within that structure. The resulting output can be turned into an instance of the Swift type rather than being treated as an arbitrary string.

The benefit is not that the model becomes more knowledgeable. The benefit is that the space of outputs becomes narrower and more legible to the application. A field that must be a date can be represented as a field in a known object; a choice can be represented as an enum; a collection can have an expected shape. The app no longer has to hope that a prompt’s wording will make the model produce parseable punctuation.

That changes the failure surface in a useful but limited way. Constrained decoding can prevent a malformed object, a missing delimiter, or an invented tool name. It cannot verify that a date was read correctly from an image, that an entity was identified accurately, or that the user’s request was safe. Structural correctness and semantic correctness are different properties. A valid object may still contain a wrong value, so the application needs ordinary validation and appropriate confirmation for actions that matter.

Tool calling extends the model without putting every possible capability into its weights. A developer implements a tool that provides a specific source of information or service. The model can decide to call that tool, produce the name and arguments in the expected structure, receive the tool’s result, and continue the interaction. Apple describes framework support for serial and parallel call graphs, which matters because a real task may require one lookup before another or several independent lookups before a final response.

The boundary between the model and the tool should remain explicit. The model proposes a call; the tool owns the external operation. The tool may read a database, perform a calculation, or create an application object. It can fail, return stale information, require permission, or change state. A structurally correct call is not automatically an authorized or successful action. The framework reduces one class of error by preventing hallucinated tool names or arguments, but the app still owns decisions about available tools, input validation, confirmation, and recovery.

The same division applies to state. Apple’s LanguageModelSession is an append-only session coupled to the model’s KV cache.