Every generative UI framework is React-first. Here is what that leaves for Swift.

Search for a generative UI framework for Swift and the results arrive in two piles, neither of which answers the question. One is SwiftUI introductions, pulled in by the language name. The other is framework roundups, and in the best one on the page — nine projects, checked 6 August 2026 — SwiftUI appears exactly once, inside the clause "Same A2UI JSON renders on Lit, Angular, Flutter, React, SwiftUI."

That is not a gap in the writing. It reflects the projects, which are React-first for reasons that live in their source rather than their marketing: a JavaScript component catalog, a hooks runtime and a patchable render tree are three assumptions a compiled Swift binary does not satisfy.

So here is the same inventory read from the other end. What each project ships for a native iOS app as of 6 August 2026, what the three ways of reaching a JavaScript framework from Swift cost, and the two axes none of the roundups rank on. For the category itself, start with what generative UI means on iOS.

The short version

If you want a JSON contract with a native Swift renderer today, A2UI is the only one, and the Apple renderer is community-maintained rather than official.

If you want a hosted model that returns interface instead of text, Thesys C1 does that, through a React SDK.

If you want the runtime, the hooks and the streaming, CopilotKit and Vercel's json-render both deliver it in JavaScript, so a Swift app reaches them through React Native or a web view.

If you want the model's output checked before it reaches the device, none of the four ships that. It stays your problem.

Why every one of these is React-first

The shared design starts with the catalog. In each project, the set of things the model may emit is declared as components in TypeScript: json-render uses Zod schemas for the props, CopilotKit registers frontend tools through hooks. The declaration is code in the app's own language, which is what makes the developer experience good.

Streaming follows from the same choice. Partial output paints immediately because the render target is a virtual DOM patched node by node, so a half-finished tree is a legitimate intermediate state rather than a broken screen.

What that assumption costs a compiled app

Neither property survives the trip to iOS. A native binary has no JavaScript runtime unless you add one, and a SwiftUI view tree is rebuilt from state rather than patched, so "apply what arrived and fix it later" is not a rendering strategy. Portability here means one more JavaScript renderer, and Swift is not one — which is why every roundup's compatibility row is a single cell.

What every generative UI framework for Swift actually ships today

Each status below was checked against the project's own page or repository on 6 August 2026.

Google A2UI. The spec is the most portable artifact in the category: v0.9.1 is the current stable release and v1.0 is a candidate, with finalization targeted at Q4 2026. The roadmap lists React as stable and official, and the SwiftUI renderer for iOS and macOS as Planned, against a stated target of Q2 2026. The renderer directory shows thirteen renderers, of which exactly one — @a2ui/react — is maintained by the A2UI team. a2ui-swift, covering SwiftUI, UIKit and AppKit through a shared core for spec versions 0.8 through 0.9.1, is listed as available and community-maintained.

CopilotKit. @copilotkit/react-native provides the provider, the hooks and optional prebuilt chat components, and requires React Native 0.70 or later. The docs describe it as feature complete with documentation still catching up; API parity with the v2 surface landed in v1.57.2 on 19 May 2026, so the "beta" label that circulated earlier this year is out of date. Separately, the AG-UI Kotlin Multiplatform SDK, announced 4 November 2025, carries agent events to iOS from a shared codebase. It is transport, not rendering: your app still draws every pixel in SwiftUI.

Vercel Labs json-render. Apache-2.0, and the broadest renderer set of the four: React, Vue, Svelte, Solid, React Native, terminal, PDF, email, video, images. There is no Swift package in the repository, and there is no server — the catalog is declared in Zod and the library renders what the model returns. InfoQ dated the release to January 2026.

Thesys C1. The documentation describes an OpenAI-compatible endpoint that returns interface rather than text, so adoption is a change of base URL for a backend that already speaks the OpenAI SDK. The client half is a React SDK, and no native iOS, Swift or SwiftUI SDK is named in the docs. That is the honest answer to the Thesys C1 native mobile support question: the endpoint travels, the renderer does not.

Three ways to reach one of these from Swift

If you want one of the four rather than the protocol underneath it, three routes exist and each bills you differently.

1. Embed a web view. Fastest to a demo, and it ends the argument about whether the result is native. Type, focus, scrolling, accessibility and the transition into the rest of your app become approximations, and the assistant surface becomes a second rendering engine your team maintains.
2. Adopt React Native for that surface. Legitimate, well-trodden, supported directly. You are adding a JavaScript runtime, a bridge and a second build for one feature. If React Native is already in your stack this is nearly free; if it is not, it is the expensive option wearing the cheap option's clothes.
3. Take the contract and write the renderer. Read the JSON format, implement the components in SwiftUI, ignore the JavaScript. This is what the community Apple renderer for A2UI did. You own a renderer permanently, and every component behaves like the rest of your app.

Route three is the only one where the result is indistinguishable from the screens you already ship. It is also the only one where the maintenance never ends.

What all four share, and what they leave to you

The convergence is real and worth stating plainly, because it is what makes the category tractable: in all four projects the model does not emit interface code. It emits JSON constrained to a catalog someone declared in advance, streamed, with interaction routed back to handlers the host registered.

What none of them decides for you is what happens when a record does not fit that catalog. Consider a fragment of a wire contract:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["type", "items"],
  "properties": {
    "type": { "const": "metrics" },
    "items": {
      "type": "array",
      "minItems": 2,
      "maxItems": 4,
      "items": { "$ref": "#/definitions/metric" }
    }
  }
}

A model that emits six metrics, or one extra property, has produced something this contract rejects. Three answers are available — drop the record, patch it into the nearest legal shape, or fail the turn — and none of the roundups ranks the projects on which one they take. They measure stars, lock-in, learning curve and time to prototype. For an app that has already shipped, the invalid record decides more than all four.

The axis nobody ranks on: where the checking happens

A catalog constraint declared in the client is enforced in the client, so the invalid bytes crossed the network and reached the device before anything rejected them. That is fine for a prototype and awkward for a regulated app, where the failures you most want logged are the ones you want stopped somewhere you control.

The alternative is two-sided: a server-side gate that validates each record before forwarding it, and a client that re-implements the same grammar and does not trust the gate. When they disagree, the tighter one wins and the record does not render. This costs you a server, which is precisely the component json-render does not include and A2UI does not specify.

The second axis: a catalog change costs a release, not a deploy

Every roundup offers the same escape hatch when the model wants something the catalog lacks: add a component. On the web that is a deploy. On iOS it is App Review, then a staged rollout, then a long tail of installs that will not update for months — and your assistant keeps answering on those old versions the whole time.

A record vocabulary you can extend weekly is a web assumption. Design as if the catalog is closed, because for most of your users it is.

So a native catalog should be small, semantic and general — metrics, comparisons, steps, facts — rather than a growing set of specific widgets. That is the opposite of the advice the React-first guides give, and it follows from the release model rather than from taste.

Where Uzori sits

Uzori is an in-app assistant for native iOS apps that answers in real screens rather than text, built from the two axes above rather than from the catalog-authoring experience.

Validation runs server-side before anything is forwarded, and the gate forwards the original bytes, so what renders is byte-identical to what passed. A record that fails is rejected rather than repaired; the server never patches model output, and one bounded re-ask is permitted only when the first record fails and nothing has reached the client. The iOS reducer re-implements the grammar and its own cardinality limits independently, so the tighter of the two decides.

The wire schema has no colour, font, spacing or tree field in any of its 23 records and every definition is additionalProperties: false, so the model cannot author style. Interactions carry an actionRef and nothing else, and a reference the app was not configured with is dropped. Mutating verbs are disabled by default; an operation reaches the model only if a human both allowlists it and classifies it read.

The limits belong here too. It is iOS only, where several projects above are genuinely cross-platform. Read-only fits service questions — a bill, a delayed flight, a denied claim — and fights commerce, where the session ends in a purchase. And it inherits your specification's accuracy: drift a human reader would forgive becomes a hard tool error.

Which one to pick

Pick by the constraint you cannot move. If your assistant surface can be JavaScript, CopilotKit or json-render gets you there fastest. If your backend already speaks the OpenAI SDK and the client is web, C1 is the shortest path. If the app must stay native and you can own a renderer, implement A2UI's contract in SwiftUI, or use the community renderer and follow the official one when it lands. If the requirement is that invalid output never reaches a customer's device, rank on where validation runs and treat catalog ergonomics as secondary — the rest of this blog works through that question.

Frequently asked questions

Is there a generative UI framework for Swift that is not React?

Not a first-party one. A2UI's JSON contract has a community Apple renderer covering SwiftUI, UIKit and AppKit, listed as available on the project's ecosystem page on 6 August 2026, while the official SwiftUI renderer remains on the roadmap. Every other major project in this category ships JavaScript packages, so the practical Swift path is to implement the contract yourself.

Can I use CopilotKit in a native iOS app?

Not directly in Swift. CopilotKit's iOS story is @copilotkit/react-native, which its docs describe as feature complete and which requires React Native 0.70 or later. The AG-UI Kotlin Multiplatform SDK reaches iOS as an event transport rather than a renderer, so your app still draws the interface itself in SwiftUI.

Does Thesys C1 support native mobile?

The documentation names a React SDK and describes C1 as an OpenAI-compatible endpoint that returns interface instead of text. No native iOS, Swift or SwiftUI SDK appears in the docs as of 6 August 2026. Because C1 is an API rather than a client library, a native app can call the endpoint and render the payload with its own code.

Do I have to ship a web view to render model-generated UI on iOS?

No. A web view is one of three routes and the only one that gives up native behaviour. The alternatives are React Native for the assistant surface, or implementing the JSON contract in SwiftUI so that generated screens use the same components, type settings and navigation as the rest of the app.

Where to start

Read the contract before the marketing page. For any project on this list, the schema tells you what the model may emit and the runtime tells you what happens when it emits something else — two files that settle more than a feature table will.

If you would rather see a generated screen answer a real question from your own API, write to hello@uzori.ai with the question your customers ask most.