DivKit vs Nativeblocks

Alireza Fard

07/04/2025

A developer-first deep dive into two Server Driven UI platforms

Why SDUI is worth talking about

Mobile teams today are shipping faster than ever — but your UI updates are still stuck behind app store releases. You build a screen. The product team wants a change. You update the code, submit to the store, wait for review, and finally the change goes live.

Two weeks later, it happens again.

Server Driven UI (SDUI) fixes this. Instead of hardcoding every screen, your app renders UI based on a layout sent from the server. Update the backend, and your app updates instantly — without shipping a new build.

If you're looking at SDUI seriously, two options probably stand out: DivKit and Nativeblocks.

They sound similar, but the experience using them — and scaling with them — is completely different.

What DivKit is

DivKit is an open-source layout engine created by Yandex. You define your screens using JSON. The DivKit SDK reads that layout and renders your UI dynamically.

It supports Android, iOS, and Web. It comes with its own set of components — containers, text, buttons, images, and so on — and renders them based on the layout defined in the backend.

You can't use your own components. If you want a custom design or interaction, you have to extend the DivKit engine itself. You also have to write and manage the layout JSON yourself or build your own UI editor and deployment system.

It's a powerful engine. But it expects you to build the rest.

What Nativeblocks is

Nativeblocks is a complete SDUI toolchain designed for modern native apps. It lets you create, update, and deliver UI layouts remotely — using your own components and design system.

It works directly with SwiftUI, Jetpack Compose, and React. Your UI logic stays native. Nativeblocks just tells your app how to render it, not what components to use.

This gives you total control over UI behavior, performance, and styling — with none of the restrictions or overhead of using a fixed component library.

More importantly, Nativeblocks gives you the full workflow out of the box:

• SDKs for iOS, Android, and Web (React)
• A layout compiler
• A visual Studio for editing screens
• CLI tools
• Device preview
• Hot reload
• Component versioning
• Dynamic logic and actions
• A fully self-hostable toolchain (cloud optional)

You're not just getting a renderer. You're getting a system.

SDK size and app footprint

This is a real concern, especially on mobile.

DivKit includes a full set of internal components. That means your app carries every layout, style, and rendering rule — even if you don't use all of them. These baked-in components increase your final app size significantly, especially on iOS where static linking adds up fast.

Nativeblocks, on the other hand, uses your app's own components. There's no built-in rendering engine and no bundled UI library. The SDK itself is extremely lightweight because all the heavy lifting is already handled by SwiftUI, Compose, or React.

The result? Smaller SDK. Smaller final bundle. Faster startup time. Zero duplication.

Component architecture

DivKit forces you into its world. It provides a fixed set of components, layouts, and behaviors. Want to change them? You modify the engine. Want to extend it? You implement new internal nodes, write serializers, and test against their layout system.

It's possible — but not simple. It also means your design system has to match DivKit's.

Nativeblocks does the opposite. You build your components the way you always do. SwiftUI, Compose, React — your code, your style, your logic. Then Nativeblocks connects backend-driven data to those components through clean, type-safe contracts.

It works with your architecture, not against it.

Platform support

• DivKit supports Android, iOS, and Web, with a goal of consistency across all three. It uses its own internal rendering engine across platforms to keep things uniform.
• Nativeblocks supports Android, iOS, and Web too — but integrates with each platform natively:
• SwiftUI on iOS
• Jetpack Compose on Android
• React for Web

This means Nativeblocks doesn't simulate UI. It uses your real components on each platform, giving better performance and a more natural developer experience.

Tooling and developer workflow

DivKit gives you a rendering SDK and a schema. That's it. There's no official editor, no CLI, no live preview system, no version control, no hot reload. You'll have to build all those tools yourself.

Nativeblocks gives you all of it out of the box:

• Core SDK – lightweight and fully native
• Compiler – converts your block tree into efficient layouts
• Studio – visual layout editor for both developers and non-devs
• CLI – build, test, and deploy layouts directly from the terminal
• Hot Reload – preview changes instantly without rebuilding
• Device Preview – see layout updates on a real device in seconds
• Component Versioning – control rollout and safely ship changes
• Dynamic Logic – add conditions, API calls, and actions from the backend

Everything you need to build and ship faster is already there.

Scaling in the real world

DivKit might be okay for small apps or MVPs where you only need a few basic screens. But as your product grows, the limitations add up fast.

Adding a new UI component? You have to extend DivKit's rendering system.

Want to support different layouts for different users or experiments? You'll need to build a versioning system on your own.

Trying to scale to multiple teams working on different screens? You'll run into friction with layout conflicts and schema drift.

You end up adapting your team to the tool — not the other way around.

Nativeblocks is built for scaling. You don't need to change your architecture. You just plug Nativeblocks into it. Every team can work on their own layouts independently. You can version components, roll out experiments, preview changes instantly, and keep using the tools your team already knows.

Whether you're launching new features, testing flows, or managing multiple apps — it just works.

Final comparison

The takeaway

DivKit is a solid rendering engine. But it brings a lot of assumptions — and it requires you to adapt your workflow to its rules. As your app grows, those constraints turn into blockers. You'll need to build your own tooling, manage your own schemas, and wrestle with performance as the component set grows.

Nativeblocks gives you everything you need from day one. You use your own components. You keep your design system. You get fast iteration, small app size, and tools that help you scale without complexity.

It doesn't just help you render screens. It helps your entire team build, test, and ship faster — without sacrificing flexibility.

If you're building for real users and planning to grow, Nativeblocks is the clear choice.