What is Uzori? An In‑App AI Assistant for Native iOS Apps (And How It Handles div + img vs background‑image Layouts)

Uzori is a developer‑focused platform that turns AI answers into fully native SwiftUI interfaces, streamed directly into your iOS app.

Instead of another chat box, Uzori acts as an in‑app AI assistant that responds with real SwiftUI screens – lists, forms, carousels, multi‑step flows – all validated on your server.

This article explains:

• What Uzori is and how the Uzori iOS SDK works
• How Uzori fits into AI UI and server‑driven UI (SDUI)
• How classic web patterns (like div + img vs background-image) translate into Uzori’s native media layouts
• When to prefer image‑like content vs background‑like content in AI‑generated UI

We’ll end with a comparison table and practical recommendations for iOS teams.

This piece complements the broader pillar article: “What are my options now? — rebooking, refunds and the shape of a disruption answer”, which dives into how AI‑generated flows should be structured. Here we focus specifically on media layouts in native, AI‑driven UI.

What Is Uzori? From AI Answer to SwiftUI Screen

Uzori is an AI interface layer for iOS.

Instead of returning paragraphs of text, Uzori’s engine returns SwiftUI view descriptions that your app renders natively:

• The AI agent receives the user’s request plus your backend APIs (usually via OpenAPI).
• It composes a SwiftUI screen schema – a typed layout description.
• Your server validates that schema for safety and correctness.
• The Uzori iOS SDK streams the resulting views live into your app.

Uzori is not a design tool or code generator; it’s a runtime SDK:

• Uzori iOS SDK (SwiftUI) integrates as a single screen.
• That screen can become many flows – concierges, product explorers, configuration wizards.
• Every screen feels native: SwiftUI, platform conventions, accessibility, performance.

Why iOS Teams Use Uzori

Modern iOS orgs are under pressure to ship AI features, but chat UIs feel bolted‑on.

Uzori solves several recurring pain points:

• Turning LLM text into real, shippable UI is slow and brittle.
• Pure chat interfaces don’t match the richness of the main app.
• Hand‑building every AI flow is expensive and hard to iterate on.
• Pure SDUI systems are structured but not intelligent; pure LLM UIs are flexible but unsafe.

Uzori combines:

• Generative UI (AI composes the layout)
• Server‑driven UI (your server validates schemas)
• Native SwiftUI (fully on‑platform, no web views)

Uzori vs Traditional Server‑Driven UI (DivKit, JSON Layouts)

If you’ve used SDUI frameworks like DivKit, you already understand part of Uzori’s story.

DivKit:

• Uses JSON to describe layouts.
• Renders native views across iOS, Android, and web.
• Is great for changing layouts without shipping a new app version.

Uzori builds on that pattern but adds AI composition and iOS‑first focus.

Uzori vs DivKit at a Glance

• Platform scope
  • DivKit: cross‑platform (iOS, Android, Web)
  • Uzori: SwiftUI‑native iOS only
• Layout authoring
  • DivKit: humans design JSON layouts and templates.
  • Uzori: AI composes SwiftUI screens based on user intent and backend data.
• Safety & validation
  • Both use server‑driven contracts.
  • Uzori emphasizes LLM output validation – no arbitrary remote code.
• Use cases
  • DivKit: broad SDUI, marketing layouts, generic product pages.
  • Uzori: AI concierges, guided flows, task‑specific assistants inside iOS apps.

Uzori sits at the intersection of generative UI and SDUI, designed for teams who want AI‑native experiences without leaving SwiftUI.

Why Trust and Structure Matter for AI UI

The broader developer ecosystem is already embracing AI – but with reservations.

From Stack Overflow’s 2025 survey (49,019 devs, 177 countries):

• 84% use or plan to use AI tools in development.
• 46% don’t trust AI output.
• 75.3% say they don’t trust AI answers outright.

Yet among AI agent users:

• 69% report increased productivity.
• ~70% say agents reduce time spent on specific tasks.

Most developers use AI tools today, but nearly half still don’t trust AI output without safeguards.

This tension is exactly why Uzori insists on:

• Typed schemas – SwiftUI layout descriptions in a constrained contract.
• Server‑side validation – your backend approves every screen.
• Native rendering – SwiftUI handles accessibility, interaction, and performance.

You get the upside of generative UI, without shipping raw LLM output to production.

How Uzori Handles Media Layouts: Div + img vs background‑image in Native Terms

On the web, teams often debate:

• Should I use an <img> tag inside a <div>?
• Or should I apply background-image via CSS on a container?

In Uzori and SwiftUI, you don’t literally use div or img.

But the same design decisions apply:

• Is this media content or decoration?
• Should it be accessible and responsive?
• Will AI or the server reflow it dynamically?

The Web Patterns, Quickly Recapped

<img> inside <div> is best when:

• The image is primary content (product photo, illustration, chart).
• You need alt text and screen‑reader support.
• You care about intrinsic sizing and responsive behaviors.

CSS background-image on a container is best when:

• The media is decorative (hero background, texture, overlay).
• You need flexible cropping (background-size: cover) and layering.
• You don’t want it announced as content to assistive tech.

Translating Those Choices to Uzori SwiftUI

Uzori’s generative UI schema needs to encode the same distinction:

• Content images map to SwiftUI’s Image or media components.
• Background visuals map to container styling, overlays, or Z‑stacks.

For AI‑generated UI and server‑driven layouts, that impacts:

• Accessibility: whether the assistant treats an asset as semantic content.
• Responsiveness: how screens adapt across device sizes and orientations.
• SDUI compatibility: how easily your backend can swap media without breaking UX.

Uzori’s schema expresses this difference explicitly, so the AI knows when to render a media view vs a background effect.

Accessibility: When Media Must Behave Like <img>

For accessible AI experiences, anything the user should understand or act on should be modeled like an <img>:

• Product images
• Step illustrations in wizards
• Diagrams or charts
• Thumbnails in carousels or comparison views

Uzori’s SwiftUI‑first approach leans on Apple’s accessibility guidance:

• SwiftUI provides default labels and values for common controls.
• You can add accessibilityLabel, accessibilityHint, and traits.

In Uzori’s schema, that means:

• The AI marks content images with metadata that can become alt‑like labels.
• Your server can enforce that certain components must carry accessibility text.

For production‑ready AI UI in 2026, treat content media as:

• Independent views with semantic meaning.
• Objects that the AI assistant can reference in explanations and flows.

This is the native equivalent of div + img with proper alt attributes.

Decorative Visuals: When Media Should Behave Like background-image

Not all visuals need to be content.

Hero gradients, subtle textures, and decorative illustrations often:

• Don’t carry independent meaning.
• Shouldn’t be read aloud by VoiceOver.
• Exist to support branding and mood.

In Uzori, you treat these as background‑style media:

• Applied to containers, stacks, or layout shells.
• Often ignored by accessibility APIs, or marked as decorative.
• Swapped or tuned by the AI without changing the flow’s semantics.

For AI‑generated interfaces, that distinction matters because:

• The assistant can remix layouts without confusing users.
• Your server can validate that decorative changes are safe.

This is the native equivalent of background-image in CSS.

Responsiveness and Server‑Driven Layouts: Why the Distinction Matters

Server‑driven or AI‑generated UI systems must work on many device sizes.

For iOS, you care about:

• iPhone SE vs Pro Max
• Portrait vs landscape
• iPad split‑screen

If you blur the line between content media and background media:

• Content images may get cropped or hidden like decorative backgrounds.
• Background visuals may get announced like primary content.

Uzori’s schema prevents that by modeling media with clear roles:

• Content image components (analogous to img in a div) get layout rules tuned for clarity and legibility.
• Background visuals (analogous to CSS backgrounds) get layout rules tuned for cover, emphasis, and tone.

This helps the AI:

• Generate responsive screens that feel intentional.
• Avoid layout bugs when streaming UI in real time.

Comparing Approaches: <img> vs background-image vs Uzori Media Components

Here’s how the classic web choices map to Uzori’s generative SwiftUI model.

| Criteria | div + img (Web) | background-image (Web) | Uzori SwiftUI Content Media | Uzori SwiftUI Background Media | |----------------------------------|----------------------------------------------|---------------------------------------------|--------------------------------------------|----------------------------------------------| | Primary use | Content images (photos, charts) | Decorative visuals (textures, hero art) | Product photos, thumbnails, diagrams | Hero shells, decorative illustrations | | Accessibility | Alt text; announced to screen readers | Usually decorative; not announced | Uses SwiftUI accessibility labels & hints | Marked decorative or ignored | | Responsiveness | Intrinsic sizing; flexible containers | Cropped via cover or contain | Layout rules tuned for clarity & legibility| Layout rules tuned for emphasis & tone | | Interaction | Clickable, focusable | Rarely interactive | Tap targets, carousels, detail views | Mostly non‑interactive | | Authoring | HTML + CSS; hand‑written | CSS; usually design‑driven | Generated by AI from backend data | Generated by AI as container styling | | SDUI / AI impact | Hard to express in JSON layouts | Even harder to encode semantics | Explicit in Uzori schema; server‑validated | Explicit in Uzori schema; server‑validated |

For production‑ready AI iOS interface tools in 2026, you want a system like Uzori that:

• Understands the difference between content images and decorative backgrounds.
• Lets AI compose both, but keeps them inside a safe, typed, server‑approved schema.

When Should iOS Teams Use Uzori for AI‑Native Interfaces?

If your current plan is to embed a generic chat box, it’s worth re‑evaluating.

Uzori is a better fit when:

• You need AI concierges that feel like part of your app (roaming protection planners, booking or disruption flows, product finders).
• You want to turn LLM responses into SwiftUI screens, not just text.
• You prefer server‑driven safety over free‑form UI generation.

Examples of flows Uzori can generate:

• Disruption answers: structured options for rebooking and refunds, instead of a long explanation. (See our pillar article on “What are my options now?” for the shape of those answers.)
• Product discovery: galleries of gowns with div‑like image tiles and rich detail screens.
• Configuration wizards: multi‑step forms with clear content images and minimal background decoration.

For iOS teams evaluating the best tools to turn LLM responses into native iOS interfaces, Uzori’s strengths are:

• One screen to integrate, infinite flows to explore.
• Native SwiftUI rendering with App Intents and future Apple Intelligence integrations in mind.
• A balance of generative UI and server‑driven UI that keeps AI under control.

Recommendation: How to Model Media in AI‑Generated iOS UI

To wrap it up, here’s a practical decision guide.

Use Uzori content media components (like div + img) when:

• The image is part of the core answer or task.
• You’d otherwise provide alt text or caption.
• The user might tap it, zoom it, or compare it.

Use Uzori background media components (like background-image) when:

• The visual is decorative or purely brand‑driven.
• Cropping and cover behavior matter more than the full asset.
• You don’t want assistive technologies to treat it as content.

Let the AI decide the layout and flow, but ensure:

• Your schema encodes this distinction.
• Your server validates every generated screen.

That’s the core of Uzori’s POV: AI UX shouldn’t be a chat box pasted on your app; it should be your app’s interface – including how content and background media are rendered.

FAQ: Uzori, SwiftUI AI SDKs, and Media Layouts

1. What is Uzori in one sentence?

Uzori is a SwiftUI‑native iOS SDK that turns AI answers into server‑validated, generative UI screens streamed directly into your app.

2. How is Uzori different from DivKit and other server‑driven UI frameworks?

Uzori is AI‑first and iOS‑only: it uses an LLM to compose SwiftUI layouts inside a constrained schema, then validates those screens on your server, while DivKit and similar tools focus on human‑authored JSON layouts across multiple platforms.

3. Can Uzori replace a chat‑style AI interface in my app?

Yes. Uzori is designed specifically for non‑chat AI interfaces, where the AI responds with screens, flows, and actions instead of paragraphs of text, so users interact with native controls instead of reading long chat messages.

4. How does Uzori handle images, videos, and other media compared to web div + img layouts?

Uzori’s schema distinguishes between content media components (analogous to img inside a div) and background media components (analogous to CSS background-image), which helps the AI assistant generate accessible, responsive layouts while your server enforces safety.

5. What’s the integration cost of the Uzori iOS SDK?

Uzori is designed as a single‑screen integration: you drop in one SwiftUI view that connects to Uzori’s engine and your backend, and from there the AI can orchestrate many flows (concierges, product explorers, disruption answers) without additional client‑side layout code.