What Is Client-Approved UI?

Client-approved UI is a server-driven UI pattern where the iOS client validates and constrains any server- or AI‑proposed layout against a typed, platform-specific schema before rendering it, so only safe, supported SwiftUI screens ever reach the user.

In other words, the server (and any AI in the loop) can propose what the interface should look like, but the app itself decides whether that proposal is allowed to become real UI.

How Client-Approved UI Works

At a high level, client-approved UI is a contract between three parties:

• Your backend and AI layer, which propose screen structures.
• A shared schema, which defines what kinds of components and layouts are valid.
• The iOS client, which validates proposals against that schema and only renders what passes.

This mirrors how Apollo describes server-driven UI (SDUI): the client “handles pixels, not data,” mapping schema types to native components via a registry. It also echoes OpenAI’s Structured Outputs pattern, where models must adhere to developer-supplied JSON schemas.

1. The server (and AI) propose a screen

When a user asks your in-app assistant for help—say, “find me roaming protection for my trip to Spain”—your backend uses an LLM plus your business logic to generate a screen description.

That description might include:

• A vertical stack layout
• A header title and subtitle
• A list of roaming plan cards with prices and badges
• A call-to-action button to continue checkout

Crucially, this is not arbitrary code. It is data that claims to conform to a known schema, for example:

• Screen
• Section
• Card
• FormField
• Action

2. The schema defines what “valid” means

The schema is the heart of client-approved UI. It is a constrained model of everything the app is willing to render:

• Allowed view types (lists, carousels, forms, detail sections)
• Allowed properties and enums (e.g., style: .primary | .secondary)
• Limits on nesting and complexity
• Constraints for accessibility and platform fit

This is where you encode your design system and architectural rules. OpenAI reports that using structured outputs can take schema-following from under 40% to 100% on their benchmarks; the same idea applies here: you only trust screens that fit the contract.

3. The iOS client validates before rendering

When the Uzori iOS SDK receives a proposed screen, it:

1. Deserializes the payload into Swift types that mirror the schema.
2. Validates:
   • Is every required field present?
   • Are enums and component types recognized?
   • Does the layout respect depth and size limits?
3. Rejects or repairs anything that fails validation.

Only then does Uzori map the approved structure into real SwiftUI views via a component registry. If the proposal is invalid or suspicious, the SDK can:

• Fall back to a safe default screen
• Show an error state
• Log or report the issue for debugging

This approval step reflects the reality that only 29% of developers in Stack Overflow’s 2025 survey say they trust AI outputs to be accurate, while 46% actively distrust them. Client-approved UI bakes that skepticism into your runtime.

4. SwiftUI renders native, on-brand screens

Once validated, the structure composes into native SwiftUI:

• Screen(type: .wizard) → a navigation stack or tabbed flow
• ListSection(items: [Card, Card, …]) → List or ScrollView
• FormField(text, options) → TextField, Picker, toggles

Because the client controls this mapping, you keep:

• Your design tokens and brand styling
• Your existing navigation patterns
• SwiftUI’s accessibility fundamentals (labels, traits, Dynamic Type)

The result is a dynamic user interface that feels like your app, not someone else’s chatbot.

Why Client-Approved UI Matters for iOS AI Experiences

For Uzori’s audience—iOS engineering teams building AI-native features—client-approved UI solves three major problems: trust, iteration speed, and native quality.

Trusting AI without surrendering control

AI is now ubiquitous: 84% of developers use or plan to use AI tools, but trust has not kept pace. When only 3% “highly trust” AI outputs, shipping an AI that can arbitrarily change UI is a non-starter.

Client-approved UI gives you a safety rail:

• AI can be creative inside the schema.
• The app enforces non-negotiables: component types, data constraints, and layout limits.
• You can evolve the schema over time as your comfort increases.

This is “generative UI, server-driven safety” in practice.

Compressing UI iteration without app reviews

Apollo notes that SDUI shines in mobile precisely because app-store releases add friction. Firebase Remote Config and similar tools exist for the same reason: teams want to tune behavior and layout without shipping new binaries.

Client-approved UI lets you:

• A/B test assistant flows (wizards vs. carousels vs. comparison tables).
• Adjust component usage (more imagery on product explorers, more forms on configuration flows).
• Update copy, ordering, and grouping—all from the backend.

All of this happens within the schema your client understands, so you get speed without chaos.

For a deeper architectural walkthrough, see our guide on server-driven UI for iOS and safely shipping dynamic user interfaces with AI in the loop.

Preserving native SwiftUI quality

Apple’s Human Interface Guidelines emphasize consistency, accessibility, and respect for platform conventions. SwiftUI builds a lot of that in by default.

Because client-approved UI composes into your own SwiftUI components:

• Dynamic Type, Dark Mode, and adaptive layouts still work.
• Accessibility labels and traits live in familiar places.
• Performance matches your existing SwiftUI screens.

Unlike webview-based “AI UI” approaches, you’re not embedding a foreign surface; you’re orchestrating the UI you already know how to ship at scale.

Related Terms and How Client-Approved UI Differs

Client-approved UI sits at the intersection of several concepts and often gets conflated with them. They overlap, but they are not the same.

Client-approved UI vs. generic server-driven UI (SDUI)

Server-driven UI is a broader pattern: the server describes UI, and the client renders it. Many SDUI systems assume the server is trusted, human-authored, and relatively static.

Client-approved UI is a constrained SDUI variant tuned for AI and high-change environments:

• It assumes proposals may be wrong, incomplete, or adversarial.
• It emphasizes a strict validation gate on the client.
• It encodes AI-specific safeguards (depth limits, component whitelists).

Uzori positions itself here: generative UI that is always run through a client-approved, schema-validated contract.

Client-approved UI vs. AI chat interfaces

AI chat interfaces usually:

• Render unstructured text in a chat view.
• Rely on the user to parse, decide, and then take action elsewhere in the app.

Client-approved UI instead:

• Lets the AI respond with structured screens—lists, forms, wizards.
• Converts intent directly into operable UI instead of paragraphs.
• Keeps the conversational feel but upgrades the response to native interface.

If “AI as text” is an answer in a chat bubble, “AI as interface” is client-approved UI.

Client-approved UI vs. arbitrary remote code execution

Running arbitrary remote code (e.g., downloading and executing Swift or JavaScript) would give you maximum flexibility—and maximum risk.

Client-approved UI explicitly rejects that:

• No remote code, only data that maps into your shipped components.
• No arbitrary system calls, only actions routed through your existing APIs.
• No silent expansion of capability; new UI primitives require app updates.

This is how you stay inside the risk tolerance of modern iOS orgs while still giving AI room to orchestrate complex flows.

Example: Uzori’s Client-Approved UI in an AI Roaming Concierge

Consider an iOS team at a telecom startup adding an AI “roaming concierge” to its SwiftUI app. The goal: users can type “I’m going to Spain for 10 days, mostly using maps and messaging” and get a tailored roaming package, without reading a long AI answer.

Step 1: User asks for help

Inside a single SwiftUI screen backed by the Uzori SDK, the user types their travel plan into an input field. The app sends:

• The user’s query
• The user’s account and device data (through your backend)
• Your roaming offers and prices (via OpenAPI-described APIs)

Step 2: Backend and AI generate a proposed screen

Your backend calls Uzori’s engine, which uses an LLM to propose a SwiftUI-like structure:

• A summary card of the recommended plan
• A comparison table of three alternative plans
• A details section for “What’s included?”
• A primary button: “Activate for this trip”

The proposal is expressed in a data format that claims to match your client’s UI schema.

Step 3: Uzori enforces client-approved boundaries

The Uzori iOS SDK receives the proposal and validates it:

• All view types must be known (Card, ComparisonRow, Button).
• Text lengths must respect limits you’ve set.
• Certain disclaimers must appear when roaming is activated.

If anything violates the schema or rules—say the AI tries to invent a new SuperPromoBanner type—the SDK rejects or downgrades that element before construction.

Step 4: SwiftUI renders the approved interface

Only the approved subset of the proposal is mapped into actual SwiftUI views:

• Your existing PlanCardView for cards
• Your ComparisonTableView for the plan matrix
• Your PrimaryButtonStyle for the call-to-action

To the user, it feels like the app instantly designed a custom flow for their trip. To your team, it’s just Uzori using client-approved UI to turn AI intent into safe, on-brand SwiftUI screens.

This same pattern applies to:

• Product discovery in ecommerce (gowns, dresses, accessories)
• Multi-step configuration flows (insurance coverage, device protection)
• Concierge-style helpers (onboarding, account optimization)

In each case, the AI proposes; the iOS client approves; SwiftUI does the rest.

Client-approved UI is the missing layer between powerful generative models and production-grade iOS apps. It lets you explore “an interface that builds itself” while keeping structure, safety, and native quality firmly under your control.