The problem we kept hitting
Design the screen once. Build it for iOS. Build it again for Android. Build it again for the web. Three implementations of one design, each drifting from the original in its own direction, and none of them quite matching the others.
The tools meant to fix this are almost all Figma plugins, and they share a structural problem. A plugin reads a file it did not create and has to infer what the designer meant. Two adjacent boxes might be a row or a coincidence. The plugin guesses, and the guess is why generated code so often needs a pass by hand before it matches the design.
That guess is not a bug that better models remove. The information about intent was never in the file.
What we did about it
We built the canvas instead of reading someone else's.
When you place a box at specific coordinates, those numbers are the design. They go into one representation, and each generator renders that representation into its own language: React Native, SwiftUI, Flutter, HTML and CSS. Nothing is inferred, because nothing has to be.
What we believe
Exact beats idiomatic, for this job. Our output is absolutely positioned. It is not how you would hand-write a screen, and it is exactly what you drew. For reproducing a design across platforms, we think that is the right trade, and we say plainly what it costs.
A claim should be checkable. Generated SwiftUI is type-checked against the real iOS SDK, and generated Flutter passes flutter analyze and builds, both run by a dedicated verification suite against the real toolchains rather than checked by hand. The code samples on this site are byte-compared against real generator output. Our build fails if the marketing copy claims the output is responsive, because we wrote that claim down once by mistake and would rather a machine caught it than a customer.
Say who you are wrong for. Our comparison pages name competitors as the better choice in specific cases, because they are. A tool that claims to win at everything is telling you nothing.
Who this is not for
If you need one layout that adapts fluidly to any width, this is the wrong tool. Generated screens are authored at a fixed device size and do not reflow. Tools that generate Flexbox do that properly, and we name them.
If your designs live in a large Figma design system that is not moving, we have no import path. That is a real cost and worth weighing before you evaluate us.
Who it is for
People shipping application UI to more than one platform, where the recurring cost is making every platform match the design and each other.
What we do not do yet
The short list, in one place, so you do not have to find it out by shipping:
- No responsive layout. Screens are authored at a fixed device size and do not reflow. Cover more sizes by drawing more screens.
- No Figma import. You design on our canvas or you do not use us.
- Images are not bundled, except in Flutter. The Flutter export bundles image assets with a generated
pubspec.yaml. React Native, SwiftUI, and HTML exports reference images by name and you supply the files. - No font embedding. Every target references fonts by family name. The HTML export links the Google Fonts CDN for fonts served there. No target embeds font files into a code export.
- No round-trip. Editing exported code does not update the canvas.
Some of these are consequences of how the fidelity works and will not change. Others are just not built yet. We would rather you knew which is which before you evaluate us than after.
Where we are
Early. The product is real and the code it generates is real, but the surface is deliberately narrow: four targets, screens rather than whole applications, no round-trip. We would rather do a small number of things exactly than a large number approximately.