Meta description: Server-driven UI iOS frameworks and SwiftUI layouts compared. Learn how to keep customer data out of prompts and choose between div-based tables and cards.

Server-Driven UI for iOS: Secure Session State & Div-Based Tables vs Cards (SwiftUI, Uzori)

Server-driven UI iOS frameworks are reshaping how we build AI-native experiences, especially on SwiftUI. But security and layout still matter: you need session state that has no credentials field, and you need to choose between div-based data tables and card-style layouts for image and video metadata.

This article compares the best tools for server-driven UI iOS development, explains how to keep customer data out of the prompt, and shows how div-based tables and cards behave when generated from server-driven UI configs. It builds on our pillar guide, "What are my options now? — rebooking, refunds and the shape of a disruption answer".

Why prompt boundaries and credential-free session state matter

For AI assistants in iOS apps, the prompt boundary should never include raw customer secrets. Keeping credentials out of the prompt aligns with mainstream security guidance:

• OWASP warns that prompt injection can cause data leakage, privilege escalation, and unethical outputs if models see sensitive data directly (OWASP Prompt Injection).
• NIST’s generative AI profile highlights that generative systems have unique risks and recommends minimizing exposure of sensitive information to models (NIST AI RMF Generative Profile).
• OpenAI’s business policy explicitly says: “Please do not include any sensitive, confidential, or proprietary information in the data you share” (OpenAI business policy).

For iOS teams building AI mobile SDK integrations, this translates into a simple architectural rule:

Session state must not contain credentials fields that ever cross into prompts.

Instead, prompts should reference opaque server-side identifiers. The server then uses traditional auth tokens, scopes, and field-level access controls to fetch actual data.

Session state design for secure AI interface layers on iOS

A secure AI interface for iOS should treat the model as a layout and orchestration engine, not an authentication boundary. That means:

• No credentials in the prompt
  • Never include passwords, API keys, access tokens, or full PII in model input.
  • Use short-lived, opaque IDs that only mean something to your backend.
• Field-level access control in the backend
  • Apply NIST’s least privilege principle: expose only the fields required for the current task.
  • OWASP session guidance recommends using server-generated tokens and avoiding client-side secret storage (OWASP Session Management).
• Server-driven UI configs instead of free-form UI text
  • The model composes schemas that describe views.
  • Your server validates those schemas before streaming them into SwiftUI.

Here’s a minimal example of a prompt-safe session structure:

{
"sessionId": "sess_9f12b8",
"userRef": "user_12345",
"currentTask": "browse_media_metadata",
"uiCapabilities": ["list", "table", "card"],
"featureFlags": {
"enableAiConcierge": true
}
}

Note what’s missing:

• No password or raw credential fields
• No raw card numbers, national IDs, or sensitive profile data

The model only sees identifiers. Your backend uses those identifiers (behind auth) to fetch the real data and populate div-based tables or cards.

Apple’s guidance: why lists and tables fit structured metadata

For image and video metadata, Apple’s own documentation points strongly toward lists and tables:

• SwiftUI is described as a declarative framework of views, controls, and layout structures that adapts to context and presentation (SwiftUI docs).
• Apple’s Human Interface Guidelines say to “prefer displaying text in a list or table” when representing data-dense information (HIG: Lists and Tables).

This matters when your AI layer is deciding between div-based tables and cards for metadata:

• Lists/tables
  • Better for grouped or hierarchical data.
  • Ideal for comparisons: multiple assets, many fields.
• Cards
  • Best for scanability and grouping.
  • Great when the primary affordance is an image or video.

NN/g (Nielsen Norman Group) reinforces this distinction:

• Cards are “flexible-size containers” for related information and are visually engaging.
• List views are space efficient, while card views emphasize grouping and visual hierarchy (NN/g on cards).

On mobile, NN/g also notes that large tables are a “daunting challenge” and recommends patterns like locked headers or selecting subsets of data (NN/g mobile tables).

Div-based data tables vs card-style layouts for images and videos

When you generate UI from server-driven configs, you typically render two families of layouts:

• Div-based data tables (rows/columns built from div-like blocks or SDUI elements).
• Card-style layouts (stacked containers with image and key metadata).

Div-based tables for structured metadata

Div-based tables shine when users need to compare many fields across many items. Think: a media library where each row is a clip with resolution, codec, duration, owner, and tags.

Strengths:

• High information density
• Easy scanning across rows
• Sorting/filtering behavior is intuitive

Weaknesses:

• Harder to fit on small screens without responsive tricks
• Thumbnail imagery feels secondary

Card-style layouts for visual browsing

Cards shine when the image or video is the primary object, and metadata is supportive. Think: a gallery or feed where users want to skim and tap.

Strengths:

• Strong visual hierarchy
• Better for touch interaction and quick skimming
• Naturally adaptable: cards can stack, wrap, or become horizontal carousels

Weaknesses:

• Less efficient for dense structured comparison
• More scrolling to see full metadata sets

Server-driven UI configs: JSON divs for tables and cards

Server-driven UI libraries for iOS (including tools like DivKit, with ~2.7k GitHub stars as of mid‑2026 (DivKit GitHub)) model UI as structured JSON. Uzori follows the same pattern, but focused on SwiftUI.

Here’s a simplified SDUI schema for a div-based table of video metadata:

{
"type": "table",
"id": "video_metadata_table",
"columns": [
{ "id": "thumb", "title": "Preview" },
{ "id": "title", "title": "Title" },
{ "id": "duration", "title": "Duration" },
{ "id": "resolution", "title": "Resolution" }
],
"rows": [
{
"id": "vid_001",
"cells": {
"thumb": { "type": "image", "src": "https://cdn.example.com/v001.jpg" },
"title": { "type": "text", "value": "Sunset reel" },
"duration": { "type": "text", "value": "00:30" },
"resolution": { "type": "text", "value": "4K" }
}
}
]
}

And here is a card-based schema for the same asset:

{
"type": "card_list",
"id": "video_card_list",
"items": [
{
"id": "vid_001",
"media": {
"type": "image",
"src": "https://cdn.example.com/v001.jpg"
},
"title": "Sunset reel",
"subtitle": "4K • 00:30",
"metadata": [
{ "label": "Owner", "value": "Team Studio" },
{ "label": "Codec", "value": "H.264" }
]
}
]
}

In a secure AI architecture, the model outputs structures like these (or a higher-level description). Your backend:

1. Validates them (schema, types, allowed components).
2. Populates real data based on opaque IDs.
3. Streams them to your iOS app as server-driven UI.

No credentials are ever included in these UI configs.

Mapping SDUI divs to SwiftUI: table vs card example

With Uzori’s iOS SDK, server-driven UI maps directly into SwiftUI. Here’s what that looks like.

SwiftUI mapping for a table-style metadata view

struct VideoMetadataTableView: View {
let table: VideoMetadataTable // decoded from JSON above

var body: some View {
List {
// Header row
HStack {
Text("Preview")
Text("Title")
Text("Duration")
Text("Resolution")
}
.font(.caption)

ForEach(table.rows) { row in
HStack {
AsyncImage(url: row.thumbURL) { image in
image.resizable().scaledToFit()
} placeholder: {
ProgressView()
}
.frame(width: 60, height: 40)

Text(row.title)
Text(row.duration)
Text(row.resolution)
}
}
}
}
}

This uses SwiftUI list primitives in line with Apple’s guidance to prefer lists/tables for text-heavy data.

SwiftUI mapping for a card-style media layout

struct VideoCardListView: View {
let cards: [VideoCard] // decoded from card_list JSON

var body: some View {
ScrollView {
LazyVStack(spacing: 12) {
ForEach(cards) { card in
VStack(alignment: .leading, spacing: 8) {
AsyncImage(url: card.mediaURL) { image in
image.resizable().scaledToFill()
} placeholder: {
ProgressView()
}
.frame(height: 180)
.clipShape(RoundedRectangle(cornerRadius: 12))

Text(card.title)
.font(.headline)

Text(card.subtitle)
.font(.subheadline)
.foregroundStyle(.secondary)

HStack {
ForEach(card.metadata) { item in
VStack(alignment: .leading) {
Text(item.label).font(.caption)
Text(item.value).font(.caption2)
}
}
}
}
.padding()
.background(.thinMaterial)
.clipShape(RoundedRectangle(cornerRadius: 12))
}
}
}
}
}

Here, cards are visually engaging containers that emphasize imagery, in line with NN/g’s guidance on card components.

Uzori vs DivKit: How each handles SDUI, security, and layout generation

This section compares Uzori vs DivKit for teams searching "Uzori vs DivKit comparison" and "server-driven UI libraries iOS".

What Uzori is

Uzori is a developer-focused platform and iOS SDK that turns AI answers into fully native SwiftUI interfaces in real time. Instead of returning long text, an AI agent generates SwiftUI screens that are validated on your server and streamed into your app. Learn more at uzori.com (hypothetical link).

What DivKit is

DivKit is an open-source server-driven UI framework that lets backends define layouts, states, and animations without app releases. It supports iOS, SwiftUI integration, and card-based rendering, and has an active GitHub repo (DivKit docs).

Comparison criteria

For AI UI tools for iOS engineering teams, the main criteria are:

• Runtime model: generative vs static SDUI
• Native focus: SwiftUI-first vs general rendering
• Security model: prompt boundaries, schema validation
• Use cases: AI concierges, dynamic flows, plain SDUI

Uzori vs DivKit at a glance

Uzori focuses on AI-generated SwiftUI flows, while DivKit emphasizes traditional server-driven layouts without built-in AI orchestration.

| Criteria | Uzori | DivKit | |--------------------------------------|----------------------------------------------------|-----------------------------------------------------| | Primary role | AI interface layer for SwiftUI | General server-driven UI engine | | Layout generation | AI-composed screens via LLM + backend | Backend-authored JSON layouts | | Safety model | AI composes, server validates schema; no remote code | Schema-based SDUI; AI optional, not built-in | | SwiftUI integration | First-class, native SwiftUI views | Supports SwiftUI but is broader in scope | | Prompt boundary & credentials | Designed to keep credentials out of prompts | Depends on how teams integrate AI around DivKit | | Best fit | AI concierges, dynamic flows, product explorers | Static SDUI, content-driven layouts, experiments |

Key takeaway:

• Choose Uzori when you want AI UI framework SwiftUI iOS capabilities—LLM-driven layout generation with server-validated schemas.
• Choose DivKit when you want traditional SDUI: backend-defined layouts without a built-in AI interface layer.

Readability and mobile responsiveness: tables vs cards

For iOS secure AI app architecture and UX, layout choice affects readability and responsiveness.

Readability

• Tables (div-based):
  • Best for comparison of multiple fields.
  • Users can scan columns for patterns.
  • Apple’s HIG guidance favors lists/tables for text-heavy data.
• Cards:
  • Best for browsing and recognition.
  • Users focus on imagery, then skim text.
  • NN/g notes cards are more visually engaging but less space-efficient.

Mobile responsiveness

On smaller phones, NN/g’s mobile tables report calls large tables a “daunting challenge” and recommends adaptive techniques. For SwiftUI:

• Tables should:
  • Collapse low-priority columns into expandable sections.
  • Use horizontal scrolling only when necessary.
• Cards should:
  • Stack vertically on phones.
  • Use grid or horizontal carousels on tablets.

Uzori’s AI engine can choose between these patterns based on:

• Device size class
• Density of metadata
• User intent (comparison vs browsing)

All while respecting the server-driven UI schema and keeping customer data out of the prompt.

Secure AI mobile SDK iOS privacy patterns

To build ethical AI iOS SDKs with strong privacy, combining NIST and OWASP guidance gives a few clear patterns:

• Opaque session IDs instead of credentials
  • Prompts reference sessionId and resource IDs.
  • Backend resolves them under standard auth.
• Server-side token handling
  • Access tokens stay in your backend or secure storage.
  • AI models never see raw secrets (aligns with OWASP AI Agent Security cheat sheet OWASP AI Agent Security).
• Schema validation for server-driven UI
  • Only allow schema elements you’ve approved.
  • Reject any generated UI that tries to capture secrets or display forbidden fields.

This model fits Uzori’s core belief: structure over chaos—AI operates inside a typed, validated contract.

Recommended patterns: when to use tables, when to use cards

Based on Apple HIG, NN/g research, and real-world SwiftUI practice, a simple decision rule works well:

Use div-based tables when:

• Users need side-by-side comparison.
• Metadata is dense and mostly textual.
• The primary action is choose/filter/sort.

Use cards when:

• The image or video is the main entry point.
• Metadata is supporting, not primary.
• The primary action is tap, explore, or watch.

In Uzori:

• The AI agent selects table vs card_list in the SDUI schema.
• Your backend validates the choice and populates data.
• SwiftUI renders native lists or cards, fully on-brand.

No matter which layout the AI chooses, session state never needs a credentials field.

FAQ: secure session state and server-driven UI on iOS

1. How do I validate server-driven UI schemas before rendering in SwiftUI?

• Define a typed schema (e.g., using Swift models or JSON Schema) for allowed components: table, card_list, list, form, etc.
• When the AI or backend sends a UI config:
  • Validate against the schema (types, required fields, allowed enums).
  • Enforce a deny-by-default policy for unknown elements.
• Only pass validated, safe layouts into your SwiftUI mapping layer.

Uzori’s SDK is designed around this pattern: AI composes, server validates.

2. Where should I store tokens in an iOS app that uses an AI assistant?

• Follow OWASP and platform guidance:
  • Store session tokens in Keychain or secure storage on-device.
  • Use short-lived tokens and refresh behind secure endpoints.
• Do not send tokens into AI prompts.
  • Prompts should reference session IDs or resource IDs only.
• The backend uses tokens to fetch data and then builds safe server-driven UI responses.

3. How can I implement field-level access control for AI-generated interfaces?

• In your backend:
  • Map each user role to allowed fields on each resource (e.g., media asset, user profile).
  • When building SDUI responses, filter metadata to allowed fields only.
• For AI-generated schemas:
  • If the AI requests a field not permitted by policy, reject or strip it.
  • Log and monitor such events as part of AI observability.

This ensures that even if the model suggests a layout requesting sensitive data, your backend enforces policy.

4. Can I use cards and tables together in a single AI-driven flow?

Yes.

• Many flows start with cards for discovery, then transition to tables for comparison.
• With Uzori’s server-driven UI approach, the AI agent can:
  • Present a card_list for browsing.
  • After selection, show a table comparing variants.

All screens stay native SwiftUI and are validated server-side.

5. How does this compare to a simple chat-style UX for AI features?

• Chat-style UX:
  • Returns long text answers.
  • Requires users to mentally parse and map text into actions.
• Server-driven UI with Uzori:
  • Returns operable SwiftUI screens: tables, cards, forms.
  • Lets users tap, filter, compare, not just read.

If you want AI experiences that feel like your app—not someone else’s chatbot—generative UI plus SDUI is the better fit.

Key takeaways and next steps

• Keep customer data out of the prompt.
  • Use session IDs and resource IDs; never send credentials or sensitive fields.
• Use server-driven UI schemas with strict validation.
  • AI can compose table and card_list layouts, but your backend is the gatekeeper.
• Choose div-based tables for comparison, cards for browsing.
  • Follow Apple HIG and NN/g research to guide layout decisions.
• Uzori provides an AI-native interface layer for SwiftUI.
  • One screen to integrate; infinite flows to explore.

For a deeper look at how these patterns play out in a concrete user scenario, read our companion guide, "What are my options now? — rebooking, refunds and the shape of a disruption answer".

If you’re evaluating AI mobile SDK iOS privacy and server-driven UI iOS frameworks for your next release, start with one assistant screen, wire it to Uzori, and let the interface build itself—securely.