Snapchat's Valdi: a TypeScript UI framework that compiles to native iOS, Android and macOS views

The problem Valdi targets: cross-platform velocity against native runtime cost

Cross-platform UI frameworks usually force a choice. Either you write the interface once in a shared language and accept a runtime penalty, or you write it twice and keep native performance. Valdi's answer is to keep the shared language but remove the runtime layer: components are written in declarative TypeScript, and the build compiles them into platform-native views. The README states there are no web views and no JavaScript bridges. That is the whole pitch, and it is a narrower claim than it first sounds. Valdi is not trying to replace your application architecture. It is trying to replace the view layer, and it is explicit that it can be adopted incrementally: the README describes embedding Valdi components inside existing UIKit or Android view hierarchies, and embedding platform-specific views inside Valdi layouts through a custom-view element. The audience is therefore teams with an existing native app who want to move screen-building work into TypeScript without rewriting the app, plus teams starting fresh who want one UI codebase across iOS, Android and macOS. The README also notes Valdi has been used in Snap's production apps for eight years, with the beta label attached to the open source tooling and documentation rather than the framework's use inside Snap.

How Valdi compiles TypeScript into native views

The mechanism visible from the repository is a compiler plus a C++ runtime. The top level contains compiler/, valdi_core/, valdi/, valdi_protobuf/, snap_drawing/, libs/ and modules/, and the build is driven by Bazel files (BUILD.bazel, MODULE.bazel, .bazelrc, .bazelversion). A component is a TypeScript class extending Component with an onRender method, and the JSX-like markup inside it becomes native views rather than DOM nodes. The README's example uses a view element with a backgroundColor and padding, containing a label with a color and a value, which shows the model: attributes in the markup map to native view properties. Around that, Valdi generates type-safe bindings between TypeScript and native platforms. The README describes TypeScript interfaces compiling to Kotlin, Objective-C and Swift bindings, and polyglot modules letting you write performance-critical code in C++, Swift, Kotlin or Objective-C with typed bindings back to TypeScript. Several performance claims sit on top of this architecture: a global view pooling system that reuses native views across screens, independent component re-rendering that does not trigger parent re-renders, a C++ layout engine running on the main thread, and viewport-aware rendering that only inflates visible views. Those are design statements from the README, not measured results, and the repository does include an apps/benchmark directory for anyone who wants to check them on their own code.

Installing the Valdi CLI and rendering a first component

The README lists a single prerequisite, Xcode, and only on macOS. Everything else is handled by the CLI's setup command. Install the CLI globally from npm, then run the setup step, which the README says installs all dependencies.

npm install -g @snap/valdi
valdi dev_setup

With the toolchain in place, create a project directory and let the CLI scaffold it. The install subcommand takes a platform argument, ios or android.

mkdir my_project && cd my_project
valdi bootstrap
valdi install ios

The README's minimal component shows the shape of a Valdi file. It imports Component from valdi_core/src/Component, extends it, and returns markup from onRender.

import { Component } from 'valdi_core/src/Component';

class HelloWorld extends Component {
  onRender() {
    const message = 'Hello World! 👻';
    <view backgroundColor='#FFFC00' padding={30}>
      <label color='black' value={message} />
    </view>;
  }
}

The README points to apps/helloworld as the fastest way to get something on screen, and to apps/navigation_example, apps/managed_context_example, apps/valdi_gpt and apps/cli_example for other patterns. For editor support, the README recommends the VSCode or Cursor extensions documented in docs/INSTALL.md, which it says add syntax highlighting, debugging and device logs during hot reload. Note that the README's example markup is not a return statement, so treat it as illustrative of the component structure rather than copy-paste-ready code.

What the beta label actually covers, and where Valdi is the wrong tool

The README is unusually direct about this: Valdi has run in Snap's production apps for eight years, and the beta label exists because the tools and documentation need more testing in the open source world. Read that as a statement about the open source surface, not the runtime. The practical consequence is that you should expect the developer experience around the framework to move: the CLI, the docs and the editor extensions are the parts the maintainers describe as needing battle testing. The repository's release history fits that picture. The most recent release listed is beta-0.1.1 from 2026-07-01, preceded by beta-0.1.0 on 2026-05-29, and the last push to the main branch was on 2026-09-19. There is no 1.0. A second limitation is environmental. The quick start names Xcode as a prerequisite and marks it macOS only, so a Windows or Linux developer cannot follow the documented path to an iOS or macOS build. A third is architectural. Valdi's value comes from compiling to native views and generating bindings, which means the build pipeline is a Bazel-driven C++ toolchain plus a TypeScript compiler. If your project is a web app, a server-rendered site, or anything that does not need native platform views, Valdi solves a problem you do not have, and the polyglot bindings and Bazel setup are cost without benefit. Finally, the README does not document rollback or migration procedures for moving an existing screen from native code to Valdi and back, so plan that path yourself before committing a large surface.

Valdi compared with React Native and Flutter

The most obvious comparison is React Native, since both put TypeScript or JavaScript in front of a native view layer. The difference the README draws is the bridge. Valdi states it has no JavaScript bridges and no web views, and that components compile into native views, with a C++ layout engine on the main thread. React Native's model, by contrast, is a JavaScript runtime communicating with native views, which is the layer Valdi's design removes. Whether that produces a measurable difference on your screens is something only your own profiling can answer, and the repository ships apps/benchmark for that purpose. Flutter takes a third route: it renders through its own drawing layer and widget set rather than mapping to platform views, which gives consistent rendering across platforms but a different relationship to native platform components. Valdi's position is the opposite: it leans on native views and offers custom-view and native bindings so platform-specific components can sit inside Valdi layouts. If your requirement is pixel-identical rendering everywhere, that is a different goal from Valdi's. If your requirement is that a screen built in TypeScript behaves like a screen built in UIKit or Android views, Valdi's compile-to-native approach is aimed squarely at that.

Licence, maintenance and the cost of upgrading

The README carries an MIT licence badge linking to LICENSE.md, and the repository has a LICENSE file at the top level. The repository metadata, however, reports the licence as NOASSERTION, which means the licence could not be identified automatically from the repository contents. Those two signals disagree, and the LICENSE file itself is the only authority. Read it before you depend on the project, and if the terms matter to your organisation, have someone qualified review them; nothing here is legal advice. On maintenance, the last push to main was on 2026-09-19 and the repository is not archived. The release cadence visible in the repository is two beta releases about a month apart in mid-2026. The upgrade cost is tied to the beta status. The README says Valdi will exit beta when the maintainers are satisfied with the developer experience, which means the CLI, the setup command and the documentation are the parts most likely to change between releases. The repository also carries a ROADMAP.md and a CONTRIBUTING.md, and the README links to GitHub Discussions as the project's homepage, so the roadmap file is where to check what is planned before you build a long-lived dependency on a specific CLI behaviour.

Editorial conclusion

Adopt Valdi if you are building a mobile app that needs native rendering and you are willing to work in TypeScript with C++, Swift, Kotlin or Objective-C for the parts that need it, and if you accept that the tooling is still labelled beta. Do not adopt it if you need a stabilised API surface, or if your team has no Xcode-equipped macOS machine, since the quick start lists Xcode as a prerequisite. Before committing, verify the version of @snap/valdi on npm, read docs/INSTALL.md for the current setup steps, and check the LICENSE file for the exact terms, since the repository metadata does not match the MIT badge in the README.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Snapchat/Valdi on GitHub