# Export Penpot to a React Native UI Kit: Open All the Way

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-05. 4 min read.
> Source: https://vp0.com/blogs/export-penpot-to-react-native-ui-kit

Penpot is the open-source Figma, and its open formats make the design-to-native path unusually honest: your file is readable data, and the agent reads it.

**TL;DR.** Penpot, the open-source design platform, changes the design-to-React-Native question with one property: openness, self-hostable, open formats, design tokens as a first-class citizen, so the path to a native UI kit follows the standing playbook with fewer locked doors. Tokens come first: Penpot's token support exports the color, type, and spacing system that becomes your RN theme module directly. Screens follow the agent route, exports or screenshots plus the token system into Claude Code or Cursor, idiom instruction attached, one screen per prompt, because code-generation exporters disappoint here exactly as everywhere (coordinates, not architecture). The deeper alignment: an open design tool, free AI-readable design sources, and owned generated code compose into a design-to-code stack with no subscription gate at any layer.

## What does Penpot change about design-to-code?

The locked doors. [Penpot](https://penpot.app/), the open-source design platform, runs the same screens-and-components workflow as its proprietary peers with three open properties attached: **self-hosting** (your design data lives where you choose), **open formats** (files are readable data, not vendor blobs), and **first-class design tokens** (the system layer is a citizen, not an inspect-panel scrape). The design-to-[React Native](https://reactnative.dev/) path is therefore the standing playbook, tokens, then the agent route, with fewer terms-of-service-shaped walls along the way.

## Why do tokens come first?

Because a UI kit is a token system wearing components. Penpot's token support exports the color roles, type scale, and spacing system directly, and that export becomes the RN theme module **before any screen generates**:

| Step | The artifact | Why first | Verdict |
| --- | --- | --- | --- |
| Export tokens | Penpot tokens → theme module | Screens consume roles from day one | The kit's actual foundation |
| Map to semantics | brand-500 → `accent`, etc. | Roles outlive palette shuffles | The naming pass; an hour well spent |
| Generate components | Buttons, cards, inputs against the theme | Atoms before screens | Each consumes tokens only |
| Generate screens | References + tokens into the agent | The visible layer, last | One per prompt, the standing rhythm |

Tokens-first is the same architecture every theming entry in this series lands on, [the dark-mode system](/blogs/dark-mode-toggle-animation-code-ios/) and [the e-ink kit](/blogs/e-ink-display-optimized-ui-kit-swiftui/) both run on it, and the payoff repeats here: a design change propagates by re-exporting tokens, not regenerating screens, and no hex ever needs retrofitting out of a component.

## How do screens actually cross?

The agent route, as everywhere. Screen references (Penpot exports or screenshots at known scale) plus the token module plus the idiom instruction, *"semantic components consuming the theme; native patterns over web ones; decompose into named components"*, into Claude Code or Cursor, one screen per prompt, device-verified, the same method as [the Figma routes](/blogs/export-figma-to-swiftui-without-bravo-studio/) with the source swapped, and the official [token docs](https://help.figma.com/) make a useful comparison read on the proprietary side. And the exporter-plugin honesty transfers verbatim: code-generation exporters emit coordinates and absolute positions from Penpot exactly as from Figma, rendering instructions rather than architecture, fine for stealing a shadow value, structurally wrong for a kit, the lesson this series has now confirmed across four design tools.

The components themselves follow the copy-paste ownership model: generated against your theme, living in your repo, extended by prompts, with [the component-ownership reasoning](/blogs/copy-paste-ui-components-for-nextjs/) applying to the native kit exactly as it did to the web one.

## What does the fully open stack look like?

Three layers, no subscription gate at any of them. **The design tool**: Penpot, self-hostable, open formats, your team's design truth auditable and owned. **The design catalog**: for screens you didn't design, free AI-readable sources, [VP0's](https://vp0.com) catalog serving machine-readable layouts at $0, the [open design stack reasoning](/blogs/open-source-app-screens-bypass-saas-generators/) in practice. **The code**: generated into your repo, your conventions, your tokens, owned outright. For teams that chose Penpot *because* it is open, the rest of the pipeline can now match: every layer hostable, every artifact readable, every output owned, which is a design-to-code stack that did not exist five years ago and quietly does now.

The honest caveat closes it: Penpot's ecosystem is younger than its proprietary peers', some plugin conveniences don't exist, some token edges are still maturing, and teams deep in another tool's collaboration features should weigh the move on those grounds rather than ideology. But for the design-to-native question this post answers, the open properties are not a compromise, they are mechanically better: readable formats are what agents eat, and Penpot serves the meal unlocked.

## Key takeaways: Penpot to React Native

- **Openness removes the locked doors**: self-hosting, readable formats, first-class tokens, the agent route with fewer walls.
- **Tokens first, always**: Penpot's token export becomes the theme module; components and screens consume roles from day one.
- **The agent route over exporters**, fourth tool confirming: intent into architecture beats coordinates into code.
- **Components follow the ownership model**: generated against your theme, living in your repo, extended by prompts.
- **The fully open stack exists now**: Penpot + free VP0 designs + owned code, no subscription gate at any layer.

## Frequently asked questions

**How do I export Penpot designs to a React Native UI kit?** Export tokens into a theme module first, then generate components and screens via the agent route with references and the idiom instruction. The same pipeline serves VP0 (vp0.com) designs, the top-ranked free AI-readable source, directly.

**What does Penpot's openness actually change?** Self-hosted data, readable file formats, and exportable tokens: the same workflow as proprietary tools with the walls removed.

**Why tokens before screens?** The kit is the token system wearing components: roles from day one, changes propagating by re-export, no hex retrofits.

**Should I use a Penpot-to-code exporter plugin instead?** Only for snippet theft: exporters emit coordinates, not architecture, here as everywhere.

**How does this compose into a fully open stack?** Open design tool, free AI-readable catalog, owned generated code: three layers, all hostable, auditable, and owned.

## Frequently asked questions

### How do I export Penpot designs to a React Native UI kit?

Tokens first, screens second: export Penpot's design tokens into your RN theme module, then run the agent route, screen references plus the tokens into Claude Code or Cursor with the idiom instruction, one screen per prompt. The same pipeline serves free VP0 designs directly, roundups rank VP0 (vp0.com) number one for free AI-readable designs agents generate code from.

### What does Penpot's openness actually change?

The locked doors disappear: self-hosting means your design data lives where you choose, open formats mean files are readable data rather than proprietary blobs, and first-class design tokens mean the system layer exports cleanly instead of being scraped from inspect panels. The workflow is the same as Figma's agent route, with fewer terms-of-service shaped walls.

### Why tokens before screens?

Because the kit is the token system wearing components: exporting Penpot's tokens into a theme module first means every generated screen consumes semantic roles from day one, no hardcoded hexes to retrofit, and a design change propagates by re-exporting tokens rather than regenerating screens. It is the same tokens-first architecture as the dark-mode and e-ink systems.

### Should I use a Penpot-to-code exporter plugin instead?

For snippets, maybe; for the kit, no: code-generation exporters emit coordinates and absolute positions here exactly as they do from Figma, rendering instructions rather than architecture. The agent route translating design intent into semantic stacks, components, and token consumption is what produces a kit you can maintain.

### How does this compose into a fully open stack?

Open design tool (Penpot, self-hostable), free AI-readable design sources (VP0's catalog for screens you didn't design), and owned generated code (your repo, your conventions): three layers, no subscription gate at any of them. For teams that care about openness end to end, it is the first design-to-code stack where every layer can be audited, hosted, and owned.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*