Div Data vs View Models: Representing AI Media Layouts in Your iOS Codebase

AI is now good enough to design complex media layouts: image grids, video overlays, carousels, comparison views.

The question for iOS teams isn’t whether to use AI, but how to represent its layouts safely in Swift.

This article compares two competing approaches—raw div data JSON vs typed Swift view models—and shows how Uzori combines both: flexible div-like data for AI orchestration, strongly-typed interfaces for your SwiftUI components.

Why representation matters for AI media layouts

Before you decide between div JSON and view models, clarify what you need your layout representation to do.

For AI-generated media layouts on iOS, teams typically care about:

• Safety – No arbitrary remote code; layouts must be constrained and validated.
• Performance – Smooth SwiftUI updates, minimal over-rendering.
• Flexibility – AI can compose new combinations of images, text, and actions.
• Developer ergonomics – Easy to debug, test, and refactor as the product evolves.

Apple’s own direction with SwiftUI makes this explicit.

Model data drives the UI, and the newer Observation system tracks only the properties a view actually reads—Apple notes this can improve performance and that migration from ObservableObject to @Observable can be done incrementally.

That’s a strong hint: typed data structures are the end-state, even if the input from AI starts as JSON.

Option 1: Raw div data JSON for AI layouts

Many server‑driven UI iOS frameworks (and web stacks) represent layouts as JSON trees—essentially a hierarchy of div‑like nodes.

On iOS, the closest analogue is DivKit, which:

• Accepts layouts as [String: Any], Data, or DivData.
• Renders native interfaces via DivView or DivHostingView for SwiftUI.
• Supports templates, states, variables, and dynamic item_builder containers.

DivKit’s GitHub repo has 2.7k stars, 193 forks, and over 5,300 commits as of September 2026, showing this pattern is mature and actively maintained.

Pros of div data JSON

Raw div JSON shines in a few areas:

• Maximum flexibility for AI
  LLMs (especially with Structured Outputs) are excellent at filling JSON trees that describe layout.
• Transport-friendly
  JSON is easy to send over the network, cache, and log.
• Schema-constrained AI outputs
  OpenAI reports gpt-4o-2024-08-06 hits 100% on complex JSON Schema adherence tests, versus less than 40% for gpt-4-0613.
  That means you can reliably ask the model to output div trees that follow your contract.
• Server-driven UI compatibility
  The same JSON shapes can be generated by AI or authored by backend code, fitting Shopify/Netflix‑style SDUI architectures.

Cons and risks of div JSON in your app

Div JSON at the UI boundary is great; inside your iOS codebase, it can create friction:

• Un-typed access
  Accessing layout data via dictionaries ([String: Any]) increases runtime errors and makes refactoring painful.
• Weak tooling
  Xcode, the compiler, and Swift language features can’t help you much if your core layout representation is dynamic JSON everywhere.
• Harder local testing
  Snapshot tests and unit tests often want typed fixtures; deeply nested JSON is cumbersome.
• Coupling to schema changes
  A small tweak to JSON structure can require manual fixes across many call sites.

As a result, div JSON works best at boundaries: between AI / backend and your app—not as the primary representation driving your SwiftUI views.

Option 2: Typed Swift view models for media layouts

Typed Swift view models are the natural fit for SwiftUI and Apple’s Observation model.

Instead of generic div nodes, you define explicit types that describe your layout:

struct MediaOverlayLayout: Identifiable {
let id: UUID
let baseImageURL: URL
let overlays: [Overlay]

struct Overlay: Identifiable {
let id: UUID
let position: CGPoint
let size: CGSize
let content: Content

enum Content {
case label(text: String)
case badge(iconName: String)
case button(title: String, actionID: String)
}
}
}

Now the interface is first‑class Swift data, not loose JSON.

Pros of typed view models

Typed models unlock several benefits:

• Native SwiftUI alignment
  Model data drives the view; property-level observation updates only when necessary.
• Compiler safety
  Breaking changes are visible at compile time, not in production.
• Better tooling and refactors
  Rename symbols, change enums, and restructure models with strong IDE support.
• Clear contracts for components
  A MediaGridView can require a MediaGridLayout instead of a random JSON blob.
• Testability
  Creating fixtures and running snapshot tests is straightforward with typed structs.

Limitations of pure view-model approaches for AI

If you only use typed view models and avoid JSON altogether, you hit some constraints:

• AI output mapping overhead
  You still need a mapping layer from AI outputs (JSON) into your Swift types.
• Limited generativity
  The more rigid your models, the harder it is to let AI invent new layout combinations.
• Evolution cost
  For early explorations, strict models can slow iteration compared to flexible schemas.

In practice, you don’t want to hand a Swift data structure to the LLM and hope it fills it correctly—you want JSON at the AI boundary and Swift types inside the app.

The emerging pattern: JSON at the boundary, typed Swift inside

Looking across DivKit, Shopify, Netflix, and OpenAI’s Structured Outputs, the strongest architecture pattern for AI media layouts on iOS is:

Use JSON (or div data) as the contract at the AI/server boundary, and convert to typed Swift view models inside your app.

This hybrid approach is increasingly standard:

• DivKit – JSON input; native rendering and reuse on iOS.
• Shopify Shop app – server-driven UI defines sections; native clients render them.
• Netflix dynamic pages – backend assembles layout via GraphQL; clients consume structured data.
• OpenAI Structured Outputs – AI emits JSON shapes guaranteed to match a schema, perfect for UI generation.

Uzori builds directly on this pattern for SwiftUI.

How Uzori combines div data flexibility with typed Swift view models

Uzori is designed specifically for AI-native iOS apps.

Instead of letting AI respond with long-form text, Uzori’s iOS SDK lets an AI agent respond with generated SwiftUI screens that are:

• Composed from a constrained, server-approved schema.
• Validated on your server for safety and correctness.
• Streamed live into your app as native SwiftUI views.

Inside Uzori: div-like schema for AI, typed models for you

At a high level, Uzori uses a div-like representation internally to describe layouts:

• Containers, stacks, overlays, galleries, and pagers resemble div-based SDUI.
• Components reference your APIs and data (often via OpenAPI descriptions).
• AI composes these into task-specific flows—media grids, comparison views, wizards.

But the SDK you integrate with is strongly typed Swift.

You don’t pass around [String: Any] or hand-crafted JSON; you:

• Embed a single Uzori SwiftUI screen.
• Configure it via typed parameters (e.g., session IDs, capabilities, initial context).
• Let Uzori stream validated screens that map onto your existing SwiftUI components.

You get the best of both worlds:

• Flexible div data for AI orchestration.
• Strongly-typed interface for your iOS codebase.

For a deeper dive into how div-based layouts can handle image, video, and text overlays specifically, see this related guide: Divs for Media Layout on iOS: A Pillar Guide to Image, Video and Text Overlays.

Uzori vs DivKit: different tools for different layers

It’s helpful to compare Uzori with DivKit directly, because many iOS engineers evaluate both when building server-driven UI.

Comparison criteria

When choosing between div data JSON and typed view models (and tools like DivKit vs Uzori), most teams care about:

• Integration surface – How many screens/components must you wire up?
• AI-native support – Is the system built around LLM-driven layouts?
• Safety model – How are layouts validated before hitting the device?
• Native fidelity – Are outputs full SwiftUI screens or generic views?
• Iteration speed – How quickly can you experiment with new flows?

Quick comparison table

• Primary representation — DivKit (JSON-first SDUI): Div-like JSON ( DivData , [String: Any] ); Uzori (AI-native SwiftUI SDK): Constrained layout schema + typed Swift SDK
• Rendering layer — DivKit (JSON-first SDUI): Native iOS views, SwiftUI via DivHostingView; Uzori (AI-native SwiftUI SDK): Native SwiftUI screens streamed into your app
• AI integration — DivKit (JSON-first SDUI): Possible, but you build your own LLM integration; Uzori (AI-native SwiftUI SDK): Built-in AI engine generates layouts from user intent + your APIs
• Safety model — DivKit (JSON-first SDUI): You own schema validation; JSON flexibility cuts both ways; Uzori (AI-native SwiftUI SDK): AI outputs must conform to server-approved schema; every screen validated before display
• Integration cost — DivKit (JSON-first SDUI): You design JSON schema, map to components, handle SDUI plumbing; Uzori (AI-native SwiftUI SDK): "One screen" integration; Uzori orchestrates flows over your existing backend
• Best fit — DivKit (JSON-first SDUI): Teams already invested in JSON SDUI, building card-based layouts; Uzori (AI-native SwiftUI SDK): Teams shipping AI-native assistants, concierges, and media flows with strong SwiftUI ergonomics

Uzori does not replace DivKit for all scenarios.

But if your main goal is generate native iOS UI from LLM responses—particularly media-heavy flows—Uzori is built for that from the ground up.

Common use cases: when to prefer div JSON vs typed view models

When div JSON (or DivKit) makes sense

Choose div JSON-centric architectures when:

• Your layouts are largely server-authored, not AI-generated.
• You want a card-based, repeatable SDUI system with templates.
• You’re comfortable owning schema design, validation, and AI integration yourself.

DivKit’s item_builder is especially good for:

• Product grids.
• Mixed carousels of images and text.
• Reusable cards with varying content.

When typed Swift view models + Uzori shine

Use Uzori’s hybrid approach when:

• You want AI concierges for complex media-centric flows (e.g., roaming protection plans with image-based options).
• Your product team wants to iterate on task-specific wizards and comparison views quickly.
• You need LLM responses mapped to native iOS interfaces without building the entire mapping layer yourself.

Uzori:

• Treats AI as an interface layer, not just a chat box.
• Keeps everything native and safe via server-validated schemas.
• Lets you compress weeks of UI iteration into streaming, AI-driven interfaces.

Recommended architecture for most iOS teams

If you’re an iOS lead or staff engineer at a product-led company, the safest and most future-proof pattern is:

1. Define a JSON layout schema at the AI/backend boundary.
   • Use OpenAI Structured Outputs or equivalent to force LLMs into that schema.
2. Validate JSON layouts server-side before they reach devices.
   • Reject or normalize invalid screens.
3. Convert validated JSON to typed Swift view models in or near your SDK layer.
   • Keep app code working with Swift structs and enums, not arbitrary dictionaries.
4. Render via SwiftUI using native components and property-level observation.
   • Follow Apple’s guidance on data-driven views and Observation.

Uzori essentially gives you this pattern as a product:

• JSON + AI orchestration handled in the Uzori engine.
• Server-side validation baked in.
• SwiftUI integration reduced to a single screen that streams structured layouts.

For most AI-native iOS efforts, this beats both extremes:

• Pure div JSON everywhere (too loose inside app code).
• Pure view models with no JSON boundary (too rigid for generative UI).

Actionable steps to move toward hybrid representation

You don’t have to rewrite your app to adopt this pattern.

Start incrementally:

1. Pick a single AI-native flow
   • Example: an AI product explorer or media-based setup wizard.
2. Define a minimal JSON schema for that flow
   • Think in terms of containers, items, overlays, and actions.
3. Use an LLM with Structured Outputs to emit that schema.
   • Enforce JSON Schema so the AI must comply.
4. Implement a small mapping layer from JSON → Swift view models.
   • Keep this mapping near your SDK boundary.
5. Render via SwiftUI components that accept typed models.
   • Add snapshot tests around a few representative layouts.
6. Evaluate Uzori as a way to productize this pattern.
   • Replace custom plumbing with Uzori’s iOS SDK and server validation.

Once this single flow feels solid, you can expand the pattern across more media-heavy parts of your app.

FAQ: Div data vs view models for AI media layouts on iOS

1. Should I store AI layouts as raw JSON or typed Swift structs?

Store AI layout outputs as JSON at the boundary for flexibility and interoperability.

But inside your iOS codebase, convert them to typed Swift view models.

This lets you leverage SwiftUI’s data-driven patterns, compiler safety, and testability.

2. Is DivKit enough for AI-generated UI, or do I need something like Uzori?

DivKit is excellent as a JSON-first SDUI library, especially for card-based layouts.

For AI-native experiences where LLMs design flows and screens in real time, you also need:

• Schema-constrained AI output.
• Server-side validation.
• A mapping layer into native SwiftUI.

Uzori provides that layer, purpose-built for AI-generated SwiftUI screens.

3. How does Uzori keep AI-generated UI safe for large-scale deployment?

Uzori:

• Uses a constrained layout schema that AI must adhere to.
• Validates every generated screen on your server for correctness and policy.
• Streams only approved SwiftUI views into the user’s device.

There is no arbitrary remote code execution—only schema-approved layouts rendered natively.

4. What’s the performance impact of using AI-generated layouts with SwiftUI?

Performance depends mostly on how you observe and update state, not on whether layouts were AI-generated.

By converting JSON layouts into typed Swift models and using SwiftUI’s Observation system, you can:

• Limit updates to properties the view actually reads.
• Avoid full-tree invalidations.

Uzori follows these principles, so AI-driven screens still feel like normal, performant SwiftUI views.

5. Can I A/B test AI-generated layouts in production?

Yes.

With JSON at the boundary and typed view models in your app, you can:

• Record different AI layout variants as schemas.
• Control which variant the server validates and streams.
• Use feature flags to toggle flows per cohort.

Uzori is designed to make these experiments easy to run without exploding client-side complexity.

If you’re exploring how to generate native iOS UI from LLM responses—especially for image and media-heavy layouts—adopt the hybrid pattern: div data at the AI boundary, typed Swift view models in your app.

Tools like DivKit help with JSON-first SDUI; Uzori helps you turn those AI layouts into safe, native SwiftUI screens with minimal integration work.