Server UI: Server-driven SwiftUI for AI-native iOS

Server UI, also called server-driven UI, is a data-only pattern where the structure of a screen—its layout, components, and states—is described as a validated schema on the backend and then rendered as native UI on the client, especially in SwiftUI-based iOS apps; for example, an Uzori engine can emit a validated SwiftUI schema for a comparison table that the app renders without shipping new client code.

How server UI works on iOS (SwiftUI)

In a server-driven UI iOS architecture, the backend owns the description of the interface, while the app owns the rendering.

The core idea: the server sends data, not executable code, describing what the user should see and how they can interact with it.

A typical server UI flow for SwiftUI looks like this:

1. User intent
   The user takes an action: opens an AI concierge, starts a setup wizard, or asks a question.
2. Backend + AI decide the UI
   The app sends context (user request, session state, feature flags) to a backend service.
   That service may:
   • Call an LLM via tools like Vercel AI SDK.
   • Use OpenAPI-described endpoints to fetch data and actions.
   • Compose a server UI schema describing sections, components, and navigation.
3. Validated schema, not remote code
   The backend constructs a JSON (or similar) payload that is:
   • Validated against a schema known to both client and server.
   • Data-only, with no arbitrary scripts or executable code.
   • Versioned and logged for observability and rollbacks.
4. Native rendering in SwiftUI
   The iOS app receives the payload and renders it using native views:
   • Lists, forms, carousels, comparison tables.
   • Multi-step flows like wizards or configuration screens.
   • Navigation and state transitions defined by the schema.
5. Incremental updates & streaming
   For AI-driven flows, the server can stream partial schemas as they’re generated or refined.
   The SwiftUI view updates in place, producing an interactive, conversational UI.

Apple explicitly positions SwiftUI as a declarative, hierarchy-based framework that can be adopted incrementally alongside UIKit. That makes it a strong fit for server-driven UI iOS frameworks and tools that want to describe views as data and let the client render them natively.

Where Uzori fits in this pipeline

Uzori sits at the intersection of generative UI and server-driven UI for iOS.

With the Uzori iOS SDK:

• The app integrates a single SwiftUI screen that talks to Uzori’s engine.
• Uzori’s backend combines user intent, your OpenAPI-described APIs, and an LLM.
• The engine emits a validated schema for SwiftUI screens and flows.
• The SDK renders these screens natively and streams updates in real time.

The result: you get an AI-native interface layer that turns AI decisions into concrete SwiftUI views instead of long text answers.

For a deeper architectural walkthrough, see our related guide on server-driven patterns and AI: Server-driven UI for iOS: how to safely ship dynamic user interfaces with AI in the loop.

Why server UI matters for AI-native iOS apps

Server UI matters when you’re building AI assistants and dynamic user interfaces because it gives AI a safe, structured way to control what the user sees, without giving it free rein over the client.

Several trends make this pattern increasingly important:

• From chat to structured interfaces
  Teams are moving beyond generic chat boxes. Tools like Thesys OpenUI and CopilotKit focus on model-driven, interactive UI instead of plain text. Uzori applies the same idea to fully native SwiftUI.
• Backend contracts via OpenAPI
  The OpenAPI Initiative calls OpenAPI the world’s most widely used API description standard. Those machine-readable contracts make it natural to let AIs and backends safely orchestrate flows.
• Mature server-driven UI ecosystems
  DivKit, a cross-platform SDUI framework, has ~2.7k stars and more than 5,500 commits on GitHub. That level of activity underscores that server-driven UI is a stable, evolving pattern—not a fad.

For Uzori’s audience—SwiftUI-focused mobile teams—the payoff is straightforward:

• Compressed iteration cycles
  You can ship new AI flows, comparison views, and wizards without cutting fresh client builds.
• AI that feels native
  The assistant doesn’t just talk; it presents tappable, on-brand SwiftUI screens that match the rest of your app.
• Safety and control
  Every generated screen passes through a validated schema and a server-side approval step before it reaches users.

Best server-driven UI tools & frameworks for iOS (2026)

If you’re evaluating the best tools for server-driven UI iOS development and AI-native flows, this is the current landscape.

Uzori (SwiftUI, AI-native)

• Focus: AI-generated, server-driven SwiftUI screens for iOS.
• Fit: Product-led iOS teams adding AI concierges, explorers, and wizards.
• Strengths:
  • Single-screen SwiftUI integration.
  • Validated schema, server-side safety checks.
  • Streaming updates and tight SwiftUI alignment.

DivKit (open-source SDUI)

• GitHub: ~2.7k stars, 5,503 commits (as of 2026), multi-platform runtime.
• Focus: Classic server-driven UI—backend-authored layouts rendered natively on iOS, Android, Web.
• Fit: Teams that want a mature SDUI runtime without AI in the loop.

Vercel AI SDK + JSON / SwiftUI Instructor

• Focus: LLM orchestration and structured output.
• Fit: Custom pipelines where you:
  • Use Vercel AI SDK to call models.
  • Use tools like SwiftUI Instructor or JSON UI frameworks to coerce output into typed schemas.
  • Implement your own iOS renderer for those schemas.

Thesys OpenUI

• GitHub: OpenUI repo with ~9.9k stars and 689 forks.
• Focus: Generative UI API for multiple frontends—chat, apps, dashboards.
• Fit: Cross-surface AI products needing a shared generative UI backend.

CopilotKit

• GitHub: ~37.6k stars, 4.7k forks.
• Focus: Agent + UI infrastructure with shared state and human approvals.
• Fit: Web-heavy teams building complex agentic workflows; mobile integration is more custom.

Other JSON UI / server-driven UI libraries

• Pattern: JSON-based schemas mapped to UIKit/SwiftUI components.
• Fit: Teams that want server-driven flexibility without the AI layer.

These server-driven UI iOS frameworks and tools differ chiefly in how tightly they integrate with SwiftUI, how much of the AI pipeline they cover, and how opinionated they are about schema design and validation.

Uzori vs DivKit: feature, safety and integration comparison

Uzori and DivKit are often mentioned together as server-driven UI options, but they make different bets.

Integration and platform focus

• Uzori
  • SwiftUI-first, iOS-only.
  • Integrates as a single SwiftUI screen.
  • Designed for AI-native assistants and flows.
• DivKit
  • Cross-platform (iOS, Android, Web).
  • Typically integrated deeper into navigation and layout.
  • Designed for general-purpose SDUI without assuming AI.

Schema & validation model

• Uzori
  • Uses a validated schema optimized for SwiftUI components.
  • AI composes screens; server validates them before streaming.
  • Focus on AI safety and guardrails.
• DivKit
  • Server describes elements, states, and animations directly.
  • No built-in AI orchestration; you add AI on top if desired.
  • Strong for deterministic layouts and frequent content updates.

Streaming & generative UI

• Uzori
  • Built for streaming SwiftUI screens as the AI refines them.
  • Ideal when you want conversational, adaptive UX.
• DivKit
  • Focuses on delivering complete layouts.
  • Can be used with AI, but streaming generative UI is not its core story.

Open-source vs commercial

• Uzori
  • Commercial AI UI framework for SwiftUI.
  • You get a managed engine and opinionated integration path.
• DivKit
  • Open-source SDUI runtime.
  • You manage your own backend authoring and any AI orchestration.

If your priority is AI-native SwiftUI experiences with validated schemas and streaming, Uzori is the sharper tool. If your priority is broad SDUI coverage across platforms with full control over layout logic, DivKit is a strong open-source option.

How to generate native iOS UI from LLM responses

Many teams ask a specific question: how do you turn LLM responses into native iOS interfaces without sacrificing safety?

A practical pipeline looks like this:

1. Capture user intent
   The user describes a task: “Help me compare roaming plans,” “Show gowns under $300,” or “Guide me through device setup.”
2. Call the LLM with tools
   Use an orchestrator like Vercel AI SDK to call an LLM, passing:
   • User input.
   • Context from your backend.
   • The schema for allowed UI components.
3. Constrain output to a schema
   Use: The goal is to ensure the LLM emits data-only, schema-compliant UI descriptions.
   • JSON schema validation.
   • Swift-side helpers like SwiftUI Instructor or typed decoders.
   • Custom JSON UI frameworks that map schema nodes to SwiftUI views.
4. Validate server-side
   Run validations before the payload hits the client: Thesys OpenUI and similar platforms emphasize validation and correction as core features; Uzori follows the same principle.
   • Schema validation.
   • Business rules (no hidden actions, no unsafe endpoints).
   • Observability/logging.
5. Render with SwiftUI
   The client decodes the schema into native views, often using a generic renderer that:
   • Maps JSON node types to SwiftUI components.
   • Handles layout, navigation, and state transitions.
   • Supports incremental updates and streaming.
6. Iterate and A/B test
   Because the client renderer is generic, you can:
   • Swap out schema variants.
   • A/B test different flows.
   • Let AI adjust layouts based on user behavior, all without new app releases.

Uzori packages this entire pipeline into a focused AI UI framework SwiftUI teams can adopt with one screen. Other stacks (Vercel AI SDK + JSON UI frameworks + custom renderers) give you more raw control but demand more infrastructure.

Tool selection matrix: stability, performance, team fit

Here’s a qualitative view of how major tools compare for iOS AI UI prototyping frameworks and production use:

• Uzori
  • Stability: Managed, production-focused runtime.
  • Performance: Native SwiftUI; streaming optimized for iOS.
  • Docs & DX: Tailored to iOS engineers; one-screen integration.
  • Best for: Teams wanting the best AI UI SDK SwiftUI iOS experience with minimal glue code.
• DivKit
  • Stability: Mature SDUI library with active development (~2.7k stars, 5,503 commits).
  • Performance: Native rendering on iOS, Android, Web.
  • Docs & DX: Strong for SDUI, less prescriptive about AI.
  • Best for: Cross-platform SDUI without built-in AI orchestration.
• Vercel AI SDK + JSON UI / SwiftUI Instructor
  • Stability: Widely used for LLM apps; evolving fast.
  • Performance: Depends heavily on your backend and client renderer.
  • Docs & DX: Strong for backend/edge; you own iOS integration.
  • Best for: Teams comfortable building their own AI UI layer from primitives.
• Thesys OpenUI
  • Stability: Open-source with ~9.9k stars; focused on generative UI.
  • Performance: Designed for multi-surface, real-time interfaces.
  • Docs & DX: Broad, cross-front-end focus.
  • Best for: Companies running AI products across web, dashboards, and apps.
• CopilotKit
  • Stability: Large open-source footprint (~37.6k stars).
  • Performance: Optimized for agent + UI workflows on the web.
  • Docs & DX: Rich examples for web; mobile requires adaptation.
  • Best for: Agent-centric products with heavy web surfaces and custom mobile integrations.

Related terms and common confusions

Server UI is often conflated with a few adjacent concepts. Understanding the differences helps clarify when server-driven UI is the right tool.

Server UI vs classic chat UIs

• Classic chat UIs
  • The model returns text.
  • The user reads and manually translates that into actions.
• Server UI
  • The model (or backend) returns a validated schema for a screen.
  • The user interacts with native controls: buttons, pickers, forms, tables.

Uzori’s core belief is that AI as interface beats AI as a text-only assistant for complex product flows.

Server UI vs remote code execution

• Remote code execution
  • Ship scripts or code to the client and execute them there.
  • Hard to secure, audit, and reason about.
• Server UI
  • Ship data-only descriptions of layout and components.
  • Client renders them using pre-compiled native code.

Server-driven UI iOS frameworks lean heavily on this distinction to keep security and performance predictable.

Server UI vs traditional SDUI

In many contexts, "server UI" is just another way to say server-driven UI or SDUI. Classic SDUI meant humans authored layouts on the backend.

The generative turn (with LLMs) adds a twist:

• Traditional SDUI: Layouts are designed by humans, serialized as JSON, and rendered by the client.
• Generative UI + SDUI: An AI composes layouts, which are then validated server-side before rendering.

Uzori embodies this new hybrid: generative UI, server-driven safety.

Example: roaming plan concierge with Uzori

To ground the definition, here’s a concrete example of server UI in Uzori’s domain.

Imagine you’re shipping an AI-powered roaming protection concierge in your iOS app:

1. The user says, “I’m traveling to Spain for 10 days; suggest the best roaming option.”
2. The app sends this to your backend, which:
   • Calls an LLM via Vercel AI SDK.
   • Hits your pricing APIs (documented in OpenAPI).
   • Asks the model to propose a layout using your server UI schema.
3. The backend builds a validated schema for a SwiftUI screen that includes:
   • A comparison table of roaming plans.
   • A highlight card for the recommended option.
   • A stepper or date picker to adjust trip length.
   • A confirmation button wired to your purchase endpoint.
4. Uzori’s engine validates the schema and streams it to the app.
5. The Uzori SDK renders a native SwiftUI screen with these elements.

No new client code was shipped for this specific screen. The AI orchestrated the flow, the server enforced constraints, and SwiftUI delivered a polished, native experience.

That is server UI in practice: the backend—possibly with AI in the loop—describes the screen, and your iOS app turns that description into a real, safe, on-brand interface.