Skip to content

Guide

Exporting

Getting the code out, and what comes with it.

Two ways out

Copy from the code panel. The fastest path. Pick a target, copy the file, paste it into your project. Best when you are pulling one screen into an existing codebase.

Export the project. For when you want every screen at once. For Flutter this is a full runnable project: pubspec.yaml, a README, and bundled image assets alongside the code. For React Native, SwiftUI, and HTML, it is the same per-screen files copy would give you, zipped together, not a scaffolded project.

What you own

All of it. The exported code has no runtime dependency on One Redesign, no watermark, no attribution requirement, and no phone-home. If you stop paying us, the code you already exported keeps working, because there is nothing of ours in it.

The only third-party dependencies that appear are ones your design actually requires, and today there are two, both React Native:

  • expo-linear-gradient, if a shape has a gradient fill.
  • React Navigation, if a button navigates to another screen. The export calls navigation.navigate() and expects each screen registered in a Stack.Navigator.

If your design does not use the feature, the dependency does not appear. The SwiftUI, Flutter and HTML exports use their platform's own navigation and need nothing extra.

Assets

Flutter bundles your images as real asset files, referenced from a pubspec.yaml entry it also generates. React Native, SwiftUI, and HTML exports reference images by the name you gave them in code, but do not yet bundle the image files themselves. That is a real gap, not a hedge: for those three targets today, you supply the image files yourself.

Fonts are referenced by family name in every target's code; the HTML export additionally links Google Fonts' CDN for a font it actually serves there. No target embeds font files into a code export.

Naming

Generated identifiers come from the layer names you set in the inspector. A shape called Submit button produces a readably named variable; a shape left as its default does not. If you care what the export reads like, name your layers before you export, not after.

Multiple screens

A project can hold several screens, each with its own device. They export independently, because each is authored at its own size. Linking one screen to another as a press target is covered in Controls and inputs.

What export does not do

  • It does not generate a build system, navigation stack, or state management. You are getting screens, not an application skeleton.
  • It does not round-trip. Editing exported code does not update the canvas, and there is no import path back.
  • It does not produce responsive layouts, for the reasons in the fidelity guide.