WWDC 2026 Expanded Foundation Models. React Native Still Needs a Cross-Platform Runtime.

TL;DR — WWDC 2026 significantly expanded Apple's Foundation Models framework. What began as a native API for Apple's on-device models now supports provider-based model routing, Private Cloud Compute access, image input, Dynamic Profiles, and third-party models through the new LanguageModel protocol. Apple's direction suggests that AI frameworks are converging on a common architecture: provider abstraction, capability detection, privacy-aware routing, and adaptive model selection. If you build cross-platform applications with React Native or Expo, you still need a way to bring those ideas to Android, cloud providers, and TypeScript. Expo AI Runtime is my attempt to solve that problem.

For most of the last three years, the interesting question about on-device AI was whether it was even possible — could a phone run a model useful enough to summarize a private note or extract structure from a document, rather than just autocomplete a keyboard. That question is now settled. Apple Foundation Models ship a capable language model on-device with iOS. Android devices increasingly expose Gemini Nano capabilities through AICore and related Google AI APIs such as ML Kit GenAI. The details vary by device, OS version, and model availability, but the broader trend is clear: useful language models are becoming part of the operating system rather than services that always require a network request. The model moved into your pocket, runs offline, costs nothing per token, and keeps the prompt on the device.

WWDC 2026 settled a second question I didn't expect Apple to answer so directly: what is the right architecture for calling these models? This post is about that answer, why React Native developers still can't reach it cleanly, and the runtime I built to fix it.

What Apple announced at WWDC 2026: Foundation Models evolved into a broader AI platform

When Apple introduced Foundation Models at WWDC 2025, the focus was straightforward: give developers access to the same on-device language model that powers Apple Intelligence.

WWDC 2026 expanded that vision considerably. Foundation Models is no longer just an API for Apple's local model. It now acts as a common framework for working with Apple Foundation Models, models running on Private Cloud Compute, and even third-party providers that conform to the new LanguageModel protocol. In practice, Apple moved from exposing a single model to exposing an extensible AI platform. ^[1]

The headline additions, all shipping with iOS 27:

• A LanguageModel protocol. Foundation Models can now work with Apple Foundation Models, models running on Private Cloud Compute, and third-party providers such as Claude and Gemini through a common API surface. ^[1]
• Direct access to Apple Foundation Models running on Private Cloud Compute. Developers can now use larger Apple-hosted models through the same framework while remaining within Apple's privacy architecture. ^[2]
• Capability detection. Code can inspect a model's context window and whether it supports multimodal input or reasoning, instead of hard-coding assumptions.
• Dynamic Profiles. A single session can swap its underlying model, tools, and instructions mid-conversation — a "quick answer" profile and a "deep research" profile backed by different models.
• Tools and multimodal input. Built-in Spotlight-powered retrieval, on-device Vision/OCR tools, and image input alongside text.
• An Evaluations framework for measuring whether AI features behave correctly across these dynamic conditions.

Read that list again as an architecture, not a feature changelog: provider routing, capability detection, a privacy-tiered model hierarchy, adaptive profiles, and an evals harness.

The most interesting shift, at least to me, is not any individual feature. It is that Apple is increasingly treating Foundation Models as an abstraction layer rather than a wrapper around a single model. The framework now describes capabilities, providers, tools, and profiles rather than assuming one model sits behind every request. That architectural direction looks remarkably similar to the provider-routing systems many AI platforms have independently converged on over the last few years. ^[1]

Apple made it the native default on iOS — and that's where the problem starts for everyone not writing Swift.

Why the new LanguageModel protocol matters most

Of everything in the WWDC 2026 update, the LanguageModel protocol has the longest reach. By defining a single protocol that the on-device model, Private Cloud Compute, and third-party providers all conform to, Apple turned which model into an implementation detail behind a stable interface. A developer writes against the protocol; the concrete model — local, Apple-hosted, or a Claude or Gemini package — becomes swappable without rewriting call sites.

That is the move worth making on any platform. Once a model is an interchangeable provider behind a protocol, routing, fallback, capability checks, and privacy policy become decisions the framework makes once, not logic every feature re-implements. Apple made that protocol native to Swift and Apple platforms. The open question for the rest of us is how to get the same interchangeability in a cross-platform codebase — which is exactly where a runtime comes in.

Why on-device AI matters for mobile apps

On-device AI matters because it changes four things at once that a cloud API can't: privacy, latency, cost, and offline behavior. In rough order of how much teams care:

• Privacy. The prompt never leaves the device. For anything touching health, finance, messages, or a user's own notes, that's not a feature — it's the permission to ship at all.
• Latency. No network round trip. First token returns in the time it takes to warm the model, not the time it takes to reach a data center.
• Cost. There is no per-token bill for a model running on hardware the user already paid for.
• Offline. It works on a plane, in a tunnel, or in a market where your backend doesn't exist.

None of this is controversial anymore, and Apple's WWDC 2026 direction — keeping even the larger model inside Private Cloud Compute rather than a third-party cloud — is a bet that privacy is the durable advantage. The catch is what it takes to actually wire this up in a cross-platform app.

Why on-device AI is still hard to reach from React Native

On-device AI is hard to reach from React Native for one blunt reason: Apple shipped it as a native Swift framework for Apple platforms. A cross-platform app gets none of it for free. To support both platforms today you integrate two unrelated native SDKs — Swift FoundationModels on one side, Kotlin ML Kit GenAI on the other — each with its own session model, its own error surface, and its own definition of "available."

And availability is genuinely conditional. The OS version has to be high enough. The user has to have Apple Intelligence enabled. On Android, AICore might still be downloading the model when your screen mounts. Import the iOS module on an Android device and a naive integration throws inside requireNativeModule before your app even renders.

So you end up hand-rolling a capability layer, a routing policy, a privacy-accounting layer, and an error-normalization layer — per app, every time, in TypeScript, bridging to two native worlds — just to get to the first token. Apple solved this elegantly inside its own platform. The gap is that React Native lives above both platforms and still has to solve it again.

Expo AI Runtime: one TypeScript API across on-device and cloud providers

Expo AI Runtime is an open-source, mobile-native provider layer that gives React Native and Expo apps a single TypeScript API — ExpoAI — over Apple Foundation Models, Android's Gemini Nano, an optional bring-your-own-model runtime, and a cloud fallback you opt into rather than inherit. A router picks the best available provider; every call returns not just text but which provider ran it and what that meant for privacy.

The design rests on a few principles that are really hard-won opinions about mobile AI — the same ones Apple bakes into iOS 27 Foundation Models, here carried cross-platform:

• Capabilities over assumptions. Nothing is presumed available. Every feature is runtime-detected before it's offered to a user.
• Providers over platforms. "iOS" isn't a provider; Apple Foundation Models is. A single platform can expose several providers, and the router treats them as a priority list.
• A stable TypeScript API over replaceable native adapters. Native SDKs churn fast — WWDC 2026 is proof. The public API shouldn't move when they do.
• Privacy metadata on every result. Not a config flag set once and forgotten. A property on every response.

In practice the common path is short:

import { ExpoAI } from "@stewmore/expo-ai-core";
import "@stewmore/expo-ai-apple-foundation-models"; // registers iOS adapter
import "@stewmore/expo-ai-android-aicore";          // registers Android adapter

const caps = await ExpoAI.getCapabilities();
if (caps.available) {
  const result = await ExpoAI.generate({
    prompt: "Summarize this note in five bullets.",
    fallback: "cloud",
  });

  result.text;                 // the output
  result.provider;             // which provider actually ran it
  result.privacy.privacyMode;  // "on-device" | "third-party-cloud" | ...
}

The adapters register themselves at import time, guarded by Platform.OS, so importing the iOS package on Android is a no-op instead of a crash. The core is pure TypeScript with no native imports, which means routing, validation, and privacy logic all unit-test in plain Node, away from a simulator.

Privacy as metadata on every call

Privacy in Expo AI Runtime is a property of every result, not a setting you configure once. Each GenerateResult carries a privacy object describing exactly what happened to the prompt:

const result = await ExpoAI.generate({
  prompt: userNote,
  sensitive: true,   // this prompt must not silently leave the device
  fallback: "cloud", // ...and even then, only if I explicitly allow it
});

result.privacy.isOnDevice;           // did this run locally?
result.privacy.sendsPromptOffDevice; // did the prompt cross the boundary?
result.privacy.privacyMode;
// "on-device" | "apple-private-cloud-compute" | "third-party-cloud" | "unknown"

The rule the router enforces is strict: a prompt marked sensitive is never silently routed to a third-party cloud. If on-device generation isn't available and you haven't explicitly set a cloud fallback, the call fails loudly rather than leaking.

Notice the "apple-private-cloud-compute" value. That tier — and its slot in the router's default priority order — is deliberate. These modules are a cross-platform take on Apple's own model hierarchy. On iOS the full ladder applies: on-device → Apple-private cloud → third-party cloud. Android has no Private Cloud Compute equivalent, so it collapses to on-device → third-party cloud — but the API, the privacy accounting, and the explicit-fallback rule are identical on both. One call site, one privacy contract, two platforms. Private Cloud Compute already existed as an Apple privacy tier when I built the modules, so I modeled it from the start. What WWDC 2026 adds is direct developer access to Apple Foundation Models running on Private Cloud Compute through the Foundation Models framework. The runtime's existing privacy-tier model aligns naturally with that capability, which means adopting Apple's newer APIs is largely adapter work rather than an architectural change. ^[2]

Capability detection and normalized errors

Because on-device availability is conditional, the ugliest real-world states aren't generation failures — they're the model isn't here yet states, and there are many. The OS is too old. Apple Intelligence is switched off. AICore is mid-download. The device simply isn't supported.

A runtime that ignores these ships apps with an AI button that does nothing. So capability detection is first-class, and every failure normalizes to a single ExpoAIError with a machine-readable code — UNSUPPORTED_DEVICE, MODEL_NOT_READY, MODEL_DOWNLOAD_REQUIRED, USER_SETTING_REQUIRED, SAFETY_BLOCKED, CONTEXT_WINDOW_EXCEEDED, and more — plus the fields you branch on: retryable and fallbackRecommended. That's the difference between "something went wrong" and a screen that says "Turn on Apple Intelligence to use this," or "Downloading the model, try again in a minute."

Above that sits an ergonomics layer that deliberately lives in TypeScript, not native code: sessions (native on iOS, emulated elsewhere), streaming with AbortController cancellation, and generateObject for structured output with JSON-schema validation and a repair loop for almost-valid JSON. The native methods stay primitive on purpose; the niceties belong in a layer you can fix without shipping a new app binary.

How Expo AI Runtime maps to Apple's iOS 27 Foundation Models

Expo AI Runtime maps almost one-to-one onto the iOS 27 Foundation Models architecture, which is why adopting Apple's new capabilities is additive rather than a rewrite. The seams already exist; new Apple features slot in as adapters and capability flags.

The honest read: Apple's native framework is now ahead of the runtime on tools, multimodal input, and Spotlight RAG — those are deferred in v1 on purpose. But on the parts that make cross-platform AI shippable — one stable API, provider routing, capability gating, privacy accounting, and normalized errors — the runtime is built on the same model Apple is now shipping natively, and deliberately so. Its job is to carry that model where Apple's Swift framework can't reach: to Android's Gemini Nano, to a real cloud fallback, and to TypeScript — one API across both platforms.

What Expo AI Runtime is not

Expo AI Runtime is deliberately narrow. It is not a LangChain for phones, not an agent framework, not a vector database, and not a hosted backend. There is no memory system, no tool-calling loop, and no RAG pipeline in version one. Bring-your-own-model runtimes like LiteRT-LM, native tool calling, multimodal input, and agent loops are mapped out but deferred.

It solves exactly one hard problem: reliably calling native models from React Native, with the capability detection, privacy accounting, and error normalization that make that safe to ship. The runtime ships as a small set of focused packages — a pure-TS core, an iOS adapter, an Android adapter, a cloud adapter, and a Node eval harness — plus example apps for generation, structured output, streaming, and cloud fallback. Foundation first; the higher-level work is far easier once the layer underneath it is honest.

Frequently asked questions

What is Expo AI Runtime? Expo AI Runtime is an open-source TypeScript library that gives React Native and Expo apps one API for on-device and cloud AI models — Apple Foundation Models on iOS, Gemini Nano on Android, and an optional cloud fallback — with provider routing, capability detection, and privacy metadata on every result.

Does it work with Apple's iOS 27 Foundation Models changes from WWDC 2026? By design, yes — with some adapter refactoring in progress. The runtime is modeled on the same architecture Apple ships in iOS 27: an adapter contract, provider router, capability detection, and an apple-private-cloud-compute privacy tier. Adopting Private Cloud Compute and the new LanguageModel providers is targeted adapter work against the shipping APIs, not a ground-up rewrite.

Does it send my prompts to the cloud? No, not unless you opt in. A prompt marked sensitive is never silently sent to a third-party cloud. Cloud fallback only happens when you explicitly set it, and every result reports its privacyMode so the app always knows whether the prompt stayed on-device.

Do I need an API key or a backend? No, for on-device generation. Apple Foundation Models and Android Gemini Nano run locally with no key and no backend. A backend is only needed if you choose to enable the cloud fallback adapter.

Can I use it in Expo Go? No. Because it includes custom native code, the example apps require an Expo development build (npx expo prebuild then run:ios / run:android), not Expo Go.

Where this lands

The interesting thing about this moment is how much infrastructure now exists beneath us. There are now capable language models running directly on consumer devices. Apple's Foundation Models framework continues to mature. Android is steadily exposing similar capabilities. Privacy-preserving cloud tiers like Private Cloud Compute are beginning to blur the line between local and server-side inference. The building blocks are arriving faster than most application architectures are adapting to them. ^[1]

For teams building native Swift applications, Apple's framework now provides a compelling path forward. For teams building cross-platform applications, the challenge remains connecting those platform-specific capabilities behind one coherent API surface.

That's ultimately why Expo AI Runtime exists. Not because React Native needs a competing AI framework, but because cross-platform apps need a practical way to participate in the AI capabilities that platform vendors are increasingly making available by default.

If you want to experiment with that idea, the docs and source are available at stewartmoreland.github.io/expo-ai-runtime. The project is MIT licensed, and I'd love to see what other developers build as these platform-native AI capabilities continue to evolve.

Stewart Moreland builds mobile-native AI tooling for React Native and Expo, and is the author of Expo AI Runtime. Last updated June 20, 2026.