Breaking Up with WebViews with SDUI

Server Driven Cross-Platform UI Revolution to Take Over WebViews

WebViews are everywhere — they're fast to deploy, easy to update, and flexible.
But they’re also brittle, hard to maintain, and pose serious security risks to the app,
especially for fintech domains.
We asked ourselves: Is there a better way to deliver dynamic content across platforms
without the WebView baggage?

In this session, we’ll share how we’re replacing WebViews with a fully native,
server-driven UI framework built using
Kotlin Multiplatform
and
Jetpack Compose Multiplatform.

You’ll get a deep dive into how we designed our dynamic UI engine,
how we defined a JSON-based UI schema, and how we ensured
performance and flexibility across Android, iOS, and Desktop
— all in a single Kotlin codebase.

Expect real-world lessons from our rollout, performance benchmarks,
and how Compose Multiplatform helped us build fast
without learning Flutter or React Native.

If you’re tired of maintaining complex WebViews and want a modern, secure,
cross-platform Kotlin-native solution for dynamic UI,
this talk is for you.

Transcript

1. Aman Tonk September 11, 2025 Breaking Up with WebViews Server-Driven UI with Kotlin Multiplatform 1
2. 2 Aman Tonk Android Engineer AmniX About Me!
3. 3 3 3 1 Webviews and their pros & cons 2 How Server Driven UI can help 3 Sample SDUI framework with KMM 4 Scale SDUI to production Outline!
4. WebViews! Question: What Are WebViews? Simplest ever Answer: An Android view that shows web content right inside your app. 4
5. 5 5 5 Why WebViews? • Fast Updates • Cross-Platform • Cost-Effective • Web Ecosystem
6. 6 6 6 Thoughts? 🤔
7. 7 7 7 WebView Cons • Runs slowly and uses a lot of memory. • Feels laggy and not so smooth. • Cannot fully use phone features. • Debugging is difficult.
8. 8 8 8 Security Concerns! • Open to web attacks. • Can leak sensitive data. • addJavascriptInterface, Web code can control the app • Blind trust: You must fully trust the developer.
9. 9 9 9 Security Concerns!
10. 10 10 10 WebViews: A Liability
11. 11 11 11 What is the alternative? • Native apps are faster and smoother than WebViews. • But we still need dynamic updates and experiments. • Server-Driven UI combines native performance with dynamic content.
12. 12 12 12 What is SDUI? The server sends a UI schema, and the app renders it with native widgets. • The server describes the UI, the client maps schema to real views and shows them • Instant updates across platforms.
13. 13 13 13
14. 14 14 14 The Core Principles • Server controls the app. • Not just what to show, but how, when, and what actions to take. • The app just receives instructions and acts.
15. 15 15 15 Client-Side & Data Exchange • The app has a library of native UI components. • The server sends UI as simple JSON. • App will map json to UI • Defines actions for user interactions.
16. 16 16 16 SDUI v/s WebViews WebViews Limitations SDUI Benefits Security Vulnerabilities Store sensitive logic on the server, minimizing vulnerabilities in client-side code. Performance Issues Native Performance Maintenance Headaches & Increase Client-Side Complexity Reduced Client Complexity & Centralized Maintenance Limited Personalization Dynamic Personalization & Efficient A/B Testing Cross-Platform Inconsistencies A single backend manages UI structure across Web, iOS and Android ensuring an uniform experience.
17. 17 17 17
18. 18 An SDUI Framework With Kotlin MultiPlatform
19. 19 19 19 But, Why KMM? • Why not? As an Android dev, Kotlin is home. • Remains Native for Android • Write code once, run it everywhere. • SDUI is hard enough, don’t build it twice.
20. 20 20 20 KMP + CMP: A strong combo • Shared UI + logic on Android and iOS with native speed. • Android stays 100% native. • Mature ecosystem. • Add platform-specific code when needed. • iOS is stable, ship confidently.
21. 21 The Architecture with KMM
22. 22 From Server to Screen • Server sends the UI JSON • Kotlinx serialization parses it • A type-to-component resolver • Memory level state management • Compose then draws the resolved components to the screen.
23. 23 From Server to Screen • Components handle interaction events. • Events go back to the server or are handled locally. • Default UIs and values are applied during mapping.
24. 24 Enough Talking, ShowMeTheCode()
25. 25 First let’s see, What’s not SDUI
26. 26 This is NOT SDUI
27. 27 This is SDUI
28. 28 This is SDUI
30. 30 30 30 • Here are the basic data transfer objects. • Some fields are required, others are component-specific. • The list can grow as needs evolve. DTOs
31. 31 31 31 • Here we will deserialize JSON to our DTOs. • Use kotlinx.serialization • We will have a pseudo validation layer • Error handling Serialization
32. 32 32 32 • Kept it simple. • Check for data not supported in this SDUI version. • The resolver decides to render or skip based on severity. Validation
33. 33 33 33 • SduiMainComponent is the main entry point. • It receives the parsed DTO. • Rendering uses a plain type-based mapping. Entry Point
34. 34 34 34 • Sample SDUI rendering • Types are already validated by the validation layer. • Use the mapped native widget for the component type. TextComponent
35. 35 35 35 • Serializable style object • Layout and typography • Visuals: color, borders, shadows • Flex and responsive sizing Styling
36. 36 36 36 • Sealed, serializable action model. • JSON maps to specific action types. • Supports chained actions. Actions
37. 37 Let’s Assemble everything. Now, witness the demo.
38. 38 38 38 Sample Code
39. 39 How we could scale SDUI to production
40. 40 Create your own SDUI library • Plenty of open-source options. • Use your design style. • Get designers involved. • Make many widgets.
41. 41 Design a Json Schema • Schema enables pre-validations. • Server manages schema. • AI can build UIs. • Support schema versioning.
42. • QA, Design, Product review first. • Desktop app preferred. • Playground should give clear errors. • Works with current dashboards. • Multiplatform support 42 Playground to test
43. 43 Start with smaller parts • Not all screens can use SDUI. • Use for onboarding, signup, feedback. • Then highly dynamic screens (like home or after sale). • Add analytics for better tracking.
44. 44 Security & Compliance • SDUI is for UI only. • Never send sensitive data (like API keys). • Encrypt data and reuse app-side variables.
45. 45 Compatibility Testing • New vs old SDUI library versions. • Server matches schema to app version. • Avoid breaking changes. • Minimize fallback UI usage.
46. 46 Success stories Who uses SDUI?
47. 47 Reddit Reddit uses SDUI for its feed, fetching layout JSON from the backend to render UI dynamically. Source
48. 48 Netflix Netflix’s Tudum platform uses SDUI to deliver content for web, mobile, and TV devices. Source
49. 49 Airbnb Airbnb uses SDUI for its listing screen so it can iterate faster without waiting for app updates. Source
50. 50 And more… Other companies like Lyft, Yelp, Yandex, Delivery Hero, and RapiPay also use SDUI in their apps and benefit from easier UI updates.
51. 51 The Future • AI-Powered UI • Hyper-Personalization • Seamless Apps • More Adoption
52. 52 Integrating with AI Systems • AI creates or updates UI schemas instantly. • Uses context like location and device status. • UI changes ahead of user needs. • Supports real-time, data-driven optimization. • Blends analytics and ML for the best user UI.
53. 53 Breaking Up for a better future • WebViews: quick but risky long-term. • SDUI: agile and secure. • KMP + Compose: best native SDUI. • Embrace SDUI for better apps.
54. Thank you Questions? Contact amantonkem@gmail.com Curious to dive deeper? Please scan the QR Code for a detailed blog.
55. 55 Appendix • Detailed Blog • Github Repo of the Sample • SDUI Sources: Lyft, Yelp, Yandex, Delivery Hero, RapiPay