Delacour UI vs HeroUI

The difference is where the code lives.

HeroUI Native and HeroUI Pro are good libraries built on the same stack as this one — Tailwind v4 through Uniwind, Reanimated, the Gesture API. They install into node_modules. Delacour UI writes the component's source into your repository, under your import alias, on your branch — the shadcn model, for React Native. Everything below follows from that one difference.

HeroUI Native, and HeroUI Pro

node_modules/heroui-native/lib/button

Resolved from the registry, or downloaded from a CDN against a licence. Read-only in practice: you configure around it, wrap it, or fork the whole repository.

Delacour UI

app/components/ui/button.tsx

Written by delacour add, MIT, committed by you. Open it and change it. delacour diff will tell you what moved upstream and will never overwrite your work to do it.

The main point

Adding one variant, both ways.

Not a contrived example — a brand colour on a button is the first thing every design system asks for that the library it started from did not ship.

With a package

// node_modules/heroui-native/button — not yours to edit.// A new variant is a wrapper, and the type union// never learns about it.import { Button } from "heroui-native/button";import type { ButtonProps } from "heroui-native/button";export function BrandButton(props: ButtonProps) {  const className = cn("bg-brand", props.className);  return <Button {...props} className={className} />;}// Every call site says <BrandButton>, forever — and// the next release can change Button's internals// underneath this without telling you.

With the source in your repository

// app/components/ui/button.variants.ts — the file// delacour add wrote. A new variant is a line in an// object you own.variant: {  primary: {    root: "bg-primary",    label: "text-primary-foreground",  },  brand: {    root: "bg-brand",    label: "text-brand-foreground",  },},// <Button variant="brand"> typechecks, because the// union is derived from this object at build time.// Nothing wraps anything.

HeroUI's own contributing guide is explicit about which side of that line a consumer is on — only the core team adds components, and behaviour is not changed without prior discussion, because the library is drawn from a design system its team maintains. That is a reasonable way to run a library. It is a bad fit for a product whose design outgrows the defaults, which is every product eventually.

Side by side

Every row, including the ones we lose.

Three products: this library, HeroUI's free React Native library, and HeroUI Pro's licensed one. Every mark carries the note that says what it means — a tick with no explanation is a claim you cannot check.

Where the code lives

This is the whole difference, and everything else on this page follows from it. Delacour UI's CLI writes a component's source into your repository, under your import alias, on your branch. Both HeroUI libraries resolve out of node_modules.

Component source in your repository

Yes

Delacour UI

delacour add button writes app/components/ui/button.tsx

No

HeroUI Native

node_modules/heroui-native

No

HeroUI Pro

node_modules/heroui-native-pro, fetched from a CDN

Change a variant by editing the file

Yes

Delacour UI

it is your file — open it and change it

No

HeroUI Native

wrap it, override classes, or fork the repository

No

HeroUI Pro

the terms forbid modifying components for redistribution

Your edits survive an upgrade

Yes

Delacour UI

delacour diff prints both sides and picks no winner

No

HeroUI Native

npm update replaces the package wholesale

No

HeroUI Pro

the CLI re-downloads the licensed build

Add a component the library does not have

Yes

Delacour UI

it is a folder beside the others, in your own style

Partly

HeroUI Native

beside the library, not inside it — only the core team adds components

Partly

HeroUI Pro

beside the library, not inside it

Delete what you do not use

Yes

Delacour UI

you only ever added the components you asked for

Partly

HeroUI Native

subpath imports keep the rest out of the bundle, not out of the tree

Partly

HeroUI Pro

subpath imports keep the rest out of the bundle, not out of the tree

Installs with no account, no login, no token

Yes

Delacour UI

a public registry and a public npm package

Yes

HeroUI Native

npm install heroui-native

No

HeroUI Pro

heroui-pro login, and HEROUI_AUTH_TOKEN in CI

You can publish the source you shipped

Yes

Delacour UI

MIT — the copy in your repository is yours

Yes

HeroUI Native

Apache-2.0

No

HeroUI Pro

sharing, publishing or sub-licensing the source is prohibited

Priced per developer

No

Delacour UI

free, and there is no paid tier to graduate to

No

HeroUI Native

free

Yes

HeroUI Pro

perpetual seats, one year of updates, renewals optional

The stack is the same

Both libraries style with Tailwind v4 through Uniwind, animate with Reanimated and read gestures through the Gesture API. Nothing above turns on one of them having picked better tools.

Tailwind v4 className styling, via Uniwind

Yes

Delacour UI

className on every component

Yes

HeroUI Native

className on every component

Yes

HeroUI Pro

className on every component

Reanimated and the Gesture API

Yes

Delacour UI

declared as peers, never dependencies

Yes

HeroUI Native

declared as peers, with pinned ranges

Yes

HeroUI Pro

peer detection is part of the install

Granular subpath imports

Yes

Delacour UI

@delacour/react-native-ui/button — no package-wide barrel

Yes

HeroUI Native

heroui-native/button

Yes

HeroUI Pro

heroui-native-pro subpaths

A provider at the root of the app

Yes

Delacour UI

DelacourProvider

Yes

HeroUI Native

HeroUINativeProvider

Yes

HeroUI Pro

HeroUINativeProvider

iOS and Android, Expo or bare

Yes

Delacour UI

pinned to the versions Expo SDK 57 bundles

Yes

HeroUI Native

peer ranges, checked by the install

Yes

HeroUI Pro

peer ranges, checked by the install

Theming and design tokens

Delacour UI paints from shadcn's palette, name for name, so the theme a web team already maintains is the mobile theme after one command. HeroUI ships its own token vocabulary and, on Pro, a hosted builder for it.

Token names match shadcn's

Yes

Delacour UI

--primary, --muted-foreground, --radius — every one of them

No

HeroUI Native

its own token vocabulary

No

HeroUI Pro

its own token vocabulary

Bring a web app's globals.css across

Yes

Delacour UI

delacour theme takes a path, a URL or stdin

No

HeroUI Native

no import path from a shadcn or tweakcn theme

No

HeroUI Pro

themes are authored in HeroUI's own dashboard

A visual theme builder

Yes

Delacour UI

/theme — server-rendered, every state a URL, no account

No

HeroUI Native

edit the theme by hand

Yes

HeroUI Pro

a hosted dashboard, behind the licence

The theme file is yours to hand-edit

Yes

Delacour UI

theme.css sits in your repository from delacour init

Yes

HeroUI Native

your own CSS overrides the package's

Yes

HeroUI Pro

your own CSS overrides the package's

Where HeroUI is ahead

Three of these are structural and are not going to change: HeroUI covers the web, it is the work of a company rather than one maintainer, and Pro sells finished screens. If any of them is what you are buying, buy it.

React components for the web

No

Delacour UI

React Native only — the web story is the shared palette

Yes

HeroUI Native

the HeroUI React library, Apache-2.0

Yes

HeroUI Pro

the Pro React library too

One design system across web and native

Partly

Delacour UI

the tokens cross over; the components do not

Yes

HeroUI Native

a similar API on both

Yes

HeroUI Pro

sold as one system in the Super Hero tier

Prebuilt screens, blocks and templates

No

Delacour UI

components, and a playground that demonstrates them

No

HeroUI Native

components

Yes

HeroUI Pro

templates and blocks are most of what the licence buys

Maintained by a company, with paid support

No

Delacour UI

one maintainer, GitHub issues

Partly

HeroUI Native

NextUI Inc., community support

Yes

HeroUI Pro

private Discord and prioritised support

Past its first stable release

No

Delacour UI

0.1.0-alpha — the API still moves

Yes

HeroUI Native

1.x, with NextUI's history behind it

Yes

HeroUI Pro

1.x

A Figma design system behind the components

No

Delacour UI

the code is the design system

Yes

HeroUI Native

the core team designs in Figma first

Yes

HeroUI Pro

design system files ship with every tier

Not a lock-in

The npm package is right there.

If your team would rather take updates than own files, install the package and skip the CLI entirely. It is the same source — the registry serves the library's own files rather than a copy of them — so the two can never drift.

You can also start on the package and move later. Run delacour add button in a project that already installs @delacour/react-native-ui, delete the package import, and point at the new path. Nothing about the component changes on the way across.

Copy the source in

bunx delacour@alpha add button

Or install the package

bun add @delacour/react-native-ui@alpha
How the CLI works →

The case

Why you would pick Delacour UI.

For a React Native product that will outlive its first design, this is the trade almost every team eventually wants: the components are yours from the first commit, and nothing about that costs you the updates.

The exception is real and it is narrow: if you need React components for the web from the same system, or you are buying finished screens rather than components, HeroUI is the better purchase — and the table above says so in its own words.

Sources

Read from HeroUI's own documentation and terms. Prices are deliberately not quoted here: HeroUI publishes its tier names and its licence model but not the amounts, so the pricing page is the only honest citation. If something below has changed, open an issue and this page gets corrected.