“Does It Train On Our Data?” — How Server‑Driven UI, Client‑Driven Screens, and Uzori Shape AI-Native iOS Apps

Introduction: Why “Does It Train On Our Data?” Comes First

For any iOS team shipping AI features, the first stakeholder question is almost always:

Does this train on our data?

That question isn’t just about model providers like OpenAI and Anthropic.

It now applies to AI UI platforms, server‑driven UI frameworks, and any SDK that touches user behavior, content, or payments.

In this article, we compare:

• Conventional client‑driven screen development (pure SwiftUI/UIKit)
• Server‑driven UI (SDUI) frameworks (DivKit, Nativeblocks, Firebase Remote Config, etc.)
• AI‑native interface platforms like Uzori that generate SwiftUI screens from LLM output

We’ll focus on three lenses:

• Release cadence
• Experimentation velocity
• Data privacy & “does it train on our data?”

By the end, you’ll have a clear recommendation for the most common iOS use cases, including AI concierges and dynamic flows.

TL;DR: How the Options Compare

Here’s the high‑level comparison before we dive into details.

| Approach | Release cadence | Experimentation velocity | UX polish | AI integration | Data training risk | |---------|-----------------|--------------------------|----------|----------------|--------------------| | Client‑driven SwiftUI | Tied to App Store releases and review | Moderate; feature flags and config help but still build‑bound | Highest; full control, native-first | Manual; you wire LLM responses into UI | Lowest; you choose what to send to models | | Traditional SDUI frameworks | Very fast; UI can update hourly or faster without releases | High; ideal for A/B tests and incremental rollout | Good, but can lag client‑driven for delight | Limited; SDUI itself is not “intelligent” | Moderate; depends on how remote config and logging work | | AI‑native platforms like Uzori | Fast; generative UI and SDUI converge for streaming updates | Very high; AI composes flows from schemas and APIs | High if output is constrained to native components | Deep; AI orchestrates tasks, not just text output | Depends on platform policy; structure enables privacy‑by‑design |

For many teams, the right answer is a hybrid: core navigation and critical flows client‑driven, plus server‑driven + AI‑native layers where iteration and personalization matter most.

Uzori lives in that hybrid zone: it uses generative UI with server‑side validation to stream SwiftUI screens, while keeping everything native and schema‑constrained.

Client‑Driven Screens: Control, Craft, and Slow Iteration

What is client‑driven UI?

Client‑driven UI means:

• Your app’s screens are fully defined in SwiftUI or UIKit.
• Layout, navigation, and interaction live in the app binary.
• Changes require new builds and App Store review.

Apple’s direction with SwiftUI emphasizes:

• Declarative native views
• Fast previews in Xcode
• Tight integration with on‑device and Private Cloud Compute AI

All of that benefits polish—but comes at a cost.

Release cadence and operational friction

Client‑driven UI is bound to your release pipeline.

• Spotify reports a weekly release cadence to 675M+ users worldwide.
• Apple says 90% of App Store submissions are reviewed in <24 hours, but 40% of unresolved issues involve app completeness.

Every additional UI change means:

• Updated screenshots, release notes
• Cross‑team coordination
• Risk of review delays and rollback

For high‑risk flows like transaction disputes (e.g. “Where did my money go?”), that friction matters.

You want to iterate wording, steps, and states—but you might only ship changes weekly.

Our pillar guide, “Where did my money go? — a transaction dispute is a four‑step status answer”, dives deep into how those status flows should work; here, we focus on how fast you can change them.

Experimentation velocity

Client‑driven apps can still experiment, but:

• Feature flags and remote config tune behavior, not full layouts.
• A/B tests often require new builds for each variant.

Spotify’s experimentation approach stresses balancing velocity and quality—fast tests are meaningless if noisy.

With client‑driven UI, it’s easy to keep quality high, but velocity is limited by release cadence.

Data privacy and “does it train on our data?”

With client‑driven UI:

• You control exactly what data is sent to LLM APIs.
• You choose providers with strong defaults (e.g. OpenAI’s API data is not used for training by default, logs kept up to 30 days, optional zero‑retention).

The risk is mostly about your backend and logging, not the UI layer.

If your AI feature is a simple chat or a structured dispute flow, this is the most conservative option.

Server‑Driven UI: Release Speed and Config Power

What is server‑driven UI on iOS?

Server‑driven UI (SDUI) frameworks like DivKit and Nativeblocks:

• Let the backend describe screens via JSON/DSL.
• Render those descriptions as native SwiftUI/Compose.
• Ship layout changes without new app releases.

DivKit explicitly claims UI can update “every hour or more often”.

Meta’s MobileConfig shows the same pattern at massive scale:

• Configuration changes reach billions of devices without app updates.
• Used for A/B testing, feature rollout, and personalization.

Release cadence and experimentation velocity

With SDUI:

• You can tweak layouts, copy, and component visibility server‑side.
• You can run experiments in production without touching the client.

This is perfect for flows like a transaction dispute wizard:

• Step 1: identify the charge
• Step 2: show status definition
• Step 3: collect evidence
• Step 4: confirm and track

Instead of shipping four variants via App Store, SDUI lets you:

• Test different copy for “status answers”
• Reorder steps for lower support burden
• Add contextual hints for high‑risk merchants

All of this fits the “Where did my money go?” pattern, but with a much faster loop.

UX polish and interactivity

Meta’s engineers noted a tradeoff:

• Server‑driven architecture can improve startup speed.
• But they were “not convinced” it would match client‑driven apps for interactivity and delight.

SDUI is powerful, but if you push everything into JSON:

• Complex gesture handling, animations, and custom components can feel constrained.
• Accessibility and performance must be carefully engineered in the renderer.

For premium iOS products, the answer is usually a hybrid:

• Client‑driven shell for core navigation and high‑touch surfaces.
• SDUI for configurable blocks, experiments, and long‑tail flows.

Data privacy and training implications

Traditional SDUI frameworks typically don’t involve LLMs directly.

The main privacy questions become:

• What analytics/logging do you collect about layouts and interactions?
• Do any of these logs feed back into ML models for personalization?

These are usually internal data governance questions, not public model‑training issues.

When you start combining SDUI with AI—e.g. letting a model choose which template to show—you re‑enter the “does it train on our data?” territory.

AI‑Native Interface Platforms: Generative UI + Server‑Driven Safety

What is an AI‑native UI platform?

Platforms like Uzori sit at the intersection of:

• Generative UI (using AI to compose screens)
• Server‑driven UI (backend‑controlled layouts)

Uzori’s iOS SDK does this by:

• Receiving a user request in your app
• Combining it with your backend APIs (often described via OpenAPI)
• Having an AI agent propose SwiftUI screen definitions
• Validating them server‑side against a constrained schema
• Streaming the validated screens directly into the running app

You integrate one SwiftUI screen, and Uzori handles:

• Wizards
• Comparison views
• Product explorers
• AI concierges for complex plans (e.g. roaming protection or dispute assistance)

How this changes release cadence and experimentation

Uzori effectively compresses weeks of UI iteration into live, AI‑composed interfaces.

• Like SDUI, changes can happen without App Store releases.
• Unlike traditional SDUI, layouts are AI‑composed, not hand‑authored JSON.

This dramatically increases experimentation velocity:

• You can test entirely different flow structures for “Where did my money go?”—without redesigning each state manually.
• The AI can adapt the interface to user intent in real time, picking the right components from your design system.

As the industry moves toward agent‑driven interfaces, Google’s A2UI sets a precedent:

• Agents generate contextual interfaces as secure messages, not executable code.

Uzori mirrors that principle for SwiftUI:

• AI proposes views.
• Your server validates them.

UX polish, stability, and native feel

An AI‑native UI layer can easily become chaotic if not constrained.

Uzori’s stance aligns with “structure over chaos”:

• Screens are composed from a typed, server‑approved SwiftUI schema.
• No arbitrary JavaScript or remote code execution.
• Output uses your native components, respecting platform conventions.

This addresses Meta’s concern around interactivity and delight:

• Rendering is still fully native.
• The “intelligence” exists in the composition, not in bypassing your renderer.

In 2026, stability and reliability for AI UI tools comes from this combination:

• Native renderers for performance and accessibility.
• Constrained schemas for safety.
• Server‑side validation to ensure generated UI is on‑brand and correct.

The big question: “Does it train on our data?” for Uzori and peers

For AI‑native platforms, the privacy question becomes explicit.

Teams ask:

• Does Uzori train on our data?
• Does the SDK send user data to train models?
• Is there a clear Uzori data privacy policy?

As of August 2026:

• Public web search returns no indexed Uzori privacy or training policy. The only visible page is a reserved‑domain notice.
• There’s no public evidence that Uzori does or does not train on customer data.

So when evaluating Uzori—or any similar SwiftUI AI SDK—you should:

1. Request a written data policy
   • Ask whether API/SDK data is used for training by default.
   • Ask about retention windows and deletion.
2. Look for familiar enterprise patterns
   • OpenAI’s API data is not used to train models by default; logs kept up to 30 days, with zero‑retention options.
   • Anthropic’s commercial terms similarly restrict training on customer content.
3. Ask about deployment options
   • Do they support on‑premise inference or private cloud?
   • Can data stay in your VPC while models run via secure messages like A2UI?
4. Check architectural boundaries
   • Are generated screens validated by your server before hitting devices?
   • Is sensitive data (e.g. identity, transactions) summarized before entering prompts?

Uzori’s architecture (generative UI + server‑side validation) is inherently compatible with privacy‑by‑design, especially if paired with:

• On‑device AI (Core ML/Core AI)
• Private Cloud Compute patterns, where requests are not stored and only used to fulfill the interaction

But until there’s a published Uzori data privacy policy, enterprises should treat this as an architectural opportunity, not a solved compliance story.

Uzori vs DivKit vs Client‑Driven Screens: Practical Comparison

Criteria that matter for iOS teams

When comparing Uzori vs DivKit vs pure SwiftUI, most teams care about:

• Release cadence: How often can we change UI without an App Store release?
• Experimentation velocity: How fast can we run safe experiments?
• UX polish: Does it feel like a first‑class iOS app?
• AI depth: Is AI just a chatbot, or can it orchestrate flows?
• Data privacy & training: What data leaves our stack, and how is it used?

Side‑by‑side: Uzori vs DivKit vs client‑driven

1. Release cadence
   • Client‑driven SwiftUI: Bound to release pipeline and App Store review.
   • DivKit / Nativeblocks (SDUI): Can update screens hourly or faster without releases.
   • Uzori: Similar SDUI benefits, plus AI‑driven layout changes under server approval.
2. Experimentation velocity
   • Client‑driven: Moderate; feature flags help, but layout changes require builds.
   • SDUI: High; configuration and templates support rapid A/B tests.
   • Uzori: Very high; AI composes new flows against your schema, enabling interface‑first experiments.
3. UX polish and native feel
   • Client‑driven: Highest; direct SwiftUI control.
   • SDUI: Good; renderer quality and design discipline matter.
   • Uzori: High; SwiftUI output constrained to your components and validated server‑side.
4. AI depth
   • Client‑driven: You wire prompts and responses manually into your UI.
   • SDUI: Not inherently AI; mostly configuration and templates.
   • Uzori: AI becomes the interface layer, orchestrating flows and state.
5. Data privacy & training risk
   • Client‑driven: Lowest; you control all calls to AI providers; use OpenAI‑style non‑training defaults.
   • SDUI: Moderate; depends on analytics and personalization models.
   • Uzori: Depends on Uzori’s policy; architecture supports strong safeguards, but you must confirm training and retention directly.

Here’s how these approaches stack up on release vs experimentation using public benchmarks.

Server-driven and AI-native UI layers dramatically reduce dependency on App Store releases, shifting iteration from weekly builds to near-real-time configuration and AI-composed layouts.

Recommendations by Use Case

1. Critical compliance flows (e.g. KYC, transaction disputes)

Examples:

• “Where did my money go?” dispute flows
• Identity verification
• Regulatory consent screens

Recommended stack:

• Client‑driven SwiftUI for the core shell and critical steps.
• SDUI or Uzori only for non‑critical variants (tooltips, education, help overlays).

Privacy stance:

• Keep sensitive data in tightly controlled APIs.
• Use AI mainly for explanations and guidance, not decisions.

2. Product discovery and personalization

Examples:

• Gown selectors, roaming plan explorers, bundled offers.
• Personalized home screens and recommendation carousels.

Recommended stack:

• Uzori or similar AI‑native interface layer to generate:
  • Dynamic carousels
  • Comparison tables
  • Multi‑step wizards
• SDUI as a fallback/guardrail for minimum viable layouts.

Privacy stance:

• Ask explicitly: “Does this AI UI platform train on our data?”
• Prefer providers with non‑training defaults and short retention windows.

3. AI concierges and in‑app assistants

Examples:

• Help me configure roaming protection.
• Help me understand a confusing transaction.

Recommended stack:

• Uzori‑style SwiftUI AI SDK with:
  • Constrained, server‑validated schemas.
  • Connection to your backend via OpenAPI.
• Client‑driven entry points and escalations (e.g. “talk to human”).

Privacy stance:

• Combine on‑device AI where possible with Private Cloud Compute style patterns.
• Ensure any remote inference follows OpenAI/Anthropic‑style non‑training defaults.

Actionable Checklist: Questions to Ask Any AI iOS SDK Vendor

Before you integrate an AI UI SDK (Uzori or otherwise), ask:

1. Training and retention
   • Is API/SDK data used to train models by default?
   • What is the retention period for logs and prompts?
   • Is there a zero‑data‑retention option?
2. Architecture and validation
   • Are generated screens validated server‑side before rendering?
   • Is UI described as declarative messages, not executable code?
3. Deployment options
   • Can we run models on‑premise or in a private cloud?
   • How does the SDK integrate with Core ML/Core AI and on‑device inference?
4. Data boundaries
   • What data fields never leave the device?
   • Can we redact or summarize sensitive content before prompts?
5. Compliance and documentation
   • Is there a published data privacy policy?
   • Do you provide DPA / SOC2 / ISO documentation if required?

For Uzori specifically, today’s public web footprint doesn’t answer these questions.

Treat that as a prompt to engage directly with the team, not a blocker—especially if you’re piloting in a sandboxed feature flag.

FAQ: Server‑Driven, AI‑Native UI, and Data Training

Does Uzori train on our data?

Publicly indexed sources as of August 2026 do not provide a clear answer.

There is no visible Uzori data privacy policy or training statement, so you should request one directly and confirm whether your data is used for training and for how long it’s retained.

Does the Uzori SDK send user data to train models?

The SDK’s architectural role is to connect user intent and your backend APIs to an AI engine that generates SwiftUI screens.

Whether that data is used for training depends on Uzori’s underlying model providers and policies; ask specifically about training defaults, retention windows, and opt‑out mechanisms.

How is server‑driven UI different from client‑driven SwiftUI on iOS?

Client‑driven SwiftUI defines screens in code and requires App Store releases for changes.

Server‑driven UI lets the backend describe screens (JSON/DSL) and render them natively, enabling frequent UI updates and experimentation without new builds.

Are AI‑native interface platforms production‑ready in 2026?

Yes, when they follow patterns similar to Google’s A2UI and modern SDUI frameworks:

• Declarative, constrained UI schemas
• Server‑side validation of generated interfaces
• Native rendering (SwiftUI) for performance and accessibility

Uzori positions itself in this production‑ready lane, but you should still validate latency, failure modes, and privacy.

When should I avoid AI‑generated UI altogether?

Avoid AI‑generated UI for:

• Legally critical consent flows
• Security‑sensitive steps (password reset, MFA enrollment)
• Flows where every pixel must be audited (e.g., regulatory disclosures)

Use AI to augment these experiences (guidance, explanations) while keeping the core screens client‑driven and fully deterministic.

For a deeper look at how status‑driven transaction dispute flows should work in practice, read our related guide: “Where did my money go? — a transaction dispute is a four‑step status answer.”

Then, decide which parts of that flow should be client‑driven, which can be server‑driven, and where an AI‑native interface layer like Uzori can safely accelerate iteration.