Design to code tools in 2026: sorted by what the code is

Anima — input Figma, URLs, images and prompts; output “HTML” and “React”, with a choice of “clean CSS, Tailwind, or inline styles”, and Vue in the Figma plugin. No native mobile claim on the page.

Locofy — input “Figma & Penpot designs”; output “React, React Native, HTML-CSS, Flutter, Vue, Angular, Next.js”. The only tool in this group that also appears in the next one.

Builder.io — “Turn designs into code your team can ship”; “Turn designs into UI for the frontend your product already runs on, with the routes, styling approach, and patterns that decide what can ship.” The page names no framework list and makes no mobile claim; the pitch is fit with an existing web codebase.

v0 — “Clone pages with screenshots or Figma files”; stack “Next.js, Tailwind, shadcn/ui”.

Bolt — lists “start from Figma” beside GitHub and team templates; output web apps, and Expo apps through its mobile path.

Lovable — three documented ways in: the Figma plugin (“select frames or components in Figma and send them to Lovable without leaving your design tool”), the Figma MCP (needs the “Lovable desktop app” and the “Figma desktop app with Dev Mode enabled”), and a .fig upload that brings “variable collections, colors, typography, and frame structure” but does “not import interactive designs or components”. Output: web apps — the FAQ states Lovable “does not generate React Native projects”.

Figma Make — Figma’s own builder; produces “prototypes” and “web apps”, with “Use Make locally to build in any codebase, then ship right to production” marked “Coming soon” on 23 September 2026. No iOS, Android or Swift on the page.

When this group is the right one: the product is a website or a web app, the design system already lives in Figma variables, and the question is how much of the layout survives. When it is not: the product is an app on a phone. A web page in a wrapper is what App Store guideline 4.2 describes as a “repackaged website”; native app vs web app has the boundary.

Locofy — the same tool, with “React Native” and “Flutter” in its output list. The design becomes screens in a JavaScript or Dart codebase that a runtime renders on both phones.

FlutterFlow — a visual builder rather than a converter: the Figma import maps the theme (“Colors will be appropriately mapped from your Figma theme to your FlutterFlow theme and assets will be automatically incorporated”), and the screens are built in FlutterFlow’s editor. Output: Flutter.

What this group gives: one codebase, both stores, the same screens on both systems. What it costs: the runtime between the code and the phone — platform features reach the app through modules, and the UI is the framework’s, not iOS’s or Android’s. React Native vs native has the trade-off in full; for a product where “feels like an iPhone app” is a requirement, it is the deciding paragraph.

The newest group, and the one where “design to code” stops being a converter and becomes an agent with the design as one of its inputs.

Figma’s MCP server + a coding agent. Figma’s own help page: the server “helps developers explore and implement designs quickly and accurately”, lets a client “get design context and code from your Figma designs, FigJam, and Make files”, and works with Cursor, VS Code, Claude Code, Windsurf, Android Studio, Codex, Copilot CLI, Gemini CLI, Replit and Xcode (beta), among others. The remote server is on “all seats and plans”; the desktop server needs a Dev or Full seat. The page names no output framework, because the agent decides: point Claude Code at a frame and ask for SwiftUI, and SwiftUI is what it writes. This route gives full freedom and no structure — the agent writes what you can direct it to write, and the project, the architecture and the build loop are yours to set up.

Modaal — ours. The agent’s first prompt takes “text, images, Figma links — whatever you provide”, and “you can attach a PRD, design doc, or screenshot with no text at all”. The docs describe the Figma route in one sentence: “Point the agent at a Figma design — it pulls the design context and screenshots through the Figma integration and builds the screens to match.” What is different from the previous route is the structure around the agent: with Plan on it first writes “a structured implementation plan (a feature spec) without writing code” — overview, user scenarios, technical approach, implementation steps, files to create or modify, risks and open questions, testing strategy — which you approve before any screen exists; the output is Swift/SwiftUI for iPhone and Kotlin/Jetpack Compose for Android from one project, built and run on your Mac, in Xcode and Android Studio projects you own. The Free plan builds one project with unlimited prompts on one platform; Pro is €9 per user per month billed annually and adds both platforms and TestFlight/App Store distribution — /pricing has the rest.

Rork — native Swift and Kotlin as separate apps; a Figma import is not stated on its pages as of 23 September 2026.

When this group is the right one: the product is an app, the design has to be the app’s real UI rather than a preview of it, and the code has to be something the platform’s developers recognise. What it does not give: a one-click conversion. The agent rebuilds the screens from the design and from your description of what they do — which is the point of the next section.

Every group above converts the same three things and none of them converts the fourth.

Layout, spacing, type, colour survive in all three groups. This is what “design to code” means on every vendor page and what the accuracy claims are about.

Tokens and components survive when they exist as Figma variables and components and the tool reads them — Lovable’s .fig path names “variable collections, colors, typography”; FlutterFlow maps the theme; the Figma MCP exposes variables to the agent. A screen drawn with detached instances and hard-coded hex values converts as a picture, whichever tool.

Behaviour never survives, because it is not in the file. Tap targets, navigation, states (loading, empty, error, success), validation, what happens offline: a Figma frame shows one state of one screen. This is the part the product manager supplies, and it is why the native-mobile group asks for a description alongside the file rather than the file alone. The one-page form that carries it is the app requirements document; the prompt that turns it into a plan is on the PRD prompt page.

The practical order for a product team: freeze the design system in Figma first (variables, components, variants), write the scenarios per screen, then convert — with whichever group matches where the product ships.

1. What does the code have to be? A website, a cross-platform app, or a native app. This eliminates two of the three groups; the vendor page tells you which group a tool is in, and the table below has the quotes.

2. Who owns the result, and in which plan? A downloadable project in the framework named, or an app that lives on the vendor’s platform. Read the pricing page, not the homepage; we did this for nineteen builders in the export table.

3. Where does behaviour come from? If the tool takes only the file, you will add behaviour afterwards by hand or by prompt. If it takes the file and a description, write the description first. For a product manager this is the familiar artefact: the PRD, the user stories, the acceptance criteria — the same document that would have gone to engineering.

The persona version of this page — what a designer’s week looks like with these tools — is Modaal for designers; the tool decision for a whole mobile product is cross-platform app builders sorted by output.