Skip to content

Guide

What you can build

Everything the canvas offers, and what each thing proves about the output.

The short version

You draw a screen. Position, size, colour, typography and layout behaviour all reach the code, in all four languages, at the geometry you drew.

A few finishing touches do not reach every target: image filters and dashed borders are honoured on two of the four. Each is called out inline below rather than left for you to discover at export.

This page is the full inventory, limits included. If you want the idea rather than the list, read why the canvas is the source of truth instead.

Screens and devices

  • Device presets for iPhone, iPad, Android phones and tablets, macOS, Windows and watchOS, plus a plain artboard when you want a card or component rather than a whole screen.
  • A canvas that can be taller than the device, which is what makes a screen scroll.
  • Multiple screens per project, each with its own device.
  • Safe areas drawn from the device you picked, so a notch or home indicator is accounted for while you design.

The device decides which languages you can export. SwiftUI is Apple only and never offered for Android. React Native covers phones and tablets but not desktop. Flutter covers mobile and desktop but not watchOS. On a watch, SwiftUI is the only option. You will never be offered a target we cannot fully build for.

Shapes

  • Rectangles with a corner radius per corner, not just a uniform one, on every export.
  • Regular polygons and stars, with control over the number of sides, the number of points, and how spiky a star is. Real vector shapes on every export, the exact point coordinates, never approximated.
  • Borders with a width and a colour on every export. Solid, dashed, or dotted style is honoured on HTML and React Native; SwiftUI and Flutter always render a solid border regardless of the style you set.
  • Drop shadows with colour, blur, and x/y offset, on every export.
  • Rotation, horizontal and vertical flip, and opacity on anything, on every export.

Colour and gradients

  • Solid fills anywhere.
  • Linear gradients with a real angle, on every export. The angle you set is the angle in the export: each target computes real start and end points from it rather than snapping to a fixed diagonal, which is the usual shortcut.

Text

Full typographic control, and all of it survives export:

  • Font family, size, and weight from 100 to 900.
  • Italic and underline.
  • Line height as a multiplier and letter spacing in pixels, on every export, both of which are usually the first things to drift in generated code. SwiftUI reaches them the way SwiftUI does: .tracking() for letter spacing, .lineSpacing() for line height, computed from the same multiplier the other three targets use directly.
  • Left, centre and right alignment.

Images

  • Place an image, and choose how it fills its box: cover, contain, or stretch, on every export.
  • Tint, a flat silhouette recolour, on every export.
  • Alt text, which matters if you are exporting to the web.
  • A set of filters: blur, brightness, contrast, grayscale, hue, invert, saturation, and sepia. These apply on the HTML and React Native exports. SwiftUI and Flutter do not apply them: a filtered image on the canvas exports unfiltered on those two. (React Native's blur uses a different scale than the canvas does, and its invert is on-or-off rather than a percentage.) See Exporting for how images themselves are carried into each export, which differs by platform and is worth reading before you rely on it.

Controls

Any box can become interactive, and it keeps the fill, border and radius you designed. A button is the rectangle you drew, not a framework's idea of a button.

Buttons do one of two things when pressed:

  • Go to another screen in the same project, wired up in the generated code.
  • Call a function you name, so the export lines up with the handler your codebase already has.

Text inputs support:

  • Placeholder text.
  • Secure entry for passwords.
  • Keyboard type: default, email, number, phone, or URL, mapped to each platform's own keyboard.
  • A text colour independent of the box fill.
  • Multiline, which is the interesting one.

Multiline fields that actually grow

This is the hardest thing in the product and the one worth testing first if you are deciding whether generated code really behaves like a design.

On the canvas, a multiline field grows as text wraps and everything below it moves down. In the export, the same thing happens at runtime on all four platforms: the field measures its own text in its own font at its own width, grows to fit, and pushes the elements below it down by exactly that amount. The scrollable area grows with it, so a form that outgrows the device still reaches its true bottom.

Each platform solves it natively, because there is no shared abstraction to borrow: onContentSizeChange in React Native, a self-measuring TextEditor in SwiftUI, a measured TextField in Flutter, and the browser's own scrollHeight on the web. Controls and inputs shows the generated code for it.

Scrolling

A screen scrolls when the canvas is taller than the device, and also whenever it contains a multiline field, even if everything currently fits, because that field can grow past the bottom at runtime. The web target additionally scrolls horizontally when the canvas is wider than the device; the other three scroll vertically only.

Export

  • Four targets from one screen: React Native, SwiftUI, Flutter, HTML and CSS.
  • Copy a single screen from the code panel, or export the project.
  • The code is yours, with no runtime dependency on us.
  • 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 rather than checked by hand.

Exporting covers what you get in each case, including the parts that are not there yet.

The pattern behind those gaps

You may have noticed the same two names in each caveat above. Worth stating plainly rather than making you assemble it:

HTML and React Native are the visually complete targets. Everything on this page reaches them.

SwiftUI and Flutter have two confirmed gaps left, both niche finishing touches: image filters are not applied, and dashed and dotted borders render solid. Separately, image files are not bundled into the export (Flutter does bundle images; React Native, SwiftUI, and HTML reference them by name and expect you to supply the files). Per-corner radii, gradients, letter spacing, line height, image fit mode, and image tint used to also be gaps; all six are now exact on every target, verified against the real Flutter SDK and Xcode's Swift compiler.

What matters is which side of the line those fall on. The fidelity core is identical on all four: placement, sizing, typography, gradients, shadows, rotation, opacity, corner radii, image fit and tint, real vector polygons and stars, multiline fields that grow and push content down, and scrolling that reaches the true bottom. Nothing about how your screen is laid out or behaves differs between targets. What differs is two niche decorative properties.

So if you are shipping SwiftUI or Flutter, the layout you drew is the layout you get. Check this list before relying on a dashed border or a filtered image, because those are the only two things left that will surprise you.

What it does not do

Worth knowing before you plan around it. The full list is on the about page, but the two that shape how you work:

  • Screens do not stretch to fit. One screen is one device size. Cover a phone and a tablet by drawing two screens.
  • There is no Figma import. You design here, or you do not use us.