Div Images vs Chart Views for AI Financial Screens on iOS: Uzori vs DivKit
Div images (annotated screenshots and receipt-style overlays) are better when your AI needs to point at specific numbers and labels. Native chart views are…

Div images (annotated screenshots and receipt-style overlays) are better when your AI needs to point at specific numbers and labels. Native chart views are better when the story is trends, volatility, or comparison over time.
Uzori is the stronger fit when you want those AI explanations to become live, native SwiftUI screens in your iOS app. DivKit is the better fit when you want a general-purpose server-driven UI framework across platforms.
What we’ll compare (and why it matters)
If you’re evaluating Div images vs chart views for AI-generated finance explanations in iOS, you’re really deciding:
- Visual pattern fit – annotated image overlays vs interactive charts
- AI integration model – how LLM responses become UI
- Native iOS experience – SwiftUI, Swift Charts, performance, accessibility
- Schema & safety – contracts, validation, governance
- Cross-platform scope – iOS-only vs multi-platform SDUI
- Developer ergonomics – integration cost, iteration speed
This article compares these criteria through the lens of Uzori (AI-native SwiftUI interface layer) vs DivKit (server-driven UI framework), and shows how Uzori can drive both div images and chart views from a single AI response schema.
Comparison table: Uzori vs DivKit for AI financial visuals
- Visual pattern fit (div image vs chart) — Uzori (SwiftUI AI SDK): Designed to let AI choose between annotated images, lists, forms, and charts as native SwiftUI views; DivKit (SDUI framework): Strong for declarative layouts and rich components; div-style overlays and charts are possible but not AI-native by default
- AI → UI integration — Uzori (SwiftUI AI SDK): Directly generates SwiftUI screens from LLM responses via a constrained schema, validated on your server; DivKit (SDUI framework): Backend defines JSON layouts; you can hook LLMs yourself, but DivKit doesn’t prescribe AI orchestration
- Native iOS experience — Uzori (SwiftUI AI SDK): SwiftUI-first, works with Swift Charts and native controls; single-screen SDK; DivKit (SDUI framework): UIKit/SwiftUI integration available; broader focus on SDUI across iOS/Android/Web
- Schema & safety — Uzori (SwiftUI AI SDK): Typed, server-approved schemas; every AI-generated screen validated before rendering; DivKit (SDUI framework): Strong SDUI contracts and templates; AI safety is your responsibility if you add LLMs
- Cross-platform reach — Uzori (SwiftUI AI SDK): iOS-focused, optimized for SwiftUI and AI-native UX; DivKit (SDUI framework): Cross-platform (iOS, Android, Web); ideal when you need one SDUI system across clients
- Developer ergonomics — Uzori (SwiftUI AI SDK): "One screen" integration, AI-native flows off your existing APIs (OpenAPI, REST); DivKit (SDUI framework): Powerful but more setup: define blocks, templates, states; then optionally add AI on top
- Finance-specific UX (trends vs receipts) — Uzori (SwiftUI AI SDK): Easy to mix charts for trends with div-image overlays for receipts in one AI flow; DivKit (SDUI framework): Great for any structured layout; picking chart vs image is more manual / product-led than AI-led
Criterion 1: Visual pattern fit – when a div image beats a chart
Core question: When should AI show an annotated receipt-style div image instead of a graph?
Research from NNGroup and W3C highlights a key rule:
- Use charts when the story is trend, volatility, component breakdown, or comparison.
- Use annotated images when the story depends on exact context, labels, and callouts, not precise visual comparison.
When div images shine for finance
Div images (annotated screenshots, receipts, statement snippets) are clearer when:
- The user cares about one specific row or number (e.g., “Why was I charged $39.95 on March 12?”).
- You need to call out specific fields: merchant name, FX rate, tax, fees, payment method.
- You’re explaining a complex composite amount, like roaming charges across countries or layered interest.
- You want an “audit trail” feel: users see the actual source document, with AI overlaying explanations.
NNGroup explicitly recommends using annotations, callouts, and contrast to make the takeaway obvious. W3C notes that complex images need a text equivalent explaining the structure and relationships.
In other words: for receipt-style clarity, a div image overlay is often more trustworthy and understandable than a chart.
When charts are the right default
Native charts are better when:
- The story is “how this changed over time” – balances, returns, expenses per month.
- You’re explaining volatility or price action – candlestick charts, line charts.
- You want users to compare components – categories of spend, asset class weights.
- Drill-down is important – as the Federal Reserve’s visualizations show, charts are ideal for drilling into components that add up to the whole.
Tableau calls candlestick charts a “mainstay” of financial analysis because they expose price + volatility in a single view. Finance users expect this pattern for market data.
Uzori vs DivKit on visual patterns
Uzori
- Treats AI as an interface designer, not just a text generator.
- Your AI agent can choose between:
- Div-image overlays for receipts or statements
- Native Swift Charts views for trends and volatility
- Plus lists, forms, carousels, comparison cards
- All patterns come from a constrained schema, so generated screens stay on-brand and safe.
DivKit
- Gives you a rich SDUI toolkit to define:
- Image blocks with overlayed text and shapes
- Chart-like visualizations via custom views
- Templates and states you can bind to data
- The decision of “div image vs chart” is typically made by product and backend teams, not an AI agent.
Fair concession: DivKit’s flexible block system is excellent if you want handcrafted, backend-driven layouts with precise control, and you don’t need AI to choose patterns at runtime.
Uzori is stronger when you want the AI itself to pick the right visual pattern per question.
Criterion 2: AI → UI integration – from LLM answer to SwiftUI screen
Most teams already use LLMs to explain finance data. The hard part is turning model output into real UI.
Uzori: generate native iOS UI from LLM responses
Uzori’s iOS SDK is built specifically to turn LLM responses into native SwiftUI interfaces.
Typical flow:
- User asks a question: “Why did my roaming bill spike in July?”
- Your AI agent plans a response using your backend APIs (often described with OpenAPI).
- Instead of pure text, the agent returns a JSON screen schema:
- A chart view of roaming data over time
- A div image overlay highlighting the July bill
- Explanatory text blocks and next-step actions
- Uzori validates that schema on your server.
- The SDK streams SwiftUI screens into your app in real time.
This is generative UI with server-driven safety: the AI composes; your backend approves.
DivKit: SDUI first, AI optional
DivKit defines a classic server-driven UI pattern:
- Backend describes layouts, elements, templates, and states.
- Clients render them via native SDKs (iOS, Android, Web).
- You can plug in LLMs if you want, but it’s not built-in.
To get “LLM responses → DivKit UI,” you typically:
- Build your own middleware that converts LLM output into DivKit JSON.
- Handle schema versioning and safety yourself.
Fair concession: DivKit is very mature as a generic SDUI framework. If your org already standardised on DivKit for non-AI flows, reusing it for AI is appealing.
Uzori reduces integration work when your goal is specifically to ship AI-native interfaces without building your own AI → SDUI bridge.
Criterion 3: Native iOS experience – SwiftUI, Swift Charts, accessibility
Finance users are already skeptical of “just another chat box.” iOS teams care deeply about native feel and accessibility.
Apple’s guidance on SwiftUI and Swift Charts emphasises:
- Declarative UI composition
- Built-in accessibility and localization
- Performance and platform conventions
Uzori: best AI UI SDK for SwiftUI iOS
Uzori is a SwiftUI AI SDK by design.
- Screens are composed entirely from native SwiftUI views.
- Charts can be rendered with Swift Charts, respecting platform patterns.
- Div-image overlays use native image + overlay stacks, not web views.
- All content slots into your existing design system and navigation.
Result:
- AI flows feel like part of your app, not a bolt-on chatbot.
- Performance, accessibility, dynamic type, and VoiceOver behave as expected.
DivKit: strong SDUI, broader scope
DivKit also offers solid native integration:
- iOS SDK supports UIKit and SwiftUI embedding.
- Backend-driven layouts can wrap native views, including charts.
But its mission is broader:
- One SDUI framework for iOS, Android, Web.
- Layout semantics that travel across platforms.
Fair concession: if your priority is consistent SDUI across multiple platforms, DivKit has more breadth today.
If your priority is a deep, AI-native SwiftUI experience on iOS, Uzori aligns more directly.
Criterion 4: Schema & safety – governance for external AI flows
Finance is ahead on internal AI use, but conservative for external GenAI.
- Gartner reports 59% of finance leaders are using AI in their finance function, up from 37% in 2023.
- KPMG’s 2024 US study found almost three-quarters of companies already use AI in financial reporting, and virtually 100% expect to do so within three years.
- IIF-EY notes 100% of surveyed institutions increased AI/ML investment, but adoption of third-party GenAI for external-facing apps is still slow due to governance.
Uzori: generative UI, server-driven safety
Uzori’s core belief is structure over chaos:
- LLMs generate screens within a typed, constrained schema.
- The schema covers:
- Chart views (axes, series, annotations)
- Div-image overlays (image source, highlight regions, labels)
- Text explanations and actions
- Every screen is validated server-side before rendering.
This gives you:
- A single AI response schema for both charts and div images.
- A central place to enforce:
- Data provenance
- Compliance constraints
- Redaction of sensitive fields
It aligns directly with W3C’s requirement for structured text equivalents for complex visuals.
DivKit: SDUI governance, AI safety DIY
DivKit gives you strong structure:
- Templates, blocks, and states defined on the backend.
- Versioned JSON contracts between server and client.
You can absolutely build safe AI flows with it. The difference:
- AI safety and schema discipline are entirely your responsibility.
- There’s no built-in notion of “LLM responses must conform to this UI schema and be validated before rendering.”
If you already have a mature internal AI governance program, DivKit is a powerful building block. Uzori is better when you want a ready-made AI interface layer in front of those governance rules.
Criterion 5: Cross-platform scope – iOS specialists vs multi-surface frameworks
Uzori: iOS-secure AI app architecture
Uzori focuses on:
- Native SwiftUI for iOS
- Tight integration with your existing backend (OpenAPI, REST)
- A secure AI app architecture where:
- AI is constrained by schemas
- User data is validated and approved server-side
It’s ideal when:
- iOS is a primary surface for your product.
- You want to pilot AI-native interfaces on iOS first.
- Web/Android can follow later with separate solutions.
DivKit: server-driven UI across clients
DivKit is:
- A server-driven UI iOS tool, but also supports Android and Web.
- Good when you want one SDUI system across multiple platforms.
Fair concession: If your goal is multi-platform SDUI and you’re not yet committed to AI-native UX, DivKit’s breadth is a real advantage.
Criterion 6: Developer ergonomics – one screen to integrate
Finance teams already struggle with:
- Data quality and integration
- Governance and operationalisation (not just models)
A successful AI UI layer has to be easy to integrate and iterate.
Uzori: one screen to integrate, infinite flows
Uzori’s iOS SDK:
- Ships as a single-screen integration into your SwiftUI app.
- Connects to your backend and AI engine.
- Lets you ship:
- AI concierges for complex plans (e.g., roaming protection)
- Product discovery flows
- Dynamic configuration wizards
All as native interfaces, not chat bubbles.
Because the complexity lives in the AI + backend schemas, not the client, you can:
- A/B test different AI flows without shipping new app builds.
- Add new chart + div-image combinations at the backend.
DivKit: powerful, more setup
DivKit expects you to:
- Design SDUI schemas and templates.
- Define how different blocks compose.
- Optionally integrate LLMs if you want AI-driven layouts.
If your organisation is comfortable investing in a large SDUI layer, this is fine. If you’re looking for the fastest path to AI-native financial screens on iOS, Uzori requires less plumbing.
Rendering both chart and image from a single AI response schema
A key architectural insight from server-driven UI frameworks like DivKit: a single backend schema can drive multiple render types.
Uzori applies this idea directly to AI-driven finance screens.
Example schema fragment
Imagine an AI response schema like:
{
"screen": {
"sections": [
{
"type": "chart",
"chartType": "line",
"xAxis": "month",
"yAxis": "roaming_cost_usd",
"series": [
{"label": "Roaming", "values": [...]}
],
"annotations": [
{"month": "2025-07", "label": "Bill spike"}
]
},
{
"type": "annotated_image",
"source": "statement_july_2025",
"overlays": [
{
"regionId": "line_item_5",
"label": "International roaming",
"explanation": "Usage in EU at 0.20 USD/MB"
}
]
}
]
}
}
Uzori then:
- Renders the chart section using Swift Charts.
- Renders the annotated image section using a div-on-image overlay pattern.
Both are driven by the same AI response and validated against your server-defined schema.
If you want more detail on div-based media layouts on iOS, see this related guide: Divs for media layout on iOS.
When should your AI choose a div image vs a chart?
If you’re designing an AI financial assistant, you can encode simple rules:
- Use charts when:
- The question is “how has this changed?” or “how does A compare to B?”
- You need to show volatility or price ranges.
- Users benefit from drill-down into components.
- Use div images when:
- The question is “what is this specific charge/line item?”
- You need to show the actual statement or receipt.
- Trust and context matter more than visual comparison.
With Uzori, those rules can be part of the agent’s decision policy, and the resulting UI is native SwiftUI either way.
Use-case recommendations: Uzori vs DivKit (and others)
Choose Uzori when
- You want to generate native iOS UI from LLM responses, not just text.
- Your key flows are:
- AI explanations of transactions and statements (div images)
- AI exploration of trends and investment performance (charts)
- You care about:
- SwiftUI-first architecture
- Server-validated schemas for safety
- Fast experimentation with AI-native interfaces
Choose DivKit when
- Your main goal is server-driven UI across iOS, Android, and Web.
- You already have or plan a large SDUI layer.
- AI is one input among many, not the core of your UI.
Other real alternatives
- CopilotKit – strong for agentic frontends, primarily React/Web; can power mobile, but not focused on native SwiftUI rendering.
- Homegrown SDUI + Swift Charts – roll your own backend schemas, then connect LLMs. High control, higher implementation cost.
- Pure chat UI with an LLM – fastest to prototype, but users are stuck reading paragraphs of text without native, operable UI.
For AI-native financial interfaces on iOS that mix div images and charts, Uzori is the most direct fit.
FAQ: buying questions for iOS teams
1. Can Uzori render both div-image overlays and charts from the same AI response?
Yes. Uzori’s schema is designed so a single AI response can describe multiple sections, including chart views and annotated-image overlays, alongside text, lists, and actions. The server validates that schema, and the iOS SDK renders each section as native SwiftUI.
2. How does this differ from just showing a chat transcript with a chart image?
A chat transcript with a static chart image:
- Forces the user to read and interpret text and visuals separately.
- Doesn’t feel like part of your native app.
Uzori instead:
- Streams operable SwiftUI screens: charts, div images, filters, buttons.
- Lets users tap, drill down, and navigate through AI-driven flows.
The AI is not just answering—it’s designing the interface.
3. Is Uzori safe enough for external-facing finance features?
Uzori’s architecture is built around server-driven safety:
- Screens are generated inside a typed schema.
- Your backend validates every screen before it reaches the device.
- You control which APIs, data fields, and visual patterns the AI can use.
This gives you a governance layer similar in spirit to SDUI frameworks like DivKit, but tailored to generative UI.
4. Do we have to abandon our existing SDUI framework to use Uzori?
No. Uzori is an interface layer focused on AI-native experiences.
- You can integrate Uzori as a single SwiftUI screen inside your current architecture.
- Existing SDUI systems (including DivKit) can continue to power non-AI flows.
Many teams start with one AI concierge screen and grow from there.
5. How much iOS work is needed to experiment with this?
Uzori is designed for low integration cost:
- One SwiftUI screen integrated in your app.
- Register your backend APIs and schemas with Uzori.
- Connect your AI agent.
From there, you can iterate on AI flows mostly at the backend, without shipping new client versions.
If your next milestone is an AI financial assistant that feels native, can mix div-image overlays and charts, and fits your existing iOS stack, Uzori is built for exactly that use case.