What Solaris is
Solaris was introduced as the first product in Runway’s Interface World Models family. The core idea: a single world model that renders interfaces and their responses to input frame by frame, removing the intermediate step of compiling designs into code.
Read carefully, that is a specific and unusual claim. Most AI interface tools generate code — HTML, CSS, a component tree — and rely on a browser to render it. Solaris is described as generating the rendered result directly.
Why rendering frames is not the same as generating code
| Approach | Output | Consequence |
|---|---|---|
| Generate code | HTML/CSS/components | Deterministic, inspectable, editable, accessible |
| Render frames | Pixels over time | Visually fluid, but no accessible structure or editable source |
This trade is the crux. Code generation gives you something you can maintain, test and make accessible. Frame rendering gives you fluidity and behaviours that are hard to express in code, at the cost of structure.
The accessibility question is the hard one: a rendered interface has no document structure underneath. Screen readers, keyboard navigation and semantic markup do not exist unless they are produced some other way.
Why this idea is surfacing now
- Video models got good enough to hold visual coherence over time, which is the precondition for rendering a persistent interface.
- The video generation market is commoditising, so companies with strong models are looking for adjacent categories.
- “World model” framing gives a coherent story for generating interactive systems rather than clips.
What it implies if it works
- Prototyping becomes closer to the final artefact — you interact with the thing rather than a mock of it.
- Motion and transition design, which is painful to express in code, becomes describable directly.
- Design and implementation converge, potentially collapsing a handoff that has always been lossy.
If it works, the interesting consequence is not faster UI code. It is that behaviours which are currently expensive to specify — how a thing feels when you interact with it — become cheap to explore.
Where to be sceptical
-
Ask what you get out
If the output is pixels, ask how you ship it. A product interface still needs to run in a browser, on real data, with real state.
-
Ask about state and data
An interface that renders beautifully but is not connected to anything is a prototype, not a product.
-
Ask about accessibility
No document structure means no accessibility without a separate path. That is a blocker for production use in most organisations.
-
Ask about determinism
Interfaces need to behave identically every time. Generative rendering is probabilistic by nature.
The likely near-term role: exploration and prototyping rather than production. That is still valuable — most interface work is wasted on exploring options that are never built.
Who should care
- Product designers exploring interaction concepts before committing to implementation.
- Teams producing demo and marketing footage of interfaces, where pixels are the deliverable anyway.
- Video teams — this is the same underlying capability that makes UI-in-video shots possible without screen recording.
- Anyone currently maintaining expensive prototypes purely to test how something feels.
How to evaluate it
-
Bring a real interface you need
Not a demo concept. Something with real states, real data shape and real edge cases.
-
Try to break it
Enter unexpected input, resize, interrupt an animation. Robustness under interruption is where generative interfaces fail first.
-
Test with assistive technology
If it cannot be navigated by keyboard or read by a screen reader, it is not shippable as a product surface.
-
Compare against your current prototype cost
The relevant question is whether it beats how you explore today, not whether it replaces your frontend.