# DivKit: a Server-Driven UI framework with clients for Android, iOS and Web

> DivKit renders JSON layouts on Android, iOS and Web from one schema, with server-side builders in TypeScript, Kotlin and Python. It fits teams that want to ship UI changes without an app release, and not teams targeting Flutter or React Native.

**divkit/divkit** — DivKit is an open source Server-Driven UI (SDUI) framework. SDUI is a an emerging technique that leverage the server to build the user interfaces of their mobile app

- Repository: https://github.com/divkit/divkit
- Website: https://divkit.tech
- Stars: 2,675 · Forks: 194
- Language: Kotlin
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/divkit-divkit

## What DivKit solves, and who it is actually for

DivKit is an open source Server-Driven UI framework. The README states its purpose plainly: it lets you roll out server-sourced updates to different app versions, and it can be used for fast UI prototyping by writing a layout once and shipping it to iOS, Android and Web. That second use case is the one most teams underestimate. You do not need a backend to start. The README says that at the starting point you do not need server integration, and that you can include all JSON on the client side to try it in a real application.

The intended audience is a product team with more than one client platform. If you maintain an Android app and an iOS app and a web front end, three implementations of the same screen drift apart. DivKit moves the layout description into JSON that all three render. The repository lists clients for Android, iOS and Web, so the three-platform claim is structural rather than aspirational.

The README also lists clients such as Yandex Browser, Yandex Search, Yandex Music, Alice Voice Assistant, Yandex Market, Zen, Smart Camera, Yandex Realty, Edadeal, Mobile Ads SDK and Yandex bank. Those names tell you the scale of deployment the project has seen, but they say nothing about whether the integration is easy for a small team. Treat them as context, not as a recommendation.

## The architecture: one schema, three clients, three JSON builders

The repository is split along a clear line. Client-side libraries render UI, and they live under client/android, client/ios and client/web/divkit. Server-side libraries build JSON in the DivKit format, and they live under json-builder/typescript, json-builder/kotlin and json-builder/python. A schema directory holds the JSON schema that describes the DivKit data format, and an api_generator directory generates a common API for all platforms from that schema.

That generator is the interesting part. Rather than hand-writing three renderers that drift, the project derives platform APIs from a single schema. The practical consequence for you is that the JSON your server produces is the contract. If the schema does not describe a property, no client will render it, and a client that receives an unknown field has no schema-level guarantee about how it behaves.

The data flow follows from that layout. Your backend emits a JSON document. Each client parses it against the schema and renders it as native views. There is no shared runtime that draws pixels identically across platforms; each platform renders with its own toolkit. That is why DivKit can be dropped into an existing app as a view, and also why visual parity across platforms is something you verify rather than assume.

The README notes that the project maintains a sandbox at divkit.tech/playground where you can try samples in a web editor and see the results on the web or in the Android demo app, and that the sandbox connects to the demo app over web sockets so the UI updates live. A visual-editor directory and a figma-plugin directory sit alongside the clients, which suggests the tooling around authoring layouts is part of the project rather than an afterthought.

## Getting a first DivKit layout on screen

The README does not give a single install command. It points to the DivKit website, divkit.tech, for samples and documentation, and the repository carries the platform sources under client/android, client/ios and client/web/divkit. The json-builder directory is where server-side code lives. Start from the documentation site rather than guessing at a package name, because the README does not print one.

The lowest-friction path the README describes is the one that skips the server entirely. You write a DivKit JSON document, keep it in the app, and hand it to the renderer. The README states that you can include all JSON on the client side to try it in a real-world application. The schema directory in the repository is the reference for what such a document may contain, since the README does not reproduce a sample document itself.

The second path is the sandbox. Open divkit.tech/playground, edit a sample in the web editor, and watch the result in the browser. If you also install the Android demo app, the README says the sandbox connects to it over web sockets, so edits appear on the device. For an iOS demo app the README says it will be published shortly, so do not plan a device test around it.

The third path is server-side. Use one of the builders under json-builder to emit the same document from your backend, in TypeScript, Kotlin or Python. Because those builders and the clients are generated from the same schema, the document you produce on the server is the one the clients expect. The README does not document a versioning or rollback story for documents already shipped to old app versions, so plan your own compatibility testing before you rely on that.

## Where DivKit is the wrong tool

The repository's client directory lists Android, iOS and Web. Flutter and React Native do not appear there. If your product ships only as a Flutter app, DivKit's rendering libraries do not cover your target, and neither the README nor the repository layout suggests otherwise. That is a hard boundary, not a gap that a wrapper closes.

There is a second boundary around scope. DivKit renders a layout described in JSON. It is not a general application framework and the README does not present it as one. If your screens depend on custom native views, platform-specific gesture handling or drawing that the schema does not describe, the JSON document cannot express them, and you fall back to native code for those parts.

The README's own framing is worth reading carefully. It says DivKit can be easily integrated as a simple view in any part of your app. That is a claim about integration granularity, not a claim that a whole screen is easy. A screen assembled from many divs, with states and templates, is a different amount of work from a single text div.

Finally, the licence. The repository metadata reports NOASSERTION, while the README's badge links to a LICENSE file and labels it Apache. Those two signals disagree. If your organisation has licence review, read the actual LICENSE file before you plan around it. Do not take the badge as the answer.

## DivKit against writing native screens per platform

The real alternative for most teams is not another framework. It is writing the screen three times: once in Kotlin or Java for Android, once in Swift for iOS, and once in TypeScript for the web. That approach has no schema to learn, no JSON document to version, and no renderer between your code and the platform. It also means every copy of the screen must be updated and released separately, and the release is gated by app store review on mobile.

The difference in approach is where the layout lives. In the native approach the layout is compiled into the binary, so changing it requires a new build and a store submission. In DivKit the layout is a JSON document the client parses at runtime, so changing it means changing what the server sends. The README frames this as the core benefit: rolling out server-sourced updates to different app versions.

That benefit has a cost that the native approach does not pay. A JSON document must be valid against the schema, and an old app version must cope with whatever the server sends it. The README does not document a compatibility policy for that case, so the burden sits with you.

A narrower alternative is to keep native screens and use DivKit only for the parts that change often, such as promotional blocks or configurable forms. The README supports this directly, since DivKit integrates as a view in any part of an app and does not require a server at the start. That is often the better first step than a full migration.

## Release cadence, licence and what upgrading costs

The project is not archived, and the last push to the default branch was on 2026-09-24. Recent releases are close together: 33.4.0 on 2026-09-22, 33.3.0 on 2026-09-15, and 33.2.0 on 2026-09-08. A weekly release train means the version number moves whether or not you do.

That cadence shapes the upgrade cost. Because clients for three platforms and builders for three languages are generated from one schema, a schema change can ripple into every generated API at once. Upgrading the Android client while leaving the web client behind is possible in principle, but the shared schema is the thing that keeps them consistent, and splitting versions works against that. Budget for upgrading clients together.

On licensing, the README carries an Apache badge linking to a LICENSE file, while the repository metadata reports NOASSERTION. The LICENSE file is the authoritative text; read it in full rather than relying on the badge or on this description. Nothing here is legal advice, and the mismatch is exactly the kind of thing your review process exists to catch.

The repository also contains a CHANGELOG.md, which is where release-by-release detail lives. The README itself does not describe a deprecation policy, a migration guide between major versions, or a support window for older clients. If you need those commitments in writing before adopting, ask in the Telegram community chat the README links, or check the documentation site.

## Conclusion

Adopt DivKit if you ship to Android, iOS and Web and want layout changes to arrive from the server without a store release; the client list in the repository is the boundary that matters. Do not adopt it if Flutter or React Native is your only target, because neither appears in the client directory. Before committing, verify the licence text in the LICENSE file, since the repository metadata reports NOASSERTION rather than a named licence, and check that your app can host a single view rather than a whole screen.

## FAQ

### What is SDUI used for in DivKit?

Server-Driven UI lets a server describe the interface and the client render it from that description. In DivKit the description is a JSON document, and the README states the framework lets you roll out server-sourced updates to different app versions and prototype UI once for iOS, Android and Web.

### Does DivKit support Flutter or React Native?

The repository lists clients for Android, iOS and Web under client/android, client/ios and client/web/divkit. Neither Flutter nor React Native appears in that list, and the README does not mention them.

### Do I need a server to try DivKit?

No. The README states that at the starting point you do not need server integration and that you can include all JSON on the client side to try it in a real-world application. Server-side builders in TypeScript, Kotlin and Python are available when you are ready to move the JSON to a backend.

### How can I preview a DivKit layout before shipping it?

The README points to a sandbox at divkit.tech/playground where you can try samples in a web editor and see the results on the web or in the Android demo app. It also states that the sandbox connects to the demo app over web sockets, so the UI updates live.

### What licence is DivKit released under?

The README shows an Apache badge that links to a LICENSE file, while the repository metadata reports NOASSERTION. The LICENSE file is the text to read, since the two signals do not agree.

## Sources

- [divkit/divkit on GitHub](https://github.com/divkit/divkit)
- [Issues](https://github.com/divkit/divkit/issues)
- [Project website](https://divkit.tech)
- [README](https://github.com/divkit/divkit/blob/main/README.md)
- [Releases](https://github.com/divkit/divkit/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/divkit-divkit