Why the canvas is the source of truth

The problem with reading a design file

Most design-to-code tools are plugins. A plugin opens a file it did not create and has to answer a hard question: what did the designer mean? Two boxes sitting next to each other might be a row, or they might be two boxes that happen to be adjacent. A group might be a component or an accident of how someone organised layers. The tool guesses, usually well, sometimes not, and the guess is why generated code so often needs a pass by hand before it matches the design.

The guess is not a quality problem that better models fix. It is structural. The information about intent was never in the file.

What we do instead

We own the canvas, so nothing has to be inferred. When you place a box at x 24, y 180, 320 wide and 56 tall, those four numbers are the design. They go into an intermediate representation, and each generator turns that representation into its own language.

The result is that the export is not an interpretation of your design. It carries the same numbers.

• React Native gets a style with literal left, top, width, height.
• SwiftUI gets .position(x:, y:) computed from those coordinates.
• Flutter gets a Positioned inside a Stack.
• HTML gets position: absolute with pixel values.

Four languages, one set of numbers, no re-derivation on the way.

The trade-off, stated plainly

Absolute positioning is how the fidelity works, and it costs you responsive layout.

Generated screens do not reflow. There are no breakpoints, no flex containers, no size classes, no LayoutBuilder. A screen is authored at one device size and exports at that size. Content taller than the device scrolls, and so does any screen containing a multiline field, since that field can grow past the device once someone types. But scrolling is not a layout that adapts.

If you need one layout that works fluidly at any width, a tool that generates Flexbox will serve you better than we will, and our comparison pages name which ones.

How to work with the constraint

Design each size you need as its own screen. An iPhone screen and an iPad screen are two screens here, not one layout with a breakpoint between them. That is more drawing than a responsive tool asks for, and in exchange every one of those screens is exact.

This suits application UI on fixed device targets better than it suits fluid marketing sites, which is the honest shape of who we are for.

How we keep ourselves honest about it

The claims on this page are enforced, not asserted:

• Generated SwiftUI is type-checked against the real iOS SDK with swiftc -typecheck, and generated Flutter passes flutter analyze and builds with flutter build web, both via a dedicated verification suite (npm run verify:native) that runs against the real toolchains, outside the fast test suite because it needs the Flutter SDK and Xcode installed.
• The code samples shown throughout these docs are byte-compared against real generator output, so a sample cannot drift from what you would actually get.
• A test fails our build if marketing copy claims the output is responsive or adaptive.

That last one exists because we got it wrong once, in a draft, and would rather have a machine catch it than a customer.