Server‑Driven UI vs Workflow Engines: Who Owns the Dynamic User Interface Layer on iOS?

Server‑driven UI frameworks and workflow engines solve different problems. If you're an iOS team building AI‑native experiences, you need both, but you need a…

Key-shaped steel hanger casting a long shadow in an empty gallery, symbolizing control over server-driven UI frameworks.

Server‑driven UI frameworks and workflow engines solve different problems. If you're an iOS team building AI‑native experiences, you need both, but you need a clear contract between them.

Short answer:

  • Server‑driven UI (SDUI) and tools like Uzori should own the visible screens, layouts, and native SwiftUI components.
  • Workflow engines (Temporal, Camunda, Step Functions, Google Workflows) should own process state, orchestration logic, retries, approvals, and long‑running business flows.

This article explains how to split responsibilities cleanly, where Uzori fits, and how to avoid either layer overreaching into the other.

Why this split matters now

Mobile UX is no longer a cosmetic layer on top of backend processes.

  • Sensor Tower's 2025 State of Mobile report notes 4.2 trillion hours spent in apps and $150 billion in consumer spend.
  • FullStory's 2025 analysis (based on 4+ billion digital sessions) found:
    • Mobile session duration +332%
    • Error‑related session exits +254%
    • Bounce rates +54%
    • 64% of consumers prefer a brand's app over its website.

Longer sessions and higher exits don't mean users are delighted, they often mean users are stuck.

In this environment, the dynamic UI layer is business‑critical, and who controls it, SDUI vs workflow, decides:

  • How fast you can iterate on flows
  • How safe your AI and SDUI systems are
  • Whether your app feels like a polished native experience or a bolted‑on chatbot

The products we're really comparing

In practice, iOS teams are deciding between two types of tools:

  • Server‑driven UI iOS frameworks (e.g., Uzori, DivKit‑style systems, Apollo SDUI schema patterns)
  • Workflow engine orchestration tools (Temporal, Camunda, AWS Step Functions, Google Workflows)

They overlap in one sense: both "decide what happens next". But they live at different layers.

This article focuses on Uzori as the AI‑native SDUI layer and how it should integrate with existing workflow engines, not replace them.

For a deeper architectural overview of SDUI on iOS, see our in‑depth guide: Server‑Driven UI for Native iOS: The Definitive Guide to Dynamic Interfaces in 2026.

Comparison criteria (what actually decides the choice)

Before comparing SDUI and workflow engines, let's state the criteria explicitly.

These are the dimensions that matter for iOS teams:

  1. Ownership of state and source of truth
  2. Screen composition and layout responsibility
  3. AI integration and agentic orchestration
  4. Safety, validation, and compliance
  5. Developer ergonomics for iOS teams
  6. Latency and UX quality
  7. Scalability and operational maturity

We'll walk through each criterion, then summarize in a table and close with per‑use‑case recommendations.

1. Ownership of state and source of truth

Core question: who should own durable state, the SDUI framework or the workflow engine?

Workflow engines: process state owners

Workflow engines are explicitly built to own long‑lived, durable process state:

  • Temporal defines workflows as code with a durable event history as the source of truth. Workflow replay restores an execution to the exact same state after a pause or failure.
  • Google Workflows supports waits, retries, and orchestrations that can run for months.
  • AWS Step Functions models distributed apps as state machines.

These tools are designed for:

  • Long‑running flows (days, weeks, months)
  • Robust recovery and replay
  • Auditable decision history
  • Cross‑system orchestration (dozens of endpoints per process)

Camunda's surveys show an average of about 50 endpoints per process, and 82% of organizations fear "digital chaos" from complex, multi‑system flows. This is exactly the domain where workflow engines shine.

Server‑driven UI: session‑level UI state

Server‑driven UI frameworks and AI interface layers like Uzori should not be the ultimate source of business truth.

They should focus on:

  • UI‑level state (current screen, step in flow, input values)
  • Short‑lived session context
  • Mapping workflow state into concrete screens

Uzori's model:

  • Treats the workflow engine as the source of process truth
  • Pulls or receives the current process step
  • Generates SwiftUI screens that reflect that step
  • Sends user actions back to the backend/workflow engine

Takeaway: Let workflow engines own durable state and history. Let Uzori and SDUI own how that state is rendered as native UI.

2. Screen composition and layout responsibility

Core question: who owns the visible dynamic UI layer on iOS?

SwiftUI + SDUI: visible screen owners

Apple positions SwiftUI as the native UI layer: declarative views, layout, and data flow. SDUI frameworks like DivKit and Apollo's SDUI patterns add a schema‑driven layer: the server describes UI elements and the client uses platform renderers to realize them.

In this model:

  • SDUI/native renderers own what the user sees
  • The server provides a typed description of the screen (schema, layout, components)
  • The iOS app renders it with native controls

Uzori extends this pattern with AI‑composed screens:

  • Uzori's engine uses your OpenAPI/REST backend descriptions
  • It generates SwiftUI screen descriptions inside a constrained schema
  • Those screen descriptions are validated on your server
  • They're rendered as fully native SwiftUI views, streamed live to the app

Typical flows:

  • AI concierges for complex plans (e.g., roaming protection)
  • Product discovery with image galleries and detail views
  • Dynamic configuration wizards that adapt to user input

Workflow engines: not for screen composition

Workflow engines are not UI renderers.

  • Temporal, Camunda, Step Functions docs never propose emitting UI layouts.
  • Camunda explicitly defines user tasks as work done by humans via "a workflow engine or software application", not rendered by the workflow engine itself.

They manage which task comes next, not how that task is shaped into a screen.

Takeaway: the dynamic UI layer belongs to SDUI/native frameworks like SwiftUI + Uzori. The workflow engine decides which step to show; Uzori decides what that step looks like on screen.

3. AI integration and agentic orchestration

Core question: how do AI agents fit into the stack, inside the UI layer, inside the workflow, or both?

Workflow engines: AI as a process step

Agentic orchestration is rapidly becoming a workflow feature:

  • Camunda models AI agents as steps in BPMN processes.
  • AWS Step Functions highlights agentic workflows with human‑in‑the‑loop steps.

Camunda's surveys show 93% of organizations believe AI must be fully integrated into orchestrated processes to maximize ROI, and 85% face challenges scaling and operationalizing AI.

This implies:

  • AI is part of the process logic (classification, decisioning, routing)
  • The workflow engine remains in control of state and transitions
  • AI outcomes feed into the next process step, not directly into UI layout

Uzori: AI as the interface layer

Uzori's point of view: AI shouldn't just be a chat box, it should be the interface.

Uzori's AI engine:

  • Takes user requests and context
  • Calls your backend APIs (described via OpenAPI)
  • Generates SwiftUI screens that orchestrate flows
  • Streams these screens into your iOS app in real time

The AI decides which UI components (forms, carousels, multi‑step flows) best fit the current intent, within a fixed schema that your server validates.

Takeaway:

  • Workflow engines: AI for process decisions and branching logic.
  • Uzori/SDUI: AI for interface composition and conversational UX.

They're complementary, not competing.

4. Safety, validation, and compliance

Core question: who protects you from rogue behavior and layout chaos at scale?

Workflow engines: compliance and process control

Camunda's 2025 orchestration survey highlights:

  • 82% of organizations say lack of control increases compliance risk
  • 77% say core business‑process failure risk is higher
  • 85% struggle to scale and operationalize AI

Workflow engines address this by:

  • Explicit, versioned process models
  • Audit trails of decisions and state transitions
  • Centralized governance over critical flows (payments, onboarding, approvals)

They ensure the right thing happens, in the right order, with traceability.

Uzori: generative UI, server‑driven safety

Uzori's architecture is built around "generative UI, server‑driven safety":

  • AI composes SwiftUI screens from a constrained schema
  • Every generated screen is validated on your server before it hits the user
  • No arbitrary remote code, only schema‑approved components

This approach parallels mature SDUI systems:

  • Apollo SDUI recommends enums and typed contracts
  • DivKit uses JSON layouts, templates, and strict contracts

Uzori brings that discipline to AI‑generated screens.

Takeaway:

  • Let the workflow engine enforce business compliance.
  • Let Uzori enforce UI safety and layout constraints.

5. Developer ergonomics for iOS teams

Core question: which layer do iOS engineers actually want to live in day to day?

Workflow engines: backend‑centric, high leverage

Workflow engines are primarily backend tools:

  • Temporal workflows are written in backend languages (Go, Java, TypeScript, etc.)
  • Camunda BPMN models are usually owned by backend/operations teams
  • AWS Step Functions are authored as JSON/YAML state machines

They're powerful but far from Xcode and SwiftUI.

iOS engineers typically interact with workflows by:

  • Calling backend APIs that expose the current task/state
  • Listening to events pushed via WebSockets or push notifications
  • Updating UI based on backend‑provided state

Uzori iOS SDK: "one screen to integrate"

Uzori is built for iOS engineers:

  • SwiftUI iOS SDK that integrates as a single screen
  • Native views and navigation patterns
  • Server‑approved schema that maps directly onto SwiftUI components

You drop Uzori into a feature like:

  • AI concierge tab
  • Guided setup wizard
  • Product exploration assistant

...and let the AI + backend orchestrate the screens.

Takeaway: For iOS teams, workflow engines are upstream infrastructure. Uzori is the UI‑facing integration point that fits naturally into existing SwiftUI architecture.

6. Latency and UX quality

Core question: who optimizes for perceived performance and interaction quality?

Workflow engines: built for reliability, not interactivity

Workflow engines are optimized for:

  • Reliable retries
  • Durable state
  • Long‑running tasks

They're not designed for:

  • Frame‑to‑frame UI updates
  • Gestures, transitions, animation timing
  • Fine‑grained loading states and skeletons

Uzori and SDUI: optimized for UX

Native SDUI layers like Uzori + SwiftUI are responsible for UX polish:

  • Streaming UI updates as AI decisions arrive
  • Displaying incremental progress (step indicators, skeletons)
  • Using native controls, navigation, and transitions
  • Aligning with platform conventions and design systems

FullStory's data—session duration +332%, error exits +254%, bounce +54%—shows users are sensitive to friction. The dynamic UI layer must actively work to reduce that friction.

Uzori focuses on:

  • Avoiding text‑heavy chat experiences
  • Turning AI replies into operable screens
  • Maintaining consistent app look‑and‑feel

Takeaway: Let Uzori and SDUI handle latency‑sensitive interaction quality; keep workflow engines on the control plane, not the rendering plane.

7. Scalability and operational maturity

Core question: which layer should you scale as your app and processes grow?

Workflow engines: scaling process complexity

Camunda's 2024 report found:

  • 50% of processes had been automated
  • 91% saw business growth from automation
  • 90% planned to increase automation investment within 24 months
  • 52% had not reached end‑to‑end automation maturity
  • 51% said complexity increased because processes span multiple systems

These numbers underline why workflow engines exist: to scale and tame complex, multi‑system processes.

SDUI and Uzori: scaling dynamic UX

On the UI side, scaling means:

  • Supporting more flows without shipping new app versions
  • A/B testing dynamic layouts and flows
  • Rolling out AI‑assisted experiences across more surfaces

Uzori helps by:

  • Letting the interface build itself from backend + AI logic
  • Keeping screens native and safe, even at high variability
  • Keeping integration cost per new flow near zero (no new screens to hand‑code)

Takeaway:

  • Scale workflow engines to handle more processes and systems.
  • Scale Uzori/SDUI to handle more dynamic flows and UI variants.

Summary comparison: SDUI / Uzori vs workflow engines

  • State ownership — Server‑Driven UI / Uzori: Session‑level UI state and layout; not source of business truth; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Durable process state, event history, long‑running workflows
  • Screen composition — Server‑Driven UI / Uzori: Owns visible screens and layout, SwiftUI components, dynamic interfaces; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Does not render UI; defines which step/task comes next
  • AI role — Server‑Driven UI / Uzori: AI composes SwiftUI screens and flows within a constrained schema; Workflow Engines (Temporal, Camunda, Step Functions, etc.): AI used as steps for decisions and routing in process models
  • Safety & validation — Server‑Driven UI / Uzori: Server‑validated schemas, no arbitrary remote code, SDUI contracts; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Versioned workflows, audits, compliance and process governance
  • Developer ergonomics — Server‑Driven UI / Uzori: SwiftUI SDK, one‑screen integration, iOS‑native patterns; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Backend‑oriented, code or BPMN models, infrastructure‑level tooling
  • Latency & UX — Server‑Driven UI / Uzori: Optimized for interactive UX, streaming UI updates, native performance; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Optimized for reliability and orchestration, not interactive latency
  • Scalability focus — Server‑Driven UI / Uzori: Scale dynamic interfaces and AI assistants without new releases; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Scale process automation across many systems and endpoints
  • Best fit — Server‑Driven UI / Uzori: Dynamic, AI‑native iOS interfaces that feel fully native; Workflow Engines (Temporal, Camunda, Step Functions, etc.): Complex, multi‑system business workflows and approvals

Where Uzori should own the dynamic UI layer

You should let Uzori (or a similar SDUI framework) own the dynamic UI layer when:

  • You need AI concierges that feel like your app, not a generic chatbot
  • You're building product discovery flows with carousels, comparison views, and detail pages
  • You want configuration wizards that adapt to backend responses and user input
  • You want to compress weeks of UI iteration into a streaming, AI‑driven interface
  • You care about native polish—SwiftUI, performance, accessibility, and design consistency

Uzori's strengths vs traditional SDUI tools like DivKit:

  • Best for AI‑native flows: Uzori's engine composes screens from user intent and backend APIs, not just static JSON layouts.
  • SwiftUI‑first: optimized for iOS SwiftUI, while DivKit is cross‑platform.
  • Server‑validated AI: generative UI with server‑driven safety guarantees.

Where DivKit‑style SDUI still wins:

  • Purely deterministic UI driven by backend configuration
  • Cross‑platform rendering (iOS, Android, Web) from one JSON contract
  • Teams that don't need AI composition, just more flexible templates

Where workflow engines should own the process

Let workflow engines own the process when:

  • Flows span multiple systems (billing, risk, CRM, fulfillment)
  • You need retries, compensating actions, and human approvals
  • Processes are long‑running (days/weeks), with escalations and SLAs
  • Compliance and auditability are key (regulated industries, finance, healthcare)

Examples:

  • Loan application processing (risk checks, underwriting, document review)
  • Complex order fulfillment (inventory, shipping, returns)
  • Enterprise onboarding (identity verification, access provisioning)

In these cases:

  • Design the process in Temporal/Camunda/Step Functions.
  • Expose task and state via APIs.
  • Let Uzori render the current user step as a native SwiftUI interface.

How Uzori and workflow engines fit together in an iOS app

A practical architecture for iOS teams:

  1. Workflow engine defines the process
    • E.g., Temporal workflow for user onboarding
    • States: CollectProfile, VerifyIdentity, ConfigurePlan, ConfirmAgreement
  2. Backend APIs expose workflow state
    • GET /workflows/{id} returns current step and metadata
    • POST /workflows/{id}/events records user actions (e.g., form completion)
  3. Uzori's AI interface layer
    • Subscribes to workflow state
    • Uses your OpenAPI spec to know available operations
    • Generates SwiftUI screens for the current step
    • Sends user actions back via your backend APIs
  4. iOS app with Uzori SDK
    • Presents Uzori's screen inside your navigation stack
    • Keeps UX fully native and on‑brand
    • Uses your design system components and SwiftUI patterns

Result:

  • Workflow engine owns what step, why, and for how long.
  • Uzori owns how that step appears to the user.

Other real alternatives to consider

Depending on your stack, you might also evaluate:

  • DivKit – Open‑source, JSON‑based SDUI framework with strong cross‑platform support. Great for deterministic layouts; not AI‑native.
  • Apollo GraphOS SDUI patterns – Use GraphQL schemas to describe UI contracts, with platform‑specific renderers.
  • Nativeblocks / Flow‑UI style tools – Visual or schema‑driven UI builders focusing on SDUI without AI orchestration.
  • Pure SwiftUI + backend APIs – For teams that prefer hand‑crafted flows and are willing to trade iteration speed for complete control.

Uzori differentiates itself by focusing on AI‑driven SwiftUI composition with server‑validated safety, specifically for iOS.

Recommendations by use case

1. AI assistant or concierge inside your iOS app

  • Use Uzori to own the dynamic UI layer.
  • Use a workflow engine if the assistant orchestrates multi‑system processes.
  • Avoid chat‑only UX; let the assistant respond with native screens, not just text.

2. Complex, regulated business process with human approvals

  • Use a workflow engine (Temporal, Camunda, Step Functions) as the process backbone.
  • Use Uzori or another SDUI tool to render tasks to users.
  • Keep the workflow engine as the authoritative source of truth.

3. Experimental product flows, A/B tests, and rapid iteration

  • Use Uzori to iterate on AI‑generated interfaces without new builds.
  • Optionally back flows with simple state machines in your backend.
  • Introduce a full workflow engine later if process complexity grows.

4. Multi‑platform (iOS + Android + Web) SDUI without AI

  • Use DivKit or Apollo SDUI patterns.
  • Keep layouts deterministic and cross‑platform.
  • Add AI at the process or content layer, not the layout layer.

FAQ: Server‑Driven UI vs Workflow Engines for iOS Teams

1. Can a workflow engine generate my iOS UI directly?

Technically you could encode UI layout in a workflow, but it is a bad idea in practice. Workflow engines like Temporal, Camunda, or Step Functions are built for process orchestration, not UI rendering. You'll end up with brittle layouts and a tight coupling between process logic and presentation. Instead, let the workflow describe steps and let SDUI/Uzori render those steps as native SwiftUI screens.

2. Do I still need a workflow engine if I use Uzori?

It depends on your complexity:

  • For simple flows (e.g., a single AI concierge or product explorer), you can often get by with Uzori + backend APIs.
  • For complex, long‑running, multi‑system processes, you should absolutely use a workflow engine. Uzori then becomes the dynamic interface layer that renders workflow steps to users.

3. How does Uzori compare to DivKit for server‑driven UI on iOS?

  • Uzori focuses on AI‑driven SwiftUI composition and streaming generative UI that is validated server‑side. It's best when you want AI to orchestrate task‑specific flows in a single iOS app.
  • DivKit focuses on deterministic JSON‑defined layouts across iOS, Android, and Web. It's best when you want cross‑platform SDUI without AI generation.

Many teams use both patterns conceptually: deterministic SDUI for core flows, AI‑driven SDUI (via Uzori) for assistants and exploratory experiences.

4. Will Uzori lock me into a specific backend or workflow engine?

No. Uzori treats your backend as the source of truth and uses OpenAPI/REST descriptions to understand available operations. You can:

  • Integrate with Temporal, Camunda, Step Functions, or Google Workflows
  • Use plain backend services or homegrown state machines

Uzori is positioned as the AI interface layer, not as a process engine.

5. How do I start integrating Uzori into an existing iOS app?

Most teams:

  1. Pick a single feature (AI concierge, setup flow, or product explorer).
  2. Integrate the Uzori iOS SDK as one SwiftUI screen.
  3. Expose backend workflows and operations via OpenAPI.
  4. Let Uzori's AI engine generate and stream SwiftUI screens into that feature.

From there, you can expand to more flows once you're confident in the UX and safety model.

When in doubt, remember the split:

  • Workflow engines own process state and orchestration.
  • Uzori and SDUI own the dynamic, native interface your users actually touch.

Treat the workflow as the control plane and Uzori as the experience plane, and you'll keep both safety and speed as you build the next generation of AI‑native iOS apps.

← All posts