Kristopher Baker iOS roots · Product systems · AI-assisted workflows
← Shikisha

shipped · 2026.06.18 · 2 min read

The Foundation Models backend I said I'd get to

Back in June I wrote that Apple's WWDC26 Foundation Models framework had expanded into a lot of Shikisha's own territory, and that I planned to explore it myself to see where Shikisha should sit on top of it. This week I did. FoundationModelsChatModel is a new on-device backend, backed by SystemLanguageModel: no API key, no base URL, no network call at all. It conforms to the same ChatModel protocol as the OpenAI, Anthropic, and Google backends, so swapping one of those out for it in an existing chain needs no other code changes. System messages become the session's instructions, the latest turn plus prior history becomes the prompt, and streaming maps Apple's cumulative response snapshots down to the incremental deltas the rest of Shikisha expects.

The gating mattered more than the model call itself. Shikisha's package floor is macOS 14 and iOS 17, and I did not want one backend to drag that up. Apple's framework is macOS 26 and iOS 26 only, so the type sits behind #if canImport(FoundationModels) and an @available(macOS 26, iOS 26, *) annotation: an older toolchain excludes it entirely, a current one compiles it but gates it at runtime, and it costs nothing extra because FoundationModels is a weak-linked system framework rather than a package dependency. Tool-calling is out of scope for this first pass. I also went back through the README and the DocC guide to put it next to Ollama as the other no-API-key option, since "I don't have a key handy" is the exact moment this backend earns its keep.

The part worth noting is not that the on-device model answers questions. It is that adding a fourth provider needed zero changes anywhere else in Shikisha, which was the actual point of building a shared ChatModel vocabulary in the first place.