Building a native mobile app means assembling screens, navigation, state management, and validation from dozens of pieces that rarely change at the same time. StemJSON takes a different approach: a declarative JSON language that AI tools, backend servers, and prototyping environments can emit, and that a native runtime renders directly on iOS and Android. The format is open, and the renderers are native, not web views.

What StemJSON Actually Is

StemJSON is a declarative language built on JSON. It describes the full surface of a native module: the UI components, their layout, the actions they trigger, the expressions that bind data to views, and the navigation logic that connects screens. A single .stem file contains everything the runtime needs to render a working screen.

The language is intentionally constrained. It does not try to describe every possible native API. Instead, it defines a portable set of components and behaviors that map directly to native widgets on each platform. The Swift and Kotlin runtimes interpret StemJSON and render real native views, not HTML.

The Stem AI Area

The most interesting use case is a sandboxed region inside an existing app where users type what they want in plain language. An LLM converts that prompt into StemJSON. The runtime validates the output, renders it natively, and keeps it contained inside the sandbox the developer defined. No new binary is compiled. No backend round-trip is needed for the UI layer.

This is a new interaction pattern: apps that adapt to individual users on demand. A user who needs a specific settings screen or a content feed describes it once, and the runtime builds it from the StemJSON that the LLM produced. The sandbox ensures the generated module cannot access parts of the app the developer did not permit.

The concept is patent pending.

Three Other Ways To Use It

Server-driven UI is the most established pattern. Your backend emits a complete StemJSON module with state, actions, expressions, navigation, and validation, and the device renders it without an app update. This is useful for feature flags, remote configuration screens, and anything that changes faster than your release cycle.

Prototyping removes the glue code that usually connects a design to a working app. A Figma export or an AI prompt produces StemJSON, the runtime renders it on-device, and the result is a runnable native prototype. No bridge layer, no translation step between a design tool and a real screen.

Alongside hand-written code, StemJSON handles the parts of an app that change often. Settings screens, onboarding flows, and content feeds are good candidates. The rest of the app stays in Swift or Kotlin, and the StemJSON modules render where they are needed.

The Runtime And SDK

The runtime is available as a Swift package for iOS and a Kotlin library for Android. Drop it into an existing app and render StemJSON modules alongside your existing native code. There is a free tier with no time limit.

The SDK enforces the conformance rules defined in the StemJSON specification v1.1. A .stem file is validated before it is rendered, so malformed or out-of-spec modules are rejected rather than silently producing broken UI.

Working example apps are published on GitHub for both platforms. Clone one, replace the included .stem file with your own, and reuse the patterns that fit your project.

The Tooling Around It

StemStudio AI is a mobile IDE purpose-built for StemJSON. It lets you author and preview modules on-device, with the runtime rendering your changes in real time. An MCP server brings the same capabilities to AI chat interfaces, letting an LLM emit StemJSON from a conversation and have it rendered on a connected device.

Pluri is the consumer-facing product built on the same runtime. It is described as an app that builds itself, where end users describe features and the runtime renders them natively inside a sandbox.

The format is open and documented in a full specification. StemJSON is not tied to a single vendor or a single AI model. Any tool that can emit valid JSON can produce StemJSON, and any app with the runtime installed can render it.

Why This Matters For App Development

The traditional mobile development cycle assumes that every screen and feature is compiled into a binary, submitted to an app store, and approved before users see it. That cycle is slow and expensive. Server-driven UI partially solves the problem by letting your backend control what renders on the device, but it still requires you to define every possible screen ahead of time.

StemJSON goes further. A user's natural language description, processed by an LLM, can produce a working native module in real time. The sandbox model keeps this safe: the generated code runs in a constrained area with limited permissions, and the runtime validates the StemJSON before rendering it.

For teams building mobile apps, the implications are practical. Feature experimentation does not require an app update. Prototyping does not require a bridge layer between design and code. And the parts of your app that change frequently do not need to live in the same binary as the parts that never change.

The language is open, the runtime is available, and the example apps are on GitHub. The easiest way to evaluate it is to clone an example, write a .stem file, and see what the runtime produces on a real device.