iOS 27 Foundation Models: What They Can Actually Do in Production

iOS 27 shipped on September 14, 2026, and most teams that submitted alongside the release now have two weeks of real data on the new Foundation Models framework. This is a field report on what changed, what actually works in production, and where the on-device model still can't help — measured on shipping apps, not demo reels.

Last year's version was promising but narrow. This year's is the first one we would build a shipping feature on top of without a cloud safety net for the common tasks.

What Foundation Models actually is in iOS 27

Foundation Models is Apple's Swift-first API for talking to an on-device language model that ships with the operating system. It is a small language model, resident on Apple Intelligence hardware, sandboxed per-app, invoked through a LanguageModelSession that your code owns like any other resource. No keys, no accounts, no billing, no network round-trips.

Apple has been deliberately imprecise about the model's size for the iOS 27 revision, and reports vary. What is consistent is that it is meaningfully larger and more capable than the iOS 26 version, tuned for the short-in, short-out tasks the framework is built around. Two properties matter for planning: it is Apple-provided, so you do not bundle weights or ship updates, and it is per-app sandboxed, so your session cannot cross the app boundary. For anything privacy-adjacent, that is a materially different posture than a cloud call.

What's new since iOS 26

The framework's shape is familiar from last year, but every dimension that mattered got bigger:

• A larger context window. Not cloud-scale, but comfortably enough for a full email thread, a multi-page note, or a small transcript.
• Better tool calling. The model reliably invokes Swift-defined tools with structured arguments and handles a small number of sequential turns without drifting.
• Structured output. Guided generation against a Swift-declared schema, so JSON-shaped responses arrive already typed. This is the single feature that most cleaned up our production code.
• Streaming. Token-by-token output is exposed as an AsyncSequence, so responsive UIs come for free.
• Image input. The model accepts images alongside text — useful for description, extraction, and lightweight visual understanding.

Individually these are incremental. Together they are the difference between "novel demo" and "we can build a real feature on this."

Where it wins today

Two weeks of shipped-app observations line up with what the model's shape predicts. It is excellent at the well-defined, bounded work that dominates real apps:

• Classification. Multi-label routing over user text, ticket triage, content tagging. The small model handles this at near-instant speeds.
• Extraction. Pulling names, dates, amounts, and order numbers out of unstructured text or screenshots. Structured output makes the response arrive already typed.
• Summarization of one thing. A single email, note, or transcript. Short in, short out.
• Smart form fill. The user pastes an appointment confirmation; the app fills in the fields. Image input turns receipts into structured expense entries.
• Simple agent turns. Not a full autonomous agent, but a one- or two-step "look up X, then call tool Y" flow completes reliably enough to ship.
• Personalization on-device. Learning small preferences from local data without any of it leaving the device.
• Offline mode. The model doesn't need a network. Apps on planes, subways, and in coverage-thin places keep their intelligence.

If a feature you were going to send to a cloud model is on that list, the honest recommendation is to try it on-device first.

Where it still fails

The limits are the ones a small model always has, and no framework upgrade removes them:

• Long-form generation. Quality falls off across longer outputs. Coherent for short, drifty for long.
• Multi-hop reasoning. Chains of three or more inferential steps, especially arithmetic ones, are where the small model quietly gets things wrong.
• Code generation. Passable for one-liners. Not close to frontier quality for anything you'd merge.
• World knowledge and current events. Frozen at training. Ask it about last week and you'll get last year.
• Nuanced tone or voice work. Serviceable, not stylish. If the output is the product, the cloud still wins.

Treat the model like a fast, private junior colleague: plenty you can hand off, and work that still belongs elsewhere. Naming that boundary early separates apps that ship a good AI feature from ones that ship a frustrating one.

The iOS 27 on-device model is the first version we'd trust to carry a shipping feature by itself — but only for the tasks it was built for. Respect the boundary and it earns its keep.

Battery, thermals, latency

Every on-device inference costs something, but in two weeks of production data the pattern is consistent and manageable. Short prompts feel instant. Longer generations are visible but not slow. The streaming API keeps perceived latency good even when the raw generation is not.

Battery cost is real but bounded. A handful of inferences per user session is a rounding error. A feature that runs the model constantly in the background will get noticed — by users and by the OS's energy accounting. Thermals only show up in unusual patterns: long, back-to-back generations without pauses. The mitigation is the same as any compute-heavy work: batch, debounce, and be honest about how often the feature really needs to fire.

The line that matters is the one you don't get with cloud inference: per-call cost is zero and stays zero. A feature you ship to a million users costs the same as a feature you ship to a thousand. Founders burned by runaway cloud AI bills recognize that number instantly.

App Store implications

Apple has been unusually explicit that on-device intelligence is a positive signal for app quality. Two practical consequences:

• Privacy positioning. "Your data stays on your phone" is not just marketing when it is technically true. Foundation Models makes it easy to make that claim honestly and disclose it clearly in the app's privacy labels.
• Low-value app purge protection. Apple has been quietly pruning apps that look like thin wrappers over generic cloud AI. A meaningful on-device feature is one of the clearest ways to look like a real product, not a shell — a pattern we've watched play out during review over recent months.

Neither is a reason to add on-device AI where it doesn't fit. Both are reasons not to skip it where it does.

Where Foundation Models wins vs. where cloud still owns the task

A defensible default, drawn from what we've seen ship in the last two weeks. Measure on your own real inputs before you commit.

How to route: on-device for the 80%, cloud for the 20%

The routing pattern hasn't changed — the split has. A year ago most non-trivial AI calls belonged in the cloud. In iOS 27 the honest default flips: reach for the on-device model first, and escalate only when it falls short on your real inputs. The full routing logic, including how a single LanguageModelSession can reach cloud models through the same framework, is in On-Device AI: When Apple Intelligence Beats the Cloud (and When It Doesn't).

What to build with it right now

Concrete, low-risk starting points for teams shipping this quarter:

• Inbox and notification triage. Classify and rank incoming items on-device. Zero data leaves the phone.
• Receipt, ticket, and appointment capture. Point the camera; get a structured entry. Image input plus structured output makes this feel magical.
• Local search that understands intent. Turn "notes about last quarter's launch" into a real query against your app's local data.
• Auto-fill and auto-tag flows. Anywhere the user is doing repetitive structuring work, the model does most of it and lets them correct the edges.
• Offline assistant surfaces. A quick-action button that summarizes, classifies, or rewrites — works on the subway.

Skip, for now: long-form content generation, autonomous multi-step agents, and anything where a confident wrong answer would be materially harmful. For an overview of the wider iOS 27 SDK changes, see our iOS 27 for indie developers recap.

Where people go wrong (and when to call a pro)

The patterns from two weeks of production data are consistent enough to name:

Frequently asked questions