Uzori vs DivKit: div-based media layouts vs SwiftUI‑native AI screens

Uzori is the better fit when you want AI to generate native SwiftUI screens in real time on iOS. DivKit is the better fit when you want deterministic…

Arc of sand tracing a path across a concrete plaza, symbolizing diverging paths between Uzori and DivKit.

Uzori is the better fit when you want AI to generate native SwiftUI screens in real time on iOS. DivKit is the better fit when you want deterministic, cross‑platform server‑driven media layouts defined as JSON.

If your primary question is:

  • "How do I turn LLM responses into real, tappable iOS UI?" → Start with Uzori.
  • "How do I render the same JSON media layout on iOS, Android, and Web?" → Start with DivKit.

This article dives into Uzori vs DivKit specifically for text, image, and video layouts generated by AI, and how each behaves as a UI framework for media‑heavy flows.

The criteria: how should you compare Uzori vs DivKit?

For iOS teams evaluating AI UI frameworks or server‑driven UI tools, these criteria actually decide the choice:

  1. Media primitives & expressiveness – Text, image, and video capabilities.
  2. AI integration model – How LLM responses turn into UI.
  3. Streaming & adaptivity – Whether the interface can update as the AI answers.
  4. Platform scope & native feel – iOS‑first vs cross‑platform JSON rendering.
  5. Safety & structure – Typed contracts, validation, and control over layouts.
  6. Integration cost & developer ergonomics – How much code and plumbing you own.
  7. Best‑fit use cases – Where each clearly wins.

We’ll walk each criterion with a dedicated section, then close with use‑case‑based recommendations and alternatives.

Comparison overview: Uzori vs DivKit

| Criterion | DivKit (div‑based JSON layouts) | Uzori (SwiftUI‑native AI screens) | Practical takeaway |
|---|---|---|---|
| Media primitives & expressiveness | Mature JSON DSL for text, images, video; rich properties and formats. | Media lives inside generated SwiftUI screens; no public separate media DSL yet. | DivKit wins for generic, reusable media cards; Uzori wins when media is part of a larger AI‑composed flow. |
| AI integration model | Backend sends JSON; AI can generate JSON, but DivKit itself is not AI‑native. | Designed as an AI interface layer: LLM + tools generate SwiftUI screens directly. | Uzori is built for "answer becomes UI"; DivKit is a strong renderer if you supply JSON from elsewhere. |
| Streaming & adaptivity | Supports JSON patches, states, and additional loading; not focused on conversational streaming. | Explicitly streams SwiftUI interfaces progressively as the answer generates. | Uzori wins for conversational, streaming AI UX; DivKit for conventional SDUI updates. |
| Platform scope & native feel | Cross‑platform: iOS, Android, Web; JSON renders on all clients. | iOS‑only SDK, SwiftUI‑native, tightly integrated with platform patterns. | DivKit wins for shared cross‑platform contracts; Uzori wins when iOS is the primary surface and quality bar. |
| Safety & structure | Strong SDUI model: templates, states, variables; deterministic layouts. | Typed, allowlisted SwiftUI schema validated server‑side before display. | DivKit excels at predictable layout delivery; Uzori excels at keeping generative UI safe in an AI context. |
| Integration cost & ergonomics | Embed a single DivView; feed it JSON; can start with local JSON. ~2.7k GitHub stars and 5+ years of production use. | Single SwiftUI screen integration; tie to existing APIs via typed tools and OpenAPI. | Both are relatively light to integrate; DivKit is simpler for pure SDUI, Uzori is simpler for AI concierges. |
| Best‑fit use cases | Promo cards, media carousels, cross‑platform content layouts, feature flags. | AI concierge, product discovery, configuration flows, streaming task‑specific screens. | DivKit for layout delivery; Uzori for interface generation. |

1) Media primitives & expressiveness (text, image, video)

How DivKit handles text

DivKit’s div‑based JSON model is built around deterministic media primitives. For text, the docs show:

  • Font size and weight controls.
  • Gradients and per‑range color overrides.
  • Line height, max lines, and truncation behavior.
  • Rich text ranges for styling parts of a string.

This makes DivKit very strong for generic SDUI text layouts:

  • Marketing cards.
  • Promo banners.
  • Multi‑line descriptions with precise truncation.

When you send JSON to the client, you know exactly how the text will behave.

How Uzori handles text

Uzori doesn’t expose a public, separate "text DSL." Instead, text is part of the generated SwiftUI hierarchy:

  • The AI generates screens using Uzori’s SwiftUI contract.
  • Text sits inside native controls—Text, Label, forms, lists, detail views.
  • Layout rules come from your design system and SwiftUI, not a standalone JSON spec.

For iOS engineers, this matters when text is just one part of a rich flow:

  • An AI concierge explaining options while showing controls.
  • Multi‑step wizards where text is tied to state, validation, and actions.
  • Comparison views where copy sits alongside tappable cards and filters.

Uzori’s strength is not tuning every text gradient via JSON; it’s orchestrating text inside native flows.

DivKit vs Uzori for text

  • DivKit wins when you need pixel‑precise, repeatable text layouts as JSON, shared across iOS, Android, and Web.
  • Uzori wins when text should be contextual narrative inside an AI‑generated SwiftUI flow that users can act on immediately.

2) Image layouts: div‑based JSON vs SwiftUI‑native media flows

DivKit’s image layout JSON

DivKit’s image primitive is one of its strongest points for media‑heavy SDUI:

  • URLs to remote assets.
  • Placeholders and preview images.
  • wrap_content sizing and scaling options.
  • Support for PNG, JPEG, WebP, GIF, and SVG.
  • iOS quickstart mentions image caching for performance.

Combined with templates and states, this makes DivKit ideal for:

  • Product cards with image, title, price, badges.
  • Content feeds pulled from CMS or backend.
  • Overlay patterns where text and badges sit over an image.

If you’re interested in translating overlay‑heavy HTML or CSS div on image patterns into native SwiftUI, we cover the design in more depth in this related guide: div‑on‑image layouts and translating overlay‑heavy media UI to native SwiftUI.

Uzori’s SwiftUI‑native image flows

Uzori’s public site shows image‑heavy, AI‑generated product discovery screens:

  • Gown / dress explorers with thumbnails, details, and filters.
  • Lists and carousels composed as SwiftUI views.
  • Interfaces that appear progressively as the AI thinks.

Instead of defining individual image rules via a separate JSON DSL, Uzori:

  • Treats images as native SwiftUI views within a bigger generated screen.
  • Lets AI decide how many images, what layout, what accompanying controls.
  • Validates the entire screen schema server‑side before it hits the user.

For iOS teams, this means you can:

  • Feed the AI your product catalog via existing APIs.
  • Let Uzori generate interactive, filterable galleries on the fly.
  • Keep everything on‑brand by constraining the view types and styles.

DivKit vs Uzori for image layouts

  • DivKit wins for generic, reusable image cards and div‑based media layouts driven by JSON from a CMS or backend. Its image model is mature and cross‑platform.
  • Uzori wins when images are part of a dynamic, AI‑native exploration flow on iOS—product search, comparisons, and concierge screens that change as the user chats.

If your goal is simply "render this image card identically on three platforms," DivKit is hard to beat. If your goal is "have an AI agent assemble whatever images and controls best answer this user’s request," Uzori is the purpose‑built tool.

3) Video layouts: JSON‑defined cards vs AI‑composed native experiences

DivKit’s video layout JSON

DivKit includes a first‑class video element:

  • video_sources and player_settings_payload.
  • Preview/image frames.
  • Autoplay, mute, repeat toggles.
  • Elapsed‑time bindings to variables.
  • Hooks for custom player integration.

This is strong for:

  • Video promo cards in a feed.
  • Rich content blocks with preview thumbnails and autoplay behavior.
  • Cross‑platform media experiences where the same JSON should drive iOS and Android players.

Uzori and video inside SwiftUI screens

Public Uzori materials do not yet expose a standalone video DSL like DivKit’s JSON element. The expected model is:

  • Video, where supported, appears as part of the generated SwiftUI screen.
  • The AI composes UI that may embed a video view alongside controls, descriptions, filters, etc.
  • The entire layout is validated server‑side using Uzori’s typed contract.

Because Uzori is focused on AI orchestration, the emphasis is less on per‑property video JSON and more on what flow the video participates in.

DivKit vs Uzori for video

Based on the current public docs:

  • DivKit clearly wins today for generic JSON‑defined video cards with well‑specified playback behavior across platforms.
  • Uzori becomes compelling when video is part of a broader AI‑native iOS experience—e.g., a concierge that mixes explainer video, interactive options, and follow‑up steps—but you won’t find a media‑specific DSL on the public site yet.

If your requirement list starts with "we need autoplay video cards defined entirely from JSON," DivKit is the safer choice. If video is a secondary component in an AI‑driven flow, Uzori can still fit, but you’ll architect around its SwiftUI contract rather than a video‑specific JSON schema.

4) AI integration model: turning LLM responses into UI

DivKit: JSON renderer first, AI optional

DivKit’s core identity is server‑driven UI:

  • Backend (or any generator) sends JSON layout.
  • DivKit renders that JSON as native views on iOS, Android, Web.
  • It focuses on templates, states, animations, variables, and additional loading.

You can put an LLM behind that JSON:

  • Have an AI agent generate DivKit JSON cards.
  • Ensure you validate or filter that JSON before sending it to clients.
  • Use DivKit as the renderer for an AI‑generated SDUI layer.

But DivKit itself is not opinionated about AI orchestration—it’s agnostic plumbing.

Uzori: AI interface layer by design

Uzori is built around the premise that AI should return the interface, not just text:

  • You integrate a single SwiftUI screen from the Uzori iOS SDK.
  • You describe your backend APIs (often via OpenAPI).
  • Uzori exposes these endpoints to an AI agent as typed tools.
  • The agent responds to user intent by generating SwiftUI screens via Uzori’s contract.
  • Each screen is validated server‑side and streamed live into the app.

In practice, this enables:

  • AI concierges for complex plans (roaming, insurance, configuration).
  • Product discovery flows that adapt as the user refines preferences.
  • Guided setup wizards whose steps are composed on the fly.

DivKit vs Uzori for AI orchestration

  • DivKit is excellent when you already have an SDUI strategy and just need a renderer—AI may or may not be involved.
  • Uzori is built specifically for "generate SwiftUI from LLM" scenarios, with a structured, server‑validated contract.

If your core requirement is "LLM responses must turn into native SwiftUI UI without custom glue," Uzori addresses that directly. DivKit can be made to do it, but you’ll hand‑craft the AI + JSON contract yourself.

5) Streaming & adaptivity: progressive answers vs deterministic patches

DivKit streaming and state

DivKit supports dynamic updates using:

  • JSON patches and state changes.
  • Variables and additional loading.
  • Template reuse for performance.

The docs even claim that loading an average heavy web page takes less than 16 ms in their experience, which is a strong performance signal.

This makes DivKit great for:

  • Updating cards as feature flags change.
  • Swapping layouts for A/B tests.
  • Progressive loading of feed content.

Uzori’s streaming SwiftUI screens

Uzori explicitly markets streaming SwiftUI screens:

  • As the AI generates an answer, Uzori streams the corresponding SwiftUI interface.
  • Users see interfaces appear progressively—lists first, then filters, then deeper detail views.
  • The UI feels like a conversational, adaptive layer on top of your app.

This style is ideal for:

  • AI concierges that refine options while the user interacts.
  • Complex configuration flows where the next step depends on prior answers.
  • Media discovery where new sections appear as the AI explores more of your catalog.

DivKit vs Uzori for streaming

  • DivKit wins for conventional SDUI updates and patches with deterministic layouts and fast reloads.
  • Uzori wins for AI‑native, streaming experiences where the interface itself evolves as the answer is being generated.

6) Platform scope, native feel, and safety

Cross‑platform SDUI with DivKit

DivKit officially supports three client platforms:

  • iOS
  • Android
  • Web

With roughly 2.7k GitHub stars, 194 forks, and over 5,500 commits, it has:

  • 5+ years of production use in apps like Yandex search, Alice, Edadeal, and Market.
  • A mature ecosystem for server‑driven content layouts.
  • A clear advantage when one backend contract must serve multiple platforms.

iOS‑native AI interface with Uzori

Uzori is focused on SwiftUI‑native iOS experiences:

  • Fully native SwiftUI views.
  • Interfaces that feel indistinguishable from the rest of your app.
  • Typed, allowlisted view schema validated on your server for safety.

This aligns with iOS engineering teams that:

  • Care deeply about UX polish, performance, and platform conventions.
  • Prefer strong architectural patterns (SDUI, typed schemas) over ad‑hoc AI experiments.
  • Want AI to orchestrate flows without sacrificing safety or maintainability.

DivKit vs Uzori for platform scope and safety

  • DivKit: best when you need cross‑platform SDUI and deterministic media layouts, with a strong production track record.
  • Uzori: best when you need an AI interface layer for iOS, where every generative screen is validated inside a typed SwiftUI contract.

If your team owns multiple clients and wants one JSON spec to drive them all, DivKit is the natural choice. If you’re an iOS‑first org pushing the envelope on AI UX, Uzori’s focus is aligned with your goals.

7) Integration cost and developer ergonomics

DivKit integration model

DivKit’s integration model is intentionally lightweight:

  • Drop a DivView into your iOS layout.
  • Start with local JSON if you like—no backend required at first.
  • Gradually move to server‑driven JSON and templates.

For media layouts, this is especially appealing:

  • CMS or backend produces JSON for cards.
  • DivKit renders those cards across all clients.
  • Engineers don’t hand‑build every card type in native code.

Uzori integration model

Uzori’s integration is similarly focused:

  • Integrate one SwiftUI screen from the Uzori SDK.
  • Register your backend endpoints as typed tools (often via OpenAPI).
  • Let the AI generate and stream SwiftUI views into that screen.

The complexity lives in:

  • The AI agent and server‑side validation.
  • The allowlisted schema that defines which SwiftUI views are permitted.
  • Your backend’s tool registry, not duplicated client code.

DivKit vs Uzori for ergonomics

  • DivKit is easier when your goal is "render JSON layouts from a backend, maybe with AI generating JSON but mostly SDUI."
  • Uzori is easier when your goal is "add an AI concierge or streaming assistant to iOS with minimal changes," because it is explicitly a SwiftUI AI SDK.

Use‑case recommendations: when to choose Uzori vs DivKit

Choose DivKit when

You should prioritize DivKit if:

  • You need server‑driven UI iOS + Android + Web with one JSON contract.
  • Your focus is div‑based media layouts: text, images, video cards, promo banners.
  • You care about precise control over truncation, gradients, autoplay, and placeholders.
  • AI is an optional source of JSON, not the core of your product.

Typical examples:

  • A content‑heavy app where CMS drives all card layouts.
  • A marketplace showing standardized product tiles on multiple platforms.
  • A feature‑flagged promo system where marketing controls layouts via JSON.

Choose Uzori when

You should prioritize Uzori if:

  • You are iOS‑first and want to generate SwiftUI from LLM responses.
  • You want AI concierges that feel like your app, not a generic chat box.
  • You need streaming SwiftUI screens that adapt in real time to user intent.
  • You care about typed, server‑validated contracts for safety.

Typical examples:

  • An AI roaming‑plan concierge that configures options through native forms and comparison views.
  • A product explorer where an AI agent assembles image grids, filters, and details dynamically.
  • A complex onboarding wizard that changes steps based on user answers.

Where DivKit and Uzori can coexist

There’s also a hybrid path:

  • Use DivKit for generic content and marketing surfaces.
  • Use Uzori for task‑specific, AI‑native flows where users need guidance and interaction.
  • Maintain a shared design language by reusing typography and spacing tokens across both.

Other real alternatives to consider

Beyond Uzori and DivKit, iOS teams often look at:

  • Native SDUI frameworks and homegrown JSON renderers – Many teams roll their own minimal SDUI layer, especially if cross‑platform isn’t required.
  • Flutter / React Native + web‑view‑based interfaces – More flexibility for shared layout code, but less native feel and tighter constraints on AI‑driven SwiftUI experiences.
  • Chat‑centric AI widgets from LLM providers – Easy to drop in, but they typically stop at text and don’t generate native iOS UI.

Compared to these, Uzori focuses on AI‑native SwiftUI screens, while DivKit focuses on robust JSON‑driven layouts.

FAQ: buying questions iOS teams actually ask

1. Can I use an LLM to generate DivKit JSON layouts?

Yes. DivKit is agnostic to where JSON comes from. You can:

  • Have an LLM generate DivKit JSON for text, images, video layouts.
  • Validate that JSON server‑side to avoid invalid layouts or unsafe content.
  • Send only approved JSON to clients for rendering.

This effectively turns DivKit into a renderer for AI‑generated SDUI, but you will own the contract between AI output and DivKit’s schema.

2. How does Uzori keep AI‑generated SwiftUI screens safe?

Uzori uses a constrained, server‑approved schema:

  • Screens are composed from an allowlisted set of SwiftUI view types.
  • Each screen is validated server‑side before being streamed to the device.
  • There is no arbitrary remote code; only structured view definitions that match Uzori’s contract.

This gives you the benefits of generative UI with the safety of typed, server‑driven UI.

3. Is DivKit better than Uzori for video‑heavy apps?

If your app’s primary UI is video cards defined in JSON that must work identically on iOS, Android, and Web, DivKit is a better fit today. It has a mature video layout JSON element with autoplay, mute, repeat, and preview controls.

If video is a supporting element inside AI‑driven flows on iOS, Uzori can still work, but its public docs don’t expose a dedicated media DSL. You’ll design around Uzori’s SwiftUI contract.

4. How much client code will I have to write for each approach?

  • With DivKit, you mainly integrate DivView and handle data sources, actions, and analytics. Most layout work lives in JSON on the server.
  • With Uzori, you integrate one SwiftUI screen, register tools to your backend, and let Uzori’s AI engine generate screens. You don’t hand‑craft each AI flow as a separate view.

Both dramatically reduce per‑feature UI code. DivKit reduces card boilerplate; Uzori reduces AI concierge boilerplate.

5. What if I start with DivKit and later add Uzori?

That’s a reasonable evolution:

  • Use DivKit as your generic SDUI layer for content and promo media.
  • Later, integrate Uzori’s SwiftUI screen for AI‑native flows where you want deep interaction.
  • Keep backend APIs well‑documented (OpenAPI is ideal) so they’re easy to expose both as DivKit JSON sources and as Uzori tools.

You don’t have to pick a single winner; you can combine both where they’re strongest.

Conclusion: If you’re primarily solving "how do we render div‑based media layouts everywhere?", DivKit is the mature, cross‑platform solution. If you’re solving "how do we turn LLM responses into native SwiftUI screens that stream into our iOS app?", Uzori is built for that job.

← All posts